1. 1
Building Custom
Android Malware for
Penetration Testing
Stephan Chenette
Director of R&D, IOActive Labs

2. Who am I?
• Stephan Chenette
• About Me:
•Director of R&D @ IOActive
•eEye, SAIC, Websense [13+yrs]
•Breaking technology to expose weakness
•Building technology / innovation
* This is my 3rd time speaking at BruCON =]
2

3. Audience
• Built/Bought/Broken
defensive security controls for android malware
• Foundation - Android malware/apps
• This presentation is an overview of my experience
and methodology blackbox penetration testing a
android security control
3

4. Why Build
Custom Android Malware
for Penetration Testing?
4

5. Why?
• Classical thoughts of Penetration Testing (you think Network)
• Important to focus on Individual Security Controls
•Mobile Device Management, Gateway AV,
Desktop AV, Application Stores, etc.
• Compartmentalizing “security tests”
(from ITW malware) (non contrived/theoretical)
• Systematically/Structurally attempt to bypass a security control
• Improvement in technology
• Improvement in education for the developer
• Help in determining and/or exposing risks to current
boundaries of a product/technology5

6. Previous Presentations
Previous Known Work:
“Dissecting the Android Bouncer”
Jon Oberheide, Charlie Miller
http://jon.oberheide.org/files/summercon12-
bouncer.pdf
6

7. Introduction to Android
7

8. What is Android?
Android is a mostly open source operating system that runs on small devices. It is built on top of Linux
and runs a VM called Dalvik, similar to the Java VM, but optimized for speed.
From top to bottom, the stack looks like this:
8
Applications written in Java
A framework called the Android SDK
C++ Libraries and the Dalvik Virtual
Machine
Linux

9. Applications written in Java
9

10. Android SDK
Android SDK - Framework for developing applications:
• Like the .NET Framework
• APIs you can call to access key features of Android
10

11. Android NDK
• The Android Native Development Kit (NDK) is a toolset that allows you to
implement parts of your app using native-code languages such as C and
C++
• If you write native code, your applications are still packaged
into an .apk file and they still run inside of a virtual machine
on the device.
• Native code is no different from Java code running under the
Dalvik VM. All security in Android is enforced at the kernel
level through processes and uids
11

12. Android NDK
12
#include <string.h>
#include <jni.h>
#include <stdio.h>
jstring Java_com_example_hellojni_HelloJni_stringFromJNI( JNIEnv* env,
jobject thiz )
{
FILE* file = fopen("/sdcard/hello.txt","w+");
if (file != NULL) {
fputs("HELLO WORLD!n", file); fflush(file);
fclose(file);
}
return (*env)->NewStringUTF(env, "Hello from JNI (with file io)!");
}
<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE"/>
int sockfd = socket(AF_INET, SOCK_STREAM, 0);
<uses-permission android:name="android.permission.INTERNET" />

13. Applications written in C/NDK (iOS port)
13

14. Java Virtual Machine (stack based)  much slower
Dalvik Virtual Machine (register based)  much faster
Dalvik VM
The applications built for Android are run on top the Dalvik Virtual Machine.
This is a Process Virtual Machine, like the Java Virtual Machine or the .NET Runtime
The Dalvik virtual machine (DVM)
• register-based machine which executes
Dalvik bytecode instructions.
• different from a JVM, hence its bytecode is different
from Java bytecode.
14

15. Android Linux
Linux - Underlying OS that runs the Dalvik VM
• Very lightly modified version of linux kernel
• But user space wholly unlike that of any other linux system.
• File IO
• Process Management
• Drivers for:
•Display
•Camera, Audio, Video
•Keypad
•WiFi and other networking resources
•Inter-process Communication
15

16. Developing an APK in Android
1. Android programmers write android apps in java.
Native apps can included and written in native languages
e.g. C++ and are compiled for the native architecture
(ARM/MIPS, etc.)
2. The IDEs like eclipse use the JDK to generate .class files which
are then converted to .dex files (dalvik executable). AAPT is
then use to build the APK
3. The dalvik virtual machine (dalvikvm) in Android can
then run these dalvik executables by translating them
to native instructions.
16

17. Enough Intro,
Let’s Start Building Malware!
17

18. Approach/Methodology
Research In The Wild
(ITW) Android Malware
• Techniques
• Methodologies
18
Research Defensive
Security Controls
• Techniques
• Methodologies
1. Probe Environment (RECON)
2. Upload and test ITW Malware (Test barrier to entry)
3. Regroup
4. Upload “trojaned” apps / altered versions of ITW Malware
5. Regroup
6. Upload unit-tests (real-world/fabricated samples)
7. Mix, max and combine unit-based tests into samples

