DEV Community: GYPengDev

Deobfuscating AES-Encrypted H5 API Parameters Directly in Your Proxy — No Manual Decryption Needed

GYPengDev — Sat, 18 Jul 2026 14:07:06 +0000

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.

H5 Debug in Practice (2): Android WebView White Screen—From Console Remote Debug to Mock Validation

GYPengDev — Tue, 14 Jul 2026 03:52:39 +0000

A campaign H5 white-screened on some Android devices after a button tap. All requests returned 200, but the page showed nothing. Using DevPeek Console to capture the live WebView runtime logs, remote eval to confirm a polyfill override, and Mock to verify the fallback UI under error conditions.

If you've ever done H5 joint debugging, you've probably been there: the API returned 200, the data looked fine, but the page just wouldn't render. Worse still, the issue only appeared on one specific Android device's WeChat WebView—no vConsole on hand, and remote debug wouldn't connect.

This article walks through the real investigation—from packet capture confirming the network was fine, to Console remotely locating the JS runtime exception, to Mock validating the fallback UI—all without repackaging the H5.

White screen

It happened during a campaign H5 stress test.

QA posted a screen recording in the group:

"Samsung S23, Android 14, opened the campaign page in WeChat, tapped Join Now—screen goes white."

What made it tricky was that the page wasn't completely broken.

It loaded fine:

Home content displayed normally;
The button was tappable;
A loading indicator appeared after tapping;

But then the screen went white.

iOS was fine. Other Android devices were fine too.

First suspects:

JavaScript runtime error?
API response breaking the render?
Android WebView compatibility issue?

Started with the network layer.

Capture looked normal, page still crashed

First, the API request:

POST /api/campaign/join

Returned:

200 OK

Request parameters checked out. Response structure was as expected.

At least the API wasn't the problem. But the page was still white.

This is the tricky kind of issue: the request succeeded, the page loaded, but something failed mid-execution. Without runtime logs, you're guessing.

vConsole and Remote Debug weren't a good fit here

For H5 debugging, vConsole is usually the first thought. But this campaign page was already live—we couldn't repack it with vConsole injected. And the issue only happened on specific Android devices.

Chrome Remote Debug was tried too:

chrome://inspect

It could connect to the WebView. But the error happened after the button tap. By the time the page refreshed, the error was gone.

On top of that:

WebView debug flag requires client-side support;
USB connection has environment dependencies;
The live version couldn't be repeatedly adjusted.

The problem was: the WeChat WebView on the phone had already hit an error, and I needed to see what it saw at runtime.

Get the WebView Console first

The test device connected to DevPeek through the proxy.

Steps completed:

Install the HTTPS certificate;
Configure the proxy;
Enable SSL decryption for the target domain.

Full checklist: mobile web debugging; if the preview stays on "Waiting for device connection", check the FAQ.

In the DevPeek Debug tab, select the device. QA reopened the campaign page.

A red line appeared immediately in the Console:

Uncaught TypeError:
e.isIntersecting is not a function

at IntersectionObserver polyfill
(chunk-vendors.js:1847)

Real device console output streams to the debug panel.

The direction was clear.

Root cause: polyfill overrode the native implementation

This involves IntersectionObserver.

Android 14's WebView natively supports this API. But the project still loaded an old polyfill, which overrode the native implementation. So the page was running the polyfill version instead of the native IntersectionObserver—and the two implementations had compatibility differences.

A quick remote eval in Console confirmed it:

navigator.userAgent.match(/Android\s([\d.]+)/)?.[1];
// "14"  ——confirmed Android version

typeof IntersectionObserver;
// "function"  ——confirmed API exists

IntersectionObserver.toString().includes("native code");
// false  ——confirmed not running native implementation

Root cause confirmed.

Issue located, but testing wasn't done

The frontend team started fixing the polyfill. But the stress test window was still open.

QA needed to confirm: if the API returns error states, does the page fall back correctly?

For example:

Campaign ended;
User not authorized;
Insufficient inventory.

These scenarios can't wait for backend cooperation every time. We needed to simulate API responses.

Using Mock to verify error scenarios

In the DevPeek capture list, find POST /api/campaign/join.

Create a Mock rule.

Match conditions:

URL contains campaign/join
Method is POST

Response modification:

{
  "code": 10086,
  "message": "Campaign ended"
}

