Our Process to Reverse Engineer Fidelius Encryption in Android and Web App

Recently, a customer contacted us to decrypt an encrypted key. A certain part of an Android and web-based application was storing a key using the Fidelius encryption method. The customer wanted to see how this encryption mechanism worked to better understand the operation of the application and analyze its vulnerabilities.

This was a very interesting challenge for us. Although we did not have access to much technical documentation on Fidelius encryption, we knew that we could find a solution using existing reverse engineering techniques. In this article, we will explain how we went about the process, what tools we used, and the results we achieved.

Analyze the Application Code

First, we used some basic reverse engineering techniques to examine the application code. If our target was an Android application, the first thing we would do would be to open the APK file and analyze the DEX (Dalvik Executable) files inside. We used tools like JADX and Ghidra for this. On the web side, we used analysis tools like Burp Suite and Chrome DevTools to examine the JavaScript and other source code.

When we looked inside the code, we saw that the encryption process was called through a specific Java library. We noticed that Fidelius encryption uses advanced key generation functions (like PBKDF2) and AES encryption. However, we needed more information about how the key was generated.

Dynamic Analysis: Examining the Application Live

Static analysis helped us understand the basic mechanism of the encryption process, but we needed more details. For this, we decided to follow the encryption processes in real time by running the application.

This is where Frida and Xposed Framework came into play. Using Frida, we started to monitor certain function calls while the application was running and see what parameters the encryption process was running with. In particular, we were looking for answers to the following questions:

• Is the encryption key fixed or does it change with each run?
• Which algorithm is used? AES, RSA, or a custom method?
• Is the key stored within the application or does it come from the server?

During our analysis, we noticed that the encryption key is temporarily stored in RAM.

Retrieving Encryption Key from Memory

Many applications store encryption keys in RAM for short periods of time, rather than permanently storing them on disk. If we can pull this key from RAM, we can bypass the encryption mechanism.

At this stage, we used memory analysis tools such as Volatility and Cheat Engine. We took a memory dump while the application was running and tried to find where the relevant key was stored.

During our RAM analysis, we noticed the following:

• The key was created when the application was started.
• It remained in memory for a few milliseconds, then was cleared.
• The key changed depending on a specific user input.

At this point, by intervening with Frida, we were able to capture the encryption key before it was encrypted.

Decrypting Encrypted Data by Listening to Network Traffic

Now we had the encryption key, but to fully verify the process, we decided to take it a step further: Analyze the Network Traffic.

Using Burp Suite and mitmproxy, we started listening to the encrypted requests of the application. We observed how the encrypted data was being transferred and realized that we could now decrypt it using the key we had.

By writing a Python script, we were able to decrypt the encrypted data passing through the network with our AES key. Thus, we completely understood the encryption mechanism of the application.

Challenges We Face and Our Solutions

In this process, we encountered several important security measures:

Code Obfuscation:

• The application code was compressed with ProGuard and R8.
• Using JADX and Ghidra, we largely undid the obfuscation.

Anti-Debugging Mechanisms:

• The application would close when it detected that we were using a debugger.
• We disabled these protections using Frida Anti-Detection bypass scripts.

Dynamic Key Generation:

• The encryption key was changing on each run.
• By following this process with Frida, we understood the key generation logic and generated a fixed key.

Result: Our Success in Deciphering the Encryption Mechanism

Finally, we have completely deciphered the Fidelius encryption mechanism and understood how the encryption key is generated. We also discovered several vulnerabilities in the application’s encryption process:

• Key stored in RAM for an excessively long time,
• Insufficient protection of data transmitted over the network,
• Insufficient debugging and reverse engineering protections.

These findings helped our customer increase the security of their application. If you also want to ensure the security of your application, you can contact us.

Work with Us: Let Us Make Your Applications More Secure

If you would like to have your application’s encryption security analyzed or benefit from our reverse engineering services, please contact us.

📧 Contact: [email protected]
🌐 Our Website: https://reverseengineer.net/

We offer professional services for all types of cryptographic analysis, reverse engineering and security assessment.