RESEARCH | October 23, 2014

Bad Crypto 101

By Yvan Janssens

This post is part of a series about bad cryptography usage . We all rely heavily on cryptographic algorithms for data confidentiality and integrity, and although most commonly used algorithms are secure, they need to be used carefully and correctly. Just as holding a hammer backwards won’t yield the expected result, using cryptography badly won’t yield the expected results either.

 

To refresh my Android skillset, I decided to take apart a few Android applications that offer to encrypt personal files and protect them from prying eyes. I headed off to the Google Play Store and downloaded the first free application it recommended to me. I decided to only consider free applications, since most end users would prefer a cheap (free) solution compared to a paid one.

 

I stumbled upon the Encrypt File Free application by MobilDev. It seemed like the average file manager/encryption solution a user would like to use. I downloaded the application and ran it through my set of home-grown Android scanning scripts to look for possible evidence of bad crypto. I was quite surprised to see that no cryptographic algorithms where mentioned anywhere in the source code, apart from MD5. This looked reasonably suspicious, so I decided to take a closer look.

 

Looking at the JAR/DEX file’s structure, one class immediately gets my attention: the Crypt class in the com.acr.encryptfilefree package. Somewhere halfway into the class you find an interesting initializer routine:

 

public void init()
    {
        encrypt[0] = (byte)-61;
        encrypt[1] = (byte)64;
        encrypt[2] = (byte)43;
        encrypt[3] = (byte)-67;
        encrypt[4] = (byte)29;
        encrypt[5] = (byte)15;
        encrypt[6] = (byte)118;
        encrypt[7] = (byte)-50;
        encrypt[8] = (byte)-28;
        encrypt[9] = (byte)6;
        encrypt[10] = (byte)-75;
        encrypt[11] = (byte)87;
        encrypt[12] = (byte)-128;
        encrypt[13] = (byte)40;
        encrypt[14] = (byte)13;
        encrypt[15] = (byte)63;
        encrypt[16] = (byte)124;
        encrypt[17] = (byte)-68;
        …
        decrypt[248] = (byte)52;
        decrypt[249] = (byte)-51;
        decrypt[250] = (byte)123;
        decrypt[251] = (byte)105;
        decrypt[252] = (byte)-112;
        decrypt[253] = (byte)-86;
        decrypt[254] = (byte)-38;
        decrypt[255] = (byte)81;
    }

 

Continuing forward through the code, you immediately spot the following routine:
    // cleaned up decompiler code
    public byte[] decrypt(byte[] inputBuffer)
    {
        byte[] output = new byte[inputBuffer.length];
        int i = 0;
        while(i < inputBuffer.length)
        {
            int temp = inputBuffer[i];
            if(temp >= -128)
            {
                int temp = inputBuffer[i];
                if(temp < 128)
                {
                    int inputByte = inputBuffer[i];
                    int lookupPosition = 128 + inputByte;
                    int outputByte = decrypt[lookupPosition];
                    output[i] = (byte)i4;
                }
            }
            i = i + 1;
        }
        return output;

    }

 

This is basically a pretty bad substitution cipher. While looking through the code, I noticed that the values set in the init() function aren’t really used in production, they’re just test values which are likely a result of testing the code while it’s being written up. Since handling signedness is done manually, it is reasonable to assume that the initial code didn’t really work as expected and that the developer poked it until it gave the right output. Further evidence of this can be found in one of the encrypt() overloads in that same class, which contains a preliminary version of the file encryption routines.

 

Going further through the application reveals that the actual encryption logic is stored in the Main$UpdateProgress.class file, and further information is revealed about the file format itself. Halfway through the doInBackground(Void[] a) function you discover that the file format is basically the following:

 

The password check on the files itself turns out to be just a branch instruction, which can be located in Main$15$1.class and various other locations. Using this knowledge, an attacker could successfully modify a copy of the application that would allow unrestricted access to all of the files encoded by any password. Apart from rolling your own crypto, this is one of the worst offenses in password protecting sensitive data: make sure you use the password as part of the key for the data, and not as part of a branch instruction. Branches can be patched, keys need to be brute forced, or, in the event of a weak algorithm, calculated.

 

The substitution vector in the file is remarkably long–it seems that the vector stored is 1024 bytes. But, don’t be fooled–this is a bug. Only the first 256 bytes are actually used, the rest of them are simply ignored during processing. If we forget for a moment that a weak encoding is used as a substitute for encryption, and assume this is a real algorithm, reducing the key space from 1024 byte to 256 byte would be a serious compromise. Algorithms have ended up in the “do not use” corner for lesser offenses.

 

 

Yvan Janssens