Category: Uncategorized

In a previous post I described how to use a Raspberry Pi as Wi-Fi access point and how to trace the data traffic of my smartphone in real time using tcpdump and netcat. The next logical step is of course to directly trace the network traffic on the smartphone. This has the big advantage that it's not only possible to trace the Wi-Fi traffic but also traffic that goes over the cellular interface. I've laid the foundations for this a couple of weeks ago by installing CyanogenMod on my Samsung Galaxy S4. Unfortunately, though, CyanogenMod does not include tcpdump in its standard image.

There are some sources on the net that provide pre-compiled tcpdump executables for Android but since these are not well known I had a hard time trusting them. Not that I think they are not trustworthy but I just don't know them at all. So I had to find a way to get a trusted executable. At first I thought that I could perhaps use a tcpdump executable from one of my Raspberry Pis as they also run on an ARM processor. That would have probably worked if the Raspberry Pi used static linking for it's executables, i.e. bundling all libraries required into the file which is required for Android. Raspian, like most other Linux distributions, I imagine, however, uses dynamic linking with the libraries in separate directories. O.k. so that was not an option.

After doing some more research I came across a 3 piece post over on the Symantec blog (see here, here and here) that explains in detail how to cross compile tcpdump for Android from the original sources on a Debian system. Fortunately I had something close to this, an Ubuntu 12.04 in a virtual machine on which I can easily try things without backing anything by creating a VM snapshot to which I could restore later-on to undo all changes. It turned out that cross-compiling the sources is not very difficult at all as only the original source and the gnu cross compiler. As I was using Ubuntu I had to install additional packages which is not described in the Symantec posts but the error messages are quite straight forward. Also, I had to set 'LDFLAGS=-static' in the tcpdump 'Makefile' as mentioned in the comments to the third part of Symantec's description.

And here's the command to trace the cellular interface once tcpdump is up and running on your Android phone and to save the traffic into a file on the SD card:

tcpdump -n -i rmnet_usb0 -s 65535 -w /storage/sdcard1/trace.pcap

Happy tracing on Android!

I don't mind some advertisement on websites as long as it's not obtrusive. Live and let live. On the desktop that line has long been crossed with major news websites looking more like a Las Vegas casinos than news websites. So I've been using Adblock Plus for many years there already and I'm always shocked when I switch it on and see how the unfiltered web 'really' looks like these days. On the mobile side, ads were somewhat more subtle on the web sites I frequent, at least until recently.

Within a short time, however, the three news websites I visit daily on my mobile have started to push ads into my face with full screen pop-ups or keep showing me the same stupid ad over and over again. Sorry, that's it, you've pushed me over the edge and I had to resort to countermeasures. Adblock Plus is available as well for Android but unless there is no alternative I don't want a proxy in the system.

The alternative is to make use of the 'hosts' file and block ad serving domain names. This requires root access to the device but that's not a problem on CyanogenMod. Also, I've already modified the hosts file to keep apps and the OS from frequently calling home so it was little effort to also include the domain names from which the ads come from.

Actually I'm a bit shocked at how many domains I had to block to get back my peace on three news websites. Here's the list of domains they include in their pages that have nothing to do with the main content:

#Ad blocking
127.0.0.1   ad8.adfarm1.adition.com
127.0.0.1   googleads.g.doubleclick.net
127.0.0.1   stats.g.doubleclick.net
127.0.0.1   mobile.smartadserver.com
127.0.0.1   www.google-analytics.com
127.0.0.1   pagead2.googlesyndication.com
127.0.0.1   ads.stickyadstv.com
127.0.0.1   pixel.rubiconproject.com
127.0.0.1   t1.visualrevenue.com
127.0.0.1   beacon.krxd.net
127.0.0.1   rtb.metrigo.com
127.0.0.1   c.metrigo.com
127.0.0.1   ad.zanox.com
127.0.0.1   cm.g.doubleclick.net
127.0.0.1   ib.adnxs.com
127.0.0.1   ih.adscale.de
127.0.0.1   ad.360yield.com
127.0.0.1   ssp-csynch.smartadserver.com
127.0.0.1   ad.yieldlab.net
127.0.0.1   dis.crieto.com
127.0.0.1   rtb.eanalyzer.de
127.0.0.1   connect.facebook.net
127.0.0.1   platform.twitter.com
127.0.0.1   b.scorecardresearch.com
127.0.0.1   sb.scorecardresearch.com
127.0.0.1   ads.newtentionassets.net
127.0.0.1   ak.sascdn.com
127.0.0.1   fastly.bench.cedexis.com
127.0.0.1   probes.cedexis.com
127.0.0.1   linkedin.com
127.0.0.1   x.ligatus.com
127.0.0.1   d.ligatus.com
127.0.0.1   a.visualrevenue.com
127.0.0.1   radar.cedexis.com
127.0.0.1   www.googletagservices.com
127.0.0.1   pubads.g.doubleclick.net
127.0.0.1   farm.plista.com
127.0.0.1   static.plista.com
127.0.0.1   video.plista.com
127.0.0.1   tag.yoc-adserver.com
127.0.0.1   ads.yahoo.com

