Add in the ability to take advantage of the other zip sig issue

[Fuzion24]

The following is an english translation of: http://blog.sina.com.cn/s/blog_be6dacae0101bksm.html I am keeping it here incase something happens to that site.

A few days ago, Bluebox Security has just exposed the Android security vulnerability. Squad immediately grasp its technical details. After the last few days on the Android studies, the team discovered a similar vulnerability. An attacker can modify the original apk, but does not modify its original apk's signature. Just principle with Bluebox Security vulnerabilities are not the same exposure, but the effect is the same.

This time we talk about the technical details: 1 talking about this loophole, first need to thoroughly understand java, short type conversion int type of problem. To understand this loophole, you must understand the technical points.

public class JavaTest {
    public static void main (String [] args) {
        short a = (short) 0xFFFF;
        int b;
        b = a;
        System.out.println (b);
        b = a & 0xFFFF;
        System.out.println (b);
    }
}

If you can clearly understand the above code print twice the value of the variable b What is the difference and why different words, this part can be skipped. Otherwise, the thing is to figure out and then look down.

1. Zip file format
   In each of the Zip file has a Central directory, Central directory of each one is a File header. The File header structure corresponds to the Android code category is ZipEntry. File header structure has an offset pointing to local file header, local file header followed back on the file data. Next we look at in detail the structure of local file header.

        local file header Signature  4 bytes  (0x04034b50)   
        Version needed to extract  2 bytes     
        general Purpose bit flag  2 bytes      
        compression method  2 bytes            
        Last mod file time  2 bytes            
        Last mod file Date  2 bytes            
        CRC-32  4 bytes                        
        compressed size  4 bytes               
        uncompressed size  4 bytes             
        file name length  2 bytes              
        extra field length   2 bytes            
        file name (variable size)
        extra field (variable size)

You can see, except the last two fields outside, local file header of the other fields are fixed length. This two variable-length field length is determined by file name length and extra field length determined. Again, keep in extra field that is behind a file's data file data.

1. How Android apk checksum
   During Android apk file checksum when transferred ZipFile the public InputStream getInputStream (ZipEntry entry) function. This function, has this to say:

            RAFStream rafstrm = new RAFStream (raf, entry.mLocalHeaderRelOffset + 28);
            DataInputStream is = new DataInputStream (rafstrm);
            int localExtraLenOrWhatever = Short.reverseBytes (is.readShort ());
            is.close ();

            / / Skip the name and this "extra" data or whatever it is:
            rafstrm.skip (entry.nameLength + localExtraLenOrWhatever);
            rafstrm.mLength = rafstrm.mOffset + entry.compressedSize;
            if (entry.compressionMethod == ZipEntry.DEFLATED) {
                int bufSize = Math.max (1024, (int) Math.min (entry.getSize (), 65535L));
                return new ZipInflaterInputStream (rafstrm, new Inflater (true), bufSize, entry);
            } Else {
                return rafstrm;
            }

Note: The red part of the code above. localExtraLenOrWhatever is the local file header structure of the extra field length. Recall that we will be the first part of the technical points, if there's extra filed length size is greater than 2 ^ 15, what will happen? Yes, localExtraLenOrWhatever will be negative. So then, rafstrm.skip (entry.nameLength + localExtraLenOrWhatever); sentence would not really skip the variable-length field file name (variable size) and extra field (variable size). But may it will jump to file name (variable size), the even file name (variable size) before. Of course, in order to facilitate attacks, we still expect it to skip file name (variable size) in.

4 How to carry out attacks
To change an apk behavior is apparently the target of attacks in the classes.dex apk file. For classes.dex file apk file local file header structure, and its file name (variable size) field content is surely "classes.dex" it. Note that the suffix dex, and dex files just the beginning of the three-byte identical (do not understand, see the dex file format). a) Using this, from the file name (variable size) domain "classex.dex" "." in the beginning we can write after a full dex files. This dex file must be in the original apk classes.dex file. The only way to bypass the signature verification
b) modify the extra field length, so as 0xFFFD. Because this value is exactly -3. According to vulnerability, rafstrm.skip (entry.nameLength + localExtraLenOrWhatever); phrase will jump file name (variable size) domain "." In afterwards. Dex file that is a start, there must be an original dex file contents.
c) modify the local file header of the file data after the data. Here is written with exploit code classes.dex content.
d) above changes will bring about some structural apk file adjustments, such as expansion of extra field domain, adjust the file data size.
Specific attack model, as shown below.

1. Summary
   In general this means of attack, the first use of Android in the signature verification process, the Zip file corresponding 16 field read, did not take into account the case of greater than 2 ^ 15. (Because the java int, short, long is signed, unlike C / C + + li without symbols). Second, the use of a Zip file local file header structure to store extra field domain original classes.dex. But this can only domain size is 2 ^ 16-1, so it is attacked Apk Lane classes.dex size must be less than 64K. Otherwise, it can not be attacked. Which can be considered a limitation of this attack. Finally, there is a problem Additional information: The reason this attack is successful, but also because at runtime, the system extracts the hacked classes.dex, and in the signature verification, verify that the extra domain of classes.dex. The former is implemented in libdex.so which the Java layer. Java layer by layer with Native inconsistent result.

[Fuzion24]

added in pull #5

[kraghu]

Hi there, How to modify the extra field as to include 0xFFFD ? I am trying to create a zip file .. please let me know if I have to use C or any other language to modify the zip header. I tried running your apks example for bug 9695860 without any success. Any help is appreciated .

