[{"data":1,"prerenderedAt":44},["ShallowReactive",2],{"case-api-param-encryption-debug-en":3,"blog-list-en":13},{"slug":4,"title":5,"summary":6,"date":7,"featured":8,"seoDescription":9,"series":10,"seriesOrder":11,"html":12},"api-param-encryption-debug","H5 API Encrypted? Decrypt It On the Fly with DevPeek","Stuck with AES-encrypted API params during integration? Set the key and IV once in DevPeek Param Transform, and see plaintext automatically — you can even edit and re-encrypt on resend.","2026-07-18",false,"Use DevPeek Param Transform to auto-decrypt AES-GCM encrypted H5 API requests. Supports two-way transform, plaintext editing, and debug replay.","api-debug-new-tricks",1,"\u003Cp>Your H5 page encrypts the API body before sending it — \u003Ccode>{&quot;userId&quot;:&quot;123&quot;,&quot;keyword&quot;:&quot;can&#39;t see me&quot;}\u003C\u002Fcode> becomes \u003Ccode>{ &quot;data&quot;: &quot;6be9792e5ed250fc...&quot; }\u003C\u002Fcode>. What you see in the DevPeek request list is a blob of hex, with no clue what was actually sent.\u003C\u002Fp>\n\u003Cp>\u003Cimg src=\"\u002Fdocs\u002Ffigures\u002Fdemo1\u002Fdemo-ciphertext-raw.png\" alt=\"\">\u003C\u002Fp>\n\u003Cp>DevPeek can&#39;t make sense of it either:\u003C\u002Fp>\n\u003Cp>\u003Cimg src=\"\u002Fdocs\u002Ffigures\u002Fdemo1\u002Fdemo-no-decrypt-rule.png\" alt=\"\">\u003C\u002Fp>\n\u003Cp>This pattern is common in embedded H5 apps: the entire request body is symmetrically encrypted, and the backend decrypts it on receipt. It&#39;s a reasonable security measure, but during integration it means you can&#39;t read the parameters, can&#39;t write Mock rules, don&#39;t know what to change at breakpoints, and end up guessing your way through issues.\u003C\u002Fp>\n\u003Cp>This article shows how DevPeek&#39;s \u003Cstrong>Param Transform\u003C\u002Fstrong> feature can automatically decrypt those parameters — set up the rule once, and every matching request shows plaintext alongside the ciphertext.\u003C\u002Fp>\n\u003Ch2>Who This Is For\u003C\u002Fh2>\n\u003Cul>\n\u003Cli>Developers who frequently deal with encrypted API parameters during H5 integration\u003C\u002Fli>\n\u003Cli>Engineers using or evaluating DevPeek for debugging encrypted API traffic  \u003C\u002Fli>\n\u003Cli>Anyone tired of manually decoding parameters or pestering the backend team for decryption help\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2>Common Pitfalls\u003C\u002Fh2>\n\u003Col>\n\u003Cli>\u003Cstrong>AES parameter mismatch\u003C\u002Fstrong> — key encoding, IV encoding, and input encoding defaults don&#39;t match your actual format, causing silent decryption failures\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Auth Tag placement confusion\u003C\u002Fstrong> — GCM auth tags may be appended to the ciphertext or delivered separately\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Decrypt-only setup\u003C\u002Fstrong> — once you edit parameters and want to replay, DevPeek doesn&#39;t know how to re-encrypt without a two-way rule\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>The example below uses AES-256-GCM with a \u003Cstrong>fixed IV, auth tag appended to the ciphertext, and hex encoding\u003C\u002Fstrong> — the most common combination.\u003C\u002Fp>\n\u003Ch2>Step 1: Configure the Encryption Rule\u003C\u002Fh2>\n\u003Cp>Right-click on the request → \u003Cstrong>Param Transform\u003C\u002Fstrong>:\u003C\u002Fp>\n\u003Cp>\u003Cimg src=\"\u002Fdocs\u002Ffigures\u002Fdemo1\u002Fdemo-right-click-param-transform.png\" alt=\"\">\u003C\u002Fp>\n\u003Cp>In the Param Transform Rules window, first create a \u003Cstrong>Conversion Rule\u003C\u002Fstrong> to tell DevPeek which algorithm and key to use.\u003C\u002Fp>\n\u003Cp>Go to the \u003Cstrong>Conversion Rules\u003C\u002Fstrong> tab → Add → \u003Cstrong>Built-in\u003C\u002Fstrong> → select \u003Cstrong>AES-GCM\u003C\u002Fstrong>:\u003C\u002Fp>\n\u003Cp>\u003Cimg src=\"\u002Fdocs\u002Ffigures\u002Fdemo1\u002Fdemo-builtin-aes-gcm-config.png\" alt=\"\">\u003C\u002Fp>\n\u003Cp>Fill in the parameters (this is where most mistakes happen — \u003Cstrong>double-check every field\u003C\u002Fstrong>):\u003C\u002Fp>\n\u003Ctable>\n\u003Cthead>\n\u003Ctr>\n\u003Cth>Field\u003C\u002Fth>\n\u003Cth>Value\u003C\u002Fth>\n\u003Cth>Note\u003C\u002Fth>\n\u003C\u002Ftr>\n\u003C\u002Fthead>\n\u003Ctbody>\u003Ctr>\n\u003Ctd>Algorithm\u003C\u002Ftd>\n\u003Ctd>\u003Ccode>aes-gcm\u003C\u002Fcode>\u003C\u002Ftd>\n\u003Ctd>\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Key\u003C\u002Ftd>\n\u003Ctd>\u003Ccode>342e668900166e5f6731f7a172f52862e3a43da54611519dec5246dadb6e7429\u003C\u002Fcode>\u003C\u002Ftd>\n\u003Ctd>SHA-256 derived 256-bit key\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Key Encoding\u003C\u002Ftd>\n\u003Ctd>\u003Cstrong>Hex\u003C\u002Fstrong> ⚠️\u003C\u002Ftd>\n\u003Ctd>The key is a hex string, not UTF-8 text\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>IV \u002F Nonce\u003C\u002Ftd>\n\u003Ctd>\u003Ccode>a1b2c3d4e5f6a7b8c9d0e1f2\u003C\u002Fcode>\u003C\u002Ftd>\n\u003Ctd>Fixed 12-byte IV\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>IV \u002F Nonce Encoding\u003C\u002Ftd>\n\u003Ctd>\u003Cstrong>Hex\u003C\u002Fstrong> ⚠️\u003C\u002Ftd>\n\u003Ctd>Same as above\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Ciphertext Input Encoding\u003C\u002Ftd>\n\u003Ctd>\u003Cstrong>Hex\u003C\u002Fstrong> ⚠️\u003C\u002Ftd>\n\u003Ctd>The demo outputs hex, not base64 (DevPeek defaults to base64)\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Output Encoding\u003C\u002Ftd>\n\u003Ctd>UTF-8\u003C\u002Ftd>\n\u003Ctd>Plaintext encoding\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Auth Tag Length\u003C\u002Ftd>\n\u003Ctd>16\u003C\u002Ftd>\n\u003Ctd>GCM default — 16 bytes\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003C\u002Ftbody>\u003C\u002Ftable>\n\u003Cblockquote>\n\u003Cp>Why are these three encodings easy to get wrong? DevPeek&#39;s built-in AES-GCM defaults to \u003Ccode>keyEncoding: utf8\u003C\u002Fcode>, \u003Ccode>ivEncoding: utf8\u003C\u002Fcode>, and \u003Ccode>inputEncoding: base64\u003C\u002Fcode>, but this demo uses hex. If you forget to switch them to Hex, DevPeek will use completely different bytes to decrypt — guaranteed failure. \u003Cstrong>When decryption fails, check these three encodings first.\u003C\u002Fstrong>\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\u003Cp>Save the rule. It now appears in the Conversion Rules list.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Completion criteria:\u003C\u002Fstrong> A Conversion Rule with AES-GCM appears in the list.\u003C\u002Fp>\n\u003Ch2>Step 2: Configure the Param Transform Rule\u003C\u002Fh2>\n\u003Cp>Back in the Param Transform Rules window, add a new rule. This tells DevPeek \u003Cstrong>which request&#39;s which field\u003C\u002Fstrong> to decrypt using the rule from Step 1.\u003C\u002Fp>\n\u003Ch3>Match Conditions\u003C\u002Fh3>\n\u003Cp>After toggling the match conditions, the right panel previews the current request&#39;s features:\u003C\u002Fp>\n\u003Cp>\u003Cimg src=\"\u002Fdocs\u002Ffigures\u002Fdemo1\u002Fdemo-match-conditions-preview.png\" alt=\"\">\u003C\u002Fp>\n\u003Ctable>\n\u003Cthead>\n\u003Ctr>\n\u003Cth>Field\u003C\u002Fth>\n\u003Cth>Value\u003C\u002Fth>\n\u003C\u002Ftr>\n\u003C\u002Fthead>\n\u003Ctbody>\u003Ctr>\n\u003Ctd>URL Match\u003C\u002Ftd>\n\u003Ctd>\u003Ccode>\u002Fapi\u002Fquery\u003C\u002Fcode>\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Method\u003C\u002Ftd>\n\u003Ctd>\u003Ccode>POST\u003C\u002Fcode>\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Scope\u003C\u002Ftd>\n\u003Ctd>Start with &quot;Manual&quot; to target only this request\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003C\u002Ftbody>\u003C\u002Ftable>\n\u003Ch3>Transform Target\u003C\u002Fh3>\n\u003Cp>\u003Cstrong>Body › JSON › data\u003C\u002Fstrong> — tells DevPeek to decrypt the value of the \u003Ccode>data\u003C\u002Fcode> field in the request body.\u003C\u002Fp>\n\u003Ch3>Referenced Rule\u003C\u002Fh3>\n\u003Cp>Select the AES-GCM Conversion Rule created in Step 1. The right panel immediately previews the decryption result:\u003C\u002Fp>\n\u003Cp>\u003Cimg src=\"\u002Fdocs\u002Ffigures\u002Fdemo1\u002Fdemo-select-rule-preview.png\" alt=\"\">\u003C\u002Fp>\n\u003Cp>If everything is correct, the ciphertext in the \u003Ccode>data\u003C\u002Fcode> field is decoded to \u003Ccode>{&quot;userId&quot;:&quot;123&quot;,&quot;keyword&quot;:&quot;can&#39;t see me&quot;}\u003C\u002Fcode>.\u003C\u002Fp>\n\u003Cp>Save the rule. Go back to the request list and inspect the same request:\u003C\u002Fp>\n\u003Cp>\u003Cimg src=\"\u002Fdocs\u002Ffigures\u002Fdemo1\u002Fdemo-decrypted-params.png\" alt=\"\">\u003C\u002Fp>\n\u003Cp>The plaintext now appears alongside the ciphertext — crystal clear.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Completion criteria:\u003C\u002Fstrong> The request detail shows decrypted plaintext for the \u003Ccode>data\u003C\u002Fcode> field.\u003C\u002Fp>\n\u003Ch2>Going Further: Enable Two-Way Transform\u003C\u002Fh2>\n\u003Cp>With decryption working, you can enable \u003Cstrong>two-way transform\u003C\u002Fstrong> so that editing the plaintext in the debug drawer automatically re-encrypts it before sending.\u003C\u002Fp>\n\u003Cp>Toggle the &quot;Two-Way Transform&quot; switch in the Param Transform rule:\u003C\u002Fp>\n\u003Cp>\u003Cimg src=\"\u002Fdocs\u002Ffigures\u002Fdemo1\u002Fdemo-enable-two-way.png\" alt=\"\">\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Before enabling\u003C\u002Fstrong>, the ciphertext is editable and the plaintext is read-only — you can manually craft new ciphertext and replay it, but you&#39;d need to handle the encryption yourself.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>After enabling\u003C\u002Fstrong>, the ciphertext becomes read-only, and the plaintext becomes editable. Edit the value and click &quot;Send&quot; — DevPeek re-encrypts it with the same AES-GCM parameters automatically:\u003C\u002Fp>\n\u003Cp>\u003Cimg src=\"\u002Fdocs\u002Ffigures\u002Fdemo1\u002Fdemo-debug-ciphertext-readonly.png\" alt=\"\">\u003C\u002Fp>\n\u003Cp>Now you can tweak parameters during debugging without worrying about the encryption process at all.\u003C\u002Fp>\n\u003Cp>\u003Cimg src=\"\u002Fdocs\u002Ffigures\u002Fdemo1\u002Fdemo-plaintext-editable-auto-encrypt.png\" alt=\"\">\u003C\u002Fp>\n\u003Ch2>How Param Transform Works\u003C\u002Fh2>\n\u003Cp>Param Transform is a \u003Cstrong>match → extract → decrypt → display\u003C\u002Fstrong> pipeline:\u003C\u002Fp>\n\u003Cpre>\u003Ccode>Request arrives at DevPeek\n    │\n    ▼ Match paramTransformRules\n    │   URL: \u002Fapi\u002Fquery, Method: POST\n    │\n    ▼ Extract target field value\n    │   body:json:data → &quot;6be9792e5e...&quot;\n    │\n    ▼ Reference conversionRule to decrypt\n    │   AES-256-GCM(key+IV, authTagPlacement=append)\n    │\n    ▼ Result stored in record.paramTransformDerived\n    │   Original request body untouched, plaintext attached alongside\n    │\n    ▼ Displayed in: request detail, Mock matching, debug replay\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>DevPeek \u003Cstrong>never modifies the original request\u003C\u002Fstrong> — the ciphertext stays as-is, and the decrypted plaintext is stored separately in \u003Ccode>paramTransformDerived\u003C\u002Fcode>. This guarantees that even if decryption fails, the original data remains intact.\u003C\u002Fp>\n\u003Cp>Built-in conversions support AES-CBC, AES-ECB, AES-GCM, DES-CBC, 3DES-CBC, RSA, and Base64. If those aren&#39;t enough, you can use \u003Cstrong>Script Conversion\u003C\u002Fstrong> — write custom JS decryption logic in a sandboxed environment, with access to the full request context. The sandbox includes a rich toolchain (\u003Ccode>util.crypto\u003C\u002Fcode>, \u003Ccode>util.encode\u003C\u002Fcode>, \u003Ccode>util.compress\u003C\u002Fcode>, \u003Ccode>util.json\u003C\u002Fcode>) plus APIs like \u003Ccode>axios\u003C\u002Fcode>, \u003Ccode>URL\u003C\u002Fcode>, and \u003Ccode>URLSearchParams\u003C\u002Fcode>, so you can make HTTP calls to fetch keys or delegate decryption to a remote service — ideal for dynamic IVs, rotating keys, and other complex scenarios.\u003C\u002Fp>\n\u003Ch2>Next Steps\u003C\u002Fh2>\n\u003Cp>This article covers the fixed-IV, tag-appended AES-GCM scenario. Real-world encryption schemes vary widely — if your API uses something different (e.g., dynamic IVs that must be extracted from the request body, or keys fetched from a remote service), check out \u003Ca href=\"\u002Fdocs\u002Fscripts-breakpoints\u002F\">Script Conversion\u003C\u002Fa> — the sandbox comes with \u003Ccode>axios\u003C\u002Fcode>, \u003Ccode>util.crypto\u003C\u002Fcode>, and more, giving you the flexibility to handle any encryption scheme.\u003C\u002Fp>\n\u003Cp>For a full reference of Param Transform configuration options and all built-in algorithms, see the \u003Ca href=\"\u002Fdocs\u002Fparam-transform\u002F\">Param Transform docs\u003C\u002Fa>.\u003C\u002Fp>\n\u003Chr>\n\u003Cp>If you&#39;re tired of manually decoding encrypted request bodies during integration, \u003Ca href=\"\u002F\">download DevPeek\u003C\u002Fa> and follow the steps above to set up your first decrypt rule. Or join the discussion on \u003Ca href=\"https:\u002F\u002Fgithub.com\u002FGYPengDev\u002Fdevpeek\u002Fdiscussions\">GitHub Discussions\u003C\u002Fa> to share your encryption setup.\u003C\u002Fp>\n\u003Ch2>Related Docs\u003C\u002Fh2>\n\u003Cul>\n\u003Cli>\u003Ca href=\"\u002Fdocs\u002Fparam-transform\u002F\">Param Transform\u003C\u002Fa>\u003C\u002Fli>\n\u003Cli>\u003Ca href=\"\u002Fdocs\u002Fscripts-breakpoints\u002F\">Scripts &amp; Breakpoints\u003C\u002Fa>\u003C\u002Fli>\n\u003Cli>\u003Ca href=\"\u002Fdocs\u002Fmock\u002F\">Mock Rules\u003C\u002Fa>\u003C\u002Fli>\n\u003Cli>\u003Ca href=\"\u002Fdocs\u002Fdebug-replay\u002F\">Debug &amp; Replay\u003C\u002Fa>\u003C\u002Fli>\n\u003Cli>\u003Ca href=\"\u002Fdocs\u002Fquick-start\u002F\">Quick Start\u003C\u002Fa>\u003C\u002Fli>\n\u003C\u002Ful>\n",{"items":14},[15,16,25,31,38],{"slug":4,"title":5,"summary":6,"date":7,"featured":8,"seoDescription":9,"series":10,"seriesOrder":11},{"slug":17,"title":18,"summary":19,"date":20,"featured":21,"seoDescription":22,"series":23,"seriesOrder":24},"h5-debug-console-mock","H5 Debug in Practice (2): Android WebView White Screen—From Console Remote Debug to Mock Validation","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 WebView runtime logs, remote eval to confirm a polyfill override, then Mock to verify the fallback UI under error conditions.","2026-07-13",true,"DevPeek H5 debug practice part 2: troubleshoot Android WebView white screen via Console remote debug to locate a JavaScript polyfill conflict, then use Mock to verify page fallback behavior under abnormal API responses.","h5-debug",2,{"slug":26,"title":27,"summary":28,"date":29,"featured":21,"seoDescription":30,"series":23,"seriesOrder":11},"wechat-h5-storage-debug","H5 Debug in Practice (1): WeChat H5 Local Cache—Debug It on Desktop","After switching test accounts in a WeChat official-account H5, the avatar still showed the old user—capture had the new token, stale data stayed in localStorage. This post walks through a real joint-debug case and how to view and edit localStorage, sessionStorage, and IndexedDB in WeChat WebView from your PC.","2026-07-11","DevPeek H5 debug: locate localStorage, sessionStorage, and IndexedDB cache issues in WeChat H5—compared with vConsole and remote debug, with real WebView debugging workflow.",{"slug":32,"title":33,"summary":34,"date":35,"featured":21,"seoDescription":36,"series":37,"seriesOrder":24},"why-we-built-devpeek-h5-debug","Why We Built DevPeek (2): That H5 Page in the App—Debug It on Your PC","Param transform fixed login, but the activity H5 only broke inside the App WebView. Remote debug and capture lived in different windows—so we folded mirroring and our own debug panels into DevPeek.","2026-07-10","DevPeek origin series, part 2: in-app H5 bugs that only show on real devices, the split between remote debug and capture, and how the Debug tab mirrors pages with built-in DOM, Console, and Network panels.","origin",{"slug":39,"title":40,"summary":41,"date":42,"featured":21,"seoDescription":43,"series":37,"seriesOrder":11},"why-we-built-devpeek","Why We Built DevPeek (1): HTTPS Decrypted, Body Still Gibberish","The night before a release, TLS was already open—but changing one request field still meant digging up encrypt\u002Fdecrypt scripts. That pushed us toward a proxy tool with business-layer crypto built in—and DevPeek started there.","2026-07-09","DevPeek origin series, part 1: the manual request-body encrypt\u002Fdecrypt grind—and why we set out to build a proxy tool that owns business-layer crypto.",1784353379838]