TuT [TUTORIAL] How To use GikDbg - LLDB for Windows!

Oxytyramine · November 22, 2014

What is GikDbg?
GikDbg is a mobile platform assembly-level debugger, which is an application debugging tool for security researchers.It is based on: OllyDbg (32-bit assembler level analysing debugger for Microsoft? Windows); GDB (GDB, the GNU Project debugger); LLVM (collection of modular and reusable compiler and tool-chain technologies).

What features can GikDbg support?

ELF / Mach-O executable file static analysis;
Android / iOS App dynamic debugging;
Android / iOS remote console;
ARM assembler；
ARM disassembler；
Device file uploading and downloading；
Built-in GDB and LLDB；
Support for memory breakpoint, software breakpoint, conditional breakpoint;
Support for multi-threaded debugging;
Support for assembly code level file patching.

Download GikDbg

In this tutorial we will describe how to use the debugger gikdbg iOS App, App calculator explain our system as an example to explain the operation and Step by step, as well as some notes here.

Step 0. Front Description

Mobile client: iPhone 5, iOS 7.0.4, gikir_iserver v1.1.build140520.1;
PC side: ParallelDesktop virtual machine, Windows 8.0, gikdbg v1.1.build140520.1;

Step 1. Connect the device.

Click on the icon for the phone side gikir_iserver run the service program, PC-side execution iDebug / Device / Login (USB) menu, get the following output shows a successful connection:

If the situation can not connect appears in this step, please check them one by one:

1) Is there a process before lldb.exe left hand to kill and then restart gikdbg connection;
2) whether the 6080 port gikir_iserver used was left before gikir_iserver_root or / bin / sh process takes manually kill or restart the device and then restart gikir_iserver;
3) Are there other programs that use the Apple USB drive services and gikdbg conflicts, such procedures manual to kill and then restart gikdbg connection.

After the connection is successful, we can choose a different debug mode by iDebug / Option / Debugger, their characteristics are as follows:

GDB mode - debugging process equipment on 32 main thread or when debugging is recommended to use the specified function, the process of debugging symbols provided by gikdbg;
LLDB mode - recommended depth debugging process, this model is loaded for a long time, LLDB can analyze the information it needs some symbols, symbolic debugging process by gikdbg and lldb;
LLDB FAST mode - when the confirmatory debugging recommended, this mode load time is short, the process of debugging symbols provided by gikdbg. This mode is increased relative to the GDB mode debugging 32 64 equipment and multi-threaded code debugging features.

Step 2. Select the App Process
In iDebug / File / Attach menu pop-up window in the process list to find the calculator process:

Double-click or click Attach complete step process of selection;

Step 3. determine the patch operation
If this is the first time to debug the App, the confirmation dialog box will pop up as follows:

Patch App for initial commissioning of conduct are:
1) Delete MH_PIE logo to process each time you load the base is fixed;
2) Record the UUID value of App;
3) If it is FAT formatted App disabled lowest and the highest schema version;
4) If it is then decrypt the encrypted App App;
5) into debugging aids dynamic library gikir_iserver_injecter.dylib;

You can patch above the list of processes and the console menu program list, right-of unpatch removed App restored to its original state before the patch.
If you choose to cancel will not be able to debug App, if you choose determines the implementation of the operation and return the entire patch App folder to the $ (GIKDBG) / iosapp / encrypted directory, decrypted App executable file back to $ (GIKDBG) / iosapp / decrypted directory. At this point can be decrypted executable statically analyzed by ida or gikdbg.
After the patch properly executed will be prompted to restart the App:

After the restart App repeat Step2 enter Step4.

Step 4. Mount App Process

This step GDB and LLDB FAST mode will be faster, LLDB mode will wait about 2-10 minutes, according to the size and complexity of the App;
If a long time (5 minutes) to wait for the main window yet into the CPU, you can manually cancel the wait.

Step 5. The main window into the Cpu

All goes as follows CPU will enter the main interface:

Step 6. Select the main module
Execution iDebug / View / Module get the following window:

Select the main module and then double jump to the main module CPU window.

Step 7. Check the main module information
In the main module CPU to perform the disassembly listing window Right View object and View mach-o can be static data analysis:

Step 8. breakpoint debugging
F2 function found under the rear break and we are interested in running, hit the breakpoint interface:

This time you can debug function that we are interested in, and have the following precautions:
GDB mode - likely F7 F8 will always remain in the breakpoint address, this is the GDB Bug, you can cancel the breakpoint and then F7 F8 resolved;
LLDB mode --F8 can not single step through the function call, this is LLDB the Bug, can be resolved through F4 to the specified address.

Step 9. Check objc message call chain
If we want to see the news of the call chain App can be realized by $ detectobjc command:

This feature is not available in LLDB FAST mode. If you want to customize the output, Hook can be injected into the process of debugging functions in a dynamic library gikir_iserver_injecter.dylib:
int filter_objc_message (const char * cls, const char * sel);
cls is the class name, sel is the message name, return 0 printout, return a representation ignored;