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