Bypassing Root Detection in Three InTouch

Three recently released “InTouch”, an application for Android and iOS that allows you to use a WiFi network to send/receive phone calls and text messages, meaning that you can continue to use your phone as a phone without having a cellular network connection.

Unfortunately for me, Three decided not to allow rooted devices to use the application – launching the app on a rooted device resulted in a “It seems that the device is rooted. This application can not run on rooted device” error.



Not wanting to miss out on being able to use their application (my house is a signal deadzone), and being unwilling to un-root my phone, I decided to explore other avenues.

Firstly, I downloaded the APK file from my phone using adb:

adb pull /data/app/com.hutchison3g.threeintouch-1.apk

I then decompiled the application into Smali using apktool, by running the following command:

apktool d com.hutchison3g.threeintouch-1.apk

This created a new folder with the same name as the APK file. Inside that folder was another folder called “smali’, which contains the smali disassembly of the APK.

A simple grep for the string “root” was all that was needed to find the sections of the disassembly responsible for root detection:

The relevant lines were those containing “device is rooted” – in this case, “v.smali” and “FgVoIP.smali”. Opening up FgVoIP.smali and searching for the line containing the word “root” gave me some context:

Screen Shot 2014-10-16 at 15.21.09

Line 4193 is an if statement, checking if the register v0 is equal to zero. The value of v0 is return value of the method invoked on line 4189. In the case that v0 is equal to zero, execution jumps to whatever is at the label :cond_2 – if v0 is anything other than 0, then a string mentioning “device is rooted” is defined, and passed to another method. With that in mind, it’s fair to say that a() in the FgVoIP class is probably their “root checking” method.

An easy way to patch this root detection out is to modify the if statement on 4193 to make it unconditional. I did this by replacing “if-eqz v0, :cond_2” with “goto :cond_2”:

Screen Shot 2014-10-16 at 15.27.21

I then repeated a similar process on “v.smali”.

Once I had modified the two smali files to skip the root detection, I needed to re-compile the apk file so that I could install it on my device. I accomplished this by running:

apktool b com.hutchison3g.threeintouch-1 -o com.hutchison3g.threeintouch-1-patched.apk

However, the resultant APK was un-signed. In order to install the APK onto my device, I needed to generate a key and sign the APK. I did this by following the instructions for “Signing Your App Manually” on the Android SDK documentation.

Once I had signed my app, I was able to install it by running “adb install com.hutchison3g.threeintouch-1-patched.apk”. I was then able to launch and use the Three InTouch app without any problems.



It’s worth noting that I did this as a learning exercise, and don’t recommend that you necessarily go out there and do this yourself. Similar techniques can be used to bypass root detection in many Android Applications.


eBay Reflected XSS

Earlier in the year, I discovered an XSS vulnerability in the Selling Manager section of the eBay.

The problem was caused by improper escaping of the URL’s GET parameters, which were reflected back on on the page. When choosing the “drafts” section of the session manager, I noticed that several parameters appeared in the URL:

eBay XSS URL parameters


Naturally (after confirming that eBay allowed such testing), I tried modifying these parameters – to my surprise, the page happily showed my new, update values (although they weren’t saved server-wide). I could modify my feedback score, message count, inventory counts etc to contain invalid characters, such as letters. Unfortunately, eBay was escaping the strings to remove anything that would allow cross-site scripting – or so I thought.

After some more playing, I accidentally included a URL parameter twice. Again, to my surprise, the page showed both values, but separated by commas – however, this time the second value was not being escaped. By setting the duplicate parameters value to be a snippet of javascript, I could run malicious code in the context of

Combined with a phishing attack, an attacker could easily exploit this vulnerability to steal money from a user, gain access to their account and/or cause all kinds of trouble.

I reported this vulnerability to the “eBay inc Bug Bounty” on the 30th of May, and after some prodding, received an email back telling me that the eBay Inc bug bounty didn’t cover the eBay website. The problem then got forwarded on other eBay Bug Bounty . Fast forward to mid-July, I was asked for an example URL that would trigger the XSS (which I had included in my original report, but must have somehow got lost). I have not heard anything from eBay since, but the problem now seems to have been fixed.

Fixing “java.awt.HeadlessException” when launching an AVD

I’ve just bought a new laptop (Lenovo x230), and decided to go with a Debian Testing install. One of the problems I ran into was that I was unable to start an AVD (Android Virtual Device) using the GUI – the AVD manager would just crash, and I’d end up with a “java.awt.HeadlessException” exception printed to my console.

Google suggested that this was due to some incompatability between the AVD Manager and `openjdk-7-jre`, and that the fix was to remove `openjdk-7-jre` and replace it with `openjdk-6-jre`. I didn’t really want to have to do that, so came up with an alternative solution.