19. Research In The Wild (ITW)
Android Malware
19

20. 20
Initial Analysis
• What is malware?
• What are the different malware categories?
• Methodology/Techniques

21. 21
What is Malware?
Malware
something malicious, right !?

22. 22
What is Malware?
Malware
• Anything that breaks the security model (without the users consent)
• Deceptive/hide true intent
• bad for user / good for attacker e.g. surveillance, collecting passwords, etc.
• Applications that are detrimental to the user running the device.
• Harms a user
• Financial
• Privacy
• Personal information – location (surveillance) ,
• Stealing resources – cracking, botnets – processing power
•Breaks Network policy
•Example: not-compatible.
•1964 Jacob Elllis V.S. Ohio
•How do you define P0rn? …“You know it when you see it”

23. 23
What is Malware?

24. 24
What is Malware? Is this
Malware?

25. 25
Android Malware Categories
Android Premium
Service Abusers
Android Adware Android Data Stealers
Targeted
Spyware
Malicious Android
Downloaders
Source: https://www.lookout.com/

26. 26
Android Malware Analysis
Infection Vector - How it installed on the device
Entry Point – How the malicious behavior is initiated
Elevated Privileges – if and how it gained root privileges
Payload – it’s Purpose and functionality
Hosting – does it contain embedded apps

27. Top Threats
27
Source: https://www.lookout.com/resources/top-threats

28. Top Threats
28
Infection Vector  DroidDream hid the malware in seemingly legitimate applications to trick
unsuspecting users into downloading the malware (more than 50 apps on the Android App
Store were found to contain Droid Dream)
Entry Point  Requires user to launch application. Post-Launch malware will start a service
then launch the host application’s primary activity
Elevated Privileges  1) “exploid” to attempt to exploit a vulnerability in udev event
handling in Android’s init. If “exploid” fails… 2) “rageagainstthecage”, leveraging a
vulnerability in adbd’s attempt to drop its privileges.
Payload  Sends device information to C&C e.g. IMEI, IMSI and device model and SDK
version, Checks if already infected, by checking package
com.android.providers.downloadsmanager is installed. If this package is not found it will
install the second payload, which is bundled as sqlite.db. This part of the malware will be
copied to the /system/app/ directory, installing itself as DownloadProviderManager.apk.
Copying the file using this method, to this directory will silently install the APK file, and not
prompt user to grant permissions as in a standard app installation process.
Droid Dream

29. Top Threats
29
Entry Point  triggered by Intents it listens for on the device.
• receiver for BOOT_COMPLETED and PHONE_STATE intents
• single service:
Payload  DownloadManageService controls a timer-scheduled task
Gather information and send to C&C and install:
• ProductID – Specific to the DroidDream variant
• Partner – Specific to the DroidDream variant
• IMSI
• IMEI
• Model & SDK value
• Language
• Country
• UserID – Though this does not appear to be fully implemented
Powerful zombie agent that can install any payload silently and execute code with root
privileges at will.
Droid Dream

30. Top Threats
30
Source: https://www.lookout.com/resources/top-threats

31. Top Threats
31
Source: https://blog.lookout.com/wp-content/uploads/2011/06/GGTracker-Teardown_Lookout-Mobile-Security.pdf
GGTracker
Infection Vector  User is phished into visiting to a website that tricks them into installing a
battery manager application file from a fake Android Market store.

32. Top Threats
32
Source: https://blog.lookout.com/wp-content/uploads/2011/06/GGTracker-Teardown_Lookout-Mobile-Security.pdf
GGTracker
Entry Point 
When installing, the user is prompted with a list of
permissions the application requires:
android.permission.ACCESS_WIFI_STATE
android.permission.CHANGE_WIFI_STATE
android.permission.CHANGE_NETWORK_STATE
android.permission.ACCESS_NETWORK_STATE
android.permission.RECEIVE_BOOT_COMPLETED
android.permission.INTERNET
android.permission.READ_PHONE_STATE
android.permission.READ_SMS
android.permission.RECEIVE_SMS
android.permission.SEND_SMS
• This malware will either start
itself after receiving an SMS or
having the application launched.
• On the first launch, it
communicates with the tracking
server, ggtrack.org.
Payload 
• The app posts the phone
number to the GGTracker
remote server, where the
malware starts to subscribe the
device to premium services.

