APK go to Signature verification explanation

Some apk use signature check to prevent repackaging. So at the time of the crack we need to crack the signature check. The key words used in locating the signature check position are sign,signature,checksign,signcheck,getpackagemanager,getpackageinfo,verify,same and so on.Java Layer Signature code example:

1 //Original Signature Information2 Private Static FinalString SIGNATURE = "478yykkaqf+kst8y4atkvhkyibo=";3 Private Static Final intVALID = 0;4 Private Static Final intINVALID = 1;5 6  Public Static intCheckappsignature (Context context) {7     Try {8PackageInfo PackageInfo =Context.getpackagemanager (). Getpackageinfo (Context.getpackagename (), packagemanager.get_signatures);9 Ten          for(Signature signature:packageInfo.signatures) { One             byte[] Signaturebytes =Signature.tobytearray (); AMessageDigest MD = messagedigest.getinstance ("SHA"); - md.update (Signature.tobytearray ()); -              the             FinalString currentsignature =base64.encodetostring (Md.digest (), base64.default); -  -LOG.D ("Remove_me", "Include this string as a value for SIGNATURE:" +currentsignature); -  +             //Compare Signatures -             if(Signature.equals (currentsignature)) { +                 returnVALID; A             }; at         } -}Catch(Exception e) { -         //assumes an issue in checking signature., but we let the caller decide on what does. -  -     } -     returnINVALID; in}

Recently encountered a signature check of the APK, it is to obtain the signature information on the client and then on the server side of the signature, and the signature acquisition is implemented in the native code. The crack of this signature check is usually in the SD card to save a original APK package, modify the APK path, let the program get the original APK signature information. There are generally three ways to modify them, as described below.

(a) In the Java layer to modify the context to crack first install the APK, start DDMS view log information:      According to this "VERIFYHASHBYC" this string guess with the signature check has a relationship, So in the Java layer Search VERIFYHASHBYC, did not find the corresponding log print, only found the same name native function call:       guess this log printing information is in so, Then find the native function corresponding to the so load place, found that the load is libappverify.so this dynamic library:                    Open libappverify.so with Ida, search for VERIFYHASHBYC, in Verifyhash_ The code for the log log print was found in the Bysha function:                                Light look at the function name Verifyhash_bysha know is to verify the hash through the SHA algorithm, but this is not used for signature verification, the use of Ida cross-reference to view the function call relationship, found that the function in Verifyhash (_JNIENV *, char *, char const*, int) is called in the function. The Verifyhash is called by the native function Verifyhashbyc mentioned earlier. The      verifyhash function gets the app package name first, and then calls the Getapkmfdata function:                              gets the application path in the function, then extracts the application installation package, reads the contents of the MANIFEST.MF file, and then makes the signature comparison:   The sample code for the       get APK path is as follows:

1 Private Staticstring Getapkpath (String pkgname) {2Packagemanager pm =Mcontext.getpackagemanager (); 3ApplicationInfo pi =NULL; 4     Try {  5PI =Pm.getapplicationinfo (pkgname,packagemanager.get_uninstalled_packages); 6         if(Pi! =NULL)  7             returnPi.  SourceDir; 8         Else   9             return NULL; Ten}Catch(namenotfoundexception e) { One E.printstacktrace ();  A         return NULL;  -     }   -}

