This article mainly describes the practical analysis of the AliCrackm.apk program reverse engineering, and it is also a practice and practical exercise for dynamic debugging and anti-debugging technology in Android reverse engineering.
Open the program, input the verification code, and submit it after the prompt verification failed,
Use jadx_gui to open it, and the code logic is to input the verification code and pass it to the so library, if the verification is successful, load ResultActivity, otherwise, pop up the verification code verification failed,
Change the suffix of the apk file to zip, unzip, and then drag the so files in the lib directory into IDA for analysis,
First look at Java_com_yatong_crackme_MainActivity_securityCheck,
View the code logic above the two if loops of byte_6359 and byte_635A, which have no important logic. Below, GetStringUTFChars converts the string type to char and returns the value to v5. Below is the return value of off_628C to v6 and a while loop,
View the code logic above the two if loops of byte_6359 and byte_635A, which have no important logic. Below, GetStringUTFChars converts the string type to char and returns the value to v5. Below is the return value of off_628C to v6 and a while loop,
The string "aWojiushidaan" is found, and the test submission finds it is not the answer. Analysis of the while loop finds it is a dead loop, so it is preliminarily judged that off_628C may be the verification code verification logic, and the address is 12A4,
After the static registration analysis is completed, there is still a JNI_Onload dynamic registration, continue to analyze,
A while loop can be seen, with sub_16A4 and sub_17F4 two functions below. Continue to analyze sub_17F4,
It can be seen that some fields have been encrypted and their content cannot be seen. Continue to view sub_16A4 and find that there are sub_130C and dword_62B0, which are also encrypted.
Since all fields in the dynamic registration are encrypted and cannot be viewed, the program may decrypt them after running, so consider dynamic debugging next.
Since dynamic debugging is required, use AndroidKiller to open the apk, add android:debuggable="true" in AndroidManifest.xml, and then recompile. At this point, debugging is supported,
Install the recompiled apk,
Push the android_server from IDA to the emulator,
Connect to the emulator with adb and switch to the root account,
Enter the /data/local/tmp directory and modify the permissions of android_server,
Run android_server,
Port forwarding and suspend the program,
Open IDA, attach the program,
Click ok,
Select the package name of the program, click ok, after loading, check the corresponding options,
Run with F9 and load the program,
View loaded so libraries with Module list,
Libcrackme.so is loaded successfully, select static registration debugging,
Run the program with F9,
The program crashes, so it can be judged that the program has anti-debugging, and it can be judged that JNI_Onload is the anti-debugging code logic,
Select JNI_Onload for loading,
Set a breakpoint at JNI_Onload,
Run to this breakpoint with F9 and step down with F8, during static analysis, it can be judged that there is an if loop jump, so when stepping down to BLX R0, F7 enter to see the internal code logic,
The data window follows R0,
Step down with F8, you can see dlsym and getpid, so it can be judged that it is decrypting fields,
Continue down, you can see a series of fields such as creating threads and killing processes, so it can be judged that the so library code in this so library is a detection program to check if the program is being debugged, and if it is debugged, it will interrupt the program,
Continue down and you will jump out of the function,
So far, the analysis of the if loop code is completed,
Continue to scroll down to see sub_16A4 and sub_17F4,
So, by scrolling down in the dynamic debugging window, you can see sub_AB85B7F4, therefore, BLX and BL correspond to sub_16A4 and sub_17F4 in static analysis, so set a breakpoint at BLX R7,
Execute the program to this breakpoint,
Entering the internal code logic, you can see sub_AB85B6A4 and loc_AB85B6B8,
That is, the sub_130C and dword_62B0 corresponding to the static analysis,
Through testing and verification, the BL in loc_AB85B6B8 is the key to continuously executing process detection debugging,
Therefore, directly NOP the BL at this location,
After F2 modification is completed, continue to enter static registration for verification logic debugging,
After entering, press P on the code logic,
Judging from the previous static analysis, the verification logic is located at B2A4, so set a breakpoint at this address,
Run to this breakpoint with F9, the program starts, input a string of characters arbitrarily, and perform verification,
Step down with F8,
After stepping over, you can see that the value is given to R2, so enter R2 to view the data, and you can see a string of characters aiyou, bucuo,
In program input validation,
Program verification successful, successfully obtained the flag,The reverse engineering of the app is completed here. In this analysis, knowledge of smali code analysis, static analysis of the so layer code, dynamic debugging with IDA, and anti-debugging are involved, which is also a practice and consolidation of knowledge in many aspects.

评论已关闭