Trueseeing is an automatic vulnerability scanner for Android apps. It is capable of not only directly conducting data flow analysis over Dalvik bytecode but also automatically fixing the code, i.e. without any decompilers. This capability makes it resillent against basic obfuscations and distinguishes it among similar tools -- including the QARK, the scanner/explotation tool shown by Linkedin in DEF CON 23. Currently it recognizes the most class of vulnerabilities (as in OWASP Mobile Top 10 (2015).) We have presented it in DEF CON 25 Demo Labs. Our tool is at: https://github.com/monolithworks/trueseeing. Takahiro Yoshimura TAKAHIRO YOSHIMURA: He is Chief Technology Officer at Monolith Works Inc. In 2012 METI-coodinated CTF, Challenge CTF Japan 2012, his team (Enemy10) had won local qualification round at the 1st prize. In 2013, his team (Sutegoma2) took the 6th prize in DEFCON 21 CTF. He like to read binaries and hack things. He loves a GSD. https://keybase.io/alterakey Ken-ya Yoshimura KEN-YA YOSHIMURA: Working as Chief Executive Officer at Monolith Works Inc, he is supervising an R&D lab specializing in emerging technologies. His hacker life starts when he was 8 years old; he likes to hack MSXs, NEC PC-9800s, Sharp X68000s, Windows, Macs, iPhones, iOS/Android apps, and circumvent copyright protection (for fun,) etc. He adores a GSD. https://keybase.io/ad3liae

1. TRUESEEING:
EFFECTIVE
DATAFLOW ANALYSIS
OVER DALVIK
OPCODES
Takahiro / Ken-ya Yoshimura
(@alterakey / @ad3liae)

2. WHO WE ARE
➤ Takahiro Yoshimura
(@alterakey)
➤ CTO, Monolith Works Inc.
➤ Keybase:
https://keybase.io/alterakey
➤ Ken-ya Yoshimura
(@ad3liae)
➤ CEO, Monolith Works Inc.
➤ Keybase:
https://keybase.io/ad3liae
➤ Monolith Works Inc.
http://monolithworks.co.jp/
➤ Talks: DEF CON 25 Demo Labs

3. WHAT WE DO
➤ alterakey
➤ Security Researcher
➤ iOS/Android
➤ Network pentesting
➤ ad3liae
➤ Security Researcher
➤ iOS/Android

4. FINDING VULNERABILITIES
➤ Static Analysis
➤ Reversing the target and deriving its behavior
➤ Reversing data flow is important
➤ Dynamic Analysis
➤ Running the target and seeing its behavior