33. Top Threats + 1000s Other Apps
33
Source: https://www.lookout.com/resources/top-threats

34. Most Sophisticated Malware Yet
OBAD
• Installs as device admin app (permissions)
• Very difficult to uninstall
• Heavily Obfuscated
• Send SMS to Premium numbers
• Download other malware
• Remote command Execution
• Called API methods via reflection
• Took advantages of bugs in DEX2JAR to break
manual/automated analysis if using DEX2JAR
34

35. Obfuscation
• ProGuard / DexGuard
• API Reflection
• Encrypted Network Communication
• Encrypted Files
35

36. In-House Framework
• Added functionality to framework
• Library of repeatable security tests
36

37. Research
Defensive Technologies
37

38. Bypassing Detection
38
• Ultimate goal is to get app to user
• To do that you have to upload app to “walled garden”
• To do that you must bypass detection capabilities / review process
• Detection capabilities
• Hashes
• Native apps
• Dex files
• Dalvik opcodes sigs
• Decompile dalvik to smali and use sigs
• Fuzzy hashing against known apps
• AndroidManifest.xml file
Suspicious Permissions
android.permission.READ_FRAME_BUFFER (read frame buffer)
android.permission.CLEAR_APP_CACHE (delete all application cache data)
android.permission.WRITE_SECURE_SETTINGS (modify secure system settings)
android.permission.INJECT_EVENTS (inject user events)
android.permission.BIND_DEVICE_ADMIN (interact with device admin)
android.permission.INSTALL_PACKAGES (directly install applications)
android.permission.DELETE_PACKAGES (delete applications)
Etc.

39. Building Custom
Android Malware
39

40. Methodology
• Define the target and objectives
• Profile target
• Determine environment
• Determine detection capabilities
•Upload ITW Malware
• Determine what gets caught and what doesn’t
• “Rinse and Repeat”
•Create Alternative Versions (Private)
• Decompile/Obfuscate/Re-Write
• Recompile
• Upload
•Merge with legitimate applications
•Fabricate Android Malware40

41. Target
41
• Reviewer 
• End detection engine
• End user
• Internal resource that is adjacent to
the android device (e.g. internal
network)
• Etc.

42. Probes – Determine Environment
42
What’s the first thing you’d do if you go explore a new universe?
Send out a few probes to gather information, right?
No Different here.

43. Probes – Determine Environment
Red Pill/Blue Pill Test - Running in an emulator??
43
if (android.os.Build.MODEL.equals(“google_sdk”)) {
// emulator
} else {
//not emulator
}

44. Probes – Determine Environment
• Device info
• IMEI, Device Model/Make etc.
• GEO Location  help determine language to write app in
• IP Address / 3G/4G or on wifi network?
• Scan for available blue-tooth devices
• Egress filtering? ports open, etc.
44

45. Probes – Determine Environment
45
• Record Audio
• Take Video
• Take Photos
• Send Existing Photos

46. Probes – Determine Environment
46
• Other Processes/Apps on device
• Other permissions/intents of installed apps
• Info-leak in error messages?

47. Upload ITW Malware
• ADRD
• AnserverBot
• Asroot
• BaseBridge
• BeanBot
• Bgserv
• CoinPirate
• CruseWin
• DogWars
47
• DroidCoupon
• DroidDeluxe
• DroidDream
• DroidDreamLight
• DroidKungFu1
• DroidKungFu2
• FakeNetflix
• EndofDay
• And many more…

48. Build Common Scenarios
48
Scenario Description
Android Premium Service Abusers Premium service abusers subscribe users to various "services"
that add to their phone bill at the end of the month
Android Adware Android apps that use abusive advertising tactics
Android Data Stealers Android data stealers often bilk users of information such as their
operating system version, product ID, International Mobile
Equipment Identity (IMEI) number and other information that
could be used in future attacks
Malicious Android Downloaders Once a malicious downloader has infected a
victim's Android device, it is designed to contact a
remote server to await instructions or download
additional Android malware

49. Android App Entry Point
Unlike other programming paradigms in which apps are launched
with a main() method, the Android system initiates code in
an Activity instance by invoking specific callback methods that
correspond to specific stages of its lifecycle.
• Services which start at broadcast receiver callback
• Callbacks which correspond to a user action
• Actions start immediately (service, thread, etc.)
• Actions which start based on a timer
49

