You're debugging an H5 page, and every API request body looks like this:
{"data":"6be9792e5ed250fc1a19e5bf2e7d0a3d78e7d0eb3d46b8c21a5c..."}
Meanwhile, the actual parameters are:
{"userId":"123","keyword":"hello"}
The request body is AES-encrypted end-to-end. Your proxy shows you the hex gibberish. The backend says "your userId is wrong," and you have no idea what you actually sent.
This is a common pattern for embedded H5 pages: the entire request body is symmetrically encrypted, and the backend decrypts it on arrival. It makes sense for security. But during development and debugging, it's a nightmare:
- You can't write Mock rules because you can't see the params
- You can't replay with modified values because you'd need to re-encrypt manually
- You keep asking the backend team to temporarily disable encryption (famous last words before a production incident)
The root problem: your proxy sees bytes but doesn't understand their meaning. You've set up DevPeek, configured the proxy, and trusted the HTTPS certificate — but if the payload is encrypted, you're still flying blind.
What DevPeek Does Differently
DevPeek's param transform feature turns your proxy into a decryption engine. You tell it the key and algorithm once. From that point on, every matching request shows both the raw ciphertext and the decrypted plaintext side by side. If you turn on two-way transform, you can edit the plaintext, and DevPeek re-encrypts it before sending.
This is different from Charles or Fiddler — they're great at capturing traffic, but they don't know your encryption scheme. Every time you need to decode a request, you copy the hex, paste it into a script, run it, read the output, modify it, run the encrypt script, then paste the result back. DevPeek bakes this pipeline into the proxy itself.
Step 1: Configure the Encrypt/Decrypt Rule
Right-click any encrypted request → Param Transform:
In the Param Transform Rules dialog, go to the Encrypt/Decrypt Rules tab → Add → Built-in Transform → select AES-GCM:
This is the easiest place to mess up. Double-check every field:
| Field | Value | Notes |
|---|---|---|
| Algorithm | aes-gcm |
|
| Key | 342e668900166e5f6731f7a172f52862e3a43da54611519dec5246dadb6e7429 |
SHA-256 derived 256-bit key |
| Key Encoding | Hex ⚠️ | Key is a hex string, not UTF-8 text |
| IV / Nonce | a1b2c3d4e5f6a7b8c9d0e1f2 |
Fixed 12-byte IV |
| IV / Nonce Encoding | Hex ⚠️ | Same as above |
| Ciphertext Input Encoding | Hex ⚠️ | Our demo outputs hex, not base64 (DevPeek defaults to base64) |
| Output Encoding | UTF-8 | Plaintext encoding after decryption |
| Auth Tag Length | 16 | GCM default (16 bytes) |
The three ⚠️ rows are the most common pitfalls. DevPeek's built-in AES-GCM defaults to
keyEncoding: utf8,ivEncoding: utf8,inputEncoding: base64. Our demo uses hex for all three. If any one of these is wrong, decryption silently produces garbage. When decryption fails, check these three encodings first.
Save the rule. You should now see this AES-GCM rule in the Encrypt/Decrypt Rules list.
Step 2: Configure the Param Transform Rule
Back in the Param Transform Rules window, add a new rule. This tells DevPeek three things: which request to match, which field to transform, and which rule to apply.
Match Conditions
Toggle the match conditions to filter the target request. The right panel previews the current request's characteristics in real time:
| Field | Value |
|---|---|
| URL Match | /api/query |
| Method | POST |
| Scope | Start with "Manual" to limit to the current request; switch to automatic once you're confident |
Transform Target
Body → JSON → data — tells DevPeek to decrypt the value of the data field in the JSON body.
Referenced Rule
Select the AES-GCM rule you created in Step 1. The preview panel instantly shows the decrypted result:
If everything is correct, you'll see 6be9792e... decoded to {"userId":"123","keyword":"hello"}. That green light means it's working.
Save the rule. Go back to the request list and re-inspect the same request:
The data field now shows the plaintext beneath the ciphertext. No more manual copy-paste decoding.
Beyond Decryption: Two-Way Transform and Replay
Decryption is step one. The full debug loop is: see the params → spot the problem → edit → verify.
The param transform rule has a two-way transform toggle:
Before enabling two-way: the ciphertext is editable and the plaintext is read-only. You can manually tweak the encrypted blob, but you'd need to construct valid encrypted data — which defeats the purpose.
After enabling two-way: the ciphertext becomes read-only and the plaintext becomes editable. Edit the plaintext, click Send, and DevPeek automatically re-encrypts using the same key and IV before dispatching:
Real-world example: you suspect a specific error code only triggers when userId is a certain value. With two-way transform enabled, modify userId in the plaintext, DevPeek handles the encryption, and you can verify the hypothesis in one click — no scripting, no manual hex encoding.
Dealing With Non-Standard Encryption Schemes
The example above uses fixed IV, auth tag appended to ciphertext, hex output — an AES-256-GCM setup. Real projects vary wildly:
- Dynamic IV: the IV isn't hardcoded but sent alongside the request (e.g., in a header or another field)
- Remote key fetch: the key comes from a KMS service or a preliminary API call
- Different algorithms: AES-CBC, AES-ECB, RSA, or custom schemes
When built-in transforms aren't enough, DevPeek has script transforms — a sandboxed JavaScript runner with access to util.crypto, util.encode, axios, URL, and more. You can write a script that extracts the IV from a request header, fetches a key from a remote service, or calls an external decryption endpoint. See the Script Transforms docs for details.
How It Works (In 30 Seconds)
Param transform is a pipeline: match → extract → decrypt → display:
Request hits DevPeek proxy
│
▼ Match rules (URL + Method)
│
▼ Extract target field (body:json:data)
│
▼ Run referenced crypto rule (AES-256-GCM)
│
▼ Store result in paramTransformDerived
│ Original request body untouched
│
▼ Display: request detail panel, Mock matching, replay
Key design point: DevPeek never modifies the original request body. The ciphertext stays as-is. Decrypted plaintext lives in a separate paramTransformDerived field, used only for display and downstream features like Mock rule matching. A failed decryption won't corrupt your captured data.
Built-in transforms cover AES-CBC, AES-ECB, AES-GCM, DES-CBC, 3DES-CBC, RSA, and Base64.
API parameter encryption is increasingly common in H5 development. Debugging shouldn't be the bottleneck. A one-time rule configuration eliminates hours of repetitive manual decoding.
Related Docs
If you're tired of manually decoding encrypted request bodies during debugging, download DevPeek and set up your first decrypt rule using the steps above. Or start a discussion on GitHub Discussions — I'd love to hear about your encryption setup.
Top comments (0)