1. Get a second computer with the same operating system version which didn’t have a 3G modem installed (for example if your target system is running Windows 7 64 bit you need a second system with Windows 7 64 bit – different skews like Home vs Ultimate are ok, but the version and "bitness" must coincide – you could also try using a virtual machine for the second machine which supports USB forwarding like VirtualBox or VMWare)
2. Plug in the modem in the second machine. First it will recognize it as an USB stick / CD-ROM. Copy all the files from it to a separate folder (you should see files like "setup.exe").
3. Let the setup complete. Now copy the installed drivers to the same place you’ve saved setup file. Under Windows 7 you would find them in the location C:WindowsSystem32DriverStoreFileRepository in several folders starting with "gth" (like gthsubus_64.inf_amd64_neutral_4810563f34b37ef5), but here is the generic way to identify the folder:
   1. Start Device Manager
   2. Look for one of the devices associated with the modem (you will find actually several, like GlobeTrotter GI515M – Modem Interface, Network Interface and so on)
   3. Properties -> Driver -> Driver Details. Note the name of the driver for which the provider is Option (for example gtuhsser.sys)
   4. Now search your Windows folder for files ending in .inf which contain the name of driver from the previous step. This will point you to the right folders
4. On the first computer (the one you actually want to install the modem on) remove all previous versions of the software using the Add-Remove Programs facility (you will see two-three entries but they can be easily identified by the same orange icon). Restart the computer for good measure.
5. Copy over the setup program and the drivers from the second computer. Plug in the modem to the first computer, install the application (using the setup file captured on the second computer). Go into the device manager and look for "Unknown device"s (you should see four of them). Use the drivers captured on the second computer to resolve these issues.
6. Unplug and replug the modem – it now should work!

A couple more talking points:

• don’t use "driver manager" type software – they very rarely (read: never) seem to work
• a symptom that you’ve hit this problem is when the management interface (dialer / "Internet Everywhere") for the modem starts but it gets stuck in the "Initializing" phase when you connect the modem and consumes CPU (from what I’ve seen with a debugger it seems to be looking for the installed device in a loop)
• the modem seems to be prone to overheating if the signal-strength is low (around two bars) and in this case it shuts down after ~10 minutes (I assume that this is some kind of thermal protection). You can check if this is the case by putting your hand on the bottom side of the modem. I couldn’t find and solution for this, other than looking for a spot which has better signal. Using the modem in EDGE rather than 3G mode also seems to do the trick, but it has lower speeds and I don’t know of any reliable method to make the modem use EDGE if 3G is also available.

1. Remove the HWADDR line from /etc/sysconfig/network-scripts/ifcfg/eth0
2. Delete the file /etc/udev/rules.d/70-persistent-net.rules (hat tip)

These two steps are specific to CentOS 6 (on 5.x the first step is sufficient). Also, the second if is recreated at the next boot, thus after rm-ing it, you should shut down the machine and package it (not start it again, or if you do, you should remove the file again).

ADSL Modem+Router (no wireless) –-> laptop broadcasting over writess –-> ... –-> other laptops

The solution is the following:

• Set up an ad-hoc network on laptop wifi card (using a different subnet – 10.0.0.0/24 for example)
• “Connect” to it to make it work:
• Enable IP forwarding on the machine from the registry

It is simple as 1-2-3 :-p. Some caveats though:

• This setup won’t give you DHCP. So make sure that you configure your other machines with a static IP address
• It also won’t give you DNS, so configure something like the Google DNS (8.8.8.8 or 8.8.4.4) or OpenDNS (208.67.222.222 or 208.67.220.220) or even your ISPs DNS
• The ad-hoc wifi connection has reliability issues. It happened multiple times that I had to restart it because it disconnected and wouldn’t connect any more, but it is a good temporary solution.

PS. You can download the drivers and user manual for the SmartAX MT882 ADSL Router here (the link might go dead unexpectedly, since it is served out of Dropbox). This is a standard modem provided by Romtelecom (the Romanian telecom provider) and I couldn’t find it elsewhere because Huawei is very secretive about its stuff (the files were copied from the CD provided with the modem). The driver makes the USB connection work as a network card (which is very elegant and simple).

