Signature Analysis

Many APIs stamp each request with a derived token — a hash or HMAC over the method, URL, body, cookies, and a shared secret. Signature analysis works out that derivation offline from captures you have already imported, so the token can be recomputed during replay instead of copied stale. Everything runs locally in the workspace; nothing is sent anywhere. Only use this on systems you are authorized to test.

Open the Signature tab

The feature lives in the API workspace: open a capture, switch to the Signature tab (the 8th tab). It scans every visible session and lists candidate fields — per-request tokens worth investigating. Each card shows the field name, endpoint, location badge (Header / Cookie / Query parameter), encoding, request count, and the percentage of distinct values.

Type in the search box to filter by field name or endpoint. Expand a card to reveal flip analysis, observed values, the scheme tester, and a Frida hook template. Activating a card twice jumps to its first sample request.

How candidates are detected

Every request header (except Cookie), query parameter, and cookie is inspected per endpoint. A value becomes a candidate when:

• its name matches a signature hint (sign, signature, sig, hash, digest, hmac, mac, checksum), or it looks like high-entropy hex / base64 / base64url;
• it is long enough — at least 12 characters for headers and query params, 8 for cookies (truncated tokens get short), and at most 512;
• it varies on at least 70% of requests to that endpoint (a field needs at least 2 requests).

Correlation and trace IDs (x-request-id, x-correlation-id, traceparent, x-csrf-token, and friends) are denylisted — they change every request but are not signatures. Candidates are scored 0–1 from the name hint, encoding, digest length (32/40/64 hex nibbles = MD5/SHA-1/SHA-256), and variability, then sorted by score.

[!NOTE] Cookie-location tokens are first-class. A derived value living inside the Cookie header is detected just like a header or query field, and the surrounding cookies are kept as sample context so cross-field constructions can be tested.

Correlate inputs with flip analysis

Expanding a card runs flip analysis over up to 12 samples. It compares every pair of captured requests and classifies each request component:

Components tracked are method, path, body, plus each query:<name>, header:<name>, and cookie:<name>. Volatile headers (date, user-agent, authorization, content-length, host, and similar) are excluded from header correlation. Correlated components appear as badges; contradicted ones are listed under “Ruled out”. This tells you which fields the canonicalization actually reads before you spend time brute-forcing.

Brute-force classic canonicalizations

The Offline canonicalization brute-force box replays a library of common constructions against the candidate’s samples (up to 8) and reports every scheme that reproduces the observed tokens. Enter candidate secrets one per line in the wordlist, then click Test schemes.

The classic schemes cover MD5, SHA-1, SHA-256, HMAC-MD5, HMAC-SHA-1, and HMAC-SHA-256 over canonicalizations such as:

• sorted query params (a=1&b=2), raw or URL-decoded;
• secret appended, prepended, or wrapped (secret + params + secret);
• sorted params + "&key=" + secret;
• path + timestamp + MD5(body) and method + path + timestamp + body;
• HMAC(secret, method\npath\ntimestamp\nSHA-256(body)).

Digests are compared in lowercase hex, uppercase hex, base64, and base64url (trailing = padding ignored). Each match shows matched/total requests, the secret used, and the exact canonical string that reproduced the first sample. A scheme matching all samples triggers a “Signature scheme recovered” toast.

Recover prefixed and truncated constructions

Some tokens are not hashes of request components at all but of another captured field. The prefixed-hash search targets constructions of the form:

prefix + HASH(secret + <another field> + prefix)[dropN:]

It is bounded by a length equation. For hex digests, observedLength = prefixLength + (digestHexLength - dropN), which pins the viable (hash, prefix-length, drop) shapes to a handful per candidate. The search tries MD5/SHA-1/SHA-256 across the most common captured fields (up to 16, excluding correlation IDs and the signature field itself), several orderings of secret/field/prefix, prefix lengths 0–8 in steps of 2, and drops up to 16. A non-empty prefix must vary across samples, which separates a genuine random prefix from a merely truncated hash.

The canonical example is the fgssca-goldapple cookie: a 4-hex random prefix followed by sha1(appSecret + gsscCookie + prefix) with the first 4 hex characters dropped. A successful match reports its algorithm, secret, and derived from: cookie:<name>, which flip analysis surfaces as the correlated input.

Build the secret wordlist

The wordlist is pre-filled by mining the captures: values of fields whose names look like secrets (secret, appkey, api_key, client_secret, salt, and similar) are collected, then a small built-in dictionary (secret, password, changeme, key, API_SECRET, …) is appended. Edit the list freely — add anything you have recovered from the app bundle or JS. The prefixed search also tries an empty secret and caps the list at 32 entries.

[!TIP] If no scheme matches, the card’s Copy Frida hook template button gives you a ready script that hooks javax.crypto.Mac, java.security.MessageDigest, and SecretKeySpec, logs their inputs and outputs, and flags any digest whose length matches the observed token. Attach it to the app, watch for [sig-trace] lines, and feed the logged canonical string back into the wordlist.

Feed results into replay

Once a scheme is recovered, turn it into a computed field so replay recomputes the token per send. The scheme’s exampleInput and derived from map directly onto the computed-field DSL — field refs like cookie:name, header:name, query:name, and body, plus sha1 / sha256 / md5 / HMAC functions and a skip:N truncation pipe. The fgssca-goldapple construction above becomes:

{{ p = randomHex:4; p + sha1(fgsscSecret + cookie:gssca-goldapple + p) | skip:4 }}

See /docs/en/replay/variables/ for the full DSL and /docs/en/replay/workbench/ for attaching computed fields to a replay request.