shuvonsec/claude-bug-bounty/client-reverse

Claude Code and agent skill by shuvonsec/claude-bug-bounty

Trust tier 2
  • community
LLM review pending
Source check pending

Checking that the SKILL.md file is still in the repository.

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.

Install

npx vskill@latest install shuvonsec/claude-bug-bounty/client-reverse

SKILL.md

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)

Steps 2–4 alone kill ~half of "I need to reverse this" assumptions. A signature that omits the payload or endpoint, or never expires, is itself the bug — see the CoinMate pattern in Real Paid Examples.


STAGE SPINE: locate → recover → runtime → validation → replay

Pick the stage from engineering state, not from clue words. "I see the word sign" does not mean you're in recover. You are in locate until you can point at the exact line that writes the signature.

intake → evidence → locate → recover → runtime → validation → replay
StageEnter when...GoalExit when...
locatethe signing function / write boundary is unprovenfind where the sign field is written and what feeds ityou can point at writer ← builder ← entry ← source
recoverboundary is real but the code is obfuscated/opaquede-shell only the layer blocking you (webpack/wasm/JSVMP)you have a readable or callable signer contract
runtimecode is clear but browser-exec ≠ your-exec divergefind the first divergence (missing object/state/anti-debug)local run reproduces browser sign output
validationremaining work is equivalence proofmatch checkpoints, not just final outputsign(input) == observed for fresh inputs
replaysign reproduces outside the clientBurp/Python baseline request you can fuzza stable request you can mutate for IDOR/auth

Carry a one-line handoff between stages. Do not promote a guess to a fact:

text
--- Stage Handoff ---
From: locate To: recover
Proven: sign written at app.min.js:1, line ~4021; inputs = ts, nonce, JSON body, deviceId
Open: builder is inside webpack module 5f3 behind a string-table — need to de-shell that one module
Invalid: assumption that deviceId was constant (it rotates per session)

STAGE 1 — LOCATE: trace backward from the signature field

You know the output (the sign value on the wire). Walk backward to the source. Keep each layer distinct:

text
writer <- builder <- entry <- source
  • writer — the line that finally puts sign into the body/header/query/cookie/WS frame
  • builder — the transform: HMAC, MD5, AES, sort-then-concat, JSON.stringify ordering
  • entry — the UI action / callback / response that kicks off the chain
  • source — what feeds the inputs: upstream response, localStorage, cookie, Date.now(), crypto.getRandomValues, user input
Browser: find the writer in Chrome DevTools
text
# 1. XHR/fetch breakpoint — break the moment the signed request fires
DevTools → Sources → XHR/fetch Breakpoints → + → paste the endpoint path (e.g. /api/order)
trigger the action → execution pauses inside the request stack
→ walk UP the Call Stack panel: the frame that mutates headers/body is your writer
# 2. Search the bundle for the field name (catches the writer fast)
DevTools → Sources → Ctrl+Shift+F (search all loaded scripts)
search: "sign" "X-Signature" ".sign =" "headers[" "signature"
click {} (pretty-print) on the minified file so line numbers are stable
# 3. DOM/event breakpoint when a click triggers it
DevTools → Elements → right-click the button → Break on → subtree/attribute modifications
Strong first observation points (where to put the breakpoint)
Sink (where sign lands)First place to prove
request body fieldfinal JSON.stringify / submit / fetch(body=...)
request headerthe headers[...] = or setRequestHeader call
JS-set cookiethe document.cookie = setter
WebSocket framethe final envelope object right before ws.send(...)
anti-bot blob (X-Sensor-Data, _px)the SDK init() and the getter that returns the blob

Do NOT broad-deobfuscate before the boundary is real. Keyword hits are not proof — many bundles ship sign strings that never run.


STAGE 2 — RECOVER: de-shell only what blocks you

Enter only after the boundary is proven and the only remaining blocker is that the code is unreadable. Reduce the single layer in your way — never the whole bundle.

Shell you hitWhat it meansMinimal move
webpack bootstrapmodules wrapped in __webpack_require__break inside the target module, read the local closure — don't unpack the whole bundle
string-array obfuscation_0x4a2b[12] lookupsin console, print the decoder array; or set a breakpoint and read decoded values live
worker / postMessage bridgesign runs in a Web Workerbreakpoint the worker script; treat postMessage payload as the contract
wasm loadersign math compiled to wasmhook the JS↔wasm boundary; capture inputs/outputs rather than decompiling wasm
JSVMP (custom bytecode VM)a dispatcher loop interpreting bytesdo not reverse the VM — go runtime: hook inputs+output and treat sign as a black box
The black-box shortcut beats decompilation 90% of the time. You almost never need to understand the HMAC math. You need the input tuple and a way to call the function. Capture sign(input) → output pairs at runtime; if you can call the page's own signer, you never have to reimplement it.
Reimplement vs reuse the page's signer
javascript
// REUSE — if the signer is a reachable function, just call it from the console.
// Works when the page exposes it or you grab a reference at a breakpoint.
window.__sign = signFn; // assign at a breakpoint inside the builder
window.__sign({id: 999, ts: Date.now()})// → get a valid sig for ANY payload you want
// HOOK to log every real sign(input)->output the app produces (no reimplementation):
(function(){
const orig = CryptoSigner.prototype.sign; // adapt to the real object/method
CryptoSigner.prototype.sign = function(...a){
const out = orig.apply(this, a);
console.log('SIGN', JSON.stringify(a), '=>', out); // copy pairs for offline replay
return out;
};
})();