50. Android App Entry Point
50
Layout/activity_main.xml:
<?xml version="1.0" encoding="utf-8"?> <LinearLayout
xmlns:android="http://schemas.android.com/apk/res/android"
android:layout_width="match_parent" android:layout_height="match_parent"
android:orientation="vertical" > <Button android:id="@+id/button1"
android:layout_width="wrap_content" android:layout_height="wrap_content"
android:onClick="onClick" android:text="Button" /> </LinearLayout>
A broadcast receiver (short receiver) is an Android component which allows you to register for
system or application events. All registered receivers for an event will be notified by the
Android runtime once this event happens.
For example applications can register for the ACTION_BOOT_COMPLETED system event
which is fired once the Android system has completed the boot process.
A receiver can be registered via the AndroidManifest.xml file.
Alternatively to this static registration, you can also register a broadcast receiver dynamically
via theContext.registerReceiver() method.
The Broadcast receiver can then start a service to perform any number of actions.

51. Android App Entry Point
51

52. Android App Entry Point
52

53. Android App Entry Point
53

54. Broadcast Actions
54

55. AndroidManifest.xml
55

56. Build functionality
56
Functionality
Autostart on boot
Get phone number, IMSI, IMEI, …
Send information to C&C
WiFi connection-aware ( run when phone
charging)
Hide application icon
Log SMS/Send SMS
Etc.