Yes, that's from just three news portals. Quite shocking…

Knowing something in theory and experiencing something for real are two different things. I know of course that Android is based on a Linux kernel and shares many things with desktop Linux distributions. But it's all nicely hidden under the Android user interface so the concept felt quite abstract to me, even after using 'adb' for a long time and having experience with Debian running on ARM driven Raspberry Pis and all. But when I recently opened a terminal on the device itself and used the shell like I would use one on a PC with a hardware keyboard, auto command completion and on top of that write shell scripts with my favorite shell based text editor 'nano', e.g. to issue the commands to enable write access of the system partition and start the editor to modify the 'hosts' file, it started to feel quite different. Yes, there's really something under the hood I'm quite familiar with and it 'feels' very good indeed.

I'm quite surprised that pretty much the entire industry these days thinks that Wi-Fi Internet connectivity means that there is free, unlimited and ultra-fast connectivity. As a consequence many smartphones and tables are shamelessly downloading operating system updates and other things small and large without asking the user first.

A 150 MB Android update available!? No problem, there's Wi-Fi so it's downloaded by many devices without asking the user first. Now imagine you are hanging off a hotel Wi-Fi that is slow already or even paid by the megabyte. The former is still the norm rather than the exception while the later is rare these days but it still exists, which is why I would never stay in NH hotels if I can avoid it…

Even worse, you ask a friend in a café if you could tether your Wi-Fi only tablet over his phone to the Internet. He graciously agrees despite only having a contract that includes a few hundred megabytes of data a month. After all, a couple of web pages won't hurt!? Well, these probably won't but the 150 MB OS update starting automatically will. And unless you friend keeps his data counter in sight he probably never knows what hit him until a couple of days later when he hits his monthly data cap.

Therefore, think twice before you open your mobile network connectivity for anyone…

Fortunately CyanogenMod on my Samsung Galaxy S4 gives me root access so I've put the domain name of the update server in the hosts file and point it to localhost. This stops the madness and restores sanity so I will not be surprised by a bulk data download while I'm tethering or staying in a hotel.

Just a few weeks after I could use LTE for the first time while roaming in France I recently found myself in Belgium's capital for the weekend and could again benefit from LTE speeds while roaming. But how fast is it actually and is there a bottleneck on the link to the home network? The later is quite important as all data is tunneled to the PDN-Gatway in the home network and from there to the Internet. As you can see in the image on the left, Mobistar in Belgium and my home network operator have provisioned the link with ample capacity and I could reach speeds of 20 Mbit/s in the downlink direction and 14 Mbit/s in the uplink direction on LTE Band 20 (800 MHz) cell with a 10 MHz carrier in average signal conditions. Not too bad I would say. And the ping delay of 62 ms for a roaming scenario is great as well.

So there we go, somewhere along the way Android lost the radio network type (RAT) indicator over the signal bars when roaming. I wonder if that has something to do with Americans rarely leaving their country? Anyway, the important thing is that Android is open and flexible enough for someone to come up with an app to fix the issue. After looking around bit I chose the "Network Type Indicator" app and as it didn't want any suspicious rights I didn't hesitate to install it. It works as it should and my smartphone again feels as it should when I'm out of the country. It is even better than the original as I can now see the network type much easier when using the device for navigation in the car. Yes, I like to know what kind of network is around me when driving through the countryside…

I like having a good backup strategy and thus have a couple of Clonezilla images of my notebook's SSD. In case my notebook gets lost or stolen I can restore the image on a backup drive, overwrite the data partition with the latest weekly backup and put the result in another notebook and I'm up and running again in no time. The question I had, however, was how close the hardware of the replacement notebook must resemble that of the original hardware for Ubuntu to still be usable.

To find out just that I recently restored a Clonezilla image of the SSD of my PC to a backup drive and installed that in a 4 year old notebook with completely different CPU and graphics hardware and a 6 year Atom based notebook, again with a very different processor, GPU, screen, touchpad and Wi-Fi hardware. That can't possibly work now can it!? Wrong! My Ubuntu 12.04 installation booted and ran perfectly on both systems. Graphics worked, the touchpad worked, the Wi-Fi worked, suspend/resume worked, everything just worked, I could hardly believe it.

Now try that with a Windows installation…

While I've been using LTE since the very early days it has mostly been for Internet connectivity so far. When it came to the smartphone in my pocket I was downright conservative and only recently switched to a Samsung Galaxy S4 that comes with LTE. When making the switch I also decided that it was just the right opportunity to also do something about bloatware, crapware, vendor specific launchers and spyware by installing a vendor independent Android flavor.

There are many 'mod's' available these days and CyanogenMod is probably the most well known. So I decided to give it a go, and the pretty much automated installer CyanogenMod offers for a handful of devices made it a quick and hassle-free adventure. Download an app to the S4, download the installer to a Windows PC and let both run. With a few interactions and about half an hour later my S4 booted with a vanilla CyanogenMod Android 4.4.2 image.