Save and enable.

Mock rules take effect immediately, no proxy restart.

QA tapped the button again. This time, no white screen—the page showed "Campaign ended" as expected. Fallback logic verified.

To test other error scenarios, for example:

{
  "code": 10010,
  "message": "Campaign not available"
}

Just update the Mock response and quickly verify different error states.

No need to:

Modify the backend API;
Wait for API deployment;
Repack the H5.

Mock rules are persistent—they survive closing and reopening DevPeek. Remember to disable or delete temporary rules after the session.

The full investigation flow

The complete debug chain for this case:

Button tap
    ↓
Capture confirms API returned 200
    ↓
Console captures WebView runtime error
    ↓
Remote eval confirms polyfill override
    ↓
Fix confirmed
    ↓
Mock simulates error API responses
    ↓
Fallback UI verified

Throughout the entire process, no H5 repack was needed, and no client-side debug mode was required.

Why this went smoothly

In similar past situations, multiple tools were usually needed:

Capture tool to confirm requests;
vConsole to check runtime logs;
Another tool to modify API responses.

Each tool solved part of the problem. But during investigation, you'd often wonder:

Where was that error log again?
What did that API return?
Did the phone re-trigger the request after the Mock change?

Information was scattered across different tools.

This time, everything was on the same debug chain:

Network
   ↓
Console
   ↓
Mock
   ↓
Real device page

For mobile H5 debugging, fewer tool switches means less context loss—and that alone reduces investigation cost.

Limitations

Console and Mock aren't silver bullets.

1. Page completely crashed

Infinite loops, stack overflow, main thread blocking—the injected debug script may not connect either. Fall back to resource loading and network checks.

2. iframe pages

Console runs in the current page context by default. If the issue is inside an iframe, open that URL separately.

3. Mock may not intercept all requests

Mock depends on the proxy chain. Service Worker cache, native network interception, or certain WebView kernel behaviors may bypass it. Verify the request goes through the proxy.

4. Remote eval context

Remote scripts share the page's execution context. Quick checks are fine, but avoid heavy IndexedDB iteration or long synchronous tasks—use async patterns instead.

This is Part 2 of the H5 Debug in Practice series. Part 1 covered debugging WeChat H5 localStorage on real devices using the Session panel.

The tool used in this article is DevPeek, a desktop packet capture and debugging tool that integrates proxy capture, page debugging, and Mock rules on the same chain.

More resources:

If you've run into similar issues—API OK but page broken, Android WebView compatibility, or debugging production H5 without injecting debug code—feel free to share your experience in the comments or discuss on GitHub Discussions.

Why We Built DevPeek (1): HTTPS Decrypted, Body Still Gibberish

GYPengDev — Fri, 10 Jul 2026 03:57:21 +0000

Part 1 of a short series on why we built DevPeek—a proxy tool that keeps capture, business-layer crypto, and replay on one chain.

9:40 PM, pinged in the group again

Night before a release. QA dropped a line:

“Staging login is broken—production users are reporting it too.”

Not a scheduled joint-debug session. People were already chasing updates in the thread.

Proxy on, HTTPS decrypting fine. That POST /api/user/login showed 200—the path looked healthy. I opened the request body anyway:

{
  "payload": "U2FsdGVkX1+8K3v… (long string continues)",
  "sign": "a8f3c2…"
}

TLS was fine. payload was still a Base64 blob. We had been shipping this style of API for years: gateway-wrapped body, AES on the fields, a sign on the side. Normal on a slow day. That night was not slow.

TLS is decrypted in the list—but fields like payload can still be ciphertext.

Fine most days. Miserable when you are rushed.

My usual loop looked something like this:

Copy the ciphertext. Open an online decrypt page—I keep three of those bookmarked. Paste, get plaintext. Backend says “try field X,” so I edit it, encrypt again, and replay in Postman or a script.

Charles handles HTTPS. Business-layer crypto still lives somewhere else. When I am not in a hurry, hopping windows is annoying but survivable. When time is tight, bouncing between capture, browser, and terminal gets old fast.

That night

The payload in the request was still ciphertext. I could not tell where login was failing. I dropped a screenshot in the backend channel: “Can you help read the body plaintext?”

Message sent. Reply not in yet. The decrypt script in my terminal was already running—done this so many times it is basically reflex.

Then the reply:

