Reverse Engineering Tools: Difference between revisions

From iPhone Development Wiki
(→‎otool: asking people to add stuff)
(→‎Executable analysis: syntax highlighting whee)
Line 81: Line 81:


Example usage:
Example usage:
<source lang=text>
<source lang=bash>
bash$ strings crash_mover
bash$ strings crash_mover
moveLogsAtPath
moveLogsAtPath
Line 93: Line 93:


Example usage:
Example usage:
<source lang=text>
<source lang=bash>
bash$ nm CoreTelephony
bash$ nm CoreTelephony
000234c4 t +[CTCall callForCTCallRef:]
000234c4 t +[CTCall callForCTCallRef:]

Revision as of 08:38, 5 March 2014

This is a draft that needs your help. Can you improve it? Add some details!

While developing a tweak, you may find these tools useful to analyze how iOS and apps work, and to find where to interpose your functionality.

Runtime analysis

The following tools are useful for analyzing a program during runtime.

GDB / LLDB

When writing software, a debugger can help determine what is causing a crash, to find backtrace information on certain points of a program, and so on. Attaching the debugger to normal processes running on the iPhone can be done with the description on debugserver, and see Debugging on iOS 7 for more context.

Cycript

Cycript allows you to run your own code in an attached process out-of-the-box, with some JavaScript-syntax goodies to make writing code more convenient. It allows for useful runtime analysis of a program (such as for instance getting the complete view hierarchy, or checking out the properties of an object), and it allows for easy prototyping of a tweak (by hooking methods with a Substrate bridge, changing objects freely and calling functions, etc.).

Logify

While not a runtime analysis tool, Logify takes an Objective-C header file containing a class interface and generates a Logos file hooking all methods in the given class, and for each hook logging the call of the method (with parameters) to the syslog. Logify allows for convenient analysis of what methods of a class get called during runtime, and when.

weak_classdump

When class-dump (described below) can't analyze an executable and generate header files with class interfaces (due to App Store app encryption, other encryption, malformed binaries etc.), another option is to get these definitions from the runtime. weak_classdump is a Cycript tool which attaches into a project and generates class-dump-like output files.

weak_classdump can be used to dump a single class, like this:

iPhone$ cycript -p Skype weak_classdump.cy; cycript -p Skype
'Added weak_classdump to "Skype" (1685)'
cy# weak_classdump(SkypeAppDelegate, "/tmp/")
"Wrote file to /tmp/SkypeAppDelegate.h"

It can also be used to dump all the classes in a bundle (in this case, the main bundle):

iPhone$ cycript -p Skype weak_classdump.cy; cycript -p Skype
'Added weak_classdump to "Skype" (1685)'
cy# weak_classdump_bundle([NSBundle mainBundle], "/tmp/SkypeHeaders")

See the weak_classdump section of Cycript Tricks for another example.

Executable analysis

The following tools can be used to analyze an executable.

dumpdecrypted

App Store app executables are encrypted. dumpdecrypted can generate a decrypted executable out of it:

iPhone$ DYLD_INSERT_LIBRARIES=dumpdecrypted.dylib /var/mobile/Applications/.../Application.app/Application
iPhone$ ls Application*
Application #original executable
Application.decrypted #decrypted, generated executable

(Or see weak_classdump above.)

class-dump, class_dump_z, classdump-dyld

From a given executable, class-dump and class_dump_z will generate header files with class interfaces. (class-dump may produce better headers than class-dump-z for recent binaries.) This allows for an analysis of what methods exist in the executable, which can help you guess which ones to hook to get given functionality.

All default (private and public) libraries on iOS are combined into a big cache file to improve performance in /System/Library/Caches/com.apple.dyld/dyld_shared_cache_armX (see dyld_shared_cache for more details). If you want to class-dump private frameworks, you can either install Xcode and class-dump the frameworks on your Mac using the above tools, or you can use classdump-dyld, which works right on your device. Remember that the resulting files are not the original headers, so use them with caution.

You can also find other developers have done this process for many frameworks and compiled this information into repositories:

Disassemblers

Disassemblers are useful when you need an in-depth analysis of a binary. These programs convert the compiled code into assembly for your examination. Assembly is hard to understand for beginners and is platform-dependent (ARM assembly is very different from x86 assembly), so you need a good knowledge of assembly to find disassemblers useful.

IDA

IDA (Interactive Disassembler) is a popular program for disassembling binaries. It supports a plethora of processors. IDA has tons of features and has been in development for more than a decade.

It is a commercial application, and it requires some time getting used to it. For analyzing Objective-C applications, KennyTM's fixobjc2.idc script is useful for exposing Objective-C method definitions and calls.

Hopper

Hopper is quite new and only supports a small subset of the features that IDA has. It is fast and has a nice user interface. However, the produced assembly code is not as good as the one produced by IDA.

otool

Do you know anything about using otool? Add some notes to this section!

strings

strings is a simple utility that will print all the strings in a given binary.

Example usage:

bash$ strings crash_mover
moveLogsAtPath
Could not open and lock %s: %s. Proceeding with copy anyway.
Extensions
...

nm

nm is a utility that displays the symbol table of a given binary.

Example usage:

bash$ nm CoreTelephony
000234c4 t +[CTCall callForCTCallRef:]
0001ee90 t +[CTEmailAddress emailAddress:]
000199b8 t +[CTMessageCenter sharedMessageCenter]
0001db54 t +[CTMmsEncoder decodeMessageFromData:]
...