Agent skill

Client Request Signature Reversal

by awarexone in awarexone/Agentic-Bug-Hunter

Recovers a client-side request signature or anti-bot token just far enough to replay blocked requests in bug bounty testing, starting from a captured packet.

MITAuto-check passedSecurity

Install Client Request Signature Reversal

skills CLI
$ npx skills add awarexone/Agentic-Bug-Hunter --skill client-reverse -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install awarexone/Agentic-Bug-Hunter client-reverse --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/awarexone/Agentic-Bug-Hunter.git skills-src && mkdir -p .claude/skills && cp -r skills-src/skills/client-reverse .claude/skills/client-reverse && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
client-reverse
GitHub stars
5.3k
Token cost
~4.7k tokens
SKILL.md length
1,744 words
Files
2 (incl. references)
Skills in repo
10
Repo updated
First seen
Licence
MIT

At a glance

Recovers a client-side request signature or anti-bot token just far enough to replay blocked requests in bug bounty testing, starting from a captured packet.

  • Works in 5 steps: LOCATE: trace backward from the… → RECOVER: de-shell only what blocks you → ISOLATE THE INPUTS (the part that… → …
  • Replaying a request in Burp or mitmproxy that fails with an invalid signature
  • SKILL.md covers THE CORE PRINCIPLE: PACKET-FIRST, STAGE SPINE: locate → recover…, STAGE 1 — LOCATE: trace… and STAGE 2 — RECOVER: de-shell…, plus 7 more sections
  • Calls wget

What it does

The skill applies when a request works in the browser but fails in Burp Repeater with a signature or bot error because the client computes a field such as sign, token, nonce or an X-Sensor header. It insists on a packet-first order: capture the real request through a proxy or DevTools, replay it unchanged, and only reverse the signer if that replay fails, since many such requests turn out to be replayable as they are.

When reversing is needed it follows a staged path from locate through recover, runtime, validation and replay. The agent traces backward from the field that holds the signature to the writer, builder, entry point and source, separates inputs you can change, such as timestamp, nonce, device id and body, from constants like a secret key, and hooks fetch or XHR in DevTools. A reference file covers browser JavaScript signing, and the notes touch on webpack, wasm and JSVMP obfuscation.

The stated goal is access, not the signature itself: reversing the signer is not reported as a finding, and the value comes from testing the protected API behind it for IDOR, broken authorization and business logic flaws.

When your agent uses it

  • Replaying a request in Burp or mitmproxy that fails with an invalid signature
  • Finding where a web client computes a sign, nonce or token field
  • Deciding whether a signed request actually needs reversing at all
  • Reaching an API behind anti-bot checks to test for IDOR

Example prompts

  • “This request returns 401 invalid signature in Repeater. Work out how the browser builds the sign header.”
  • “Hook fetch in DevTools and show me which function writes the X-Signature header.”
  • “Check whether this captured request replays unchanged before we reverse anything.”

Requirements

  • An intercepting proxy such as Burp or mitmproxy
  • Browser DevTools access to the target web client

Workflow steps

5 steps, taken from the step headings in SKILL.md.

  1. LOCATE: trace backward from the signature field
  2. RECOVER: de-shell only what blocks you
  3. ISOLATE THE INPUTS (the part that decides if replay is even possible)
  4. RUNTIME & VALIDATION: prove your sign == the app's sign
  5. REPLAY: build the request you'll actually fuzz

What it can do on your machine

Read from SKILL.md and the folder at commit cd58a40. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • wget

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md. Its commands use wget, which can reach the network depending on how they are called.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Client Request Signature Reversal loads about 4.7k tokens when it runs, and up to ~6.4k if it reads all its reference files. Until then it costs about 225 tokens; SKILL.md has 1,744 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~225
When it runs · the whole SKILL.md, loaded when a task matches
~4.7k
With references · SKILL.md plus every file in references/, read only if the agent opens them
~6.4k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from awarexone/Agentic-Bug-Hunter at commit cd58a40, republished under its MIT licence (© awarexone). 1,744 words, ~4,736 tokens.

Download SKILL.mdSave it as .claude/skills/client-reverse/SKILL.md (or your agent's skills folder). This skill also uses 1 other file; get the full folder from GitHub.
name
client-reverse
description
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)

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

SECRET = b"extracted_from_bundle"          # or call the page's signer via a headless bridge
DEVICE = "pinned-session-device-id"

def signed_request(body):
    ts = str(int(time.time()*1000))
    nonce = uuid.uuid4().hex
    sig = sign(body, ts, nonce, SECRET)    # your validated signer from Stage 4
    return requests.post("https://target.com/api/order",
        json=body,
        headers={"X-Timestamp": ts, "X-Nonce": nonce, "X-Signature": sig,
                 "X-Device-Id": DEVICE})

# NOW the bug hunt begins — mutate the body to reach the protected logic:
for victim_id in range(1000, 1100):        # IDOR sweep behind the signature
    r = signed_request({"orderId": victim_id})
    if r.status_code == 200 and "not authorized" not in r.text:
        print(f"IDOR: read order {victim_id}", r.json())

Bridge option when the secret is server-side: keep a headless browser open, expose the page's own sign() via a tiny local HTTP shim, and have your Python fuzzer call out to it per request. You never reimplement crypto — the app signs for you.


Show full SKILL.md (667 more words)Show less

ANTI-BOT TOKENS (Akamai / DataDome / PerimeterX / hCaptcha-style)

Same spine, harder shell. These ship an SDK that emits an opaque sensor blob (X-Acf-Sensor-Data, _px, datadome cookie). Two realistic paths for a bounty hunter:

  • Reuse, don't reverse. Grab one fresh valid token from a real browser session and replay it within its (short) validity window. Enough to prove an authenticated/protected endpoint is reachable and then demonstrate IDOR/auth there. You usually do not need to generate tokens at scale to prove one bug.
  • Headless bridge. Drive a real browser (Selenium/Playwright) to mint the token, hand it to your Python fuzzer. Standard tooling, no SDK reversing.

Full reversal of Akamai v3 sensor-data (PRNG-shuffled, file-hash + cookie-hash seeded) or PerimeterX's compiled SDK is a week-long research effort — out of scope for a single bounty. If the anti-bot itself is misconfigured (token never expires, token from accountA validates accountB's requests, the protected endpoint is also reachable on a sibling host with no anti-bot), report that — it's a real finding without reversing anything. See the Stack→sibling-host idea in web2-recon.


