First, preface
In the previous article in detail the Android can be used at this stage of the anti-debugging strategy, we in the reverse application, the general is now the first step back to solve the anti-debugging, or the subsequent steps can not be carried out, of course, if you are static analysis of the acquisition is not necessary. But sometimes you have to use dynamic debugging to crack, you need to operate. At present, anti-debugging strategy mainly includes the following methods:
First, own attach process, occupy pits first, ptrace (ptrace_traceme, 0, 0, 0)!
Second, signature verification is an indispensable choice, local check and server-side verification two-pronged!
Third, the use of the system API to determine the application debug state and debugging properties, the most basic protection!
Iv. rotation Check Android_server debug port information and process information, an effective way to protect Ida!
The rotation checks the value of the Tracerpid field in its own status to prevent additional debugging from being attached to another process!
So this article one by one explains how to solve these kinds of methods of anti-debugging scheme.
Ii. Summary of methods
First: Find the key method, comment the code
This approach requires a static analysis of the code, and a key approach to the anti-debug Code feature comment, which can be used to deal with all of the above anti-debugging scenarios, but for the rotation check this way is not appropriate, why? Because if you read this article: Take off 360 reinforcement application protection shell; The students who have been working will find that the pain is in the way of removing the anti-debugging function. So this comment code, personally feel that only applies to the following types of anti-debugging:
First, self attach process
This can IDA open the key so code, find this code:ptrace (ptrace_traceme, 0, 0, 0), directly nop off. This is not difficult, because on a line of code, plainly speaking of a few arm instructions. Ida Static analysis So is also stress-free.
Second, signature verification
This has been introduced in the previous article, students who do not know can view this article: Android to crack the application of the signature check logic; Finally, a simple method of filtering signature verification is summarized: after opening the application in JADX, the global search string content: " Signatures ", this can be positioned to get the application signature information, and then you can trace the verification in turn. Find the exact local code to comment directly.
However, if the service-side interaction information carries the signature check, and the signature check is in so, then the need for additional operations, this part of the knowledge will be in a separate article in detail how to crack.
Third, call the system API to determine whether the current application is in debug state
This way of seeing the logic of our implementation is still relatively simple, calling the system's android.os.Debug.isDebuggerConnected () method directly and judging the currently applied properties: Applicationinfo.flag_debuggable, then you can still use the global search for the post-compilation application content, find this part, and then directly annotate the code.
Second: Modify the IDA Communication Port
The above analysis, directly using the static mode + Comment code function to solve the previous three anti-debugging scenarios mentioned. But there are two unresolved, the following will be described in detail a very reliable and convenient permanent method. And this part of the content is the focus of this article. First take a look at how to solve the anti-debug scenario mentioned earlier using check Ida Debug Port 23946. This is actually a simple idea, because you check the port number is the default 23946, so if we can change the port number to other values, then actually solved.
Modifying this port number is also relatively straightforward: There is a solution on the web that Android_server itself supports custom port numbers, and the commands are simple:
./android_server-p12345; directly with the-p parameter, note that there is no space between the port number and the parameter:
Some people say that this method is so simple, the following is not introduced, of course, I do not write the purpose of the article is not for the sake of simplicity, but in order to let everyone know more knowledge, would rather more detours, go many ways out. And the above way every time add-p more trouble, I would like to use another way to solve the problem at once, and I would like to be familiar with IDA in the process of use, using Ida to open the Android_server file, in fact, he is elf format, open stress-free, open after use shift+12 View the string content interface:
Finding these three key string contents, we can detect the following message after running past Android_server:
Find these three string contents, the following is simple, one place to modify, double-click the contents of the string entry:
Check press the X key to toggle:
Select the first jump to arm instruction:
This is the graph view, which can be toggled using the SPACEBAR:
See arm instructions,LDR r5,=0x5d8a; where 0x5d8a is the decimal 23946, also is the default port number, so here we just need to change this arm instruction to MOVS R5, #0xDD; R5 can be re-assigned, here is the value of DD, that is, 221; Here's a small problem is how to make changes, IDA can switch to the hex view to modify the editing binary, but such changes will not take effect into the source file, So here we have to use a binary editing tool 010Editor, after we open android_server with this software, using Ctrl+g can jump directly to the specified address, using Ctrl+f can jump to search content, remember the following two shortcut keys.
Here we see the 4D is: LDR R5, =0x5d8a corresponding instruction hexadecimal value, about the instruction and hexadecimal value between the conversion can go online search a gadget. We want to turn it into MOVS R5, #0xDD instruction, the corresponding hexadecimal is: DD 25, where DD is the immediate value, 25 means MOVS R5 instructions. So the following can be modified directly:
Once the modification is complete, save it, so we've modified it one place, and two things are exactly the same:
Continue to modify init_sockets, commands are the same, remember address: b98a, go to 010Editor to modify:
Then continue to modify Ida Android 32-bit ... Secretariat
Remember address: b64c, go to 010Editor to modify can:
So we're all done, save the Android_server file, open it again with Ida, find a place to see if the changes were successful:
It is true that the modifications were successful, so let's copy the Android_server to the device and see if the port is 221 (0xDD):
See, here the successful modification, Android_server listening port, mainly when you open Ida to connect the need to note that the port is 221, instead of 23946, or you can use the ADB forward tcp:221 ... command to forward also can!
The third type: Modify the Boot.img file, skip the reverse debugging
This approach is to solve the current anti-debugging strategy, that is, rotation check the Tracerpid value of the process, so we need to modify the device's Boot.img file, this value directly to the death of 0. On how to modify the operation, see the snow has been the great God explained the very detailed process, I just follow this process to operate: http://bbs.pediy.com/ Thread-207538.htm, because each device boot.img are different, so in the process of operation may encounter a lot of problems, so the following will be the process of my operation to explain the problems encountered, by the way refining the steps:
First step, you have to have a root phone that can be tossed
Because now is playing boot.img, the back of the brush machine, so you have to make a sense of not much meaning of equipment, even if a brick is no harm. Of course not a brick.
Step Two: Extract the Zimage kernel file in the root environment
Here I use Samsung NOTE2 equipment, I brush a CM4.4 system, according to the Great God's paste first to find the system boot file location, this path must note:/dev/block/platform/[Each Device directory is not the same]/by-name where subdirectories in the platform directory are different because each device is different, you need to be aware of the name of your device directory, and then go to by-name, use the ls-l command to view the details, find a boot, remember link's path address, Here is/DEV/BLOCK/MMCBLK0P8, then use the command to export boot to boot.img
DD IF=/DEV/BLOCK/MMCBLK0P8 of=/data/local/boot.img
ADB pull/data/local/boot.img boot.img
Some people here may encounter a problem is, see multiple boot, such as Boot1,boot2, here can choose boot, and some will find that there is no option, then you can only brush the other system to operate.
Step three: Unzip the boot.img file with the Bootimg.exe tool
This tool I will be in the back with the compression package, command usage is very simple,
Unpacking is: Bootimg.exe--unpack-boot boot.img
Pressure pack is: Bootimg.exe--repack-boot
There is a pit here, I found two versions, the first version of the tool after the operation of the brush machine is always black screen startup failed, and finally found the second version of the tool to succeed. In fact, these tools are simple in principle, is to parse the boot.img file format, because the boot and recovery images are not a complete file system, they are an Android custom file format that includes a 2K file header, followed by a kernel with gzip compression, followed by a RAMDisk memory disk, and then tightly Follow the second stage of the loader program (this loader program is optional and may not have this part in some images):
What we want is the kernel kernel information. So after working with this tool, you will find a few directories and files:
After decompression there is a kernel file, this is the kernel file, and ramdisk.gz is released to the device directory content, that is, the INITRD directory, access to view content:
See, this is the final device directory structure, you can see here are init.rc boot files, default.prop configuration files and so on.
Next we are going to special processing of the kernel kernel file: Copy the kernel file to a file named Zimage.gz file, and use the 010Editor tool, ctrl+f shortcut to find the hexadecimal content 1F 8B 08 00, found after the previous data are all erased, Make the zimage.gz file a standard gzip compressed file, so you can use Gunzip to unzip it. Command: Gunzip zimage.gz; getting to know the zimage after pressure is the final file we're going to deal with.
Fourth step: Ida Open zimage kernel file for modification
With the kernel file Zimage from the previous step, open with Ida directly, but when you open it you need to be aware of the setting options:
Then set the start address to 0xc0008000:
Why this is set to this starting address, because the Linux boot kernel address is 0xc0008000, after opening, we can directly shift+f12, view the string content, because we want to change the value of tracerpid, so directly search the string " Tracerpid "Value :
Double-click to enter, this time we can write down this address, and then subtract just our offset address 0xc0008000:
That is 0xc0a3853c-0xc0008000=0xa3053c, here is not like the snow God Operation so complex, first to locate function location, modify instructions, because each device is different, instruction code is not the same, there is no commonality, so there is a better solution, is the format string value that is changed directly to Tracerpid, the original formatted string content is:
\t%s\ntgid:\t%d\npid:\t%d\nppid:\t%d\ntracerpid:\t0\t\nuid:\t%d\t%d\t%d\t%d\ngid:\t%d\t%d\t%d\t%d\n
here should use the C language placeholder%d, to make the value of the fill, then we can put the tracerpid of the placeholder%d, changed to ' 0 ', but '%d ' is two characters, so we can change to ' 00 ', or ' 0\t ', or ' 0\n ' Just make sure the modified string content is good for it . In this way, the value placeholder for this tracerpid is invalidated, and the value is always 0. And the above calculated address is we want to go to the 010Editor operation of the address, 010Editor open zimage file, ctrl+g jump to 0xa3053c Place:
Here we change it to the ' 0\t ' value, the corresponding hexadecimal is: 30 09; So we can change the success.
Fifth step: Generate the Modified boot.img file
Here the operation is actually a reverse process, first use the gzip command to compress the above modified kernel file zimage:gzip-n-f-9 zimage;
Use 010Editor to overwrite the compressed zimage.gz binary data to the original kernel file 1F 8B 08 00 location (back to write back can not change the size of the original kernel file and modify the contents behind the original kernel file, otherwise it will be very troublesome), The new kernel file content is now available. Here need special emphasis, that is, I stepped on the pit: for example, kernel originally is 10M size, 1f8b0800 before the deletion is 1M, we modified the zimage.gz size is 8M, then we write back the cover must be 1m~9m position, and kernel front 1M content and behind 1M content can not have any change, make mistake, brush opportunity appears to start failure situation. Here are some examples of my actions:
This is my modified after the compressed zimage.gz file, the last data is 0x65e18d, and then the full selection copy good, remember, then go to the original kernel content:
The 1f8b0800 position in kernel is 0x47a0, so we need to replace the content we just assigned from here, where do we end it? Add these two addresses together: 0x65e18d+0x47a0=0x66292d; that is, to the end of 0x66292d:
So the original kernel content size will certainly not change, always is 0x662967, so in the replacement content must not change the content. After the replacement is complete, replace the new kernel file with the original kernel file and generate a new boot.img file using the Bootimg.exe tool mentioned earlier.
Sixth step: Brush Machine boot.img File
There is a pit here, the FastBoot command is used when the machine is being brushed, but the most common problem is this error:
This is because the device has not started fastboot, about each device start fastboot different operation, such as Millet is the power key + volume minus, Samsung is the volume minus +home key + Power key, the specific equipment can be self-search online. To the FastBoot interface to run the FastBoot again, you can:
FastBoot Flash Boot boot-new.img
Then restart the device by running FastBoot reboot. Some students in the operation, always into the fastboot failure, resulting in fastboot command run error, this really can't solve that will change a phone to try it.
This time we start the device, and then debug an app, found that his tracerpid value is always 0, because I previously changed tracerpid to ' 00 ' string, is also possible:
Because the feeling is not normal, so there is a re-change to the ' 0\t ' value. It's all possible.
Note: Be sure to save the original extracted kernel file boot.img, when you turn the device into a brick start failure, you can be the original boot.img brush back!
iii. extension of content
I don't know what we were looking at: 360 Protection case for ruggedized applications when it comes to a tool mprop, His role is to be able to rewrite the system's in-memory ro.debuggable This property value, so that we do not have to decompile the app every time, and then add android:debuggable= "true" in Androidmanifest.xml, Let the application be debugged.
At that time, there is a disadvantage of this tool is that he can only modify the value in memory, when the device restarts will be invalidated, then we can make him permanent, in fact, this property value is in the system root directory in the Default.prop file, the device will be parsed into memory in the boot. So if we can change the value in this file to 1, it will be permanent. In the above unpacking boot.img, said there is a initrd directory, in fact Default.prop is in this directory:
Here we will directly change it to 1, because we have now changed the boot.img operation, then the way to change the function. How convenient!
Iv. Summary of extracting kernel operations
First step: after the device root, look at the device's kernel file path: cd/dev/block/platform/[specific device specific view]/by-name, and then use the command ls-l view the Boot property, remember the path
Step Two:dd if=/dev/block/[your kernel path] of=/data/local/boot.img
ADB pull/data/local/boot.img boot.img
Step Three: use the Bootimg.exe tool for boot.img unpacking, get the kernel file, copy the kernel file as a file named Zimage.gz, and use the 010Editor tool, CTRL + F shortcut keys to find the hexadecimal content 1F 8B 08 00, found after the previous data are all deleted, so that the zimage.gz file into a standard gzip compressed file, this way you can use Gunzip decompression. Command: Gunzip zimage.gz
Fourth Step: Open the Zimage kernel file using Ida, remember to set options and start Address: 0xc0008000; After opening, use Shift+f12 to find the string "Tracerpid" value, remember the file start address, then subtract 0xc0008000; open kernel file with 010Editor, ctrl+g jump to this address, make content modification, change tracerpid that placeholder '%d ' to ' 0\t ' save
Fifth Step: First Use the gzip command to compress the above modified kernel file zimage:gzip-n-f-9 zimage; then use 010Editor to overwrite the compressed zimage.gz binary data to the original kernel file 1F 8B 08 00 position (write back can not change the size of the original kernel file and modify the contents behind the original kernel file, otherwise it will be very troublesome)
Sixth step: start the device as FastBoot mode, then use the fastboot command to brush the machine: fastboot flash boot boot-new.img, and then reboot
Summarize a Picture:
The hole that I stepped on
Pit One: be sure to keep the most original extracted kernel file boot.img, in order to prevent your brush from failing, you can restore the operation.
Pit II: When modifying the Tracerpid value, simply change the '%d ' placeholder to ' 0\t ', without altering the arm command operation.
Pit III: use in restoring kernel files Be sure to remember that you cannot change the size of the original kernel file.
Pit Four:fastboot command failed to run, the device must be in the FastBoot mode, if not yet then change a cell phone.
v. Technical Summary
First: The first solution to anti-debugging is relatively simple, that is, static analysis of the code, find the location of the anti-debugging, and then comment code.
Second: for monitoring Ida Port anti-debugging, by modifying the Android_server boot port, here also learned how to modify the port number operation.
Third: Modify the kernel file so that Tracerpid is always 0, Ro.debuggable property value is always 1, this operation process is still a bit cumbersome, there are certainly a lot of problems, and everyone encountered problems may be different, but this is a process of exercise, if successful means that you learned to extract kernel operations, understand the kernel file structure, learn to analyze kernel files, modify kernel files. is of great significance. For example, you can also modify the device's start-up diagram, slowly you can customize your own ROM.
Four: In the above operation, also familiar with the use of IDA tools, learned that the string content is always the best way to find the problem, Ida find the string shirt+f12, 010Editor ctrl+g and ctrl+f find shortcut keys.
Tools for unpacking boot.img files: http://download.csdn.net/detail/jiangwei0910410003/9793611
Vi. Summary
This article is mainly about how to solve the anti-debugging problem, mainly three kinds of programs, the last one to modify the mobile phone kernel file operation is more cumbersome, encountered problems will be more. But if it succeeds, it's much easier to hack backwards later. So try to read the article, manual operation. After reading the article, remember more points like and share spread, if there is a reward is the best!
Click here for more information:
Focus on the public, the latest technology dry real-time push
Coding Beautiful Technology Circle
sweep into my "tech circle" World
Sweep and make a small series
please specify when adding: "Code Beautiful" Thank you very much!
Android Reverse Tour---"Anti-debug" scenario resolution (additional modification of IDA Debug port and modification of kernel information)