Teach you how to dynamically debug iOS App (decompile App)
opening
Through this article, you can understand the basic knowledge of iOS reverse engineering, and have a certain understanding of the security of iOS App. Then you can draw inferences from one case to another, find dangerous loopholes in your own app to prevent them, and ensure the security of user data.
In the field of security, offense and defense always exist. Even if the iPhone has a strong security protection mechanism, it can't stop those geeks from being curious again and again and developing many powerful and convenient tools. This article is based on the tools provided by these geeks!
preparation tools
- Mac computers and jailbroken iPhones
- View the mobile phone system catalog tool iFunbox or iTools
- Network Analysis Tool Charles
- Decompiler Hopper , IDA Pro
- View the header file tool class-dump
- Dumpdecrypted , Clutch _
- Debugger lldb or gdb
- Debugging tool: Cycript
HTTP(S) packet capture
HTTP packet capture
Step 1: Get MAC IP
Press the Option key and click the Wireless Network Icon on the Mac menu bar at the same time to see the IP address of the current computer. You can also
view it by typing in the terminal .ifconfig en0
Step 2: Set up the proxy
Make sure that the mobile phone and the computer are under the same WIFI. On the mobile phone, click "Settings->Wireless LAN->Connected WiFi" to set the HTTP proxy:
Server: IP address of Mac computer (eg 192.168.1.122)
Port: 8888
Step 3: Capture the package
On the computer, open Charles. Make a network request on the phone, and Charles will pop up a dialog asking for it
Click "Allow" to allow, Charles will appear the list of HTTP request records of the phone.
HTTPS packet capture
Step 1: Obtain the certificate installation address
Install the SSL certificate to the mobile device. Click Help -> SSL Proxying -> Install Charles Root Certificate on a Mobile Device
A pop-up window appears to get the address chls.pro/ssl
Step 2: Install the certificate on the iPhone
Enter the address chls.pro/ssl in the mobile Safari browser, the certificate installation page appears, click Install, the mobile phone is set to enter the password with a password to install
Step 3: Configure the proxy host
Charles sets up the Proxy. Select Proxy -> SSL Proxying Settings...
Check Enable SSL Proxying and click Add
Host sets the HTTPS interface to be captured, and Port fills in 443.
Let the phone resend the HTTPS request to see the captured packets.
<b> Note: Please turn off the HTTP proxy of the mobile phone if you do not capture packets, otherwise you will not be able to connect to the Internet after disconnecting from the computer! </b>
Get the .h header file
The ipa directly downloaded from the AppStore is encrypted and protected by Apple's FairPlay DRM technology, and the header file cannot be obtained directly using the class-dump tool. However, if it is an App packaged through development, you can directly use class-dump to view all header files. This part of the introduction is to explain how to obtain .h files through this situation.
The installation process of the class-dump tool will not be introduced here. For the specific steps, please refer to Baidu directly.
Go to the directory where appName.ipa is located, change the extension to .zip, and unzip the file to get appName.app.
Then execute:
class-dump -H appName.app -o ./headers/
After the command is executed, you will see all the header files of the app in the headers directory of the current directory.
If the parameters -A -S are added, the IMP address (base address before the module offset) of the class method and property will be marked in the header file.
class-dump -H -A -S appName.app -o ./headers/
SSH access to phone file directory
Install OpenSSH on your jailbroken phone using the Cydia application market, and make sure that the Mac and iPhone are under the same WIFI, and type in the MAC terminal:
ssh root@IP, replace IP with the IP address of the iPhone
Enter the default password: alpine
You can enter the iPhone terminal.
Decompile the App with Clutch
Step 1: Re-sign debugserver
There are two ways to get debugserver.
The first is to get it on a Mac computer
Enter the path /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/DeviceSupport/8.3/DeveloperDiskImage.dmg(8.3 in the path represents the iOS system version, which must be consistent with the prepared jailbreak mobile phone system version). Double-click DeveloperDiskImage.dmg, and copy usr/bin/debugserver in the directory to the specified folder.
The second is to get it in a jailbroken phone
If the mobile phone has been connected to the mobile phone and the app has been debugged through XCode, a debugserver file will be generated in the /Developer/usr/bin/ directory of the mobile phone. Export to Mac desktop via iFunbox. Or use the scp command to cpoy it out.
Re-sign debugserver
That is, add task_for_pid permission to debugserver
Create entitlements.plist and add the following four keys:
com.apple.springboard.debugapplications
get-task-allow
task_for_pid-allow
run-unsigned-codeThe value corresponding to the key is set to true
Put entitlements.plist and debugserver in the same directory and execute the following command:
codesign -s - --entitlements entitlements.plist -f debugserver
This command will re-sign the debugserver and copy the signed debugserver to the /usr/bin/ directory of the mobile phone system.
<b>Note: Do not copy debugserver to /Developer/usr/bin/ path</b>
Step 2: Get the decompiled App executable through Clutch
Put the downloaded Clutch into the /usr/bin/ path of the phone. Then, grant permissions to Clutch, log in to the phone via SSH, and enter /usr/bin/ to execute chmod a+x ./Clutch.
List all applications that can be Clutched by command Clutch -i.
Unpack the application with the specified serial number, such as enterprise WeChat, the serial number is 1, and the command is Clutch -d 1. After the execution is complete, the unpacked ipa will be obtained.
Step 3: Use class-dump to get the .h header file
Use the method described in the above <b>[Get .h header file]</b> to get the unpacked App header file and write down the IMP address of the method to be interrupted.
Dynamically debug the app
The debugger used for dynamic debugging in this article is lldb.
Step 1: Put the iPhone into a waiting state
SSH into the phone and execute the ps -ecommand to get the App PID or project name.
Enter /usr/bin/ to execute ./debugserver IP:port -a PID|appProjectName. The first parameter IP can be replaced with the IP address of the Mac computer, or the * wildcard character can be used to allow all IP debugging; the second parameter port can be written at will. The fourth parameter can specify the PID or project name of the app to debug. For example, the name of the Sogou input method project whose PID is 6019 to be debugged is SogouInput, then the command is:
./debugserver *:1234 -a 6019or./debugserver *:1234 -a ‘SogouInput’
After the execution of this command is completed, the app will enter the state of waiting until it is mounted, and the app will be stuck and click unresponsive. normal phenomenon!
If this command reports an error, such as Segmentation fault: 11, etc., it means that the App has anti-dynamic debugging protection. In this case, it is necessary to first determine which protection scheme the app adopts, and then further find corresponding measures to kill its anti-dynamic debugging protection.
Step 2: Monitor the process and enter the mount state
Reopen a Mac terminal and execute lldbto enter the lldb debug state. then enter
process connect connect://iPhoneIP:port
iPhoneIP is replaced with the IP address of the iPhone; port is changed to the port just specified, ie 1234.
After the command is executed, the app enters the mounted state.
Step 3: Get the ASLR offset of the App
The ASLR offset is actually the offset of the virtual memory address relative to the module base address. There are two concepts to be familiar with:
- The starting address of the module in memory---- the base address of the module
- ASLR offset---- the offset between the virtual memory start address and the module base address
In lldb debugger mode, executeimge list -o -f
Base address after module offset = ASLR offset + base address before module offset (IMP address of method)
The above formula is particularly important, because the "base address before module offset" is displayed in Class-dump, and the "base address after module offset" is what lldb wants to operate. So from Class-dump to lldb to do an address offset conversion.
At this point, the ASLR offset of the App and the IMP address of the method have been obtained.
Step 4: Breakpoints, debugging
Execute in lldb mode, br s -a 'ASLR 偏移量+ IMP'and then execute c, make the App run, trigger a method call, and enter breakpoint mode. Enter to po $arg1print the first argument.
Then, with the package capture tool Charles (such as analyzing network request encryption logic) and Class-dump (such as modifying the method return value of a class), you can dynamically debug the app at will, just like debugging in XCode !
<b>br Command Description</b>
br dis 1 -- disable breakpoint number 1
br en 1 -- enable breakpoint number 1
br dis -- disable all breakpoints
br en -- enable all breakpoints
br del 1 -- delete breakpoint number 1
br del -- delete all breakpoints
br list -- list all breakpoints
Use dumpdecrypted to break the shell app
The principle of the dumpdecrypted unpacking tool is to run the application (the iOS system will first decrypt the program and then start it), and then dump the decryption result in the memory into a file to obtain a new executable program.
Step 1: Generate a .dylib file
Enter the downloaded directory in the terminal, cd dumpdecrypted-masterand then execute maketo generate dumpdecrypted.dylib
Step 2: Find the App's Documents folder path
Log in to the iPhone via SSH, and execute ps -eView Processes to get the PID of the process to be shelled. Then execute cycript -p PIDattach to the PID process. Finally execute [[NSFileManager defaultManager] URLsForDirectory:NSDocumentDirectory inDomains:NSUserDomainMask][0]to get the Documents folder path.
Step 3: Start breaking the shell
Copy the dumpdecrypted.dylib generated in the first step to the .../Documents/ path obtained in the second step, and the command is as follows: scp ~/dumpdecrypted.dylib root@IP:/var/mobile/Containers/Data/Application/2B4C6281-C015-4FF3-A8EC-5E5C7554D447/Documents(Replace the UDID in the path with the UDID of the app you want to break the shell)
Enter the Documents directory and execute DYLD_INSERT_LIBRARIES=dumpdecrypted.dylib /var/mobile/Containers/Bundle/<br/>Application/BFED82A3-3238-4F41-B797-C1CB584CBE05/appProjectName.app/appProjectName(replace the UDID in the path with the UDID of the app you want to unshell; replace appProjectName with the project name of the app you want to unshell)
After the command is executed, a file named appProject.decrypted will be generated in the current directory. This is the executable file of the App after the shell is broken. All you need is it! Use Class-dump to get the header files. Or decompile with Hopper or IDA Pro.
Add anti-dynamic debugging mechanism to your app
ptrace
In order to facilitate the development and debugging of application software, a method for tracking and controlling running processes has been provided since the early versions of Unix, that is, the system call ptrace().
Through ptrace, another process can be debugged and traced. At the same time, ptrace also provides a very useful parameter, PT_DENY_ATTACH. This parameter is used to tell the system to prevent the debugger from attaching.
Therefore, the most commonly used anti-debugging solution is to implement anti-debugging by calling ptrace.
sysctl
When a process is being debugged, the process will have a mark to mark that it is being debugged, so you can check the information of the current process through sysctl to check the current debugging status if there is this mark bit.
When the debugger is detected, it will exit, or create a crash, or hide the project. Of course, you can also check regularly for this mark.
syscall
In order to switch from user mode to kernel mode, the system provides a system call function syscall, and the ptrace mentioned above is also implemented through system calls.
The corresponding number of ptrace can be found in Kernel Syscalls27.
26. ptrace 801e812c T
So the following call is equivalent to calling ptrace:
syscall(26,31,0,0,0);
<b> arm </b>
syscall is realized from user mode to kernel mode through soft interrupt, and it can also be realized by assembling svc call.
If you think it's good, welcome to pay attention to my public number!