regds me

[Fuzion24]

I am not sure what you mean by including 0xFFFD in the extra field. Here is a explanation of my actual implementation: http://www.saurik.com/id/18 ... If the example apks don't work on your device, the bug has been patched on your device..

[kraghu]

what i meant is i am trying to modify the apk file structure to include the extra bytes field in the apk/zip header as explained by saurik (for bug 9695860). i am not able to do so as java keeps throwing an error. I tried running both of your example apks generated for bug 9695860 and bug 8219321. The apk you generated for 8219321 works perfect confirmed with both the devices with fix and without fix. With your 9695860 apks poc, it launches the second class in all devices , even on the devices which is claimed as patched as per blue box scanner. so i decided to create my own apk as per saurik and othe link explaination. i got classes.dex with 65,533 bytes and dex file with 65,533 bytes zipped in an apk and modifyed the zip header structure to include oxFFFD extra field value. but it is throwing an issue

[Fuzion24]

you don't need this -> . "I got classes.dex with 65,533 bytes" to take advantage of 9695860. I think you may need to re-read his paper. His approach is to not touch the file extra at all. While that would work it's very restrictive. His *actual approach is to write a secondary central directory inside the comment (that overflows a short) of another central directory. What is the error you get when you try my 9695860 POC?

[kraghu]

May be it is some thing to do with my testing. what i am doing in my testing is i am trying to extract your 9695860 poc generated apk so that i could see the classes.dex extracted to be the wrong one but i am constantly getting ENOENT exception.

Can you suggest how to verify ? How does blue box scanner verify 9695860 bug ?

On Mon, Sep 16, 2013 at 8:09 AM, Ryan Welton notifications@github.comwrote:

you don't need this -> . "I got classes.dex with 65,533 bytes" to take advantage of 9695860. I think you may need to re-read his paper. His approach is to not touch the file extra at all. While that would work it's very restrictive. His *actual approach is to write a secondary central directory inside the comment (that overflows a short) of another central directory. What is the error you get when you try my 9695860 POC?

— Reply to this email directly or view it on GitHubhttps://github.com/Fuzion24/ZipArbitrage/issues/3#issuecomment-24517078 .

[Fuzion24]

I would assume their scanner thing takes a zip file that has a central directory embedded inside a comment and checks what files get extracted...

[kraghu]

Alright I am trying to extract my generated 9695860 and your 9695860 apk . I think that is where i am going wrong. it extracts perfectly

[kraghu]

That is what i am doing. I created your apk using the command as explained ,

java -jar /Users/raghunandank/Git/ZipArbitrage/bin/AndroidMasterKeys.jar -b -a orig.apk -z moddedClassesDex.zip
this created MasterKeysModded-orig.apk .

unzip -vl MasterKeysModded-orig.apk Archive: MasterKeysModded-orig.apk Length Method Size Ratio Date Time CRC-32 Name

---

   7  Defl:N        9 -29%  09-16-13 10:19  5c99346d  META-INF/garbage
  37  Defl:N       39  -5%  09-16-13 10:19  b1d56792  5fc9ed82-d304-4e95-89f1-d01282690b4a/
  37  Defl:N       38  -3%  09-16-13 10:19  2f5dd8a3  5c7be2a6-3312-4d27-ae84-65bb6f168b15/
  37  Defl:N       39  -5%  09-16-13 10:19  7f9a03f3  5871bdb4-97c1-4b1d-af86-cf0d06c0c729/
  37  Defl:N       39  -5%  09-16-13 10:19  23a295ce  e74cbf93-2fc7-402f-a81a-56dca8d3ceaa/
  37  Defl:N       39  -5%  09-16-13 10:19  4d43c24e  e57e1838-dae6-46c0-a766-8ebfe99c9155/
  37  Defl:N       39  -5%  09-16-13 10:19  66f8e701  91c5ca4d-ead6-4c93-9a83-c4e4efdcbbc4/
  37  Defl:N       39  -5%  09-16-13 10:19  4df80213  5d3afaa5-b2b7-41a2-a458-acf966e209bb/
  37  Defl:N       39  -5%  09-16-13 10:19  c41eae5a  e465f7d6-1b85-4c3c-9477-814b5c605470/
  37  Defl:N       39  -5%  09-16-13 10:19  644a74b6  0d9e31a0-1b9c-44fd-8c1a-2b7da4db9926/
  37  Defl:N       39  -5%  09-16-13 10:19  7bc99bbf  6b58201f-d87c-4e28-94ab-a6d5c0b36dd9/
  37  Defl:N       39  -5%  09-16-13 10:19  9a2c2590  8478be81-9c8f-482c-ab87-147ce8466a7b/

449804 Defl:N 196808 56% 07-09-13 12:24 4422a27d classes.dex

---

450218 197245 56% 13 files

Now i am trying to extract in android . It is throwing an error at 09-16 10:28:36.955: E/Decompress(26798): java.io.FileNotFoundException: /mnt/sdcard/s/r/META-INF/CERT.RSA: open failed: ENOENT (No such file or directory) on both nexus which has this patch and on the Samsung S4 which doesnt have this patch !

Please let me know where i am going wrong ?

regds me

[Fuzion24]

@kraghu please stop spamming.

[kraghu]

sorry fusion24 i didnt know about it.

[kraghu]

hi @Fuzion24 can you please delete those twitter feeds from here ?