Sunday, 27 April 2014

Wickr account cloning vulnerability

USB backup attacks against Android applications

 Android allows users to make online backups of their application data. This happens silently based on settings created by the applications' developers ( According to the documentation, the data is held in "cloud storage" (the exact definition will vary based on the OEM), allowing users to restore their data when they get a new phone.

 But the backup function also allows users to make backups over USB using the "adb backup" command. This command will backup data from all applications that have not explicitly set the allowBackup flag to false in their manifest. The data that is retrieved is taken from the sandbox of the applications, in escence giving users access to the contents of their applications' sandboxes without being root. This is something that the shell user can not normally do. For an excellent writeup as to how to access, edit and restore data using adb backup by Nikolay Elenkov see here:

 As far as an attack vector it is often contrived and unrealistic. Essentially an attacker would need to have physical access to an unlocked phone. If they have this then they could do all manner of nasty things, like replace applications, install trojans or just ringing their premium rate phone line.

 For a number of applications however, the vector is more reasonable. The value of the assets is high and they can only be accessed from the sandbox. Below are three applications that can be compromised using the ADB backup restore functionality:

MyWicker (com.mywickr.wickr) - Beta
F-Secure Freedome VPN ( - 1.04
OpenVPN(net.openvpn.openvpn) - 1.1.12

OpenVPN / F-Secure Freedome VPN

Both the OpenVPN and F-Secure Freedome were found to allow backups over ADB

According to Android documentation:
Whether to allow the application to participate in the backup and restore infrastructure. If this attribute is set to false, no backup or restore of the application will ever be performed, even by a full-system backup that would otherwise cause all application data to be saved via adb. The default value of this attribute is true.

Performing a backup on the Freedome app we can see the following:

androidvm@androidvm:/tmp$ adb backup
Now unlock your device and confirm the backup operation.
androidvm@androidvm:/tmp$ dd if=backup.ab bs=1 skip=24| openssl zlib -d > backup.tar
8726+0 records in
8726+0 records out
8726 bytes (8.7 kB) copied, 0.0134311 s, 650 kB/s
androidvm@androidvm:/tmp$ tar -xaf backup.tar
androidvm@androidvm:/tmp$ cd apps/
androidvm@androidvm:/tmp/apps/$ ls -la
total 24
drwxrwxr-x 5 androidvm androidvm 4096 Jan 14 16:15 .
drwxrwxr-x 3 androidvm androidvm 4096 Jan 14 16:15 ..
drwxrwxr-x 2 androidvm androidvm 4096 Jan 14 16:15 f
-rw------- 1 androidvm androidvm 1506 Jan 14 16:15 _manifest
drwxrwxr-x 2 androidvm androidvm 4096 Jan 14 16:15 r
drwxrwxr-x 2 androidvm androidvm 4096 Jan 14 16:15 sp
androidvm@androidvm:/tmp/apps/$ ls f/
clp-beta-prov.client.crt  clp-beta-prov.client.key  clp-beta-prov.servers.conf  clp-ca-server.pem  pvpn.conf

We can see that there are a number of files available for us either to just read, or to alter and restore.

For Freedome, we are able to overwrite the configuration and key files used by the application. This would mean that every time the user then ran this application, they would connect to our malicious VPN. This would allow us to MITM the user's traffic.

The OpenVPN looked almost identical in terms of what we could access and change. This would give us access to their private VPN keys and configuration, letting us connect to the user's VPN. It would also allow us to overwrite the VPN settings as per Freedome and have them connect to our malicious VPN without them realising.


Wickr was found to also allow backups by not explicitly disabling it

MyWickr allows users to select the "remember me" option. If this is selected (the user must accept a warning), then they can log in to the app without entering their password. When they choose this option, two extra files are created in the sandbox (pcc.wic and pcd.wic). These can be accessed using the ADB backup.

androidvm@androidvm:/tmp/com.mywickr.wickr$ ls
db  f  _manifest  r  sp
androidvm@androidvm:/tmp/com.mywickr.wickr$ ls f/
icu  magic.mgc  pcc.wic  pcd.wic

This would allow an attacker to clone an account by performing and ADB backup on the victim device and then an ADB restore on to a different device. A safe guard against this is that Wickr's functionality relies on the Android device ID for decryption. Unfortunately, Wickr store the device ID when the app is first run in a shared preferences file. As this is copied as part of the backup, the security control doesn't work.

It is therefore possible for an attacker to clone a Wickr account on to a different device using the ADB backup/restore functionality. Below is a video demo-ing a wickr account on the device to the left being cloned on to a device on the right.


Communication with Wickr

19-01-2014 - Emailed Wickr with details of vulnerability
12-02-2014 - Wickr replied accepting issue as a valid vulnerability
15-04-2014 - Wickr permitted vulnerability to be disclosed

Friday, 24 January 2014

Is your phone here? Then own that too

So an interesting post has been made by Symantec regarding a piece of Windows malware. Nothing unusual in that, except it has a quick poke at ADB

ADB (the Android Debug Bridge) is used mainly by Android application developers to unlock extra features on their Android phone and allows them to more easily sideload and monitor applications.

Enabling this feature is not trivial. On a modern phone you need to display the initially hidden settings menu, select to enable ADB, accept the warning, plug in the phone via USB, accept the PC's RSA certificate, install adb on the PC and finally run adb from the command line.

This surely represents a very small group of people. But the malware takes a poke anyway...

According to Symantec, it installs adb and then tries to run "adb.exe install AV-cdk.apk", a malicious app designed to attack Korean bank users. It would require the user to have their Android phone with ADB enabled, plugged in to the PC via USB. This raises a number of interesting options:
 1. If the malware is doing other things, then this is perhaps just a stab in the dark that might affect 1 in a million.
 2. The malware is targeting a very niche group of people: developers

Tuesday, 10 December 2013

Android to Arduino: the code

In a follow up to the Android to Arduino post, here's the code used. The code currently takes a command from an Android app (a button press), and sends a value to the Arduino over serial. In the mean time the arduino is sending a "nop" string back to the app every second. Not much, but enough to prove input & output over serial.
Video of it working here
Arduino code:

 #include  String inData;
Servo myservo;
int pos=0;

// the setup routine runs once when you press reset:
void setup() {
  // initialize serial communication at 115200 bits per second:

// the loop routine runs over and over again forever:
void loop() {
      while (Serial.available() > 0)
        char recieved =;
        inData += recieved; 

        // Process message when new line character is recieved
        if (recieved == '\n')
            Serial.print("Arduino Received: ");
            int dataAsInt=inData.toInt();
            if(dataAsInt>0 && dataAsInt<360 buffer="" clear="" dataasint="" delay="" indata="" myservo.write="" nop="" pre="" recieved="" serial.println="">
The Java app is based on the example from but has a button with an onClick function with mSerialIoManager.writeAsync("10\n".getBytes());

Monday, 2 December 2013

Linking Android to Arduino

I've started our latest project (to be unveiled soon). It requires Arduino to receive commands from an Android device. It needs to be as light as possible, so ideally needs to be powered from the USB connection.

I've seen a number of solutions using Android ADK and special Arduinos, but this seems rather unnecessary. The problem seems to be the USB communication on either side, requiring USB sheilds ( Alternatively there's Bluetooth (, but that would mean an external power source.

So instead, just use a Serial interface. There are Java libraries that can be used on Android. Everything including examples can be found here:

 I've hooked up my arduino Uno to an SIII using an A to B USB cable and OTG cable. It all works nicely. Stay tuned for what we're going to use it for ;-)

Thursday, 14 November 2013

How Many Apps are on my phone?

I've seen several people posting about how they have "over a hundred apps" on their phone. I don't think this is accurate. There are a lot of apps installed by default that the user doesn't see (and can't uninstall). Interestingly, I couldn't find a good way to display the total number of packages (apps), installed on a device using the GUI. You can list apps using Settings->Apps but this is incomplete.

Instead using a USB cable and ADB it's possible to get a clearer picture.
So the total number is more like over 300

Thursday, 19 September 2013

automated odex to dex script

When grabbing a new Android device, most applications' dex files have been optimised for the device. A few people have written a guide to using smali and baksmali in this situation (, but here's a handy script to do it all. You'll need smali.jar and baksmali.jar in the local directory when you run it.

echo "+------------------------------+"
echo "+                              +"
echo "+       mass de-odexer         +"
echo "+         TROTMASTER           +"
echo "+                              +"
echo "+------------------------------+"

mkdir BOOTCLASSPATH 2>/dev/null
mkdir tobedeodexed 2>/dev/null
mkdir deodexed  2>/dev/null
#clear out the previous contents COMMENT THIS OUT IF YOU ARE USING THE SAME BOOTCLASSPATH etc.
rm BOOTCLASSPATH/* 2>/dev/null
rm tobedeodexed/*  2>/dev/null
rm deodexed/* 2>/dev/null

#get bootclasspath files TODO:get only .jar files
echo "pulling boot class path files..."
adb pull /system/framework/ BOOTCLASSPATH/ > /dev/null 2>&1

#get odexes
echo "pulling .odex files..."
for i in $(adb shell ls /system/app/*.odex | sed -e 's/odex./odex/'); do adb pull $i tobedeodexed/$(echo $i|cut -d"/" -f 4)>/dev/null 2>&1;done

#Now run smali then baksmali to change odex to dex. may need -a to change api level
for i in $(ls tobedeodexed/*.odex);do rm -R out/ 2>/dev/null; echo baksmali-ing $(echo $i|cut -d"/" -f 2);java -Xmx1024m -jar baksmali.jar  -x $i -d BOOTCLASSPATH/; echo smali-ing $(echo $i|cut -d"/" -f 2);java -Xmx1024m -jar smali.jar -o deodexed/$(echo $i| cut -d "/" -f 2).dex out;done

Sunday, 8 September 2013

Settting the phone number in an android emulator

So this is another short post to help answer a question that the Internet seems to faff around with:
  "How do I set the phone number in an Android emulator?"

This was important for me as I have been producing a proof of concept app that relies on using the phone number as a way of identifying you. Rather hard if all the emulators are on the same number.

So as a result it appears that the following information can be used:
 - The number of the phone ends in the four digits relating to the port number that the emulator is listening on. So for instance when it's run on port 5554:

To change, you can run ./emulator -avd -port
There doesn't seem to be a way to set the port when using Eclipse's AVD manager, but they will at least start on incrementing ports from 5554 onwards so no chance of a collision.