SourceDir saved the full path of the APK:

    Next, unzip the APK and read the MANIFEST.MF file:                              　　  is the content in the MF file, consistent with the contents of the memory unit in:              Analysis of so much, how to crack it? The previous analysis shows that the process of obtaining the path of the APK package in so is the:     incoming context, which is obtained through the ApplicationInfo SourceDir to the APK path, If we modify the sourcedir so that it always points to the original APK, then our goal is achieved. By deserializing the Java code and finding where to call libappverify.so, the context is the:          that is passed in from here.     What we're going to do is modify this context so that it ends up pointing to the SourceDir as the original apk path.                   according to the principle, We implement a Apkapplicationinfo class to specify SourceDir as the original apk (SD card apk) path, Apkapplicationinfo is instantiated in the Getapplicationinfo function, Because the Getapplicationinfo function is a member function of the Packagemanager class, So you need to implement a Apkpackagemanager class (inherited from the Packagemanager Class) to invoke the Getapplicationinfo function. The Apkpackagemanager class needs to be GetpackagemanaThe GER function is instantiated, and the Getpackagemanager function is a member function of the context, so it is necessary to implement a class apkcontext that inherits from the context. So, create an Android project, create three classes of Apkapplicationinfo, Apkpackagemanager, and Apkcontext, and set SourceDir to "/sdcard/myapk.apk". After compiling, will generate the APK decompile, get this three class of Smali code file, as shown in:      then, the original apk decompile, put the above three files into the anti-compiled apk Smali folder, Insert the following code in the Verifyhash function of the Lcom/rytong/emp/security/appverify class,:        repack, install run, Success!(ii) Use of hook technologywe know that the signature check is in libappverify.so, so we just hook the function in this so and change the incoming apk path. The analysis shows that the so is used to extract the Minizip apk file and then obtain the signature information. The sample code to extract the APK file using Minizip is as follows:

1 voiduncrypt_test ()2 {3   //using Minizip for file decompression4Unzfile uf=NULL;5Unzfile data[1200];6 unz_global_info64 gi;7 unz_file_info64 FileInfo; 8  9     //Open zip fileTenUF =UnzOpen64("D:\\myfile.zip"); One     intResult=unzgetglobalinfo64 (UF, &gi); A     if(Result! =UNZ_OK) -         Throw"File Error"; -   the     //Loop unzip a file -      for(inti=0;i<gi.number_entry;++i) -     { -         if(UnzGetCurrentFileInfo64 (UF, &fileinfo, 0, 0,null,0,null,0)! =UNZ_OK) +              Throw"File Error"; -   +         if(! (Fileinfo.external_fa & File_attribute_directory))//file, otherwise the directory A             //Open File at             //Result=unzopencurrentfile (UF);/* No password */ -Result=unzopencurrentfilepassword (UF, "123");/*have a password*/ -    -         //Read Content -         intSize=Unzreadcurrentfile (uf,data,sizeof (data));  -   in         //Close the current file - Unzclosecurrentfile (UF);  to   +         //Error -         if(I < gi.number_entry-1 && unzgotonextfile (UF)! =UNZ_OK) the           Throw"Error";  *     } $  Panax Notoginseng     //Close the stream - Unzclose (UF); the}

from the code above, the APK path is passed into the UnzOpen64 function as a parameter during the decompression process. So we need to hook this function. But how do you know when libappverify.so is loaded?  We know that the system loads so from the specified path through the Dvmloadnativecode function, and if the system function Dvmloadnativecode hooks, when it loads the libappverify.so, then hooks UnzOpen64 function, modify the APK path, not just OK?

Dvmloadnativecode function Prototypes:　　

Dvmloadnativecode Char* * detail)

Here we use Cydia substrate this hook framework, the key code is as follows:

 Put the compiled so file into the original apk lib directory. Then load it through the Java layer and load the code as follows:

 1  const -string/jumbo V0, " Substrate "2  invoke-static  {v0}, ljava/ Lang/system;->loadlibrary (Ljava/lang/string;) V  3  4  invoke-static  {v0}, ljava/lang/ System;->loadlibrary (Ljava/lang/string;) V  5  6  invoke-static  {v0}, ljava/lang/ System;->loadlibrary (ljava/lang/string;) V 

Because you need to load these so before the signature check code runs, we add the above code in the constructor of the Lcom/cgbchina/xpt/empview class, as shown in:

Re-package the signature, the installation runs successfully!(3) modify so file directlyBecause the signature verification is the MANIFEST.MF file, we renamed the MANIFEST.MF file in the original apk to SIGNFILE.MF under the modified APK Meta-inf folder. Then change the file name verified in so to SIGNFILE.MF: save, replace original so, re-package the installation, run successfully!

APK go to Signature verification explanation