This document provides an overview of techniques for reverse engineering mobile applications and systems. It discusses both static and dynamic analysis approaches. For static analysis, it recommends analyzing the app's manifest, resources, classes, native code, and certificate information. Tools mentioned include APKtool, smali, dex2jar, jadx, and IDA Pro. For dynamic analysis, it suggests debugging and instrumentation to observe runtime behavior like network traffic. The document provides tips on finding apps to analyze and reversing non-trivial aspects like encrypted strings and dynamic code loading. The goal is to understand an app's functionality and identify security vulnerabilities by applying the right analysis approach for the task.

1. Mobile Systems and Smartphone Security
(MOBISEC)
Prof: Yanick Fratantonio
EURECOM
Reverse Engineering
1

2. - The "art" of reverse engineering
- Pros / cons of various approaches
- Actual tools + demo
This class
2

3. - The goal: understand what X does and how it does it
- "X" could be an Android app, a MS Windows program, OS functionality,
a piece of hardware, a mechanical/physical engine, ...
- "[...] process by which a man-made object is deconstructed to reveal its
designs, architecture, or to extract knowledge from the object." (wiki)
- Why is it an "art"?
- There is no "recipe" that works in all cases
- Learn from experience which approaches work best
- I'll teach you the principles & starting points, I can't teach you everything
The "Art" of Reverse Engineering
3

4. - Input: the APK of the Android app
- Goals
- Understand what an app does from a high-level point of view
- Understand the tech details on how an app does something
- Find security vulnerabilities ~> exploit them to gain some advantage
- Steal private information, read private file, steal its permissions, etc.
Reversing an Android app
4

5. - Don't just start reading everything in details!
- You should proceed depending on what's your goal
- Generic understanding on what the app does?
- Find ways to attack the app?
- How does the app interact with network endpoints?
- How does it store private information?
- Check whether a specific functionality can be abused?
- ...
Efficient/effective Reversing
5

6. - Begin from an high-level point of view
- Start the app in an emulator and see the first UIs
- What are the "claimed" functionality?
- In a way, it will set your expectations right...
- ... and if something seems off, well, that's interesting
Generic understanding on what the app does?
6

7. - Start from the "entry points"
- Attack surface analysis
- Check the app's components (activities, etc.)
- Can they be reachable from another app?
- Check how the app interacts with the external world
- File-system, network, inter-component communications, etc.
Find ways to attack the app?
7

8. - Try to find network endpoints IPs, URLs, etc.
- Note: they could be obfuscated!
- Note: no matter what you do, just looking at the APK may not be enough!
- Try to find invocations of network-related APIs
- Run it in an emulator and monitor network activities
- Note: just running it may not be enough!
How does the app interact with network endpoints?
8

9. - What is "private information"?
- It really depends on the app...
- Examples
- User account credentials
- User sensitive data (messages, photos, etc.),
- Information accessed via security-relevant permissions
- Once you know what you are looking for, it becomes
similar to the "network" case
How does it store private information?
9

10. - Approach similar to previous case, but more targeted
- "More targeted"
- How does the app use functionality X?
- Does it use it in some unconventional ways? (read: possibly insecure?)
- How can an attacker reach it? (see: attack surface analysis)
Check whether a functionality can be abused?
10

11. - Top-down mentality:
- Start with high-level understanding of the app's organization/functionality,
then drill down on the tech details depending on your needs
- Start with the various entry points, explore the different functionalities,
explore the app as a "user"
- Perform attack surface analysis
- Keep a flexible mindset!
Generic Suggestions
11

12. - Static analysis vs. dynamic analysis
- Static analysis: inspect the app without running it
- Dynamic analysis: run the app and check what it does
- They are complementar: taken independently are limited
- Key skill: understand which one to use and when
Two Main Approaches
12

13. - Key point: you do not run the app
- You inspect it "statically"
- Take the app, unpack it, check what's inside
- Manifest analysis, disassemble/decompile .dex, check .so files, etc.
Overview on Static Analysis
13

14. - Key point: you actually run the app.
- You want to know what's going on "at run-time"
- Actual values at run-time (useful when strings are obfuscated)
- Trace of API invocation
- Trace of syscalls
- Two main techniques
- Debugging
- Instrumentation
Overview on Dynamic Analysis
14