WHAT'S SUBMITTABLE vs N/A

FindingVerdict
"I reversed your client signing algorithm"N/A — not a vuln by itself
Signed request replays unchanged forever (no timestamp/nonce freshness)Low/Medium — replay-attack window; report it
Sign omits endpoint/payload → forge requests without the secret (CoinMate pattern)Medium/High — request forgery
Secret key hardcoded in JS bundle / APK → forge any requestMedium alone; High/Critical chained to the API you unlock
Reached a protected API via reversed sign → IDOR / BOLA / mass assignment found thereHigh/Critical — the real prize; report the downstream bug
One user's anti-bot token validates another user's requestMedium — broken token binding

The deliverable is almost never the signing weakness. It is the access-control or business-logic bug on the endpoint the signature was guarding. Reach it, then run the IDOR / Broken Auth / Mass Assignment / Business Logic playbooks from web2-vuln-classes.


TOOL MAP (standard tools — no special MCP needed)

NeedTool
capture the real requestBurp Suite proxy, or mitmproxy, or DevTools Network → Copy as cURL
break on the signed requestChrome DevTools → Sources → XHR/fetch Breakpoints
read minified codeDevTools {} pretty-print + Ctrl+Shift+F global search
hook fetch/XHR / log sign()DevTools console snippet (Object.defineProperty / method override)
grep bundle for the secretwget -r -A '*.js' + grep, or /secrets-hunt --js-bundle
find hidden endpoints in JSLinkFinder / jsluice (see web2-recon)
replay + fuzz at scalePython requests (Stage 5 template)
mint anti-bot tokensSelenium / Playwright headless bridge
mobile app variant (signer in APK)apktool + jadx (static), objection / frida CLI (runtime hook) — same locate→recover→runtime→replay spine, packet-first

Mobile note: for an authorized Android app, the packet-first rule still wins — drive the app, watch Burp/mitmproxy, and only jadx/frida the APK when the packet is encrypted or unreplayable. Decompiling first is the rookie move.


