Secondary packaging of Android apps (APK files), Android apk

Secondary packaging of Android apps (APK files), Android apk

Many developers, whether individual or company, do not pay much attention to the security of their own applications, that is, whether the code will be tampered with by criminals, malicious code insertion, spam ads, or even theft of user information. I did not care too much, but I did not find the severity of the problem until I pirated an application released on the market a few days ago and uploaded it to some application markets! At the beginning of the year, I did not know that the app in the city was pirated and I was still complacent. I downloaded a mobile phone and found that many spam advertisements were inexplicably displayed in the mobile phone notification bar, I have not installed some other applications, but they appear on my mobile phone. I am wondering, the long-clicking notification bar information can display the information of the application that published the notification, let's get in and see my application, Mom! What's wrong with this? I didn't advertise it! As a result, I decompiled the installation package and found that y6 exists in the original package, and many codes including Service and Cycler are added to the configuration file, the most depressing thing is that the package name was changed. Finally, I deleted all the embedded advertisement code. After the package name was changed back, I packed the package again, what do you think ?? What do you consider when releasing your own applications ??

So long-winded, let's look at how the bad Silver is repackaged! We should be familiar with decompilation. apktool is enough. But how can we modify or insert the code and finally compile the apk? (Note: You can leave this process as if it is a stream.) The folder generated after decompiling the apk with apktool contains a smali folder,

This is the essence of the application. All the code is here. After opening it, you will see all the suffixes. smali file, open a file and check its code. It seems that I have never seen it. By the way, it is the Dalvik virtual machine instruction language. The modified code is also modified here. You can go to Baidu, the following is a simple example of how to use apktool to decompile, modify code, compile and sign the code, and install the modified application for testing:

1. decompile the apk using apktool:

First, I wrote a simple example and used Eclipse to generate a test apk (Signed), main code, and running result.

MainActivity. java

Next we will start decompilation:

Put the test file in the apktoolfolder and rename it to 123.apk. Run APKTool. cmd:

After selecting 1 decompilation, a folder named APK is generated. Open the folder and the Directory shown in the first image. Open the smali folder and find the MainActivity. smali file to open. Find the following code:

These codes are actually one-to-one correspondence with our source code. Some of the source code can be found here, But smali uses the assembly language. Therefore, if you want to make complex modifications, you still need to learn the smali syntax.

2. modify the code:

This example is relatively simple, so it won't be too copied. Let's change "test my application" to "Haha, your application has been cracked" and test it!

3. recompile:

Save the modification and return to the root directory of apktool. Open the cmd file and select 2 or 3 to start the re-compilation. After the execution is successful, press enter to sign the file, if the re-signed application is re-installed, the signature inconsistency error will be reported. Therefore, you need to uninstall the original application and re-install and run it.

At this point, the second package is successful! Before writing this article, I also decompressed several games and re-packed them. After finding the corresponding code, I can modify the paid gold coins, however, sometimes the modified gold coins or diamonds may be detected online with signature parameters. The re-packaging signature must be inconsistent with the original signature, in fact, further research is required to crack it!

What do you think? When we release an application, we must check whether there is a risk of secondary packaging of our application. We can use the above method to test it, if there is a problem, we must try to reinforce it. (Note: Only obfuscation of code cannot prevent second packaging.) otherwise, after being used by some criminals, we will not lose ourselves, the company also includes the interests of users, which will also cause some damage to its reputation!

Looking back, Let's guess how my application was installed with malicious advertisements? I personally think that the above method is used to decompile, put the smali file that has been written and generated into my bag, then make some configuration in the list file, and modify the package name, finally, package again (this result is justified. I decompile the second package apk again, delete all the inserted code and configuration code, and change the package name back, for the third package, there is still no problem after installation, and besides the advertisement, except the signature is different), the last point is to repackage the version, version number, the package names can be modified. You must pay attention to this!

Final attach apktool tool: http://download.csdn.net/detail/baiyuliang2013/8077501

Note: if you have an issue during use, you can replace aapt.exewith aapt.exe in eclipse.

How can we prevent Android apk from being decompiled and use any encryption method to protect dex source files from being injected with malicious code to prevent secondary packaging?

1. obfuscation of java code. Add useless code or rename it to make the decompiled source code difficult to understand.
2. The key code uses jni to call local code and is written in c or c ++. Compared with the class file, so is relatively difficult to decompile. Developers need to be familiar with how to write c or c ++ code.
3. If your time or technology is limited, there is now a third-party encryption platform in China. Recently, we have a very active website called love encryption. We suggest you try it and it is free of charge.
In general, APP encryption protection is a relatively difficult technology, and the easy-to-learn security performance is not good. Technology is constantly being updated, so there is no absolute security. It is better to hand over the service to a professional.

Prevent project from being repackaged during android Development

According to statistics, the main reason for APP decompilation is that developers do not pay enough attention to the prevention of Android APP apk decompilation or decompilation, or the technology is not complete. Because of the openness of the Android system and the transparency of the commonly used technologies in the industry to prevent apk decompilation, the apk can be easily decompiled and cracked. In this environment where mobile internet security is highly valued, we often talk about security protection topics for mobile users, such as user privacy protection and account security protection. One problem that is ignored is APP security protection in the blank area of mobile security.
Technically speaking. Anti-injection, secondary packaging, DEX shelling protection, DEX command dynamic loading protection, advanced obfuscation protection, can ensure the dynamic and static security of the APP, SO Library Protection, c/C ++-level code protection. Bytes. Developers only need to upload their own applications to automatically analyze which vulnerabilities can be exploited by the application and fix the vulnerabilities to protect their own applications.