The following is a reverse analysis process of an APP, mainly to better learn the ideas and solutions of the analysis process, so that the APP function can be quickly analyzed in the subsequent process.
root detection
Install the APP package on a rooted phone and open it. The result will prompt: Root should be detected.
Use jadx to load APK, global search keyword: current device detected
This string information has been searched. Its ID is toast_app_fail. Search this ID again to locate where this string is referenced.
Many calls were found, mainly in the two files MainActivity and StartActivity. Because these two files are usually the first two classes started in the APP, many detections will be placed in the startup phase to implement the calls.
Notice that each call has a different suffix, comma, exclamation point, etc. The prompt string is a comma, so select the one with a comma suffix to enter.
Seeing that the DeviceUtils.a() function is called, if it returns true, a string of detection information will pop up and then exit. The next step is to analyze how the a() function is implemented.
The above code determines whether the running environment is rooted by checking files. The conventional way to detect whether it is rooted is to try to open the su files in the /system directory. If it can be opened, it means that you have root permissions.
You can use the MT manager to open the APK package, find the a function in the DeviceUtils class, and modify the smali code so that the a function returns false directly without detection (you can also use androidkiller, jeb, etc.).
Just modify the return value to return v0. Repackage and install. The string of text popped up again, but the suffix became exclamation
Number!
Continue to search for string information and locate the location where this exclamation point appears:
Locate below the DeviceUtils.AntiRoot() logic. Such covert security protection really makes crackers ecstatic. Next, locate and analyze the AntiRoot function, and find that it is a native function, and the loaded so is myapplication: globally search for the AntiRoot keyword in the so through ida
It is found that the su file is still being checked. If check_su_files() detects that it is root, it will return "yes". If not, it will return "no". This corresponds to the detection in the java code.
Next, you can directly use the MT manager to modify the java code and change the comparison "yes" to "f*ck". In this way, even if the root is detected, the detection and comparison of the java layer will fail.
All the above root detection is bypassed. The app can be opened normally. But when I open it, it goes blank.
This situation is usually caused by not getting the correct return data.
After the APP is opened, it will definitely request various data from the backend. If the data is abnormal, it will not be displayed normally. It’s time to grab the package and take a look.
Proxy detection
Open the mobile agent and start the fiddler tool to capture packets. As a result, the APP cannot start normally again. This time this dialog box pops up:
The APP was afraid that he would not know that he was testing the agent, so he gave a very warm reminder. Then continue searching for string analysis.
Seeing that the string id is toast_api_proxy_fail, find the reference:
The process of root detection is basically the same. But it calls a b function to detect whether there is an agent. Let’s analyze the b function:
The logic of proxy detection is to ensure that http.proxyHost (proxy address) is an empty string, or http.proxyPort (proxy port) is -1.
Next, just modify the java code directly so that it always returns false. After this, you can successfully open the app and capture the data packet:
However, the inside of the APP is still completely white. Looking at the returned data, we find that it is encrypted: Next, we will analyze the data decryption.
Data decryption
Generally, the APP client will use okhttp as the http client to send and receive requests. (Currently, there is also cronet as a client, but it is only used by large manufacturers, and most of them are customized on okhttp)
The way okhttp works is a chain of responsibility, also called pipeline transmission (pipelien). Each link handles some things. For example, in the sending stage, the first pipeline is to add basic information, such as device id, timestamp, etc. The second pipeline is to calculate the signature value, and the third pipeline is to encrypt the sent data and then send it out.
Analyzing okhttp in the APP, it was found that it was obfuscated and protected:
The creation of okhttp is done in the okhttpclient class. Obfuscation can usually only confuse the function name and class name, but it cannot confuse the specific implementation of the function, including some special strings. You can start with the string to find okhttpclient.
Download a copy of the source code of okhttp and check the characteristics of the okhttpclient class:
Source code address:
https://github.com/square/okhttp
It was found that there are three consecutive strings "timeout" in the internal builder, which cannot be confused. We search globally for "timeout" in jadx:
Click in and take a look and find that the structure is exactly the same as that of okhttpclient, so you can judge that this is the okhttpclient class.
Looking at the reference, we also found the location where the APP created okhttpclient:
Another feature of the client in okhttp is the setting of read and write timeouts. From TimeUnit, we can see that this is setting the read and write timeouts of http requests.
At the same time, you see a series of .a functions at the back, which are adding piplines one by one. (It’s called an interceptor in okhttp, but I personally feel it’s essentially a pipeline).
View these piplines respectively, one is to add request headers:
There is another one related to data processing:
See the response, bodystring string, and d_key_three inside. What is this doing? Why do the secret key and return body appear? , click in to see the function f5865a.a:
I saw the characteristics of password, iv, SecretKeySpec, Cipher, and doFinal. It is obviously doing aes decryption. By using AES decryption, the mode is CBC and the padding method is PKCS5padding.
Use frida to hook this a function and see what the decrypted value is?
Directly force the correct secret key into the decryption function, and finally the decryption is completed.
The returned data shows "Signature verification failed." The next step is to analyze the signature verification function.
Signature verification
Because the signature verification failed, the correct return data was not obtained. It is necessary to analyze how the signature is calculated.
I saw the sign field in the http request header:
Generally, signatures are named like sign, sig, authcode, sec, etc. For example, a certain sound is named after a god in Greek mythology.
jadx searches for "sign" globally. (Pay attention to using sign with double quotes to search, which will improve search efficiency. Because usually when generating sign, sign will be used as the key and put into a map. And the key is a String, so there must be characters where the sign is generated in the code. string "sign")
Analyze the generation process of a7, because sign comes from the assignment of a7.
First, the ts parameter is added as the timestamp. Then connect all parameters end to end. Then add a suffix similar to the aes key. Then calculate a2 through another a function, and then make a2 all lowercase. This is the signature generation process.
Take a look at another a function:
is calculating the MD5 digest. Then the problem lies in the suffix similar to the secret key.
Indeed, because the signature is wrong, the wrong suffix is returned, but the aaxx function is used, which is different from the ddmm function used in aes.
In the same way, error will be returned if the signature is incorrect, and the real suffix will be returned if it is correct.
See how signature verification is done locally?
Obtain the signature through reflection, then calculate the MD5 and compare it with the hard-coded correct SIGN_MD5.
In this case, we hook the aaxx function so that it returns the correct value:
After running the frida script again, the correct data was successfully obtained:
At the same time, the app interface is also normal, but it shows that it has expired :)
Bypass restrictions
Successfully bypassed root detection, proxy detection, and signature verification. But each device only has 2 hours of free opportunity. If we want to have sex for free, what should we do?
Usually APP will track the device through a unique device identifier, that is, device fingerprint technology. Deviceid can directly obtain the unique identifier of the Android device itself (disabled in higher versions of Android), it can also obtain the MAC address of the device, or it can generate a UUID or a random string and hide it in a corner of the device. When the apk is reinstalled, first check to see if there are any related files hidden here before. If there are, read them directly as the device ID. If not, create one. This will ensure that the device can still be tracked before and after the apk is deleted. Of course, if you can find this file and delete it, the app will think it is a new device the next time you install it.
First find where the deviceid is and search for deviceid globally:
I found many places, including from app and from sdcard, followed by an sdcard related function:
I saw the device id read from the f file. Look at the path of the f file:
Sure enough, there is a file under the alarm file in the SD card. After opening it, it is indeed the device ID used when sending data.
Delete this file, restart, and find that the device ID still has not changed. Is it stored elsewhere?
Notice the from app above:
See that the deviceid is obtained from the b function, look at the b function:
It turned out to be taken from sharedpreferences. SharedPreferences is a way to store data internally in the app, while the sd card is an external storage method.
We opened sharedPreferences and saw customdeviceid:
See how his device ID was obtained?
First, a 10-digit random string a2 is obtained through a(10),
So the device id is randomly generated. Each new device has 2 hours of free time, which is 7200 seconds. We consider regenerating the device ID every 7000 seconds, so can we have unlimited cup refills?
Look at where the app obtains the deviceid and sends it to the server. Notice that one of the previous okhttp pipelines adds the http header:
See that the deviceid is obtained through the a() method. View the a() method
Finally, a string is returned. In fact, there is no need to continue following it, it is nothing more than getting it from the APP or the sd card. We just hook it here.
Theoretically, you only need to write a random string generation algorithm to ensure that it remains constant within 2 hours. Here I use the timestamp divided by 7000 to obtain:
Write a function and then use android studio to compile the smali code. Just insert the corresponding smalidaima before the return of the a() function:
smali code for random device id:
Insert it before the a() function returns. In this way, we will use a new deviceid every two hours. To the server, it seems that a new device has installed its app, and then you can use it for another two hours of free time. .
Original link
https://bbs.kanxue.com/thread-275423.htm
How to learn hacking & network security
As long as you like my article today, my private network security learning materials will be shared with you for free. Come and see what is available.
1. Learning roadmap
There are a lot of things to learn about attack and defense. I have written down the specific things you need to learn in the road map above. If you can complete them, you will have no problem getting a job or taking on a private job.
2. Video tutorial
Although there are many learning resources on the Internet, they are basically incomplete. This is an Internet security video tutorial I recorded myself. I have accompanying video explanations for every knowledge point in the roadmap above.
The content covers the study of network security laws, network security operations and other security assessments, penetration testing basics, detailed explanations of vulnerabilities, basic computer knowledge, etc. They are all must-know learning contents for getting started with network security.
(They are all packaged into one piece and cannot be expanded one by one. There are more than 300 episodes in total)
Due to limited space, only part of the information is displayed. You need to click on the link below to obtain it.
3. Technical documents and e-books
I also compiled the technical documents myself, including my experience and technical points in participating in large-scale network security operations, CTF, and digging SRC vulnerabilities. There are more than 200 e-books. Due to the sensitivity of the content, I will not display them one by one.
Due to limited space, only part of the information is displayed. You need to click on the link below to obtain it.
4. Toolkit, interview questions and source code
"If you want to do your job well, you must first sharpen your tools." I have summarized dozens of the most popular hacking tools for everyone. The scope of coverage mainly focuses on information collection, Android hacking tools, automation tools, phishing, etc. Interested students should not miss it.
There is also the case source code and corresponding toolkit mentioned in my video, which you can take away if needed.
Due to limited space, only part of the information is displayed. You need to click on the link below to obtain it.
Finally, here are the interview questions about network security that I have compiled over the past few years. If you are looking for a job in network security, they will definitely help you a lot.
These questions are often encountered when interviewing Sangfor, Qi Anxin, Tencent or other major companies. If you have good questions or good insights, please share them.
Reference analysis: Sangfor official website, Qi’anxin official website, Freebuf, csdn, etc.
Content features: Clear organization and graphical representation to make it easier to understand.
Content summary: Including intranet, operating system, protocol, penetration testing, security service, vulnerability, injection, XSS, CSRF, SSRF, file upload, file download, file inclusion, XXE, logical vulnerability, tools, SQLmap, NMAP, BP, MSF…
Due to limited space, only part of the information is displayed. You need to click on the link below to obtain it.