“Staging uses key set B. Do not decrypt with production keys.”

The API itself was fine. Time went to matching keys and environment first. Until the plaintext lines up, there is nothing useful to debug.

Then a small ask: “Change userId in the request to 0 and run login again—see if auth is misjudging.”

That means touching the login request the app actually sends. Same encrypted body. Same grind: decrypt, edit the field, encrypt again, let the app emit something the server will accept.

I tried Breakpoints in Charles to edit it in flight. Open the body—ciphertext. Cannot edit. Back to the Python script under scripts/debug/, untouched for three months. Postman can send a version, but headers, cookies, and signing order never quite match the real app path, so you never fully trust the result.

QA kept asking: “So can we log in on staging?”

I burned nearly an hour in that manual loop. Looking back, they wanted to check one or two fields.

Before standup, product added: “Check signup too—same encryption as login.” New URL. Copy the script. Tweak it. Same grind again.

A new backend teammate asked which key each endpoint uses. The doc is in Confluence. Not something you see in the capture UI.

We were never stuck on TLS

Charles and Fiddler earn their keep stripping HTTPS. The grind sits one layer up: request bodies still ciphertext, and every edit or replay still done by hand—decrypt, change, encrypt again.

Certs are fine. The endpoint returns 200. The thread is still blowing up. And somehow you still cannot skip copying ciphertext, matching staging vs production keys, or the decrypt–edit–re-encrypt–replay loop.

After that night

Before standup, my head was still on last night’s login request.

The proxy already sat on the path. TLS was stripped. Business-layer crypto still lived outside the proxy—external sites, terminal scripts, Postman, each doing its own thing. Change one userId? They wanted one or two fields checked, and the whole manual loop had to run again.

After grinding through that night, a blunt thought surfaced: what if one tool owned capture and business-layer crypto together? The proxy is already in the chain—decrypt scripts, environment keys, edit-and-replay should not mean hopping across four windows.

That is roughly where DevPeek started.

The first piece we wanted to pull in was the part that night would not let go of—outbound requests. Charles handles TLS; we would handle the layer above: read ciphertext in the proxy, edit plaintext, encrypt again on the way out—and request-only first, because that was the slowest, hardest-to-skip slice of joint debugging.

That became param transform. It maps onto the same manual steps, except you never leave the capture UI:

Conversion config handles how to decrypt and re-encrypt. Staging key set B vs production key set A lives next to your capture context—no more Confluence hunting. The Python under scripts/debug/ can move into script conversion; common AES setups can use built-in algorithms.

Param transform rules decide which requests and which parameters get converted. Right-click POST /api/user/login, pick URL + payload, bind the conversion config—save once, matching traffic hits it automatically.

Pick URL and encrypted fields from a captured request; bind a conversion config once.

Once that is in place, you mostly work in plaintext: decrypted fields show up in details; when backend says “try userId = 0,” edit in Mock tamper or the “Debug API” drawer and send—DevPeek re-encrypts on the way out while headers, cookies, and signing stay on the real app path. The Mock tamper dialog is not limited by client tab—whether you are on Capture or Debug, it auto-opens while items are pending, on the same proxy chain as capture and Debug tab Network. Signup? Change the URL match, reuse the config.

On manual Mock hit, edit plaintext in the dialog—Continue re-encrypts on the way out, no Postman hop.

The list still records what the client actually sent; plaintext lives in details for comparison. Postman and that three-month-old Python script can step back.

An hour that night was really about one or two fields. DevPeek grew from there; param transform was the first piece to land—turning that verification into “edit the value, hit send.”

Why We Built DevPeek (2): That H5 Page in the App—Debug It on Your PC—mobile pages opened through the proxy, mirrored in the Debug tab, with our own panel for DOM, console, and network—not just squinting at the phone.

If you are still hand-rolling request bodies under pressure, try DevPeek or say hi on GitHub Discussions—param transform guide: docs.

Originally published on the DevPeek blog.

Encrypted Mobile API Debugging? No More Copying Ciphertext Across Multiple Tools

GYPengDev — Wed, 08 Jul 2026 13:00:00 +0000

I'm an independent developer who spends a lot of time debugging mobile H5 pages through a local HTTPS proxy.

The part that never gets easier: the request body looks fine in the proxy, but every important field is still encrypted. You copy a Base64 blob into a Node REPL, tweak a phone number, re-encode it, paste it into Postman, realize the client also signs headers, close Postman, open Charles again…

