As my mom has got a certain requirement on one of her most common-used apps in her Huawei Mate9, I resolved to make a difference on that app which will consequently be called "anonymity.apk" by adapting the source code of Apktool, a versatile and powerful toolkit for reverse engineering Android apk files.
Okey. Let's hustle to make it.
1. Utilize a Shell tool to verify if the apk has been shelled.
2. Download the featured actor —— Latest Apktool.
You'd better read through the instructions and documentations listed on the official website though it'd be just not enough for the following steps.
It'd be a jar file that you may have downloaded that can be invoked by java -jar directive.
java -jar --help
Apktool is mainly comprised of smali and xpp3
- Smali is a disassemblerfor the dex format used by dalvik, Android's Java VM implementation, in a way that transforms .dex into .smali code.
- Xpp3 is a lightweight XML parser used to promptly decode the encrypted xml resources.
Now, decompile the zip file. Yep, apk is actually a zip file.
java -jar apktool.jar d -f anonymity.apk -o anonymity
Let's take a glance at the outputed anonymity folder.
-
assets
Major resources consisting of audio, video, raw pictures, fonts, models and so forth.
-
kotlin
Kotlin related files.
-
lib
Android native .so libraries.
-
original
- META-INF
Several degist and public certificate files constitute the meta security information.
- AndroidManifest.xml
An encrypted source AndroidManifest.xml.
-
res
Essential resources consisting of widget pictures and xml files which comprise id folder (values folder) and resource folders (layout, drawable, color, menu, anim, etc)
-
smali, smali1, smali2, smali3 ... folders
Involving android disassembled files that are derived from .dex byte-code files by smali.jar.
Smali is quite a human readable disassembly code based on Dalvik directives than pure Intel/arm disassembly code.
-
unknown
Files that can't be correctly identified like a file that has got a name without a extension. These files will be put back in their original places in the building process.
-
AndroidManifest.xml
Decrypted AndroidManifest.xml.
-
apktool.yaml
An inventory of the other folders and files that is not belonging to the apk archive. Apktool take advantage of such a .yaml to record something that is important to take notes in the building phase.
3. Locating the target code in smali files
A) Search the characterized string in the res\values\strings.xml as a crack-in point.
<string name="au7">出错</string>
By the way, Files that have been obfuscated by the Android proguard module involve the confusing names such as a, b, c, aa, bb, cc, a1, b2, c3, etc. Here is the item that is named "au7".
B) Map the id of the string we found in the res\values\public.xml.
<public type="drawable" name="au7" id="0x7f020d70" />
<public type="string" name="au7" id="0x7f080d79" />
<public type="id" name="au7" id="0x7f0f0f95" />
Be cautious that there'd be various types under an identical name, so it'd make sense to choose the one whose type attribute is marked as "string". Here is the item that has an id equaling "0x7f080d79".
C) Search the id globally in the project in order to find out which file has referenced the string.
D) Take whatever actions you need to achieve your aims by modifying the source smali code which won't be exhibited here in detail.
4. Rebuilt the whole of project
java -jar apktool.jar b -f anonymity
"-f" option is not forced to exist in a condition that the smali files have not been altered. Apktool will not recompile the smali files into new dex files if no alteration has been detected.
But some weird building errors encounter me.
A) No resource identifier found for attribute "XXX" in package "com.XXX.XXX"
B) No resource found that matches the given name (at "XXX" with value "XXX")
I will set it aside and move ahead in here. It's time to dive into these exceptions and apktool source code in next article.
There'd be two brand new folder generated in the root directory.
"build" folder would be stored intermediate files to be recompiled as an apk like encrypted AndroidManifest.xml, classesX.dex, resource files and their archived resources.arsc, kotlin supported files, native .so libraries.
The outputed apk would be stashed in the "dist" folder. But it can't be installed for now as it has not been re-signed.Otherwise, you should have received an error named "INSTALL_PARSE_FAILED_NO_CERTIFICATES"
If we open apk file through WinRAR or something, we'll notice that there is an extra "META-INF" folder in the root directory that we have mentioned before that serves as an security method within public certificate and Base64 hashed fingerprints mostly implemented by SHA-1 algorithm.
The folder has to be re-created by a signer like "Jarsign" or "Apksigner". I will utilize Apksigner as signer because it is just placed in the Android sdk under path %SDK Root%\build-tools\%SDK Version%\
Then we need a keystore in which involves a pair of asymmetrical keys which is analogous to the old-fashioned .pk8 (aks the private key) and X509.pem
(aks the public certificate) duo.
We can generate a custom keystore by keytool in JDK.
keytool -genkeypair -v -keyalg DSA -keysize 1024 -sigalg SHA1withDSA -validity 20000 -keystore my.keystore -storepass my_storepass -alias my_key_alias -keypass my_key_pass
keytool -genkeypair [OPTION]...
Generates a key pair
Options:
-alias <alias> alias name of the entry to process
-keyalg <keyalg> key algorithm name
-keysize <keysize> key bit size
-sigalg <sigalg> signature algorithm name
-destalias <destalias> destination alias
-dname <dname> distinguished name
-startdate <startdate> certificate validity start date/time
-ext <value> X.509 extension
-validity <valDays> validity number of days
-keypass <arg> key password
-keystore <keystore> keystore name
-storepass <arg> keystore password
-storetype <storetype> keystore type
-providername <providername> provider name
-providerclass <providerclass> provider class name
-providerarg <arg> provider argument
-providerpath <pathlist> provider classpath
-v verbose output
-protected password through protected mechanism
And it'd be recommended to migrate the proprietary JKS format to an industrially standard PKCS12 format.
keytool -importkeystore -srckeystore my.keystore -destkeystore my.keystore -deststoretype pkcs12
Then the final apk can be generated by a re-sign
process. Note that key_alias is the position in which the private key and certificate are stored in the KeyStore. This must be specified if the KeyStore contains multiple keys.
apksigner sign --ks my.keystore --ks-pass pass:keystore_pass --ks-key-alias key_alias --key-pass pass:key_pass --out output.apk anonymity.apk
The successfully re-signed apk will override the historical apk.
Finally, install and enjoy it.
By the way, if the apk provider has set a re-signed barrier, you would do more jobs to bypass it. But in fact, this particular approach is usually only adopted by mobile game providers.