REAL PAID EXAMPLES

  • CoinMate API (HackerOne, disclosed) — HMAC signature verification omitted the endpoint and payload, so requests could be forged that appeared legitimate without the correct secret (request forgery via incomplete signature coverage). This is the canonical "the sign doesn't actually cover what you'd mutate" win — find it with Stage 0 step 4.
  • Replay window on HMAC-SHA256 headers (API pentest pattern, disclosed write-ups) — custom auth headers signed with HMAC but lacking timestamp/nonce freshness; captured valid requests replay hours/days later. Prove it with Stage 0 steps 2–3, no reversing required.
  • PerimeterX iOS SDK reversal (public research) — compiled-to-ARM bot SDK reversed to a working token generator in ~1 week, disproving "compiled = unreverseable." Cited here as the realistic effort ceiling: pattern seen across anti-bot bypass research — for a single bounty, prefer token-reuse or a headless bridge over full SDK reversal.
  • Hardcoded HMAC secret in Android APK (mobile API pattern, disclosed write-ups) — secret extracted from the APK lets an attacker sign arbitrary API requests, fully bypassing request validation. Find it with the Stage 3 bundle/APK secret grep.

Cross-reference: once you're through the signature, run IDOR, Broken Auth / Access Control, Mass Assignment, and Business Logic from web2-vuln-classes; use web2-recon for hidden-endpoint and sibling-host discovery; validate with the 7-Question Gate before reporting.

See references/browser-js-signing.md for the full browser-JS staging detail, the boundary model, and handoff-card discipline.

© awarexone, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

SKILL.md and 1 other file (references) in skills/client-reverse of awarexone/Agentic-Bug-Hunter.

  • SKILL.md
  • references/browser-js-signing.md

Open the folder on GitHubat commit cd58a40

Compare with similar skills

Client Request Signature Reversal next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Client Request Signature Reversal compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Client Request Signature Reversal this skillawarexone/Agentic-Bug-Hunter5.3k—~4.7kAutomated safety check: PassMIT
Wooyun Legacytanweai/wooyun-legacy1.8k—~1.9kAutomated safety check: PassCustom licence
Bug Bounty Campaign DriverEncod3d-Sec/TORCH3291 repos~1.8kAutomated safety check: PassMIT
Performing iOS App Security Assessmentmukul975/Anthropic-Cybersecurity-Skills34k—~3kAutomated safety check: PassApache-2.0
Strix Code Vulnerability Scanusestrix/strix67k—~1.1kAutomated safety check: PassApache-2.0
Code Audit3stoneBrother/code-audit8931 repos~2.7kAutomated safety check: PassNone