By downloading openjdk-6-jre, and modifying the ‘android’ bash script (located in android-sdk-linux/tools/android) by changing the line:




it becomes possible to use Java 7 by default, but run the AVD Manager under Java 6.

Introduction to virtualenv

Keeping track of  Python package dependencies can be a tricky task, especially when you’ve already got multiple packages installed and you’re not sure what your project is/isn’t using. Thankfully, a tool called virtualenv exists which helps keep track of your packages and lets you isolate installations.

Installing virtualenv is easy – it’s a Python script, and can be obtained by running pip install virtualenv.

Once virtualenv is installed, you can create your virtual environment by running virtualenv my_env_name. This will copy your system’s Python binary (you can specify a custom version by passing the --python=/path/to/your/desired/python flag), and install both pip and setuptools to the my_env_name folder. It also creates an activation script, which you can call by running source my_env_name/bin/activate. Activating your virtual environment will update your PATH to use the newly copied Python, as well as the new packages folder and pip install.

Now that your newly create virtual environment has been activated, any calls to Python, easy_install or pip will be passed to your newly created Python install. This means that pip will install packages to your virtual environment rather than to your system install, and that any system packages that you had previously installed are no longer accessible. A useful side-effect of running under a virtual environment is that both pip and easy_install no longer require special write privileges – you’ll no longer need sudo/root privileges to install packages.

Another handy use of virtualenv is to generate a list of requirements for your project – running pip freeze > requirements.txt will create a pip install -r compatible requirements.txt file for you, allowing you to easily distribute and keep track of project dependencies.

virtualenv can be de-activated by running deactivate from your shell, which restores your environment to its former self.

Quick and Dirty VPN Server with pptpd

I’ve recently found myself wanting to be able to quickly create a VPN server, with minimal client-side setup. Normally, my VPN Server of choice is OpenVPN, but this doesn’t really fill those criteria – server side, you’ve got to generate keyfiles, certificates, config files. This wouldn’t be so bad – but it’s a similar story client-side. If your grandma want’s a VPN connection, then having to send over OpenVPN installers, certificate files and configs isn’t ideal.

Most operating systems have built-in support for a VPN Protocol called “PPTP”, or Point-to-Point Tunneling Protocol, so I decided to investigate. It turns out that minimal effort is required to set up a PPTP server, and virtually NO effort is required on the client side. PPTP is supported by OS X, Windows, Android, iOS natively, and can clients are easily obtainable for Linux and various BSD distributions.

Before I go any further – I’d like to clarify that PPTP is NOT terribly secure. I wouldn’t use it for transferring any particularly sensitive information; I’m using it purely for convenience reasons. I’d recommend it for watching Netflix or Hulu from outside the US, but not for transferring mega secret nuclear launch-codes. Services exist that allow the cracking of MS-CHAPv2, the protocol that PPTP uses for encrypting communications.

OK, now that you know not to use PPTP/MS-CHAPv2 as a security measure, lets move on.

These instructions were tested on Debian 7.0 – but installation aside, should be valid for any distro.

Install PPTPD. This can be done via a simple apt-get install pptpd.

Open up /etc/pptpd.conf in your editor of choice. At the end of the file, add these lines:

localip x.x.x.x
remoteip y.y.y.y-z

where x.x.x.x is the external IP of your server, and remoteip y.y.y.y-z, where y.y.y.y is the first address in the range you wish to assign to your clients, and z is the last octet of the last address you wish to assign to clients. For instance, if I wanted client IPs to lie in the range, I’d enter remoteip You don’t need to do anything special to be able to assign these IPs, it’s all handled for you. Just make sure you use private address space, it’d be rude not to.

You should also append:


to the file, in order to specific the DNS servers you want your clients to use. You can, of course, substitute the with DNS servers of your choice.

Now that the pptpd is configured, we need to allow our server to forward IPv4 traffic. This can be done by editing /etc/sysctl.conf, and uncommenting the line that reads #net.ipv4.ip_forward=1. We then need to reload the sysctl.conf file – this can be done by running sudo sysctl -p.

We also need to configure iptables to perform NAT – this can be done by running iptables -A POSTROUTING -t nat -j SNAT --to-source z.z.z.z, where z.z.z.z is the external IP of your VPS. It’s worth noting that iptables rules aren’t persisted to disk – check out this article to see how to make them survive a reboot.

We’re almost set – all that’s left to do is to create a pptpd user. This is done by editing the file /etc/ppp/chap-secrets. Entries are stored in the form username service password ip – so if I wanted to add a user called bob, with the password bananna and the IP, I’d add the line:

bob pptpd bananna

(Bear in mind that passwords in /etc/ppp/chap-secrets are stored in plaintext.)

Your pptpd VPN server is now configured – all that’s left to do is to run /etc/init.d/pptpd restart to make the changes take effect.