Recently I acquired an HTC HD2 smartphone. It is running Android from NAND. To be specific, the HD2_NDT_MIUI_GINGER_STABLE_V2.2_MAGLDR rom found at XDA. It is known Android isn’t quite secure in terms of physical access. It is inevitable to loose ones mobile device. When that happens we should rest assured the information on that device is not accessible by others.

Approach

There are several ways to solve this problem. But I opted to use cryptsetup because 1) I’m familiar with it 2) transparency: an encrypted container accessible by normal apps 3) portability: the raw container can be opened on other Linux systems.

The first problem is cryptsetup is absent on a standard Android system. Thanks to this post I could get a hold of a binary(ideally one should compile their own). cryptsetup must be pushed to the Rooted device with e.g. adb push
I put mine in /sd-ext/bin which is an ext2 partition the sdcard together with crypt.sh (found lower in this post, inspired by this). The script by default creates a ~1.8GB container on the sdcard called crypt.raw and the mount point at /sdcard/crypt.

Usage

First the container must be initialized. This can be done within adb shell:

It will take a while depending on the container size.

After it’s done you can mount the container:

and unmount:

What if we’re away from a computer without access to adb? Simply use connectbot to open a local connection then escalate privileges using

From here on, we can unlock the container whenever we please and it is compatible with all other apps.

Conclusions

The approach described above uses cryptsetup, a widely deployed solution in the Linux world. It enables the user to store data securely and transparently. The container size limit (2GB) can be overcome by using ext2/3/4 instead of the default vfat on the “host” filesystem. Or use a dedicated partition for it.

While this article doesn’t dive deep into realizing a water tight system it illustrates one can take measures themselves to increase security. A pit fall of this solution is that one can forget to lock the container. A device without pattern or pin lock (I don’t trust it myself. Hell, at least it is something) cannot protect your data. It is also wise to turn off debugging mode otherwise an attacker can just hook up your phone on USB and then fire up adb which grants them root access to an unlocked container. Maybe I should write an article on securing Android

Several improvements can be made in the future:
- a GUI frontend to crypt.sh
- tight integration with the system: encrypt complete /sdcard and /data for instance
- use pin/pattern to unlock container

script: crypt.sh

No related posts.

The result is a simple bash script that fetches xml data from Google Weather API using curl. This data is then parsed using xmlscarlet and awk.

View the final script

No related posts.

Related posts:

1. Projects
2. Train Recurrent neural network using particle swarm optimizer

The fitness of a solution is determined by simulating a run and then calculate the traveled distance. Check the project site for all details and source codes.

No related posts.

The story began like this: I needed a hfs (Mac OS) to do some testing. I remember the first 3 partitions on my HDD functioned as test-subject during my Amsonia adventures. So I thought, why not merge these into one larger partition. In the beginning my HDD had this structure:

This structure is then altered using fdisk and resulted in this state:

So the process of freeing space was done beautifully. The data on my logical partitions remained intact as they should be. The next step would be of course connect the disc to the macbook and launch Disk Utility to create the partition and format it. I double checked it won’t touch the partitions by reviewing the options hidden in options. Everything seems fine, so let’s apply the changes…. and there comes the surprise: Disk utility failed to apply the changes and ejects the device.

Apparently Disk Utility did modify the partitiontable but failed to do it successfully. Here I am, my partitions inaccessible. A quick web-hunt resulted in trying out gpart. The process of scanning 500GB took around 10 hours to complete; the disc was connected over usb 2.0. Average readspeed was 16mb/s. When gpart was done scanning, it didn’t report anything useful. So the hunt continues till I stumbled against Recovering lost ext2 Linux filesystems. After reading the article I decided to give their hand-crafted utility a try. My article is written with the hope to add value to the information you’ve gathered. It should not be seen as a replacement!

After scanning the whole disc, Scandrive produces a ~2mb report. As the article indicates, lines of the following format might indicate partition start:

So, let’s filter out these interesting line with grep:

The key here is to find a pattern in the less cluttered data. With pattern I mean consecutive large groups having the same size. All found groups are potential partitions, the first block of the group minus two might be the start of a partition.

Once you’ve gathered the offsets and sorted by group size, you can start trying to recreate the partitiontable (preferably one by one) using sfdisk.

Back to my situation, after some trial and error attempts I found logical 1, but the size appears to be incorrect. Because the system could only read that partition partially (some directories could not be read). So I decided to calculate the maximum size of my HDD and use it as the right-boundary. This allowed me to recover all files on logical 1. When the copying process was done, the second partition can also be found and treated in the same way.

You can define the boundaries (your new partitiontable structure) in a text file like this:

Then write it to the disc using sfdisk:

If you think it is good, commit to disc:

Then try to mount the new partition. If mount bails out with an error, don’t panic, continue trying other potential starting offsets.

Notice the start offset is calculated this way, say you found this line:

The start offset should be: 432180492-2 = 432180490
You only have to do this for the first offset in a group!

The recovering adventure lasted 1.5 days with a happy ending. I’ve learned a lot during this process, I hope you find this information useful. Special thanks go to Steve Friedl’s Unixwiz.net Tech Tips.

No related posts.

Setup – The environment I tested consists of the following components:

1. A server, in my case a Debian Etch
2. A client, mac OS X Tiger on a macbook
3. X11 on OS X
4. freenx server-3.2.0-13 from No Machine
5. nxclient-3.2.0-9, there are other platforms.
6. A window manager on the server, I use e17 (see screenshot in the end)
7. In case you wonder, my connection is an Adsl 2+ with 14mbps down and 1mbps up.  Ping to the server under normal network load is 20ms.

Performance – “Wow”, that’s all I can say. The performance is just great! Compared to RDP, I think they are on the same level, or possibly better: the special effects (animations) in e17 worked flawlessly, the transitions were smooth. Flipping desktop had a little delay, not quite noticable though. During usage it uses approximately 20kb/s (kilobytes) of the pipe.

Security – You shouldn’t worry about security as NX traffics are tunneled through SSH by default, hence you only need to open port 22 on the server side.

QtNX – George Wright released a QT-based nxclient for OS X. This is an alternative of nxclient if you dislike the X11-aqua-like interface components.

Drawbacks – First is its X11 requirement, this means a lot of things; like no clip-board integration.  GDM (or any Desktop manager) doesn’t support NX (as of this writing). This can be worked around pretty easily with a wrapper (or I hope so). I’m considering to add it to my projects queue.

Experiments – In the future some hard-benchmarks can prove freenx’ competence. For now it has convinced me enough.

No related posts.