Hack in the Box GSEC 2016 - Reverse Engineering Swift Applications
0 likes278 views
Swift apps present some challenges for reverse engineering compared to Objective-C apps. The main challenges are that Swift is less dynamic and there is limited tooling available. To analyze Swift apps, one can disassemble the binary and demangle Swift function names using the swift-demangle utility. For apps with Objective-C code as well, the class-dump tool can provide some class information. Runtime inspection using debuggers is also possible but less straightforward than with Objective-C. Overall, while more difficult, many typical reverse engineering tasks can still be performed on Swift apps.
Hack in the Box GSEC 2016 - Reverse Engineering Swift Applications
- 1. Reverse Engineering Swift Apps Michael Gianarakis Hack In The Box GSEC 2016
- 2. # whoami @mgianarakis Director of SpiderLabs at Trustwave Flat Duck Justice Warrior (FDJW)
- 3. Motivation • Seeing more and more Swift being used in apps that we test (fan boys like me tend to adopt new Apple technology quickly) • Google is even considering using Swift as a first class language on Android… (http://thenextweb.com/dd/2016/04/07/google- facebook-uber-swift/) • Wanted to dive into some of the key differences with Swift and look at the challenges with respect to Swift app pen testing • Focus is on “black box” app pen testing - for a deeper dive into Swift language RE I recommend Ryan Stortz’s talk at Infiltrate (http://infiltratecon.com/archives/swift_Ryan_Stortz.pdf)
- 4. How Does Swift Affect Testing? • Will dive into the detail in the presentation but the reality is not much in most areas, quite a bit in others? • Most issues in iOS and OS X apps are due to poor design decisions or misconfiguration and incorrect implementation of Apple and third party frameworks and libraries. • The main thing that has changed is how you reverse engineer the application
- 6. What is Swift? • Compiled language created by Apple • Released publicly in 2014 at WWDC and has seen multiple revisions since. • Open source with official implementations for iOS, OS X and Linux. • Intended to replace Objective-C eventually
- 7. Syntax (just the basics to follow along)
- 8. Syntax (just the basics to follow along)
- 9. Syntax (just the basics to follow along)
- 10. Syntax (just the basics to follow along)
- 11. Types • All basic C and Objective-C types -> String, Bool, Int , Float etc. • Collection Types -> Array, Set, Dictionary • Optional Types -> works with all types, no more nil pointers like Objective-C • Swift is a type safe language
- 12. Objective-C Compatibility • Objective-C compatibility and interoperability • Uses the same runtime environment • Still supports C and C++ in the same app but can’t be called from Swift like Objective-C • Can allow for some dynamic features and runtime manipulation
- 13. Other Language Features • Barely scratched the surface • Structs, Protocols, Extensions, Closures, Enumerations, Optionals, Generics, Type Casting, Access Control, Error Handling, Assertions…. • Automatic Reference Counting • Unicode… • var 💩 = 💩 💩 💩 💩 💩 ()
- 16. Challenges • Less dynamic than Objective-C • Less flexible than Objective-C in some areas • Can make it harder to do some of the standard tasks you would do on a standard app pen test • Less of an issue now because most Swift apps will include be mixed with Objective-C • Limited tooling • We will explore this in more detail
- 17. Challenges • Rapidly evolving syntax, APIs and features and Apple doesn’t care too much about breaking changes. • v1.0 - September 2014 • v1.1 - October 2014 • v1.2 - April 2015 • v2.0 - September 2015 (Open Sourced, Linux) • v2.2 - March 2016 • v3.0 - Late 2016
- 18. Reversing Swift Apps • Two primary reverse engineering activities when conducting a “black box” pen test • Dumping and analysing class information from the binary • Retrieving information at runtime using debuggers, function hooking, tracing etc.
- 20. Class Dump? • The most common and easiest way to retrieve class data from an Objective-C binary is the class- dump utility • class-dump retrieves class information and formats to look like the equivalent of an Objective-C header file • Usually one of the first things you do when looking at an app
- 21. Class Dump?
- 22. Class Dump?
- 23. What next? • So class-dump-z doesn’t work with Swift binaries :( • Now what? • Let’s start diving into the binary
- 24. Symbol Table • What do we get if we dump the symbol table?
- 25. Symbol Table • What if we look for something we know is in the binary?
- 26. Name Mangling • Looks promising but it’s a far cry from the output of class-dump and is kind of hard to make out • Swift stores metadata about a function in it’s symbols in the process “mangling” the name.
- 27. Name Mangling __TFC9hitb_demo4Duck13printDuckTypefT_T_ Indicates it’s a Swift method
- 28. Name Mangling __TFC9hitb_demo4Duck13printDuckTypefT_T_ Indicates it’s a Swift method Indicates it’s a function
- 29. Name Mangling __TFC9hitb_demo4Duck13printDuckTypefT_T_ Indicates it’s a Swift method Indicates it’s a function Function of a class
- 30. Name Mangling __TFC9hitb_demo4Duck13printDuckTypefT_T_ Indicates it’s a Swift method Indicates it’s a function Function of a class Module name with length
- 31. Name Mangling __TFC9hitb_demo4Duck13printDuckTypefT_T_ Indicates it’s a Swift method Indicates it’s a function Function of a class Module name with length Class name with length
- 32. Name Mangling __TFC9hitb_demo4Duck13printDuckTypefT_T_ Indicates it’s a Swift method Indicates it’s a function Function of a class Module name with length Class name with length Function name with length
- 33. Name Mangling __TFC9hitb_demo4Duck13printDuckTypefT_T_ Indicates it’s a Swift method Indicates it’s a function Function of a class Module name with length Class name with length Function name with length Function attribute
- 34. Name Mangling __TFC9hitb_demo4Duck13printDuckTypefT_T_ Indicates it’s a Swift method Indicates it’s a function Function of a class Module name with length Class name with length Function name with length Function attribute Parameters
- 35. Name Mangling __TFC9hitb_demo4Duck13printDuckTypefT_T_ Indicates it’s a Swift method Indicates it’s a function Function of a class Module name with length Class name with length Function name with length Function attribute Parameters Return Type
- 36. Function Attributes f Normal function s Setter g Getter d Destructor D Deallocator c Constructor C Allocator
- 37. Return Types a Array b Boolean c Unicode Scalar d Double f Float i Integer u Unsigned Integer Q Implicitly Unwrapped Optional S String
- 38. swift-demangle • So now we know roughly the way the names are mangle you could use this to create a script that “de-mangles” the names • Apple has already thought of that and includes a utility called swift-demangle to do just that
- 39. swift-demangle
- 40. swift-demangle • With nm and swift-demangle and some shell scripting you should be able to easily grab the function signatures from an app • Should be all you need to get basically the same information you would from class-dump to start assessing the app
- 41. class-dump-s • Hacked together script that demangles names and formats the output to approximate the output of class-dump • Written in Swift • Demo
- 42. Stripped Binaries • CAVEAT: If the developer stripped symbols from the binary then these techniques obviously won’t work. • Reverse engineering stripped binaries is a bit more complicated
- 43. Objective-C Compatibility • Part of the reason it’s much easier to get class information from Objective-C binaries is because it’s necessary for the Objective-C runtime to have that info • So what happens when you import Objective-C frameworks or use Objective-C in your app?
- 44. Revisiting Class Dump • The latest branch of class-dump by Steven Nygard (the original class-dump utility) has limited support for Swift. • Need to download and build from source (no binary release yet) • https://github.com/nygard/class-dump
- 49. Other Options • Disassemblers (i.e. Hopper, IDA Pro) • Necessary for lower level insight into the app • To demangle Swift function names https:// github.com/Januzellij/hopperscripts
- 50. Function Hooking
- 51. Hooking Swift Methods • Still possible. • Much easier with in mixed Swift/Objective-C binaries. • Can still write tweaks with Mobile Substrate.
- 53. Hooking Swift Methods • Hooking getter method (works!)
- 54. Hooking Swift Methods • Hooking setter method (kinda works…)
- 55. Hooking Swift Methods • Certain functions in Swift are inlined and the class constructor is one of them (which is directly setting the instance variable) • So in this case the setter will only be called again by the top level code. • If you call from there it works.
- 56. Hooking Swift Methods • Changing the instance variable directly (works but not a good idea probably)
- 57. Wrap Up
- 58. Wrap Up • So not all hope is lost when it comes to your standard pen test workflows with Swift apps • A bit more of a pain in the arse if you don’t get access to the source code • Most issues in iOS and OS X apps are due to poor design decisions or misconfiguration and incorrect implementation of Apple and third party frameworks and libraries.
- 59. Next Steps • Improve the class-dump-s script :) • Runtime inspection (was going to demo this but ran out of time :( ) • cycript works but not as straightforward as with Objective-C • LLDB works well if you are familiar with it • Will hopefully write a blog post soon
- 60. Q&A?