Some time ago I (wow, time files!) I suggested that using 0.0.0.0 for host-file based blocklists would be faster than using 127.0.0.1. Above you can see an other reason for using 0.0.0.0: some applications take up port 80 on the localhost and accessing it can (potentially) create havoc.

In the example above TeamViewer (which is quite a nice remote control application BTW – with support for Linux!) has taken it over and thus it displays a mock page instead of the advertisement (which is very courteous).

PS. This was also mentioned in the original article, I just wanted to give an other example.

To do this, start your java program with the following jvm paramters:

-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=23334

The meaning of the parameters is as follows:

• server=y – this application will act as a TCP/IP server (“acceptor”) and wait for incoming connections rather than trying to connect to you
• suspend=n – the server will not suspend on startup (alternatively you can set it to “y” in which case it will pause and wait for the debugger to connect – useful if you need to debug issues occurring at startup)
• address=23334 – the port on which the debugger will listen. Keep in mind that only one program can listen on a given port on a machine and if the given port is not available, the given program will not start

After the program has started open your Eclipse, go to Debug configrations, Remote Java application, create a new entry and set “Host” to the machine name or IP and “Port” to 23334 (or whatever other port you’ve set up). Connect to it and off you go. The configuration steps for IntelliJ can be found here (I didn’t check it, but they seem right). A couple of final thoughts:

• If your sources are not in sync with the remote jars, you will see weird stuff (like breakpoints not triggering, triggering and the “wrong” line, etc), so you should make sure that you have the same sources as the jar does. If you still get into the situation where the sources are different from the classfiles, I found that setting breakpoints on “method entry” works as expected (ie. it breaks even if the method in the classfile is on a different line)
• You can “detach” from a certain process and it keeps running (and later on you can re-attach to it)
• This method is of low bandwidth / overhead, so it can be used to debug servers in remote locations
• Never, ever do this in production! unless you are absolutely, 100% certain that you know what you are doing.

use Net::TcpDumpLog;
use NetPacket::Ethernet;
use NetPacket::IP;
use NetPacket::TCP;
use strict;
use warnings;

my $log = Net::TcpDumpLog->new(); 
$log->read("foo.pcap");

foreach my $index ($log->indexes) { 
  my ($length_orig, $length_incl, $drops, $secs, $msecs) = $log->header($index); 
  my $data = $log->data($index);
  
  my $eth_obj = NetPacket::Ethernet->decode($data);    
  next unless $eth_obj->{type} == NetPacket::Ethernet::ETH_TYPE_IP;

  my $ip_obj = NetPacket::IP->decode($eth_obj->{data});
  next unless $ip_obj->{proto} == NetPacket::IP::IP_PROTO_TCP;

  my $tcp_obj = NetPacket::TCP->decode($ip_obj->{data});
  my ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime($secs + $msecs/1000);
  print sprintf("%02d-%02d %02d:%02d:%02d.%d", 
    $mon, $mday, $hour, $min, $sec, $msecs), 
    " ", $eth_obj->{src_mac}, " -> ", 
    $eth_obj->{dest_mac}, "n";    
  print "t", $ip_obj->{src_ip}, ":", $tcp_obj->{src_port}, 
    " -> ", 
    $ip_obj->{dest_ip}, ":", $tcp_obj->{dest_port}, "n";
}

The code does the following: it opens the pcap file named “foo.pcap”, iterates over all the packets (it assumes that they all are Ethernet packets) and looks for TCP packets. Finally it prints out some information about these packets (capture time, source/destination mac, source/destination ip:port). You can customize it to fit your needs.

Small, somewhat offtopic rant: one should always think at least twice before publishing code which does such elementary things. Find a library and use it. If it doesn’t work, try patching it so that it works and send back the code to the original author. Only if this fails should you start from scratch.

Reusing existing code has many advantages: from your point of view, you can be sure that you can get code which worked for a couple of people. This is especially true for Perl modules which have a strong culture of testing. Also, even these “simple” problems like parsing a TCP packet have many corner cases which you will almost certainly miss at the first go, and as a result, half of your time will be spent hunting them down and only half of your time will be dedicated to solving the actual problem (this is if you are lucky – if you are unlucky, your code will skip over the special cases and it may make your entire analysis irrelevant).

