How to Hard‑Code the Encryption Key of a WeChat Public Account

A testing task required accessing a seemingly legitimate WeChat public account, but all requests captured in Burp were encrypted gibberish. The author identified the typical three‑part encryption scheme: a random AES key generated on the front end, the key encrypted with an RSA public key, the data encrypted with AES, and an MD5 signature over the ciphertext plus a secret.

Analyzing the Front‑End Code

By opening the H5 page directly in a browser (URL extracted from Burp history) and inspecting the JavaScript, the critical encryption logic was found:

// AES 密钥生成
function uid() {
  return "xxxxxxxxxxxxxxxxxxxxxxxxxxxx".replace(/x/g, function() {
    var r = 16 * Math.random() | 0;
    return r.toString(16);
  });
};
var securityInterceptor = function(chain) {
  var appSecret = "c13w5*****7421"; // 签名盐值
  var key = uid(); // 生成随机AES密钥
  // RSA加密AES密钥
  var keyEncrypt = rsa.encrypt(key);
  // AES加密业务数据（ECB模式，PKCS7填充）
  var contentEncrypt = aes.encrypt(data, keyHex, {
    "mode": mode_ecb_default.a,
    "padding": pad_pkcs7_default.a
  }).toString();
  // 生成签名
  var sign = md5(contentEncrypt + appSecret).toString();
  return {
    "encrypt": 2,
    "key": keyEncrypt,
    "content": contentEncrypt,
    "sign": sign
  };
};

The code shows three key functions: uid() generates a random 32‑character string that serves as the AES key.

The AES key is encrypted with RSA, producing the key field.

The business data is encrypted with AES, and the result together with appSecret is hashed with MD5 to produce the sign field.

Although the logic was clear, the client still required a valid WeChat openid to log in, which the author could not obtain.

Attempted Memory Editing with Cheat Engine

Inspired by a previous article that used Cheat Engine to modify a mini‑program’s memory, the author tried to force Math.random() to always return 0, making uid() produce a constant string. After attaching Cheat Engine to the WeChat process and searching for the relevant memory locations, the effort stalled: the strings found were unrelated or changing the address had no effect. The author abandoned this path.

Successful Approach: Modifying the JavaScript via Burp

Returning to the browser, the author realised the JavaScript file is fetched from the server, so altering the server response could change the encryption behaviour. By enabling Burp’s filter to show JavaScript files, the critical JS file was located in the proxy history.

An automatic replacement rule was added in Burp to rewrite the JS on the fly, fixing the generated AES key to a constant value. After restarting WeChat and re‑loading the public account, the modified script ran, producing a deterministic key field.

With the fixed key, the author configured the client’s autoDecoder to use the same constant key, successfully decrypting the content field and displaying the original data.

Why It Worked

Front‑end encryption’s Achilles’ heel: any code executed on the client can be tampered with.

Unprotected JavaScript files: no signature or integrity check, allowing a man‑in‑the‑middle to replace them.

Take‑aways for Developers

Do not rely on front‑end encryption alone; it only raises the attack cost.

Sign JavaScript assets (e.g., using Subresource Integrity) to prevent tampering.

Move critical cryptographic logic to the server; anything that can be done on the client can be bypassed.

Final Thoughts

The test reinforced that security is a system‑level concern: a single strong component cannot compensate for weak links elsewhere. Testers often need to think outside the usual debugging flow, trying alternative entry points such as traffic manipulation when memory editing fails. All testing must be performed under proper authorization.