A brief introduction overview over some beginner reverse engineering and anti debugging techniques.

1. TSC Summit #3 - Reverse
Engineering & Anti
Debugging techniques

2. Why reverse engineering?
● Because it’s fun
● Malware hunting
● Curiousity
● Military or commercial espionage
● Security auditing
● Increase (reduce) public security
● Product analysis
● Loss of documentation and/or source code

3. What can be reverse engineered?
● Physical hardware
● PHP/Javascript/Python/Ruby code
● Microsoft’s .NET family
● Java/Scala/Clojure and other JVM languages
● C/C++/Rust and other system languages
● Swift/Objective-C and other Apple products
● More or less everything

4. What tools is used for reverse engineering?
● Physical hardware
● Debug tools
● Dynamic binary instrumentation
● Forensics tools
● System monitoring
● Kernel drivers
● Hardware breakpoints
● Hex editors

5. What about decompilers?
● Assembly/Bytecode to “source code” again
● The quality of produced code is varying
● Works best with script and VM languages

6. What about decompilers?
● Assembly/Bytecode to “source code” again
● The quality of produced code is varying
● Works best with script and VM languages
● Script languages are usually never “compiled”
● The .NET family is without doubt easiest
● The JVM family is next in line
● Erlang? Sorry, forgot about it, but google says it’s
doable in the minutes before this presentation :)

7. Decompilers in action (.NET)
● 100% reversible
● 100% readable
● Can recompile
● Symbols (names)
● Strings (text)
● Keep all metadata

8. Decompilers in action (JVM)
● 30-60% reversible
● 70% readable
● Can’t recompile
● Symbols (names)
● Strings (text)
● Some metadata

9. Decompilers in action (Apple’s Objective-C/C++)
● 20-30% reversible
● 30% readable
● Can’t recompile
● Symbols (names)
● Strings (text)
● Some metadata

10. Decompilers in action (Native code)
● 0-10% reversible
● 5% readable
● Can’t recompile
● Symbols optional
● Strings (text)
● Barely metadata

11. Why anti debug?
● Protect proprietary software
● Malware in need of hiding
● Hide baaaaad code
● Just being a douchebag
Help text

12. How to do anti debugging for VM code?
● Obfuscation mostly for JVM/.NET
● Hide functionality in native shared libraries
● Runtime decryption of strings
● Multiple entry points (start of application)
○
● Various of debugger detection techniques

13. How to do anti debugging for native code?
● All the same ways as VM code can
● Deny run in virtual machine
● Operating system hooks/API to disable “debuggable”
● Debug yourself :)
● Make sure LD_PRELOAD/DYLD_INSERT_LIBRARIES is empty
● Screw up ELF/Mach-O headers just enough
● Entry point via Unix signals (Linux / OSX)
● Entry point via Thread Local Storage (TLS) (Windows only)

14. How to do anti debugging
● We’ll focus on VM based languages
● Anti debugger / evasion techniques in native code
○ Hard for n00bs
○ Requires much system knowledge
● String decryption at runtime might help
● Decryption of code at runtime (Not easily done in JVM)
● Transform your code to something a little more ugly

15. Before obfuscation
Obfuscation in JVM: Packing local vars into bitfields (PLVB)

16. After obfuscation
Obfuscation in JVM: Packing local vars into bitfields (PLVB)

17. Before obfuscation
Obfuscation in JVM: Reorder instructions (LRAII)

18. After obfuscation
Obfuscation in JVM: Reorder instructions (LRAII)

19. Inject JavaScript to explore native apps on Windows, macOS,
Linux, iOS, Android, and QNX.
● Scriptable
○ Python
○ Javascript
○ Swift
○ C
● No root needed
● No jailbreak either
● Easy to start with

20. Compile your whole application with the “mov” instruction
● Horrible
○ No control flow
○ No syscalls
● C/asm products
● Only x86?
● Binary size rises

21. Mikal Villa
mikal.villa@knowit.no, @mikalv
2017-06-19 The Security Chapter - Summit #3
Thanks