How do I find the decryption key of an android app using Frida?

[agg00]

Hi everyone! I've been reverse-engineering an Android app for a set of Bluetooth headphones, and my goal is to find the keys to decrypt the firmware. I obtained the firmware by intercepting the traffic between the device and the server.

In the code, I've found some parts that look like they should handle decryption, but it doesn't seem like these methods are actually being used in the application. I'm having difficulty tracking down the keys or identifying where and how they are applied to decrypt the firmware.

Here is the code I found that seems to handle the decryption process, but it doesn't appear to be utilized within the app.

    public final long k(k6.o oVar) {
        try {
            Cipher cipher = Cipher.getInstance("AES/CBC/PKCS7Padding");
            try {
                cipher.init(2, new SecretKeySpec(this.f20556b, "AES"), new IvParameterSpec(this.f20557c));
                k6.m mVar = new k6.m(this.f20555a, oVar);
                this.f20558d = new CipherInputStream(mVar, cipher);
                mVar.a();
                return -1L;
            } catch (InvalidAlgorithmParameterException | InvalidKeyException e10) {
                throw new RuntimeException(e10);
            }
        } catch (NoSuchAlgorithmException | NoSuchPaddingException e11) {
            throw new RuntimeException(e11);
        }
    }    public final long k(k6.o oVar) {
        try {
            Cipher cipher = Cipher.getInstance("AES/CBC/PKCS7Padding");
            try {
                cipher.init(2, new SecretKeySpec(this.f20556b, "AES"), new IvParameterSpec(this.f20557c));
                k6.m mVar = new k6.m(this.f20555a, oVar);
                this.f20558d = new CipherInputStream(mVar, cipher);
                mVar.a();
                return -1L;
            } catch (InvalidAlgorithmParameterException | InvalidKeyException e10) {
                throw new RuntimeException(e10);
            }
        } catch (NoSuchAlgorithmException | NoSuchPaddingException e11) {
            throw new RuntimeException(e11);
        }
    }

 

I've been using Frida to hook methods and classes related to encryption, but despite finding relevant classes for AES encryption (like com.android.org.conscrypt.OpenSSLEvpCipherAES$AES$CTR and com.android.org.conscrypt.OpenSSLAeadCipherAES$GCM), I can't seem to find where the actual decryption keys are being used or how the firmware is decrypted.

If anyone has any insights on how I can track the usage of keys or what I might be missing, I’d really appreciate any help or suggestions!

Thanks in advance!! :)

[FrankRizzo]

Are you sure that the app doesn't just funnel the data to the device, and let *IT* decrypt it?  I've seen that done before.

Also, follow the path of the data if you can.  If there's a button to download the firmware, follow it.  If there's not, look for references to the URL that they get the firmware files from, and see where those are dealt with.  (And the surrounding code).  

If they pull a JSON file from the server that has the firmware file details in it, look for where they get THAT.  

[Progman]

Reverse-engineering an Android app to find encryption keys and understand the decryption process can be quite challenging, especially if the app is obfuscated or if the decryption logic is not straightforward. Here are some steps and tips that might help you in your quest:

 

### 1. **Understand the Code You Found**

The code snippet you provided is using AES encryption in CBC mode with PKCS7 padding. Here's a breakdown:

- `Cipher.getInstance("AES/CBC/PKCS7Padding")`: This initializes the AES cipher in CBC mode with PKCS7 padding.

- `cipher.init(2, new SecretKeySpec(this.f20556b, "AES"), new IvParameterSpec(this.f20557c))`: This initializes the cipher for decryption (mode `2` is for decryption). The key is `this.f20556b` and the initialization vector (IV) is `this.f20557c`.

- `CipherInputStream(mVar, cipher)`: This wraps the input stream `mVar` with the decryption cipher.

 

### 2. **Trace the Key and IV**

- **Key (`this.f20556b`)**: This is likely the AES key used for decryption. You need to find where this key is initialized or set.

- **IV (`this.f20557c`)**: This is the initialization vector used for AES in CBC mode. It should be the same as the one used during encryption.

 

### 3. **Use Frida to Hook and Trace**

Since you're already using Frida, you can hook into the methods that set or use these fields. Here are some Frida scripts that might help:

 

#### Hook the Key and IV Initialization

```javascript

Java.perform(function() {

    var targetClass = Java.use('com.example.YourClass'); // Replace with the actual class name

    targetClass.f20556b.value = function() {

        console.log("Key is being accessed: " + this.f20556b);

        return this.f20556b;

    };

    targetClass.f20557c.value = function() {

        console.log("IV is being accessed: " + this.f20557c);

        return this.f20557c;

    };

});

```

 

#### Hook the Cipher Initialization

```javascript

Java.perform(function() {

    var Cipher = Java.use('javax.crypto.Cipher');

    Cipher.init.overload('int', 'java.security.Key', 'java.security.spec.AlgorithmParameterSpec').implementation = function(opmode, key, params) {

        console.log("Cipher.init called with opmode: " + opmode);

        console.log("Key: " + key);

        console.log("Params: " + params);

        return this.init(opmode, key, params);

    };

});

```

 

### 4. **Look for Key Generation or Retrieval**

The key might be generated or retrieved from somewhere else in the code. Look for:

- **Key Generation**: Methods that generate keys using `KeyGenerator` or similar classes.

- **Key Retrieval**: Methods that retrieve keys from a server, shared preferences, or other storage.

 

### 5. **Check for Obfuscation**

If the app is obfuscated, the class and method names might not be meaningful. Use tools like **Jadx** or **Procyon** to decompile the APK and look for patterns or strings that might indicate key usage.

 

### 6. **Intercept Network Traffic**

Since you intercepted the firmware, you might also intercept the network traffic to see if the keys are being sent or received from the server. Use tools like **Burp Suite** or **Charles Proxy** to inspect the traffic.

 

### 7. **Analyze the Firmware Update Process**

Sometimes, the keys are embedded in the firmware update process. Analyze how the firmware is downloaded and applied. Look for any encryption/decryption steps during this process.

 

### 8. **Check for Native Code**

If you can't find the keys in the Java code, they might be handled in native code (C/C++). Look for native libraries (`.so` files) and use tools like **Ghidra** or **IDA Pro** to analyze them.

 

### Example Frida Script to Hook Key Generation

```javascript

Java.perform(function() {

    var KeyGenerator = Java.use('javax.crypto.KeyGenerator');

    KeyGenerator.init.overload('int').implementation = function(keySize) {

        console.log("KeyGenerator.init called with keySize: " + keySize);

        return this.init(keySize);

    };

    KeyGenerator.generateKey.implementation = function() {

        var key = this.generateKey();

        console.log("Key generated: " + key);

        return key;

    };

});

```

 

### Conclusion

By combining static analysis (decompiling the APK) and dynamic analysis (using Frida to hook methods), you should be able to trace the key and IV used for decryption. Pay attention to where these values are set and how they are used throughout the app. If the keys are not found in the Java code, consider looking into native code or network traffic for clues. Good luck!