To reverse analyze and modify an Android app, the first is to unpack and package the APK, this part of the online information is overwhelming, no longer repeat it. It is worth mentioning that if Apktool cannot be unpacked or packaged, it is possible to try the Shakaapktool developed by the Chinese on the basis of Apktool, in addition to usingAndroidkiller This tool, of courseAndroidkiller Internal is the use of Shakaapktool to unpack the package.
There is a lot of information about how to unpack and package, decompile Java code, and modify Smali code, and it is easier to do it step by step. Dex2jar, Jd-gui obtained the anti-compilation of Java code, but how to analyze the code, find the key to make changes, is the most important, but also the difficulty lies. I recently need to analyze an APK anti-compilation after the volume of Pure Java code has reached more than 100 MB, how to find the key in this 100 MB code and modify, it is a very headache.
There are several ways to analyze code in books and online materials:
1. Use the Logcat tool in the Android SDK to view the log of the app runtime.
To see the app output log in Logcat, you need to have any of the following two conditions.
① the ro.debuggable value in the/default.prop file in the root directory of the Android system you are using is 1, if this value is 1, you can see all the processes on the phone in Ddms, and you can debug them or view their output logs. But the general mobile phone will not open this debug switch, of course, you may say that directly modify the/default.prop file is not on the line. No, because the change to reboot will not take effect, but a reboot,/default.prop will return to the original state, because/ The default.prop is stored in the boot.img RAMDisk, which is reloaded from the ROM each time it restarts, so you must modify the RAMDisk in the boot.img and re-swipe it into your phone to reach your goal. Specific steps can be searched online, because too much trouble left to like to toss the people to toss. Of course, you can also brush the phone on the Millet MIUI development version of the ROM, its/default.prop file ro.debuggable default is 1, you can easily debug the program.
② you want to analyze this Android app apk in Androidmanifest.xml with a sentence android:debuggable=true. But almost all published applications will not open this debug switch. Of course you can use Apktool to unpack, modify Androidmanifest.xml, and repack. However, some applications do a special treatment, can not be unpacked or packaged with Apktool, or do anti-packaging processing, packaging after the run will flash or not allow you to login account. In this case, you can not repackage the anti-packaging issue before you resolve it. Instead of using the Android emulator, the Android emulator on most PCs has a ro.debuggable value of 1 in the/default.prop file in the default root directory and can debug all apps installed on it. The best simulator for development is genymotion, followed by the Android SDK's own simulator, but sometimes the app you want to analyze may not run on these two emulators, because you know, some app developers don't want you to run their apps on the simulator, do simple processing, At this time, you can try the simulator such as Bluestacks, these simulators are more like the real phone, the application is not easy to detect.
OK, now you can see the log of the application output you want to analyze in logcat, but the problem is that many applications will not output all of its logs directly with Android.util.Log. Where to lose, the ghost does not know, perhaps a file, perhaps the server sent to it. However, it is not difficult to find the output code of the log in the decompile code. Find all of its logs in logcat later by modifying its Smali code or by using xposed to hook the associated log output function and redirecting the log to Android.util.Log. This allows you to see a lot of useful information.
2. Use TraceView to see which methods are called.
TraceView is a performance analysis tool in the Android SDK, as its name is, it is a performance analysis tool, not a reverse analysis tool, so it is very unpleasant to use. You can start profiling in Ddms, then point to the Android app and stop profiling in DDMS. You can see all of the method calls and time-consuming, but you see the overwhelming system functions, do not see the sequence of calls can not see the call stack, but also in the overwhelming system functions to find the application of its own code function, simply dashed. You can also put android.os.Debug.startMethodTracing () and android.os.Debug.stopMethodTracing () These two lines of code correspond to the Smali code inserted before and after the call to a function that you want to parse before you view the resulting profiling file. But the effect is still frustrating. Of course you can use Dmtracedump and Graphviz to generate the call Relationship view of the code based on the profiling file. Otherwise, the result is very little, with a lot of system functions, very ugly. This can be referred to "Android security technology decryption and prevention" or online search information.
2. Grab the bag. Many Android applications (except games, stand-alone applications) communicate with the server through the HTTP protocol, and if you can catch a packet, it is certainly helpful for reverse analysis. However, many applications communicate with the server as HTTPS communication, withtools such as Wireshark and tcpdump cannot catch clear text. However, according to the information on the Internet, the use of Fiddler can catch HTTPS packets, try it, sure enough, but only a small part, I want the key data not caught. The best-performing dafa in the xposed is Hook Dafa, using the Hook module, the HTTP client library API that hooks the target application to catch all plaintext data. However, you need to look at the app's code first to see what HTTP client library it is using, which APIs are used for that library, and then write the Hook module. It takes a bit of time, but the effect is good.
3. Commissioning. There are many methods and tools for debugging Android apps without source code. In the online data are all over, almost all debugging methods are tried, summed up two kinds of relatively good debugging methods.
①ida Pro Advantages: Debugging when the Smali code step walk very accurate, one step is a step, will not go disorderly, breakpoint hit is also very accurate. Disadvantage: Local variables, register content display is too poor, always known, a lot of published application code has been processed, will not leave the variable name of local variables, debugging in addition to this, the other variables are all registers V0 v1 v2, in this case you use IDA Pro debugging, in addition to this, The value of a variable is not visible. For example, all registers are bad type except this. That means you use Ida Pro to debug, basically only look at the execution process, see no data, what a ghost! But don't worry, after reading the official file of Ida Pro, it turns out that the content of the register is not impossible to display, but that it doesn't know what type it is inside and requires you to tell it manually! You have to open the Watch view window, and every step of the way, take a look at how many registers are in the locals, what their serial numbers are, then add them to watch view and tell them what it is. Then how do you know what the type is? You can read it in Jd-gui Java code and then tell Ida Pro. Since the registers are changing at any time, you need to look at the Java code every step of the way during the debugging process, and then tell Ida Pro the type of register to see the value of the variable. Can imagine, debugging up how hard, and this debugger is not stable, at any time will be stuck, Ben collapse, you need to have enough patience to toss it.
IDA Pro Official Document: https://www.hex-rays.com/products/ida/support/idadoc/1669.shtml
Https://www.hex-rays.com/products/ida/support/tutorials/debugging_dalvik.pdf
②smalidea
It's an artifact! It was released in the second half of last year (2015), and if it had been there before, then other OSS debugging tools would have been abandoned by now. It's a IntelliJ idea/android studio plugin developed by the Smali/baksmali team that lets you debug Smali code directly in your favorite Android studio or IntelliJ idea! Although its version is V0.03, it is already very useful. The key point is that as long as you add register monitoring to the watches, stepping through each step will automatically recognize the type and display the content. When I saw this effect, immediately refreshed, ran out to buy a bottle of snow and green, ready to do something big, the problem came. Every time you debug, you have to run the app manually, then attach to process debugging in idea, and if I want to debug the code when the app starts, it's not going to work. However, it is not known that you can use ADB to start an application and let it wait for the debugger. Simply use the command that was originally used to launch the appadb shell am start plus one parameter-D. Finally wrote a script using Python, first with adb shell am start-dlaunch the app, then use ADB shell PS to get all the process IDs, retrieve the process ID of the target app, and finally use ADB forward tcp:8700 JDWP: Process ID mapped to port 8700. So I just need to set the debug port to 8700 port on IntelliJ idea, every time I want to debug the app just run a script, and then I can click on IntelliJ idea to start debugging, very convenient and carefree. However, this is a small problem, the biggest problem is the use of Smalidea for debugging, the single step walk is not allowed, feel most of the time is not upstream, sometimes jumping, obviously only go to the middle of the function of the half, and there is no jump statement, but click Next, the function is over, it is bursting. Do not know that I debug the code has been confused or how to say, always happy and happy mood suddenly fell into the bottom.
Smalidea and instructions for use: Https://github.com/JesusFreke/smali/wiki/smalidea
adb profile:https://developer.android.com/studio/command-line/adb.html
other debugging methods, such as andbug because I feel more difficult to use, there is no in-depth understanding. Finally combined with the advantages of the IDA Pro single-step alignment andSmalidea variable shows the advantages of quasi, and finally I choose two together! First use Ida Pro to see the bit, see the code execution process, to the suspected key place to use Smalidea directly down the breakpoint to see the value of the variable. Of course you'd better prepare two computers, one with Ida Pro and one with Smalidea. During commissioning, IDA Pro explored the road, and then went directly to the Smalidea side to see the road (variable) details.
If you feel that this is not a bad way to debug, please see the next article, in the next article, we will use a clever way to comfortably lie in bed to the app's execution process.
This article was published by Charlessimonyi in CSDN blog:http://blog.csdn.net/charlessimonyi/article/details/51989096 Reprint please indicate the source
Android App reverse-the best two non-source debugger