15. - You run the app and you "attach" a debugger
- You can ask debuggers a number of things
- Stop the execution when you reach point XYZ
- Tell me the content of this field / memory location
- Single-step through instructions
- Helpful to understand the state / context at a given point
Debugging
15

16. - Run the app in an "instrumented" environment so that
- Every APIs invocation is traced
- Every network-related API invocation is traced + all their arguments
- Log all strings
- Dump additional information when specific conditions are met
- Note: too much info is not always good!
- Many technical ways
- Modify the Android emulator, ART environment, the app's itself
- Manual instrumentation vs. instrumentation frameworks
- But still, somehow it is still an open problem
Instrumentation
16

17. - Pros
- Initial general understanding
- What does the app do from an high-level perspective / "semantics"?
- Determine which points are interesting
- Answer questions such as: how can I reach a specific point?
- Find security vulnerabilities
- Cons
- Some values may be difficult to determine at static-analysis time!
- String obfuscation, complex algorithms, etc.
- Some of them may not even be available!
- Strings coming from the network, dynamic code loading, etc.
Static analysis pros/cons
17

18. - Pros
- Dump actual values at run-time
- Dump network traffic (both sent and received), no reconstruction needed
- Stop analysis at any-point and do context/memory inspection
- "Is this API ever invoked?", "With which arguments?"
- Verify that a security vulnerability is actually exploitable
- Cons
- Limited code coverage: Where should I click? Input to insert?
- How can I reach a specific point?
- Is what I'm seeing "bad"? Missing context!
- It can be evaded (app can understand it is under analysis / bypass it)
Dynamic analysis pros/cons
18

19. Usual Workflow
19
Static Analysis Dynamic Analysis
Key: learn when to switch between static and dynamic analysis

20. - Activity with an "access code" input field and a button
- Protected functionality is behind this activity
- Clicking around will not help you
- Complex "access code" check will make static analysis
tricky
Example where both are useful
20

21. Alright, practical stuff now
21

22. Can I haz APKs?
22
- The input: an app's APK
- Where to find the APKs?
- Install them from Google Play Store on your device and pull
- But it's tricky... see next slides
- APKMirror, copies of APKs from the Play Store
- PlayDrone, AndroidZoo, Koodous
- Self-contained package shared by security researchers