The automatic CyanogenMod installer also downloaded and installed the Google Play store and while the device doesn't call 'home' as much to Google and others compared to vendor specific Android versions, there are still frequent interactions with mtalk and other Google services. But since CyanogenMod offers a built in root mode, that's easy to take care of by modifying the hosts file as I described here.

So here we go, my first smartphone with a custom firmware not from the manufacturer and not directly from Google either. A moment to savor, it's almost like in the PC world. But there's a price to pay as some features are missing or don't quite work as I would like them to. For example: When roaming, the status bar only displays an 'R' next to the reception quality bars and omits the network technology indicator. Also, I'm no longer able to disable GSM as I don't like to drop down to 2G for various reasons even if that means I am out of coverage every now and then. That's a small price to pay, however, as even many vendor supplied Android versions of devices with LTE don't allow locking to UMTS and LTE. Another thing that has also disappeared is the Wideband-AMR capability the original Android version activated in the baseband on startup. Together with not showing the radio technology while roaming I miss that the most.

Let's see, perhaps there's a way to get some of these things back. I'll keep you posted.

A few weeks ago the Truecrypt project spectacularly imploded and Steve Gibson over at GRC has a good summary of the event. Many people, including me, always liked the idea of Truecrypt being open source but were quite skeptical of the authors being anonymous. Now that they've abandoned their project and also don't want it to be continued by anyone else it's time to think about alternatives.

Initially I used Truecrypt because there was nothing else available on Windows XP. Then I used it's advantages in cross-platform compatibility to share a file container so I could use my Thunderbird email client on Windows and Linux depending on which machine I used at a time. But I've moved on and I no longer have Windows machines at home. So cross-platform compatibility is no longer necessary.

As a consequence, I've been on the lookout for other options and on Linux, dm-crypt looks like a good alternative. In Ubuntu, and likely also in other Linux distributions, dm-crypt is straight forward to use. When formatting a new hard drive or usb memory stick, Ubuntu's "Disk Utility" offers a simple way to encrypt a new volume with dm-crypt as shown in the image on the left. When the USB stick is later-on plugged-in again, the file manager automatically asks for the password. Perfect! Encrypting hard drives for backups works in a similar way. 

So when I recently ran out of space on my backup hard drives and had to buy new ones, I went for dm-crypt instead of Truecrypt. Call it a natural migration away from Truecrypt without much pain as my backup software doesn't care if and how a drive is encrypted. Also, it seems that not too far in the future, my 500 GB notbook SSD needs to get replaced with a 1 TB variant as those virtual machine images just keep growing. A good opportunity to ditch the Truecrypt container I use for especially sensitive data and replace it with a dm-crypt container file or partition.

Speaking of container files: It's also pretty much straight forward with a couple of commands to create and use dm-crypt encrypted container files. Here's a good overview in English and here's one in German.

There are various way to use Wireshark to trace anything from local traffic to Wi-Fi packets and even Bluetooth. Recently, I’ve added yet another variant to my bag of tricks: Tracing on a Wi-Fi Access point with forwarding of all captured data to my PC for online debugging. When everything is put together I can start tracing with a single command. Here’s how it works:

The access point is a Raspberry Pi with VPN backhaul that I’ve recently put together. The VPN backhaul isn’t needed for the tracing part at all but the solution presented below lets me trace on the local Wi-Fi interface, on the backhaul interface (Wi-Fi or Ethernet) and the VPN tunnel interface itself. On the local PC netcat (nc) and Wireshark have to be installed. To start remote tracing, the data sink on the local PC and the forwarding of all data it receives to Wireshark has to be started as follows:

sudo nc -l 9999 | wireshark -k -S -i -

This command starts netcat (nc), asks it to wait for an incoming connection on port 9999 and to forward the standard ports to Wireshark. On the access point, tracing is started with the following command via an SSH shell:

sudo tcpdump -n -i wlan0 -s 65535 -w - not port 9999 | nc 192.168.55.9 9999

Wlan0 is the interface to trace (use ifconfig to check which other interfaces are available as well) and ‘not port 9999’ excludes all forwarded traffic to the local PC to be included in the trace. All output of tcpdump is forwarded to netcat which in turn forwards all traffic to the local PC with IP address 192.168.55.9 via port 9999. And that’s it!

And here’s how to combine these two commands into a single command that is issued on the local PC:

ssh pi@192.168.55.1 'sudo tcpdump -n -i tun0 -s 65535 -w - not port 22' | wireshark -k -S -i -

This chain of commands establishes an ssh connection from the local PC to the access point (192.168.55.1) and launches tcpdump on the access point. Instead of netcat, the ssh connection is used to tunnel the data back to the local PC. This is why port 22 must not be recorded by tcpdump instead of port 9999 in the example above. When the data arrives on the local PC it is piped to Wireshark in the same way as shown above. Two things may need to be in place for this to work: As I’m tired of typing in passwords I’m using client certificates for the ssh connection as described here. And the second thing to put in place is that on the Wi-Fi Access Point Pi, sudo doesn’t ask for a password either. On Raspbian that’s the default but on other devices that might not be the case. Should that be a problem, passwords can be disabled in the ‘sudoers’ file for specific commands.