STAGE 3 — ISOLATE THE INPUTS (the part that decides if replay is even possible)

For every input to the signer, classify it. This is the whole game — it tells you what you can mutate and whether you even need the secret.

InputTypeAttacker-mutable?Implication
timestamp / tsper-requestyes (you set it)fine — regenerate per replay; check the validity window
nonce / requestIdper-request randomyesfine — generate fresh; check if server enforces uniqueness (replay protection)
deviceId / uuidper-sessionyes (one value, reusable)grab once, pin it — usually constant for your session
request body / pathper-requestyesthe prize — if sign covers it, you mutate body + re-sign to fuzz IDOR/mass-assignment
secret key / appSecretconstant, baked inno (you extract it)if it's in the JS bundle / APK, extraction = full forge ability for any request
text
DECISION:
secret is in the client (hardcoded in JS or APK strings)
→ you can re-sign ANY request offline → full replay, fuzz everything
secret is server-side only, but you can call the page's signer function
→ you can sign any payload while the page is open → replay via headless browser bridge
secret is server-side AND signer is uncallable (heavy anti-debug)
→ you may only replay UNCHANGED requests
→ then test: does the sign omit the path/body? (CoinMate pattern) → forge anyway
→ does it never expire? → replay-window bug, report that

Hunt the bundle for a baked secret before doing anything clever:

bash
# Pull the JS and grep for the secret feeding the signer
wget -q -r -l1 -A '*.js' -P /tmp/js/ "https://target.com" 2>/dev/null
grep -rnoE "appSecret|secretKey|signKey|HMAC|hmac|['\"][A-Za-z0-9+/]{24,}={0,2}['\"]" /tmp/js/ | head
# Cross-reference with /secrets-hunt --js-bundle for entropy-scored hits

STAGE 4 — RUNTIME & VALIDATION: prove your sign == the app's sign

If you reimplemented the signer in Python, prove equivalence on a fresh input before trusting it. Compare checkpoints, not just the final byte:

python
import hmac, hashlib, json, time
def sign(body: dict, ts: str, nonce: str, secret: bytes) -> str:
# Reproduce the EXACT canonicalization the JS does — order, separators, encoding.
# Get these by reading the builder, NOT by guessing.
payload = json.dumps(body, separators=(',', ':'), sort_keys=False) # JS JSON.stringify keeps INSERTION order, not sorted — set sort_keys=True ONLY if the builder explicitly sorts keys
msg = f"{ts}{nonce}{payload}".encode() # match JS concat order!
return hmac.new(secret, msg, hashlib.sha256).hexdigest()
# VALIDATE: feed an input you captured from the browser, compare to the observed sig.
# checkpoints that must each match: canonical body string → message tuple → final digest
assert sign(captured_body, captured_ts, captured_nonce, SECRET) == observed_sig

The two killers are almost always (a) JSON key ordering / separator whitespace, and (b) concatenation order of the input fields. If your digest is wrong, diff the pre-hash message string against the one the app builds (log it at a breakpoint), not the output hash.


STAGE 5 — REPLAY: build the request you'll actually fuzz

You are ready only when you can answer all five:

[ ] where is the signed field written?
[ ] which inputs are constants (secret, deviceId) vs per-request (ts, nonce, body)?
[ ] which inputs come from upstream responses / cookies / storage / page lifecycle?
[ ] does request ORDER or session STATE matter (does a prior call seed the nonce)?
[ ] which fields can I mutate and still produce a valid sign?

Then drive it from Python so you can fuzz at scale:

python
import requests, time, uuid

This is the start of the file. Read the full SKILL.md on GitHub.

Security

  • Security scanPassed, 100 of 100Pattern checks on the skill's files.
  • Model reviewNot runA model review is scheduled for the next rescan.

Quality evaluation

  • Task evaluationNot runNo evaluation yet. Run one in Skill Studio.

Source

Popularity

Repository stars
4,237
Repository forks
768
7-day trend score
42

Stars and forks are for the whole GitHub repository, not this skill alone. Not refreshed yet.

Works with

Any agent vskill installs to: 56 targets in all. These 39 have a page on this site.

  • Claude Code
  • Cursor
  • GitHub Copilot
  • Windsurf
  • Codex
  • Gemini CLI
  • Cline
  • Amp
  • Roo Code
  • Goose
  • Continue
  • Kilo Code
  • Junie
  • Trae
  • OpenHands
  • Qwen Code
  • AI Agent
  • Tabnine Chat
  • Sourcegraph Cody
  • Amazon Q
  • Firebase Genkit
  • Sweep
  • Devin
  • Phind
  • Mentat
  • Claude Desktop
  • Aider
  • GPT Pilot
  • Plandex
  • bolt.new
  • v0
  • Replit Agent
  • Anse
  • TypingMind
  • BetterChatGPT
  • LibreChat
  • Warp AI
  • Pieces
  • Fig AI
Embed badge
vskill VERIFIED badge
[![vskill VERIFIED](https://verified-skill.com/api/v1/skills/shuvonsec/claude-bug-bounty/client-reverse/badge)](https://verified-skill.com/skills/shuvonsec/claude-bug-bounty/client-reverse)

Something wrong with this skill or its page? Tell us.