23. - APK path: /data/app/<package-name-prefixed-string>/*
- /data/app/com.facebook.katana-iz-DZLKZM-0t4w1giP_FWA==/base.apk
- If device is rooted: easy, just get the APK
- Trickier if the device is not rooted
- $ ls /data/app ~> "ls: /data/app: Permission denied"
Pulling Play Store's APKs from your device
23

24. - $ ls /data/app ~> "ls: /data/app: Permission denied"...
- ... but "$ cd /data/app" works
- Permissions of /data/app: rwxrwx--x
- This means that we cannot "list" the directory...
- ... but we can "cd" into it and read files inside it (if we know the path)
Pulling Play Store's APKs from your device
24

25. - $ adb shell cmd package list packages
- List of all apps' package names installed on the device
- $ adb shell pm path com.facebook.katana
- Get the path of the APK for this package name
- /data/app/com.facebook.katana-iz-DZLKZM-0t4w1giP_FWA==/base.apk
- $ adb pull /data/app/com.face...FWA==/base.apk app.apk
Pulling Play Store's APKs from your device
25

26. - If you have a real device, it's trivial
- Play Store app should be already there
- If you don't have a real device, use an emulator
- The easy way: "Target API 28 (Google APIs)"
- This will contain the Play Store (but it's not rooted)
- The trickier way: "Target API 28"
- No Google-related APIs (but it's rooted)
- Install Google apps via https://opengapps.org/
- Tutorial: link
Installing apps from the Play Store
26

27. Static Analysis
27

28. - AndroidManifest.xml
- Entrypoints enumeration, tell us what to expect when we run it
- assets/, res/
- Resources, strings, binary blobs, etc.
- Not very important, unless referenced in "interesting" ways
- Suggestion: quickly check for weird things, but don't lose too much time
- classes.dex (classes2.dex, ...)
- The juicy part: disassemble / decompile them
- libs/*.so: native code
- META-INF/*
Static Analysis
28

29. - We have seen most of them last time
- apktool, smali, baksmali, strings
- APK Studio (UI for apktool)
- dex2jar
- jadx, jd-gui, bytecodeviewer
- IDA pro, JEB
- Generic workflow
- Start from the (main) entry points and try to understand what's going on
- It's normal to end up using strings + grep
- Collect info for dynamic analysis: "How can I arrive to this point?"
Tools for classes.dex
29

30. - Encrypted strings / values
- Complex algorithms
- DexClassLoader
- Find the loaded classes.dex and unpack it separately
- Reflective calls
Non-trivial aspects to reverse
30

31. - Tricky to reverse engineer
- Easier to at least detect its usage
- You should be able to see the "native" keyword
- You should be able to see System.loadLibrary("mylib")
- More in the next deck of slides
Native code reversing
31

32. - Files
- MANIFEST.MF: hashes of all files inside the APK
- CERT.SF: like MANIFEST.MMF, but signed with the RSA key
- CERT.RSA: info about public key used to sign CERT.SF (DER format)
- Dump
- $ openssl pkcs7 -in CERT.RSA -inform DER -print
- Verify it
- $ apksigner verify app-name.apk
META-INF/*
32

33. - How can you know if this is a "system" app?
- App needs to be signed with a "system" certificate...
- "system" apps are apps signed with the same certificate
as the the app with package name "android"
- /system/framework/framework-res.apk
- Spoiler: this is the APK that defines all the "dangerous" permissions
"System app"?
33

34. Dynamic Analysis
34

35. Debugger
35
- Set breakpoints, single step, check "run-time" values
- If it's your own app / you have the source code
- Debugging is easy via Android Studio
- Start it in "debug" mode, put breakpoints, and run it
- Android Studio will auto-attach to it
- If it's not your own app: trickier
- IDA Dalvik debugging plugin (very expensive :-( )
- NetBeans seems an (horrible) alternative: link (didn't work for me)
- Decompile it and add the source code to empty project! (link)

36. - Run the app where "all actions are logged"
- API trace
- Network activities
- etc.
- Various techniques
- Modify the app itself
- Code injection
- Modify the Android emulator
- Modify the Android framework
Instrumented Environments
36

37. - Bytecode injection
- Unpack the app, add extra functionality, pack the app
- Example:
- What's the value at run-time of variable X?
- Add proper Log invocations
- Usual trick
- 1) write your functionality in Java
- 2) get the smali
- 3) inject the smali
"Manual" app modifications
37

38. - It can instrument the app itself
- Based on code injection
- It actually injects a Javascript engine into a running process
- Modules are written in Javascript
- Why Javascript? WHHHYYYY???
- Because there already exists Javascript engines for Android, iOS, etc.
Frida Framework
38

39. - By default, it requires root
- It needs to ptrace the target app for code injection
- You can inject the "frida-server" directly into the target app
- https://koz.io/using-frida-on-android-without-root/
- In both cases: it can be detected
Frida Framework
39

40. - It instruments the system itself
- Android framework / DEX/ART files
- It requires a rooted device
- It does not touch the APKs
- It can instrument even system apps
- Many user-developed plugins: link
- One random example
- module page, source code
XPosed Framework
40

41. - Android-related variant of Cuckoo sandbox
- It will list the URLs contacted, the DNS queries, API
traces, etc.
- Open source: github
Cuckoo Droid
41

42. - Online service: https://www.joesecurity.org/
- It doesn't require setting anything up
- In the past it was accepting public submissions
- Not sure about now...
- Example report: link
Joe Sandbox
42

43. - Online service similar to Joe Sandbox
- You submit the app => static/dynamic analysis report
- I was involved in maintaining it, but we didn't have enough
resources / time
- ⇒ discontinued, RIP
Andrubis
43

44. - Great overview on Android app reversing: link
- Reversing app for vending machines: link
- Frida docs: https://www.frida.re/docs/home/
More Resources
44