Existing tools are good at transport (TLS MITM) or API replay (Postman/Insomnia). Neither really owns the loop of capture → decrypt → edit in context → re-encrypt → mock or resend. That's the gap I kept hitting for months.

This post walks through that manual workflow first — then the layered config model I used to automate it.

Two different "decryptions"

Before any app-layer trickery, you need plaintext HTTP.

Layer	What you get	Typical setup
Transport (HTTPS MITM)	Readable HTTP headers/body	Proxy + trusted root CA on device + SSL decrypt allowlist
Application (param transform)	Readable business fields inside JSON/query	Rules that decode Base64/AES/etc. on specific keys

If your capture list is full of CONNECT tunnels and empty bodies, fix layer 1 first. Param transform only helps once you can already see something like:

{
  "username": "alice",
  "token": "YWxpY2U6c2VjcmV0"
}

Pain point 1: Decrypting once is easy; doing it fifty times a day is not

Here's the manual loop I used to run for a single login field:

1. Capture in the proxy

POST /v1/login HTTP/1.1
Host: api.example.com
Content-Type: application/json

{"username":"alice","token":"YWxpY2U6c2VjcmV0"}

2. Decode in a one-off script

// decode.mjs — run every time you need to inspect a value
const token = "YWxpY2U6c2VjcmV0";
console.log(Buffer.from(token, "base64").toString("utf8"));
// alice:secret

3. Change the value and encode back

const plain = "alice:new-secret";
console.log(Buffer.from(plain, "utf8").toString("base64"));
// YWxpY2U6bmV3LXNlY3JldA==

4. Paste into Postman — which doesn't know your client's header signing, cookie jar, or device fingerprint.

5. Give up and edit in Charles — but Charles has no first-class "this JSON key is always Base64" rule that also feeds your mock matcher.

The userId, phone, device token… each field repeats the same five steps. Teams share Postman collections but rarely share the half-broken decrypt scripts that live in someone's ~/tmp.

Pain point 2: Mocking on ciphertext is fragile

Say you want to mock "phone = 13800138000" on an encrypted API.

Without transform rules you either:

Pre-compute ciphertext offline and hard-code it in the mock (breaks when keys rotate), or
Write a Charles rewrite script that decrypts before matching (works, but nobody on the team wants to maintain it)

What you actually want is: match on plaintext, send ciphertext. That implies decrypt-before-match in the proxy pipeline:

incoming request
  → apply param transform (derive plaintext)
  → mock matcher reads plaintext features
  → (optional) re-encrypt before forwarding

Order matters. If mock runs on raw body only, your 13800138000 rule never fires.

Pain point 3: AES is where copy-paste really breaks

Base64 is annoying. AES-CBC with a fixed IV is where I lost afternoons.

Minimal Node version that must match the mobile client byte-for-byte:

const crypto = require("crypto");

function decryptField(b64Cipher) {
  const key = Buffer.from("1234567890123456", "utf8"); // 16 bytes
  const iv  = Buffer.from("abcdefghijklmnop", "utf8"); // 16 bytes
  const decipher = crypto.createDecipheriv("aes-128-cbc", key, iv);
  decipher.setAutoPadding(true); // PKCS7
  let plain = decipher.update(b64Cipher, "base64", "utf8");
  plain += decipher.final("utf8");
  return plain;
}

function encryptField(plain) {
  const key = Buffer.from("1234567890123456", "utf8");
  const iv  = Buffer.from("abcdefghijklmnop", "utf8");
  const cipher = crypto.createCipheriv("aes-128-cbc", key, iv);
  let out = cipher.update(plain, "utf8", "base64");
  out += cipher.final("base64");
  return out;
}

One wrong assumption — key as hex vs utf8, IV prepended to ciphertext, GCM auth tag placement — and you get garbage. Now multiply that by three environments (staging keys, prod keys, feature-flag keys).

Multi-step pipelines are worse:

// common pattern: base64 wrapper around AES output
function convertDecrypt(input) {
  const inner = Buffer.from(input, "base64").toString("utf8");
  return decryptField(inner);
}

That's when I stopped trusting one-liner snippets and started wanting versioned, exportable rules tied to URL patterns.

Pain point 4: Postman isn't on the phone's code path