57. Collecting Device Data
57
import android.app.Activity;
import android.content.Context;
import android.telephony.TelephonyManager;
public class PhoneInfo {
public static String getMyPhoneNumber(Activity a) {
try {
TelephonyManager mTelephonyMgr; mTelephonyMgr =
(TelephonyManager) a.getSystemService(Context.TELEPHONY_SERVICE);
return mTelephonyMgr.getLine1Number();
} catch (Exception e) { return ""; }
}
public static String getMyIMEI(Activity a){
try {
TelephonyManager mTelephonyMgr; mTelephonyMgr =
(TelephonyManager) a.getSystemService(Context.TELEPHONY_SERVICE);
return mTelephonyMgr.getDeviceId();
} catch (Exception e) { return ""; }
…

58. Build Custom Scenarios
58
Scenario Description
Vulnerable Lib Build an android app that uses a vulnerable version of libcurl
(why? – because then the client will be exploitable)
ALL Intents Build an android app that asked for ALL POSSIBLE permission
(why? – this will help us determine if they are filtering by
permission)
Various NDK Examples Same functionality but as a native library
Can call any static Java API from the NDK going through JNI as
long as you’re running in a library instead of an application and
instead the dalvik vm

59. Android Exploitation Space
59
ASHMEM
The ASHMEM custom shared
memory allocator written by
Google has a nasty bug that allows
your device to be easily rooted.
Maybe they should have stuck with
POSIX SHM, but the bad guys
aren't complaining.
Exploid
Nearly identical to a vulnerability
fixed in the Linux udev daemon in
2009, Exploid impacts Android's
init daemon by forgetting to check
whether Netlink messages are
coming from the trusted kernel ...
or a malicious app.
Gingerbreak
A commonly-abused vulnerability
in the wild by Android malware,
Gingerbreak affects the Android
volume manager (vold) via, you
guessed it, the same Netlink issue
as Exploid. Badness ensues.
Levitator
Malicious apps will undoubtedly be
“levitating” their privileges using
this vulnerability that affects the
PowerVR kernel module used for
3D graphics on all S-series devices
and allows unfettered access to
kernel memory.
Mempodroid
Inherited from the upstream Linux
kernel, a vulnerability in the
/proc/pid/mem interface allows for
writing arbitrary memory in the
address space of a setuid process.
It's about as complicated as it
sounds, but attackers are smart
like that.
Wunderbar
Another crossover from the Linux
kernel, this NULL pointer
dereference was one of the first
privilege escalation vulnerabilities
exploited on the Android platform,
thanks to faulty mmap_min_addr
protection on ARM.
ZergRush
No, it has nothing to do with
StarCraft, sorry. The ZergRush
vulnerability in Android's libsysutils
allows an attacker to overwhelm
the system with command
arguments, not zerglings, and take
full control of your device.
Zimperlich
Always check return values.
Android's Zygote process, from
which all new apps are spawned,
forgets this important rule and fails
to check the return value of
setuid(2), leading to plentiful root
shells!
Source: http://www.xray.io/#vulnerabilities

60. Android Exploitation Space
• Android Master Key – one of the most recent and exploit
• It lets you get at system-android-app-level permissions, not full-out root, but that's enough to do some
serious harm (read text messages without permissions, etc.) Might be in a different class than the full-
out root exploits, though.
“The Android platform is a complicated system that consists of not only the Linux kernel,
but also the entire Android framework with more than 90 open-source libraries includingWebKit, SQLite,
and OpenSSL. The complexity naturally introduces software vulnerabilities that can be potentially exploited
for privilege escalation.”
“among 1260 samples in our dataset, 463 of them (36.7%) embed at least one root exploit”
60
Source: “A Survey of Android Malware”, Xuxian Jiang, Yajin Zhou

61. End Result  Modular Framework
61

62. Considerations
62
• Store
• Set time of Application release to some date in the future (to make sureit’s not downloaded
• Gateway/Desktop AV
• Setup entire end-to-end test
• Behavior Analysis Engine
• None =]

63. End Notes
63
• Malware is a matter of perspective
• Trivial to get “malware” onto a system
• Custom malware
• almost guaranteed to get through
• because majority detection techniques are focused on
known-bad (signatures/clustering)

64. Mitigations/Improvements
64
• Hashes work (on known samples)
• Focus for detect engines should be apps that
break the security model (e.g. exploitation  root)
• Apps that conform to security model but deceive users can have
dangerous permissions highlighted for users
• App reviewers should thoroughly verify what an app does and
what it’s supposed to do before being downloaded to a user,
auto-deny on key permissions, and ask for more details
• App review process should involve running apps and reviewing
code coverage
• App review process should involve using any and all dynamic
information to help catch “known malicious artifacts” to
consolidate ‘deep-review bucket”
• App review process should have way to determine if good app
has been “trojanized”

65. Questions?
Stephan Chenette,
Email: stephan.chenette @ ioactive.com
Twitter: @StephanChenette
Slide Share: http://www.slideshare.net/schenette
Thanks to JEB Analysis Tool, Jurriaan Bremer,
Robert Erbes, Esteban Fayo and the IOActive Team!
65

66. Supplemental
66

67. 67
Android Malware Repositories
• Mal Genome Project
• Virus Share
• Wepawet
• Kaspersky (+Other AV Vendors)
• Contagio

68. Android APK Reversing
68

69. Android APK Structure
69
PK ZIP
Android
APK

70. Android APK Structure
70

71. Decompiling an Android APK File
71
unzip
AXML-
Printer2
dex2jar
or ded
Android
Manifest
XML
classes
dex
Text
Version
XML
jd-guiclasses
jar
.java
unzip
classes
jar
classes
jar
classes
.class
jad
.java
.java
Android
APK
Sony Ericon has a tool that does all of the above in a graphic layout  APKAnalyzer
http://developer.sonymobile.com/knowledge-base/tools/analyze-your-apks-with-apkanalyzer/

72. Decompiling an Android APK File
72
JEBAndroid
APK
Text
Version
XML
.java
.java
.java
res
res
res
assets
assets
assets
This is my preferred
method

73. Android Reversing Tool Bag
• The Android SDK, of course, and Eclipse
• Android APK Tool - for reverse engineering 3rd party, closed,
binary Android apps
• dex2jar, which converts Android’s Dalvik
executables into normal Java jar files.
• JD-GUI, which decompiles jar files into java source file
• ADB service (the Android Debug Bridge) – for debugging apps
• JEB – if you’re serious about reversing and can spend the $$$
http://www.android-decompiler.com/
73

74. Source Executable
1.Compile
2.Export (zip & sign)  APK
74

75. Executable  Source
• Dalvik bytecode is different from Java bytecode, Hence, Java decompilers cannot
decompile it.
• To overcome this issue is to use bytecode-to-bytecode compilers like
•DED (JED better version)
•dex2jar
• to transform the Dalvik bytecode into Java bytecode and then to use a regular Java
decompiler
•jd-gui
•dava
• Such a method is prone to errors that may exist in the conversion of the bytecode,
resulting erroneous source code.
75

76. Executable  Source
• dex files  dalvik opcode
• To convert.dex files to a more
understandable form we can
convert it to smali
representation
• Davikic opcodes to smali
(intermediate/assembly based
language and is a direct
mapping.
76

77. Executable  Source (sort-of)
• smali can't be used to completely reconstruct java source code
• Java is a very developed language
• smali is more of an assembly based language.
• Doesn’t have necessary information to be translated to Java
77