5. PROBLEMS
➤ Obfuscation
➤ Common practice
➤ Hinders decompilers
➤ Dynamic Analysis
➤ Often unwanted :(

6. RELATED WORKS
➤ Mixing multiple decompilers
(QARK et al.)
➤ Speed: even more time
➤ Fragility
➤ Mixing alone does not answer the
question, IMHO..

7. WHY IS DECOMPILING HARD?
➤ Decompiling requires…
➤ Accurate disassembling
➤ Common code pattern
(e.g. function prologue)
➤ Obfuscaters disrupt these

8. GO DIRECT
➤ Trueseeing
➤ Capable of
➤ Reversing data flow
➤ Loosely guessing constants/typesets/…
➤ Manifest analysis
➤ Uses no decompilers
➤ Speed
➤ Resiliency
➤ D8-ready
➤ Readily available on PyPI!

9. DISASSEMBLING
➤ Toolchain
➤ apktool
➤ SQLite3 DB

10. MARKING UP
➤ Parsing
➤ Regular mnemonics (op)
➤ Directives
➤ .class / .method
➤ .implements / .super etc.
➤ Annotations
➤ Marking
➤ methods
➤ classes

11. GO FASTER
➤ Mapping codebase
➤ Constants
➤ Invocations
➤ sput
➤ iput
➤ Names (method, class)
➤ Class relationships
➤ Why SQL?
— Complex queries matter
➤ Make DBs “think”

12. DATAFLOW TRACING (1)
➤ Lenient Backtracking
➤ From “interest”s to the args
➤ Attempt to trace “interests” back to
some constant
(“solving” constant)
➤ Interests
➤ API call arguments etc.
➤ Match register refs/writes
➤ move*, const*

13. DATAFLOW TRACING (2)
➤ Call tracing
➤ From args to the callers
➤ Climbing call stacks up
➤ Special case for handling p*
➤ Not always
➤ Currently R8 aggressively reuse p*
➤ WIP, soon to be fixed

14. DATAFLOW TRACING (3)
➤ Static trace
➤ Matching sget/sput
➤ Solving constants in sput

15. DATAFLOW TRACING (4)
➤ Instansic trace
➤ Matching iget/iput
➤ Ignoring instance identity
(WIP)
➤ Solving constants in iput

16. PATCH AND TIDY
➤ Partial update
➤ Disassemble
➤ Patch codebase/DB
➤ Re-assemble

17. BINARY PATCHING
➤ Removing (in smali)
➤ Removing insn
➤ Patch DB

18. AS AN EXPLOITATION TOOL
➤ Enabling debug
➤ Enabling full backup
➤ Replacing signature
➤ TLS un-pinning (WIP)

19. REPORTING
➤ Scoring vulnerabilities
➤ HTML: Readable, comprehensive report
➤ Text: CI-friendly report

20. SCORING VULNERABILITIES
➤ CVSS 3.0 Temporal
➤ Profile based fine-tuning
➤ Importance of vuln. classes

21. REPORTING IN HTML
➤ Comprehensive, crisp report
➤ Summary
➤ Description
➤ Solution
➤ Risk Factor
➤ CVSS score
➤ Instances
➤ For humans

22. REPORTING IN TEXT
➤ gcc-like
➤ For CI system or something
➤ Continuous security

23. CAPABILITY
➤ Most of OWASP Mobile Top 10 (2016)
➤ M1: Improper Platform Usage
➤ M2: Insecure Data Storage
➤ M3: Insecure Communication
➤ M4: Insecure Authentication
➤ M5: Insufficient Cryptography
➤ M6: Insecure Authorization
➤ M7: Client Code Quality Issues
➤ M8: Code Tampering
➤ M9: Reverse Engineering
➤ M10: Extraneous Functionality

24. CASE STUDY
➤ #1: InsecureBankV2
(DEFCON 25)
➤ #2: (CENSORED)
➤ #3: (CENSORED)
paper stack 1 SQ SEPIA 500X by wintersoul1 on flickr, CC-BY-NC-ND 2.0

25. CASE STUDY #1
➤ InsecureBankV2 (obfuscated)
➤ Announced at DEF CON 25
➤ Excellent ‘hack-me’ challenge
➤ Originally not obfuscated
➤ ProGuard rule based on:
“proguard-android-optimize”
➤ More passes: 5 -> 8
➤ Allow all optimizations
(i.e. HV class merging etc.)

26. M1: IMPROPER PLATFORM USAGE
➤ Insecure BroadcastReceiver
➤ Published with seemingly private
action name
➤ Backup-able

27. M3: INSECURE COMMUNICATION
➤ TLS interception
➤ Lack of certificate pinning

28. M5: INSUFFICIENT CRYPTOGRAPHY
➤ App is using cryptographic functions
with constant keys

29. CASE STUDY #2
➤ CENSORED:
This page is unintentionally blank.
Blue Static by get directly down on flickr, CC-BY 2.0

30. M1: IMPROPER PLATFORM USAGE
➤ Massive privacy concerns
➤ Massive permission requests
Blue Static by get directly down on flickr, CC-BY 2.0

31. M2: INSECURE STORAGE
➤ Something written in world readable
manner
➤ Massive logging
➤ Kind of classical no-no
Blue Static by get directly down on flickr, CC-BY 2.0

32. M3: INSECURE COMMUNICATION
➤ Not certain, but yields strong indication
of cleartext HTTP
➤ Location?
Blue Static by get directly down on flickr, CC-BY 2.0

33. M5: INSUFFICIENT CRYPTOGRAPHY
➤ App is using cryptographic functions
with constant keys
Blue Static by get directly down on flickr, CC-BY 2.0

34. M8: CODE TAMPERING
➤ Embedded public keys
➤ What if we replace them?
Blue Static by get directly down on flickr, CC-BY 2.0

35. CASE STUDY #3
➤ CENSORED:
This page is unintentionally blank.
static by Trevor Bashnick on flickr, CC-BY-NC 2.0

36. M7: CLIENT CODE QUALITY
➤ App is registering custom JS interface
with addJavascriptInterface()
➤ in API < 17, JS interfaces could be
exploited to arbitrary OS command
execution
➤ Condition:
➤ Controlling content
➤ Targets or runs API < 17
static by Trevor Bashnick on flickr, CC-BY-NC 2.0

37. GO FURTHER
➤ Roadmaps, TBDs
➤ Further binary patching mode
➤ Further accuracy
➤ Further signatures
➤ Further exploitation mode
➤ ARM code analysis
➤ MSIL code analysis
➤ iOS support
➤ True symbolic exec.
➤ Automatic dynamic analysis
摩周湖 by Sendai Blog on flickr, CC-BY 2.0

38. FURTHER BINARY PATCHING
➤ Status: Mostly done (PR soon)
➤ Introducing variable (in smali)
➤ Allocate a local
➤ Assign constant
➤ Replace offending arg.
➤ Patch DB
➤ Introducing function (in smali)
➤ Introduce templated function
➤ Introduce calls
➤ Patch DB
➤ Opens the way to more automatic code fixes

39. FURTHER ACCURACY
➤ Status: Mostly done (PR soon)
➤ Zoning storage
(e.g. external as insecure)
➤ Solving only interesting args
➤ Selectively emulate API
(e.g. StringBuilder)
➤ Recognizing more TLS pinning modes
➤ Carefully evaluate confidence

40. FURTHER SIGNATURES
➤ Status: WIP
➤ HTTP parameter injection
➤ Path traversal
➤ Client-side XSS/SQLi
➤ Weak crypto algorithms
➤ Insufficient root detection
➤ Questionable use of sensitive data
➤ Taint analysis
➤ File I/O
➤ Network I/O

41. FURTHER EXPLOITS
➤ Status: WIP
➤ TLS Unpinning
➤ Forcefully enabling logging
➤ Exploit generation on issues
➤ Reversing API spec?

42. ARM CODE ANALYSIS
➤ Status: WIP
➤ Native code analysis
➤ Considering radare2 (r2) and/or VEX IR
➤ Problem:
➤ r2 takes time
➤ r2 seemingly cannot disassemble the
whole executable at once
(cf. Produce File in IDA)

43. MSIL CODE ANALYSIS
➤ Status: WIP
➤ Mainly old versions of Unity (Mono)
➤ Considering use of CoreCLR

44. IOS
➤ Status: WIP
➤ Swift, Objective-C, bitcode analysis
➤ Considering use of radare2, VEX IR and
LLVM tools
➤ Problems:
Much as same as ARM code analysis

45. TRUE SYMBOLIC EXEC.
➤ Status: In Research
➤ Symbolic exec. will help
➤ Forward analysis
➤ Evaluating reachability
➤ With it, we might be able to do..?
➤ Partial evaluation
(e.g. Reversing transforms)
➤ Gaining more accuracy
➤ Gaining resiliency against more
advanced obfuscaters
➤ Considering use of VEX IR

46. AUTOMATIC DYNAMIC ANALYSIS
➤ Status: In Research
➤ Similar to MobSF

47. CONCLUSION
➤ We saw it is…
➤ Fast
➤ Accurate
➤ Intuitive
➤ Free as freedom
IMG_2988s by 不憂照相館 on flickr, CC-BY-NC-ND 2.0

48. FAST
➤ No decompiling
➤ Fast lookup with SQL
➤ Because complex query matters

49. ACCURATE (1)
➤ We derive data flow directly over Dalvik
opcodes
➤ Lenient Backtracking
➤ Call stack tracing
➤ Static tracing
➤ Instansic tracing

50. ACCURATE (2)
➤ We can detect issues in (obfuscated) apps
➤ M1: inappropriate CP/BR exports,
privacy concerns, enabled debug/backup
bit etc.
➤ M2: insecure file permissions, logging
etc.
➤ M3: cleartext HTTP, TLS non-pinning etc.
➤ M5: static keys etc.
➤ M7: WebView insecurities etc.
➤ M8: embedded public keys etc.
➤ M9: non-obfuscation

51. INTUITIVE
➤ Comprehensive reporting
➤ HTML for humans
➤ Text for CI
➤ Continuous security

52. FREE AS FREEDOM
➤ GPL-3
➤ https://github.com/monolithworks/
trueseeing
➤ It remains free for good
➤ More fixes and sigs to come
➤ We are striving to make it not only useful
but also essential
Freedom by Mochamad Arief on flickr, CC-BY-NC-ND 2.0

53. QUESTIONS?

54. BRING YOUR APK!

55. FIN.
9.11.2017 Monolith Works Inc.