Livers, 2013/07/11 he

0 x00 background

Bluebox’S CTO Jeff Forristal wrote on his official blog about a bug called UNCOVERING ANDROID MASTER KEY, which basically modifies ANDROID code without tampering with the signature.

Link:bluebox.com/corporate-b…

Blog: I do not want to phase in how Android applications with too many details, but phase in how Android applications are cryptographically verified & Installed (Android app with signature verification and installation inconsistent)essentially a malicious author to trick Android into believing the app is unchanged Even if it has been(let the Android system itself consider the application has not changed) these two important messages.

What’s left is a diagram of changing baseband strings:

Details were released by Blackhat at the end of July.

A few days later, on July 8, someone from abroad released poC. Rayh4c said on weibo that it has been settled. I just analyzed it.

0 x01 analysis

Before POC came out, I took a look at android’s signature mechanism and installation mechanism.

Signature mechanism: In simple words, Android makes SHA1 (irreversible) signature for all files of the app, encrypts the signature with the private key of RSA(asymmetric encryption algorithm), and decrypts the signature with the public key when the client installs authentication.

Logically, this signature mechanism is perfectly fine for checking integrity and uniqueness. A lot of mainstream encryption is like this.

Installation mechanism:

The installation mechanism is more complex.

1. System application installation - complete when starting up, no installation interface 2. Network download application installation - complete through Market application, no installation interface 3. 4. Third party application installation - through the SD card APK file installation, installation interface, by packageInstaller. APK application to handle the installation and uninstall process interface.Copy the code

Installation process: Copy the APK installation package to the data/app directory, decompress and scan the installation package, save the dex file (Dalvik bytecode) to the Dalvik-cache directory, and create the corresponding application data directory in the data/data directory.

To see here in the installation mechanism of the problem is more likely.

Looking back at the old foreigner POC:gist.github.com/poliva/36b0…

An error occurred in Linux execution line. It could be apK.

To port the POC to Windows, first use apkTool to decompile the apK to a directory apk_test

Apk_test is then packaged into a new APK

Extract apK_old from the original APK

Add all apK_old files to the new APK as zip compressed. I take Weibo. Apk as an example:

It can be seen that the size of the two changes,apktool in the decompilation process inevitably appear differences. And the recompiled APK does not contain signature files.

I changed the file name of the batch export directory to 1.txt as per POC practice

import zipfile
import sys
f=open('1.txt','r')
line=f.readline()
test=[]
while line:
    test1=line.replace("\n","")
    test.append(test1)
    if not line:
        break
    line=f.readline()
f.close()
z = zipfile.ZipFile("livers.apk", "a")
for i in range(0,len(test)):
    print test[i]
    z.write(str(test[i]))
z.close()
Copy the code

It almost doubled in size, and I installed it on my phone, and it worked. Check it out:

Multiple pairs of files with the same name appeared. CRC check is different, check, basically is two bytes will produce different.

Here I also tested only adding signature files, or dex files, etc., which failed to pass the verification.

It can be proved that the file with the same name is improperly processed when the scan List scans directories or copies files.

0 x02 validation

Prove whether source code can be changed and native signatures can be used. I changed the APK icon.

General decompilation changes, by the way:

1. Decomcompile smaliJava bytecode assembly and XML image files using apkTool or other tools. 2. Decompress apkzip. 3. Decompile dex into a Java file. 4. Find the smALI file or XML (general advertising link) that corresponds to the modification 5. Sign with autosign. There's no signature going on here and I'm just borrowing the original signature.Copy the code

0x03 Finding the Root cause

The android 2.2 file is installed in frameworks\ Base \ Core \ Java \ Android \ Content \ PM \PackageParser. Public Boolean collectCertificates(Package PKG, int flags) and private Certificate[] loadCertificates(JarFile JarFile, JarEntry je, byte[] readBuffer) This method is used to obtain signature information.

Enumeration entries = jarFile.entries(); while (entries.hasMoreElements()) { JarEntry je = (JarEntry)entries.nextElement(); if (je.isDirectory()) continue; if (je.getName().startsWith("META-INF/")) continue; Certificate[] localCerts = loadCertificates(jarFile, je, readBuffer); . } else { // Ensure all certificates match. for (int i=0; i<certs.length; i++) { boolean found = false; for (int j=0; j<localCerts.length; j++) { if (certs[i] ! = null && certs[i].equals(localCerts[j])) { found = true; break; }}...Copy the code

From the previous black box, we can roughly assume that the installation mechanism is to process the rename file simultaneously, instead of overwriting it:

if (certs[i] ! = null &&certs[i].equals(localCerts[j])) { found = true; break; }Copy the code

Both files with the same name are authenticated, and as long as one of them is authenticated, the verification is returned.

0 x04 subsequent

My Android research is not much, most used to play the reverse base. You can talk a lot about it. Welcome to leave a message to discuss ~!

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

Updated July 11 at 21:00:

It would be more accurate to read down the theoretical analysis of Zmworm from snow watching without seeing the heat that has been discussed.

The principle is briefly

Because the ZIP format allows for two or more identical paths, Android does not allow for this scenario.

In this case, the Android package manager verifies that the signature is the hash of the last file, while the dex loaded by running APK is the first dex of the ZIP.

The package manager validates that the signature is the last file (in the case of the same name).

1. Parse all entries of the ZIP and save the result in a HashMap (key is the path and value is the Entry).

2. Hashmap. put will update the value of the same key, so the above HashMap must store the Entry of the last file in the same path.

The system loads the dex file, which is the first dex.

1. Use dexZipFindEntry to find the Entry of the dex.

2. The implementation of dexZipFindEntry returns only match, so the first file is returned.

Zip can contain two files or paths with the same name, and unzip itself overwrites the previous by default.

To qualify as zip, hashmap. put should be written in a way that overwrites files directly.

The way to load dex is to load the first one first, so the information is inconsistent.

However, I have previously detected the black box to think that Android default to load both in the signature verification order of the problem, not analyzed to the upper layer of the class.

See snow is also discussed a lot of posts to get accurate principle analysis, we discuss together, pool wisdom. Hack it, know it too.

Keep up with xinzhong.