In this presentation Stephan will discuss some recent research that emerged he was asked to build malicious applications that bypassed custom security controls. He will walk through some of the basics of reversing malicious apps for android as well as common android malware techniques and methodologies. From the analysis of the wild android malware, he will discuss techniques and functionality to include when penetration testing against 3rd-party android security controls. BIO Stephan Chenette is the Director of Security Research and Development at IOActive where he conducts ongoing research to support internal and external security initiatives within the IOActive Labs. Stephan has been in involved in security research for the last 10 years and has presented at numerous conferences including: Blackhat, CanSecWest, RSA, EkoParty, RECon, AusCERT, ToorCon, SecTor, SOURCE, OWASP, B-Sides and PacSec. His specialty is in writing research tools for both the offensive and defensive front as well as investigating next generation emerging threats. He has released public analyses on various vulnerabilities and malware. Prior to joining IOActive, Stephan was the head security researcher at Websense for 6 years and a security software engineer for 4 years working in research and product development at eEye Digital Security.

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
•Offensive Defense Series
2

3. About this presentation
This presentation is an overview
of my experience and methodology
black box penetration testing a
android security control
3

4. Format
import time
...
start = time.time()
end = start + (60*75)
while True:
Present()
if Raise_Your_Hand() == True:
Try_To_Answer()
now = time.time()
if now >= end:
print(“Presentation Over!")
break
4

5. The goal we were given
• Test today’s In The Wild (ITW) malware techniques and
methodologies against a particular security control
• Create and/or use existing malicious android applications and get them
past the security control (test review/controls NOT security in phone)
• Suggest improvements to the security control
5
Security
Control
Android App User’s Phone

6. Why?
• Important to focus on Individual Security Controls/Process
•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/technology
6

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

8. Agenda
• Approach to Accomplishing our Goal
• **Introduction to Android – Q&A**
• Reversing Android Applications – Q&A
• Defensive Technologies – Q&A
• Building Custom Android Malware – Q&A
• Philosophical Rant on “What is Malware?”
• Techniques/Methodologies
• Conclusion
8

9. Agenda
• Approach to Accomplishing our Goal
• **Introduction to Android – Q&A**
• Reversing Android Applications – Q&A
• Getting to know Defensive Technologies – Q&A
• Building Custom Android Malware – Q&A
• Philosophical Rant on “What is Malware?”
• Techniques/Methodologies
• Conclusion
9

10. Approach to Accomplishing our Goal
Given the goal of duplicating ITW techniques:
• Understand the Android Platform
• Studied Defensive Technology e.g. how would you detect malicious apps.
• Analyzed ITW Malware
• Categorized the Malware
• Functionality
• Class
• Duplicated individual functionality
• Made Alternative versions (building on prev. defensive tech. knowledge)
10

11. Agenda
• Approach to Accomplishing our Goal
• **Introduction to Android – Q&A**
• Reversing Android Applications – Q&A
• Goal/Approach
• Defensive Technologies – Q&A
• Building Custom Android Malware – Q&A
• Philosophical Rant on “What is Malware?”
• Techniques/Methodologies
• Conclusion
11

12. Introduction to Android
12

13. 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:
13
Applications written in Java
A framework called the Android SDK
C++ Libraries and the Dalvik Virtual
Machine
Linux

14. Applications written in Java
14

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

16. 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
16

17. Android NDK
17
#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" />

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

19. 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.
19

20. 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
20

21. Developing an APK in Android
1. Android programmers write android apps in java.
Native apps can be 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.
21

22. Agenda
• Approach to Accomplishing our Goal
• **Introduction to Android – Q&A**
• Reversing Android Applications – Q&A
• Where to download Android Malware (research)
• Getting to know Defensive Technologies – Q&A
• Building Custom Android Malware – Q&A
• Philosophical Rant on “What is Malware?”
• Techniques/Methodologies
• Conclusion
22

23. Android APK Reversing
23

24. 24
Where to get Android Malware
• Mal Genome Project
• Virus Share
• Virus Total
• Wepawet
• Kaspersky (+Other Security Vendors)
• Offensive Computing
• Contagio

25. Android APK Structure
25
PK ZIP
Android
APK

26. Android APK Structure
26

27. Decompiling an Android APK File
27
unzip
AXML-
Printer2
dex2jar
or ded
Android
Manifest
XML
classes
dex
Text
Version
XML
jd-gui
classes
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/

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

29. 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/
29

30. Android Reversing Tool Bag
Source: http://tracedroid.few.vu.nl/thesis.pdf
30

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

32. 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.
32

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

34. 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
• …Just use JEB =] http://www.android-decompiler.com/
34

