Client Reverse
Client-side request-signing and anti-bot token reversal for bug bounty, when a request...
Install
npx skills add awarexone/Agentic-Bug-Hunter --skill client-reverse -g -a claude-code -y- Repository
- awarexone/Agentic-Bug-Hunter5.5k
- Category
- Business
- Updated
- 7d ago
- License
- MIT
- Context cost
- Mediumabout 3,000 tokens
- Runs scripts
- No, instructions only
What it does
Client-side request-signing and anti-bot token reversal for bug bounty, when a request carries a sign/sig/hmac/token/nonce/timestamp/X-Sensor header that Burp Repeater cannot replay, recover the signer just enough to reproduce the request outside the client. Packet-first staging (capture real request → prove replay works → only reverse if replay fails) across the locate→recover→runtime→validation→replay spine. Covers tracing backward from the signature field (writer→builder→entry→source), isolating user-mutable sign inputs (timestamp/nonce/deviceId/body) vs constants (secret key), hooking fetch/XHR in DevTools, JS deobfuscation basics (webpack/wasm/JSVMP), and the bounty payoff: reach the protected API to then hunt IDOR/auth/business-logic. Use when Burp/mitmproxy replay of a signed or anti-bot-gated request fails and you suspect a client-computed field is blocking you.
CLIENT-SIDE REQUEST-SIGNING / ANTI-BOT TOKEN REVERSAL
You hit a request you cannot replay. Burp Repeater returns 401 invalid signature or 403 bot detected even though the browser/app does it fine. There is a sign, sig, X-Signature, _token, nonce, X-Acf-Sensor-Data, or encrypted body the client computes. This skill recovers just enough of that signer to reproduce the request outside the client.
Why a bug bounty hunter cares: the signature is not the bug. The signature is the lock on the door. Behind it is an API the program assumed only their own client would ever reach, so that API is often under-tested for IDOR, BOLA, mass assignment, and business logic. Reversing the signer is the cost of admission; the payout comes from what you fuzz once you're inside. Never report "I reversed your sign algorithm" as a finding on its own, that is N/A. Report the IDOR/auth bug you reached through it.
THE CORE PRINCIPLE: PACKET-FIRST
Reverse engineering is a blocker-resolution step, not the default entrypoint. Capture the real request first. Prove whether it already replays. Only reverse the signer if replay actually fails.
Most hunters waste hours decompiling JS for a "signature" that turns out to be replayable as-is, or gated by a timestamp that's valid for 5 minutes. Run this gate before opening DevTools Sources:
1. Capture the real request (Burp/mitmproxy proxy, or DevTools → Network → Copy as cURL)
2. Replay it UNCHANGED (paste cURL into terminal, or Burp Repeater)
→ 200 / works? → IT'S NOT SIGNED. Skip all reversing. Go fuzz it.
3. Replay it again 5 min later → still 200? → no freshness check (replay window is wide/infinite)
4. Mutate ONE non-signed field (e.g. change an `id` in the body, keep sign as-is)
→ 200? → the sign does NOT cover that field → tamper freely, no reversing needed
→ 401? → the sign covers it → NOW you reverse (continue to STAGES below)