Looking at it from the other side we have: more concentration of the way to do “X” means that the code will be more tested, leading it to be used more, meaning that it will be better tested and thus creating a positive feedback loop. Also, if you believe in the open-source ethos (and supposedly you do, since you published your code in the first place), you should consider maximizing the return while minimizing the effort needed.

Picture taken from greyloch’s photostream with permission.

Update: updated NetPacket link – thank you Anonymous.

After validating that the MD5 sum for the downloaded file matches the one specified on the website, I first opened it up in NetworkMiner (http://networkminer.sourceforge.net/). I find the overview it gives much easier to understand than the statistics provided by Wireshark. Using it I identified the data stream between Ann’s computer and the unidentified laptop.

1. What is the name of Ann’s IM buddy?
Sec558user1 – this is tricky because the IM (which seems to be AOL – but many other IM’s behave in a similar fashion) routes chat traffic trough central servers (64.12.24.50 in this case – which belongs to AOL, making it even more probable that AIM was used) to make NAT traversal a non-issue, while file transfers are done trough direct connection to conserve bandwidth.

2. What was the first comment in the captured IM conversation?
Here’s the secret recipe… I just downloaded it from the file server. Just copy to a thumb drive and you’re good to go >:-)
(actually, > is escaped as HTML – ie >)

3. What is the name of the file Ann transferred?
recipe.docx

4. What is the magic number of the file you want to extract (first four bytes)?
50 4B 03 04 – Which corresponds to PK…, signaling that we are potentially dealing with a ZIP archive here. This is further reinforced by the filename (.docx, which is the new "open" document format from Microsoft – basically, it consists out of a zipped XML – similarly to the OpenOffice.org format)

5. What was the MD5sum of the file?
8350582774e1d4dbe1d61d64c89e0ea1

This is again tricky, because ZIP (like many other formats) admit arbitrary data after the logical end of the file. So, using a hex editor, we first carve the the part starting at PK in the 192.168.1.158 -> 192.168.1.159 (be careful not to include the traffic in the reverse direction). Then we need to convince ourselves that the end of the file has been correctly identified at the byte level. To do this we could study the ZIP specification (http://www.pkware.com/index.php?option=com_content&task=view&id=64&Itemid=107) or use a more empirical level: using a hex editor (HxD for example – http://mh-nexus.de/en/hxd/) eliminate the last byte of the file and "test" the integrity of the file (using the Test option from 7-zip for example – http://www.7-zip.org/ – but one could use almost any de-archiving program, since almost all of them offer a "Test" option). The test will fail. Now add back the last byte (which is 0x00) and perform the test again. It will succeeded. This means with a big probability that we correctly identified the actual (logical) end of the file.

6. What is the secret recipe?
The most recent version of OpenOffice.org (3.1.x) can open the docx format, so the following can be retrieved on any platform, regardless of whether MS Office 2007 is installed (an alternative solution would be to use the free MS Word 2007 viewer or the import filters available for older versions of MS Office).

The contents (sans the formatting):
Recipe for Disaster:
1 serving
Ingredients:
4 cups sugar
2 cups water
In a medium saucepan, bring the water to a boil. Add sugar. Stir gently over low heat until sugar is fully dissolved. Remove  the  saucepan from heat.  Allow to cool completely. Pour into gas tank. Repeat as necessary.

Sorry for being a little late: the T2’09 challenge just started. Via the F-Secure weblog. Don’t be fooled by the fact that page already contains two entries (“Mr. Speed” and “Mr. Style”) in the top. From what I understand, these are to signal that two winners will be selected, one for speed and one for style.

The page also contains entries from past years for you to play with.

A small Windows tip: if your computer is part of a domain and all of the sudden you can’t access resources over the network (like shares, printers, etc), try changing your password.

I observed this in several networks, and although I’m not entirely sure about the reason – I suspect that it has something to do with the password expiration policy (even though the password seem to work when logging into the given system – even after a cold boot) – this workaround always seemed to work.

Update: Here is the discussion on serverfault about the problem. There were some good suggestions by Nico, but unfortunately no final solution was found as of now.

Picture taken from gemsling’s photostream with permission.