Similar skills

  • Wooyun Legacy

    tanweai/wooyun-legacy

    WooYun business logic vulnerability methodology — 22,132 real cases across 6 domains (authentication bypass, authorization bypass, payment tampering, information disclosure, logic flaws…

    1.8k GitHub stars~1.9k tokensUpdated 2 mo ago
    SecurityAuto-check passed
  • Runs a bug-bounty engagement through a script that tracks the current pass, builds a board of rows from recon and prints the next required action each turn.

    329 GitHub starsUsed in 1 repo~1.8k tokens
    SecurityAuto-check passed
  • Performing iOS App Security Assessment

    mukul975/Anthropic-Cybersecurity-Skills

    Performs comprehensive iOS application security assessments using Frida for dynamic instrumentation, Objection for runtime exploration, SSL pinning bypass for traffic interception, keychain…

    34k GitHub stars~3k tokensUpdated 1 mo ago
    SecurityAuto-check passed
  • Runs a Strix white-box security review that reads the source, then exploits what it finds in a sandbox so each reported issue has a proof-of-concept.

    67k GitHub stars~1.1k tokensUpdated today
    SecurityAuto-check passed
  • Code Audit

    3stoneBrother/code-audit

    Professional code security audit skill covering 55+ vulnerability types.

    893 GitHub starsUsed in 1 repo~2.7k tokens
    SecurityAuto-check passed
  • Triages findings from a Strix pentest by severity, fixes each root cause with a minimal change, and re-runs Strix to confirm the exploit no longer works.

    67k GitHub stars~1.5k tokensUpdated today
    SecurityAuto-check passed

More from awarexone/Agentic-Bug-Hunter

All 10 skills in this repo
  • Web3 Smart Contract Audit

    awarexone/Agentic-Bug-Hunter

    Guides smart contract audits and bounty target selection with ten DeFi bug classes, kill signals, a Foundry PoC template and grep patterns.

    5.3k GitHub starsUsed in 3 repos~4.5k tokens
    Auto-check passed
  • Bug Bounty Hunting Methodology

    awarexone/Agentic-Bug-Hunter

    Orchestrates a bug bounty session with a 5-phase workflow and a critical-thinking framework covering developer psychology, anomaly detection and What-If experiments.

    5.3k GitHub starsUsed in 2 repos~4.7k tokens
    Auto-check passed
  • Meme Coin Security Audit

    awarexone/Agentic-Bug-Hunter

    Screens EVM and Solana meme coins for rug pull signs such as hidden mint, honeypot logic and fee tricks, starting with fast kill signals before any code review.

    5.3k GitHub starsUsed in 1 repo~2.4k tokens
    Auto-check passed
  • Bug Bounty Triage Validation

    awarexone/Agentic-Bug-Hunter

    Screens a vulnerability finding with a seven-question gate and pre-submission checks before any report is written, so weak or out-of-scope findings are dropped early.

    5.3k GitHub starsUsed in 3 repos~3.4k tokens
    Auto-check passed
  • Bug Bounty Report Writing

    awarexone/Agentic-Bug-Hunter

    Guides writing bug bounty reports for HackerOne, Bugcrowd, Intigriti and Immunefi: impact-first titles, proven claims, CVSS 3.1 scoring and a pre-submit checklist.

    5.3k GitHub starsUsed in 2 repos~3.9k tokens
    Auto-check passed
  • Web2 Recon

    awarexone/Agentic-Bug-Hunter

    Web2 recon pipeline — subdomain enumeration (subfinder, Chaos API, assetfinder), live host discovery (dnsx, httpx), URL crawling (katana, waybackurls, gau), directory fuzzing (ffuf), JS analysis…

    5.3k GitHub starsUsed in 2 repos~6.4k tokens
    Auto-check: warnings

Categories

Questions about Client Request Signature Reversal

What does Client Request Signature Reversal do?

Recovers a client-side request signature or anti-bot token just far enough to replay blocked requests in bug bounty testing, starting from a captured packet. The skill applies when a request works in the browser but fails in Burp Repeater with a signature or bot error because the client computes a field such as sign, token, nonce or an X-Sensor header. It insists on a packet-first order: capture the real request through a proxy or DevTools, replay it unchanged, and only reverse the signer if that replay fails, since many such requests turn out to be replayable as they are.

When should I use Client Request Signature Reversal?

Client Request Signature Reversal fits situations like: replaying a request in Burp or mitmproxy that fails with an invalid signature; finding where a web client computes a sign, nonce or token field; deciding whether a signed request actually needs reversing at all; reaching an API behind anti-bot checks to test for IDOR.

How do I install Client Request Signature Reversal in Claude Code?

Run `npx skills add awarexone/Agentic-Bug-Hunter --skill client-reverse -a claude-code`. Or copy the skill folder (skills/client-reverse in awarexone/Agentic-Bug-Hunter) into .claude/skills/client-reverse in your project. Claude Code loads it when a task matches its description.

How do I install Client Request Signature Reversal in Codex?

Run `npx skills add awarexone/Agentic-Bug-Hunter --skill client-reverse -a codex`. Or copy the skill folder (skills/client-reverse in awarexone/Agentic-Bug-Hunter) into .agents/skills/client-reverse in your project. Codex loads it when a task matches its description.

Can I use Client Request Signature Reversal in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add awarexone/Agentic-Bug-Hunter --skill client-reverse -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/client-reverse, .gemini/skills/client-reverse, .github/skills/client-reverse and .opencode/skills/client-reverse in your project.

What does Client Request Signature Reversal need to run?

Going by SKILL.md and its folder, Client Request Signature Reversal needs the command-line tools its instructions call (wget). Our summary lists: An intercepting proxy such as Burp or mitmproxy; Browser DevTools access to the target web client.

Does Client Request Signature Reversal access the network?

SKILL.md contains no URLs. Its commands use wget, which can reach the network depending on how they are called. This is read from the text; nothing was executed.

Is Client Request Signature Reversal safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Client Request Signature Reversal use?

Client Request Signature Reversal is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Client Request Signature Reversal use?

About 4.7k tokens (SKILL.md is roughly 19k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full. Its references folder adds about 1.7k tokens, read only when the agent opens those files.

What are the alternatives to Client Request Signature Reversal?

Skills that share tags, products or a category with Client Request Signature Reversal: Wooyun Legacy (tanweai/wooyun-legacy, 1.8k stars), Bug Bounty Campaign Driver (Encod3d-Sec/TORCH, 329 stars), Performing iOS App Security Assessment (mukul975/Anthropic-Cybersecurity-Skills, 34k stars) and Strix Code Vulnerability Scan (usestrix/strix, 67k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Client Request Signature Reversal?

awarexone (a GitHub organization) maintains it in awarexone/Agentic-Bug-Hunter, which has 5,282 GitHub stars. The repository holds 10 skills in this directory. The repository was last updated on October 5, 2026.

Source: awarexone/Agentic-Bug-Hunter on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.