This article mainly introduces two simple signature verification methods, and how to bypass verification for secondary packaging; we know that the signature is a valid identity for Android software, because the secret key file used for the signature is ours Unique, and when our app is repackaged, the app’s signature information will inevitably be tampered with, so we can decide whether the app needs to be suspended according to whether the signature of the software is the same as the signature when it is released; then Since there is this method, why is our software still cracked? That’s because the cracker changed our code logic when decompiling the app, so that we could not execute our original verification code correctly, such as changing the if judgment, returning an incorrect return value, and rewriting the verification method, etc. , This is the idea of crackers to bypass verification, and it is also a problem that we need to consider in development.
Java code signature verification is briefly introduced here, the pure java logic signature verification method, the Android SDK provides a method to detect software signatures, we can use the hashCode() method of the signature object to obtain a hash value, in the code Just compare its value. Below is the code to get the signature information of the current runtime
Next, we need to compare with the signature information when we released it. Here we have encrypted the Hash value MD5
The crc32 check of classes.dex in the Java code, usually recompiling the apk is to recompile the classes file, and after the code is recompiled, the hash value of the generated classes.dex file will change, so we can check the classes.dex after the program is installed The Hash value of the file determines whether the software has been repackaged. As for the Hash algorithm, both MD5 and CRC can be used. Here, the CRC algorithm is used directly to obtain the crc32 value of the currently running app.
Now that we have the current crc32 value, then we only need to compare it with the original crc32 value when our app was released. This is our java logic. The value of R.string.classes_txt can be assigned at will (not affecting ), then AndroidStudio began to officially package
When the packaging is successful, we obtain the crc32 value of the classes.dex of the apk, and then assign the crc32 value to R.string.classes_txt, and finally repackage it through AndroidStudio (because changing the resource file will not change the crc32 of classe.dex Value, changing the code will change the crc32 value of classe.dex). Regarding the method of obtaining the crc32 value of classes.dex, I recommend using the Windows CRC32 command tool. The method of use is as follows
The verification methods at the Java level are all fragile, because the cracker can directly change our judgment logic to achieve the purpose of bypassing the verification, so we can only achieve a little bit of anti-cracking desire by increasing its cracking workload. I suggest to encrypt the crc32 value or the hash value of the signature with MD5, and use the encrypted value in the code for comparison to prevent global search after decompilation; I suggest to combine the signature verification with the classes.dex verification, first Perform signature verification. After the verification is successful, use the correct signature hash value as a parameter to request the crc32 value of classes.dex in the background, and then compare it with the crc32 value of the current running; I suggest multiple verifications, each using a deformation judgment statement, And use it in combination with other judgment conditions to increase the workload when cracking.
Regarding bypassing Java code signature verification, here I will only use signature verification to introduce the cracking ideas. If you still don’t understand the decompilation steps, you can refer to the previous article first. First, we use the apk to be compiled to generate the smali files we need through apktool. These files will generate corresponding directories according to the hierarchy of the package. All classes in the program will generate independent smali files in the corresponding directories.
The following content is visible to members
[wc_pay_can_read id=’2026,2029,2030′ tishi=’You do not have permission to read this content, click here to become a member and refresh this page to read it’]
Then we use dex2jar and jd-gui to get the decompiled java code (often obfuscated). Those who are not familiar with the steps can check the previous article first. These two methods complement each other. By viewing the Java code, we can Quickly search for the required Android API method, and then locate the approximate location of the corresponding smali file through the location of the API method
Generally, signature verification at the java level is inseparable from signatures to obtain signature information, so we can search the signatures keyword globally in jd-gui to find a way to obtain signatures. Of course, if the app has a special Toast prompt before the verification fails Or Log information, it is more convenient.
Then open the signature code we found. Generally, the app will perform multiple verifications
Then we find the place where the f() method is called, here we just take jd-gui to try it. We can first find the Application and the main Activity through the AndroidManifest.xml file. Generally, there will be some verification and identification status judgments. After making a correction, run the app, and then locate the next according to the app exit or stuck position A place to verify the code, recursively, until it runs successfully.
From the above statement, we can know that this is just a simple equals() comparison. Then we open the corresponding smali file and search for “F010AF8CFE611E1CC74845F80266” to locate the decompiled code location for signature verification
Here we only need to change the judgment statement if-nezv0, :cond_1 to if-eqz v0, :cond_1 to flip the logic, then we repackage and sign it through apkTool, ok, the operation is successful。