1. The learning process dimension chat; Eureka615298
Like my learning process, from the beginning of my junior year to the end of the first semester of my junior year, I mainly focus on playing ctf. I participated in the group team to solve the problem in the reverse direction. The reverse problem type is like Windows, Linux and Android will be involved, and they are quite complicated. Then I started to contact Android reverse engineering during the process of playing ctf. From the first year to the third year, I also learned piecemeal, that is, I can learn in ctf. Just make the question, without too much in-depth exploration.
Then from the end of the last semester, that is, after the end of the junior year, at the beginning of this year, I began to separate the focus of learning from ctf and shift to Android reverse. Then the time to really focus on Android reverse engineering is almost four months.
The way to learn is to read the book first. I will give you the "Authoritative Guide to Android Software Security" written by the predecessor of the bug. I will understand all the terms and scan the blind spots. Then I will start reading a lot of articles, reading posts, and repeating. Now, and then it’s almost time to start the actual combat by myself, find the app to analyze and reverse engineering.
In fact, the biggest gain is in actual combat, because in actual combat, various problems are often encountered, especially some inexplicable problems may be encountered. At this time, it is a more interesting process to solve the problem, although it is also very heady. Big.
Then, some of the apps analyzed were relatively simple, and they were completely and successfully analyzed. In many cases, the analysis process was not very smooth, and it would get stuck. Then, after a period of time, I got new ideas and succeeded again.
There are also some apps that are really more difficult, such as the reinforcement of the enterprise version. The current level cannot be analyzed, so let's put it first.
There are still some that have a certain degree of difficulty, but they are not too difficult to analyze. After learning new knowledge or tools, they will come back and analyze again.
Throughout the process, I learned a lot and accumulated a lot of experience. Then, if it feels meaningful after a complete analysis, it will be posted and shared.
2. Common analysis tools
In the process of reverse analysis, several tools such as IDA, JEB, frida, jadx, Charles, and MT manager are more commonly used.
The analysis of the Java layer is that JEB, jadx and frida cooperate with each other for static analysis, dynamic debugging and hooking.
The so layer is analyzed by ida. If static analysis is more difficult, dynamic debugging is used. Most of the time, you will first run with frida hook libart, print out the parameters of the RegisterNatives function, and get the name and address of the registered function.
In addition, during the dynamic debugging process, sometimes it is necessary to dump the dex file and the so file, and the idapython script and idc script will be used.
3. Frida hook and shelling
frida is a tool that I like very much. Most of the time, I will not choose to do dynamic debugging first, but use frida for hooking. I use frida to be more proficient in the Java layer operation, and I haven’t tried it myself on the so layer. Over.
I mainly use other people's projects for frida to operate on the so layer. For example, before the so file, use the frida hook libart tool to get a shuttle to print out the name of the so and the offset address of the function.
Another example is the overall dex dump operation during unpacking. I will try to operate frida-unpack or frida-dexdump.
The former is the overall dump of the dex file by hooking some functions of the libart.so library, which is the most common unpacking point openCommon or openMemroy. The latter is to dump the dex file as a whole through the memory search dump.
Regardless of the overall instruction extraction, these two tools are very typical dex file overall dump ideas.
Then what I learned about shelling is that the idea adopted by Fdex2 is to hook the loadClass function of the class java.lang.ClassLoader to obtain the returned Class object cls, and then use the getDex method of the java.lang.Class class and com.android. The getBytes function in the .dex.Dex class finishes dumping the dex in the memory. This idea can also be realized by frida's very simple code.
Then I extract shells for instructions. I only focus on learning and understanding theoretical knowledge. I haven't really dealt with them in actual combat, but a plan and focus of my next study is to learn to extract shells against instructions.