In 2022, a critical security vulnerability was discovered in the Juiker app—a popular communication tool mainly used in Taiwan. This vulnerability, tracked as CVE-2022-38117, arises because the app’s source code actually hard-coded its AES encryption key. That means anyone who gains root access to your Android phone and is familiar with basic reverse engineering can easily decrypt and even alter your private data.

In this exclusive long-read, we’ll break down how this happened, show you real code snippets, walk through possible attack scenarios, and point you to the official references.

What is Hard-Coded Key Vulnerability?

Hard-coding is when secret values—like passwords or encryption keys—are written directly into the app’s code, instead of being securely stored or randomly generated. This is a huge no-no in security, because if an attacker can get a copy of the app (which is easy with Android APKs), they can reverse engineer the code and easily extract these secrets.

How the Juiker App Hard-Coded its AES Key

The Juiker app, used for messaging, calls, and more, is supposed to encrypt sensitive info (like messages) with AES—a secure standard—but the key was sitting right in the code.

Example: The Code Snippet

Let’s look at a simplified version of what the vulnerable code could look like (this is an illustrative snippet but mirrors what was reportedly found):

public class AESUtil {
    // SECURITY FLAW: The AES key is hard-coded in the app's source code!
    private static final String AES_KEY = "ThisIsASecretKey"; 

    public static String encrypt(String plainText) throws Exception {
        SecretKeySpec key = new SecretKeySpec(AES_KEY.getBytes(), "AES");
        Cipher cipher = Cipher.getInstance("AES/ECB/PKCS5Padding");
        cipher.init(Cipher.ENCRYPT_MODE, key);
        byte[] encrypted = cipher.doFinal(plainText.getBytes());
        return Base64.encodeToString(encrypted, Base64.DEFAULT);
    }

    public static String decrypt(String encryptedText) throws Exception {
        SecretKeySpec key = new SecretKeySpec(AES_KEY.getBytes(), "AES");
        Cipher cipher = Cipher.getInstance("AES/ECB/PKCS5Padding");
        cipher.init(Cipher.DECRYPT_MODE, key);
        byte[] decrypted = cipher.doFinal(Base64.decode(encryptedText, Base64.DEFAULT));
        return new String(decrypted);
    }
}

Anyone who decompiles and examines the .apk file can read the key (ThisIsASecretKey), and use it to decrypt any data that Juiker encrypts in this way.

Requirements for the Attacker

- Gets root access on a target’s Android device (i.e., steals it, uses malware, or exploits another vulnerability)

Step-by-Step Exploit

1. Gain Access: Physically steal the user’s Android device or otherwise get root-level access. This is not as hard as it sounds—many malware kits or local attacks can get this if the phone is unlocked or has known vulnerabilities.
2. Extract App Data: Juiker might store conversations, messages, call logs, etc., in encrypted files or databases.

Download or copy the Juiker APK (or use the installed app).

- Use tools like JADX or apktool to decompile the app.
  - Search for strings like AES_KEY, SecretKeySpec, or even just look for anything resembling a password in the code.

Decrypt User Data:

- Use the key you found (ThisIsASecretKey in our example) and a tool/script to decrypt the sensitive data.
  - If attackers want, they can also re-encrypt tampered data and put it back into the app’s storage.

PoC (Proof of Concept) Decryptor Code

Here's a simple Python snippet that could be used to decrypt Juiker data if the attacker knows the hard-coded key.

from Crypto.Cipher import AES
import base64

AES_KEY = b'ThisIsASecretKey' # 16 bytes

def decrypt(ciphertext_b64):
    cipher = AES.new(AES_KEY, AES.MODE_ECB)
    encrypted = base64.b64decode(ciphertext_b64)
    decrypted = cipher.decrypt(encrypted)
    # Remove PKCS#5 padding
    padding_len = decrypted[-1]
    return decrypted[:-padding_len].decode('utf-8')

# Example usage
encrypted = "CkGi6DZKqYg9pfC9ZcgpQg=="  # Replace this with actual ciphertext
print(decrypt(encrypted))

Persistence: Once compromised, trust in the app’s storage is lost.

Sensitive communication apps should *never* use static keys. The industry best practice is to use keys that are unique per user—and ideally protected by secure hardware elements (like Android’s keystore).

References

- NIST National Vulnerability Database: CVE-2022-38117
- Juiker Official Website
- General info on Hardcoded Encryption Keys (OWASP)
- JADX Apk Decompiler
- Apktool – Reverse engineering Android APKs

Conclusion

CVE-2022-38117 is a textbook example of a hard-coded cryptographic key gone wrong. The Juiker app’s mistake left users open to real and dangerous data theft, showing why developers must always follow secure coding best practices.

If you use Juiker or similar apps, keep alert for updates, and remember—hard-coded keys always equal hard problems.

Timeline

Published on: 10/24/2022 14:15:00 UTC
Last modified on: 10/24/2022 14:22:00 UTC