Postman is great for contract testing. It's a poor stand-in when:

The app adds a timestamp + HMAC over the sorted body
Tokens come from a previous capture-only handshake
You need to see what this WebView actually sent, then nudge one field

The useful workflow is: same captured request, same headers, one edited field, resend through the proxy. Not "reconstruct the request from docs."

A cleaner model: separate "how" from "where"

The model I ended up with splits config into two layers — conversion rules (how to decrypt/encrypt) and param transform rules (which request + which param key):

Conversion rule     → HOW to decrypt/encrypt (algorithm or script)
        ↑ referenced by
Transform rule      → WHICH request + WHICH param key
        ↓ produces
paramTransformDerived (plaintext sidecar — original capture untouched)

Why keep the raw capture?

Audit: you still see what the client actually sent
Diff: compare ciphertext drift across builds
Safety: failed transforms don't corrupt stored payloads

Example transform target for the login JSON above:

// conceptual config — not a literal file format
{
  "match": {
    "url": [{ "key": "host", "value": "api.example.com" }],
    "bodyParams": [{ "key": "token", "value": "*", "bodyKind": "json" }]
  },
  "apply": {
    "ruleId": "cr_login_b64",
    "target": { "source": "body", "key": "token", "bodyKind": "json" }
  }
}

With a builtin Base64 conversion rule on cr_login_b64, every matching capture automatically gets a derived plaintext row — no REPL, no clipboard.

Script escape hatch (when builtin isn't enough)

For custom signing, chained transforms, or calling an internal decrypt API:

function convertDecrypt(input, request) {
  // input: the param string; request: read-only snapshot (host, headers, body, query)
  return util.crypto.aesDecrypt({
    ciphertext: input,
    key: "0123456789abcdef",
    iv: "0123456789abcdef",
    keyEncoding: "utf8",
    ivEncoding: "utf8",
    inputEncoding: "base64",
    outputEncoding: "utf8",
  });
}

function convertEncrypt(input, request) {
  return util.crypto.aesEncrypt({
    plaintext: input,
    key: "0123456789abcdef",
    iv: "0123456789abcdef",
    keyEncoding: "utf8",
    ivEncoding: "utf8",
    plaintextEncoding: "utf8",
    outputEncoding: "base64",
  });
}

convertEncrypt is optional — only needed if you want to edit plaintext and send it back (mock tamper, resend drawer). MD5/SHA/HMAC-style rules are view-only by design.

That's the full layered model. I built a desktop proxy tool around it so the decrypt → edit → re-encrypt loop stays inside the capture workflow instead of bouncing between a REPL and three other apps.

What I wired this into — DevPeek

The app is called DevPeek (Electron + Vue 2 main/renderer, Node proxy in the middle). I used the pain points above as a checklist. Three places param transform actually matters:

Capture detail — a dedicated tab shows ciphertext, derived plaintext, and success/failure per rule. Day-to-day debugging reads plaintext first.
Mock — matchers can use decrypted features; tamper UI edits plaintext and re-encrypts on continue. Fixes pain point 2 without maintaining Charles scripts.
Resend / debug API drawer — start from the captured request, edit a JSON field as plain text, send through the proxy with auto re-encrypt. Fixes pain point 4.

Builtins cover Base64, AES-ECB/CBC/GCM, DES/3DES, RSA; scripts run sandboxed with helpers for crypto, compression, and HTTP if you need a remote decrypt service.

Core desktop features (proxy, SSL decrypt, param transform, mock, search) are free — no subscription wall on the workflow described here.

I'm curious — what's the most annoying encrypted param debugging workflow you've had to deal with? Feel free to share your pain points below; I may add native support for those cases in future updates.

I've released Windows builds for anyone who wants to test this param transform workflow out — macOS and Linux builds are actively in development based on community feedback.

Docs: Param transform guide

Try it: devpeek.ypgao.com

Troubleshooting cheatsheet

Symptom	Likely cause
Body still opaque gibberish	HTTPS MITM not set up (cert / decrypt allowlist)
Transform tab empty	Rule disabled or URL/body pattern mismatch
`builtin_error`	Key/IV encoding, padding, or algorithm mismatch vs client
Mock never matches plaintext	Transform didn't run before mock; check rule order
Field read-only in resend UI	Re-encrypt not enabled, or algorithm is one-way (hash/HMAC)