35. Agenda
• Approach to Accomplishing our Goal
• Introduction to Android – Q&A
• Getting to know Defensive Technologies – Q&A
• Building Custom Android Malware – Q&A
• Philosophical Rant on “What is Malware?”
• Techniques/Methodologies
• Conclusion
35

36. Defensive Technologies
36

37. Detection Technologies
37
• Ultimate goal is to upload app to “walled garden” (restrictive environment)
• 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
• Dynamic Behavior Analysis
• DroidBox - https://code.google.com/p/droidbox/
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.

38. Agenda
• Approach to Accomplishing our Goal
• Introduction to Android – Q&A
• Getting to know Defensive Technologies – Q&A
• Building Custom Android Malware – Q&A
• Philosophical Rant on “What is Malware?”
• Techniques/Methodologies
• Conclusion
38

39. Enough already,
Let’s Start
Building Malware!
39

40. Approach/Methodology
Research In The Wild
(ITW) Android Malware
• Techniques
• Methodologies
40
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

41. 41
Where do we start?
• What is malware?
• What are the different malware categories?
• Methodology/Techniques

42. 42
What is Malware?
Malware
• Not always easy to define [ start philosophical rant]
• 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 of malware vs.. useful tool: not-compatible.
•1964 Jacob Elllis V.S. Ohio - How do you define P0rn? …“You know it when you see it”

43. 43
What is Malware?

44. 44
What is Malware? Is this
Malware?

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

46. 46
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

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

48. Top Threats
48
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

49. Top Threats
49
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

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

51. Top Threats
51
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.

52. Top Threats
52
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.

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

54. 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
• Calles API methods via reflection
• Took advantages of bugs in DEX2JAR to break
manual/automated analysis if using DEX2JAR
(will break analysis only if using DEX2JAR)
54

55. Worth Investigating
HoseDex2Jar
• Injected files into the header
Source: Tim Strazzere http://hitcon.org/2013/download/Tim%20Strazzere%20-%20DexEducation.pdf
55

56. Obfuscation
• ProGuard / DexGuard
• Used at compile time
• API Reflection
• Used by desktop Java malware for years
• Reflection can allow a program to create a “method pointer” (a
rough analogy for better understanding) and invoke the target
method by using it.
• Uses this feature to deceive any casual static code analysis module
which tries to detect whether a sample is calling the method that
sends SMS messages. (e.g.:sendTextMessage())
• Encrypted Network Communication
• Encrypted Files
56

57. Building Custom
Android Malware
57

58. 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 Malware
58

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

60. Probes – Determine Environment
60
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.

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

62. Probes – Determine Environment
Anti-Emulation
62
Tim Strazzere’s Anti-Emulator Project (Lookout Security)
https://github.com/strazzere/anti-emulator

63. 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.
63

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

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

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

67. Build Common Scenarios
67
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

68. 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
68

69. Android App Entry Point
69
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.

70. Android App Entry Point
70

71. Android App Entry Point
71

72. Android App Entry Point
72

73. Broadcast Actions
73

74. AndroidManifest.xml
74

75. Build functionality
75
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.

76. Collecting Device Data
76
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 ""; }
…

77. Build Custom Scenarios
77
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

78. Android Exploitation Space
78
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

79. 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”
79
Source: “A Survey of Android Malware”, Xuxian Jiang, Yajin Zhou

80. Considerations
80
• 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 =]

81. Agenda
• Approach to Accomplishing our Goal
• Introduction to Android – Q&A
• Getting to know Defensive Technologies – Q&A
• Building Custom Android Malware – Q&A
• Philosophical Rant on “What is Malware?”
• Techniques/Methodologies
• Conclusion
81

82. Conclusion
82
• 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)

83. Conclusion
83
• 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” use certificates for known good and known bad

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