DEV Community: FeiHua

JS Reverse Engineering Case Study #3 — Reconstructing Request-Header Signatures

FeiHua — Sat, 17 Oct 2026 01:08:06 +0000

JS Reverse Engineering Case Study #3 — Reconstructing Request-Header Signatures (`Content-Md5` + HMAC-SHA1) with Carved-Out Crypto Modules and `execjs`

Part 3 of the "JS Reverse Engineering in Practice — 30 Case Studies" series.
Source code (this case): https://github.com/scool112/openJSreverse (Project3)

Note on sanitization: This is a sanitized, educational write-up. Every real domain, endpoint, site-specific constant and identifier has been replaced with a generic placeholder (example.com, <FIXED_...>). No production endpoint or secret is disclosed. The purpose is to explain the technique, not to enable abuse of any specific service.

1. Goal & Background

The target this time is the news list of an industrial steel company's public web portal (referred to as "Site C"). The list API actually lives on a separate signing host, and the request carries an entire set of signature headers:

Target site: https://www.example.com/media/news
Target endpoint: https://api.example.com/<content-list-endpoint>?domainId=<DOMAIN_ID>
Parameters to reconstruct (request headers): Content-Md5, x-date, x-nonce, x-signature, x-user
Difficulty: ⭐⭐⭐ — the algorithm is a standard MD5 + HMAC-SHA1, but the signing-string layout, the HMAC key, and a "relative require" gotcha are three real traps.

This project is a textbook case of request-header signing: the endpoint uses Content-Md5 to validate body integrity, x-nonce / x-date to defeat replay, x-signature (HMAC-SHA1) as the overall signature, and a fixed x-user application identifier. My approach was to split the signing logic into three reusable modules: MD5, HMAC-SHA1, and the assembly entry point.

2. Traffic Analysis

Open https://www.example.com/media/news, press F12 → Network → Fetch/XHR, and page through the news list. You will see a request to the content-list endpoint.

It is a POST with Content-Type: application/json;charset=UTF-8, and the body is:

{"pageNo":2,"pageSize":12,"condition":{"nodeId":<NODE_ID>}}

pageNo is the page number (note that it is zero-based here — pageNo:2 is actually page 3). The eye-catching request headers are these:

Content-Md5: <32-char lowercase hex md5 of the body>
x-date: <unix-seconds timestamp>
x-nonce: <10-digit random number>
x-signature: <40-char uppercase hex>
x-user: 0/<fixed-app-uuid>

A few observations:

x-user has a fixed shape (0/ plus a UUID) — it looks like a fixed application/tenant identifier whose value never changes between requests;
x-date is a seconds-level timestamp (10 digits), and x-nonce is a 10-digit random number; together they defeat replay;
x-signature is 40 characters of uppercase hex → the typical SHA1 length, which tells us it is HMAC-SHA1;
Content-Md5 is 32 characters of lowercase hex → MD5, used to validate the body.

📷 [Figure 1 — screenshot suggestion] The Network panel: the Request Headers of the content-list request.

Conclusion: what must be reconstructed is "how method / url / body / nonce / date are combined into x-signature", plus the Content-Md5 algorithm.

3. Locating the Signature Entry Point

In the Sources panel, do a global search for x-signature or x-nonce; it quickly lands on an axios request interceptor (interceptors.request.use). Because this is an axios wrapper, the interceptor is usually the block that assigns values to config.headers one by one.

I carved that interceptor out and kept the irrelevant axios fields as a config object, producing the entry point js/arg_sum.js in the repo. Here is the full logic:

// From the real repo JS: Project3/<site>/js/arg_sum.js
var Md5 = require("./arg_md5");
var Hmac = require("./arg_HmacSHA1")

function arg_sum(page){
    var page_tru = page - 1;
    function l(e) {
        for (var n = [], t = Array.of("0", "1", "2", "3", "4", "5", "6", "7", "8", "9"), a = 0; a < e; a++) {
            var c = Math.floor(10 * Math.random());
            n[a] = t[c]
        }
        return n.join("")
    }
    function s() {
        return parseInt((new Date).getTime() / 1e3)
    }
    var e = {
        "transformRequest": {},
        "transformResponse": {},
        "timeout": 20000,
        "xsrfCookieName": "XSRF-TOKEN",
        "xsrfHeaderName": "X-XSRF-TOKEN",
        "maxContentLength": -1,
        "headers": {
            "common": {
                "Accept": "application/json, text/plain, */*"
            },
            "delete": {},
            "get": {},
            "head": {},
            "post": {
                "Content-Type": "application/x-www-form-urlencoded"
            },
            "put": {
                "Content-Type": "application/x-www-form-urlencoded"
            },
            "patch": {
                "Content-Type": "application/x-www-form-urlencoded"
            },
        },
        "method": "post",
        "baseURL": "https://api.example.com",
        "url": "/<content-list-endpoint>?domainId=<DOMAIN_ID>",
        "data": {
            "pageNo": page_tru,
            "pageSize": 12,
            "condition": {
                "nodeId": <NODE_ID>
            }
        }
    }
    var n = l(10)
        , t = s()
        , a = Md5.Md5(e.data)
        , c = ""
        , o = "0/<fixed-app-uuid>"
        , i = "<HMAC_KEY>";
    e.headers["x-user"] = o,
        e.headers["x-nonce"] = n,
        e.headers["x-date"] = t,
        e.headers["Content-Md5"] = a,
        c = "".concat(e.method.toUpperCase(), "\n").concat(e.url.replace(e.baseURL, ""), "\nx-user:").concat(o, "\nx-nonce:").concat(n, "\nx-date:").concat(t, "\nContent-Md5:").concat(a, "\n");
    var u = Hmac.hmac(c,i)
    e.headers["x-signature"] = u
    e.headers["x-date"] = e.headers["x-date"].toString();
    // console.log(e.headers)
    return e.headers
}

 // console.log(arg_sum(2))

From this block you can read the entire signing protocol:

n = l(10) generates a 10-digit random number → x-nonce;
t = s() → parseInt(Date.now()/1000) → a seconds-level timestamp → x-date;
a = Md5.Md5(e.data) → MD5 over the request body → Content-Md5 (note that Md5.Md5 internally JSON.stringifys the object before hashing);
o = "0/<fixed-app-uuid>" is the fixed x-user; i = "<HMAC_KEY>" is the HMAC key;
Build the "to-be-signed string" c; its format is crucial:

POST
/<content-list-endpoint>?domainId=<DOMAIN_ID>
x-user:0/<fixed-app-uuid>
x-nonce:<10-digit-nonce>
x-date:<unix-seconds>
Content-Md5:<body-md5>
(with a trailing \n as well)

u = Hmac.hmac(c, i) runs HMAC-SHA1 over c with key i, and the result is x-signature.

The field order, field names, letter case, and the trailing \n on every line must match exactly — one character off and the signature is dead.

📷 [Figure 2 — screenshot suggestion] In the Sources panel: the axios request interceptor, or the HMAC breakpoint call stack.

4. Restoring the JS & Emulating the Environment

This site's JS does not depend on window / document, but the crypto library it uses was "shortcut" a bit (the MD5 / HMAC pieces of crypto-js were carved out into separate files). So I split the algorithm into three files:

// From the real repo JS: Project3/<site>/js/arg_md5.js (tail)
function MD5_my(Data){
    var md5 = r.MD5(JSON.stringify(Data ? Data : "")).toString(r.enc.Hex)
    return md5
}

module.exports = {
    Md5:MD5_my
}

// From the real repo JS: Project3/<site>/js/arg_HmacSHA1.js (tail)
RR = {
    HmacSHA1:function(e, r) {
        return new LL.HMAC.init(TT,r).finalize(e)
    }
}

function Hmac_my(c,i){
    var u = RR.HmacSHA1(c, i).toString().toUpperCase();
    return u
}

module.exports = {
    hmac:Hmac_my
}

Two things to note:

In arg_md5.js, MD5_my does JSON.stringify on Data, so the Python side can safely pass the request-body object straight in; passing "" / nothing hashes an empty string;
Hmac_my in arg_HmacSHA1.js calls .toUpperCase() at the end, which is why x-signature is uppercase — this must be copied exactly.

The top of both files is a hand-"reshaped" crypto-js internal structure (the proto3 / proto2 / Object.create prototype-chain boilerplate). The comment at the top of arg_HmacSHA1.js records the pitfall that was hit at the time:

// From the real repo JS: Project3/<site>/js/arg_HmacSHA1.js (file-header comment)
/*
 proto1_TT.cfg.__proto__.extend = function(t) { ... }

 proto1_TT.cfg.__proto__ points at Object.prototype, which is equivalent to adding an
 enumerable extend method to every object. When the mixIn loop `for (var e in t)` walks
 the argument t, it climbs the prototype chain up to Object.prototype, enumerates
 "extend", and so your breakpoint sees e = "extend".
 In the browser, extend and mixIn are defined on the same Base prototype object;
 Object.prototype has no extend, so e is correct there.
 */

In other words: in the browser crypto-js hangs extend on the Base prototype, not on the top-level Object; if you accidentally attach extend to Object.prototype while carving the code out, for...in will enumerate an extra extend, and the HMAC result will be wrong. This is one of the core pitfalls of this project.

5. Python Implementation

One crucial detail in py/<site>.py — os.chdir into the js directory first — because arg_sum.js uses require("./arg_md5"):

# From the real repo py: Project3/<site>/py/<site>.py
import requests
import json
import os
import execjs

def Spider(page:int):
    base_path  =  os.path.dirname(os.path.abspath(__file__))
    js_path = os.path.join(base_path,"..","js","arg_sum.js")
    js_dir = os.path.dirname(js_path)
    os.chdir(js_dir)
    with open(js_path,encoding="utf-8") as f:
        js_code = f.read()
    js = execjs.compile(js_code)
    headrs_arg = js.call("arg_sum",page)
    headers = {
        "Accept": "application/json, text/plain, */*",
        "Content-Md5": headrs_arg['Content-Md5'],
        "Content-Type": "application/json;charset=UTF-8",
        "Origin": "https://www.example.com",
        "Referer": "https://www.example.com/",
        # ... the rest are ordinary browser headers (Accept-Language / Cache-Control /
        # Connection / Pragma / Sec-Fetch-* / User-Agent / dnt / sec-ch-ua* etc.), trimmed here
        "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/138.0.0.0 Safari/537.36",
        "x-date": headrs_arg['x-date'],
        "x-nonce": headrs_arg['x-nonce'],
        "x-signature": headrs_arg['x-signature'],
        "x-user": headrs_arg['x-user']
    }
    url = "https://api.example.com/<content-list-endpoint>"
    params = {
        "domainId": "<DOMAIN_ID>"
    }
    data = {
        "pageNo": page - 1,
        "pageSize": 12,
        "condition": {
            "nodeId": <NODE_ID>
        }
    }
    data = json.dumps(data, separators=(',', ':'))
    print(headers)
    response = requests.post(url, headers=headers, params=params, data=data)

    print(response.text)
    print(response)


Spider(3)

Key points:

os.chdir(js_dir): this is the step most easily overlooked. execjs uses Node by default, and a relative path like require("./arg_md5") resolves relative to the current working directory (cwd), not relative to the JS file. So first switch the cwd to js/; only then will require find arg_md5.js / arg_HmacSHA1.js in the same directory.
The body must be byte-for-byte identical to what was signed. Inside arg_sum, the signed e.data is {"pageNo": page-1, "pageSize": 12, "condition": {"nodeId":<NODE_ID>}}; the body Python sends to the server must use the same object, the same key order, and the same compactness (separators=(',', ':')), or Content-Md5 will not match.
page and pageNo differ by 1. Pass page=3, and the actual pageNo is 2.

6. Result

Running python <site>.py first prints the whole set of JS-generated signature headers, then the news list returned by the API:

{'Content-Md5': '<body-md5>', 'x-user': '0/<fixed-app-uuid>', 'x-nonce': '<10-digit-nonce>', 'x-date': '<unix-seconds>', 'x-signature': '<40-char uppercase hex>'}
{"code":200,"data":{"records":[{"title":"...","publishDate":"...","contentId":...}, ...],"total":...},"message":"success"}
<Response [200]>

As long as the server returns code:200 with a populated records, both the MD5 and the HMAC-SHA1 chains are correct. If you instead get a signature error (401/403), first re-check the signing-string format and whether x-date / x-nonce are the same values used at signing time.

📷 [Figure 3 — screenshot suggestion] The terminal output: the signature headers and the news list data.

7. Pitfalls & Notes

The relative require is the biggest trap. require("./arg_md5") inside arg_sum.js depends on the cwd, so the Python side must os.chdir(js_dir), otherwise execjs raises Cannot find module './arg_md5'. This is also called out specifically in the README.
Attaching extend to the wrong prototype breaks HMAC. When carving crypto-js out, extend must be attached to its own Base prototype, not to Object.prototype, otherwise for...in enumerates an extra extend (the file-header comment records this pitfall).
x-signature must be uppercase. Hmac_my applies .toUpperCase(), so on the Python side do not "helpfully" call .lower().
The signing string is fragile. Method uppercased, url with the baseURL stripped, field names untouched, a \n at the end of every line (including the last one) — any single mismatch fails. Compare it character by character against the c captured at a breakpoint in the browser.
Body consistency. Content-Md5 is computed over the body, so the body's key order / compactness must match the signing step; the page argument and pageNo differ by 1.
Keep the request rate low and respect the terms of service.

8. Takeaways

Content-Md5 + x-nonce + x-date + HMAC-SHA1 is a common combination for CMS-style endpoints: MD5 protects the body, nonce/date defeat replay, and HMAC does the overall signing.
When carving crypto-js out, the thing to fear most is prototype-chain pollution (extend on Object.prototype): it silently changes the hash result, so always mount it the way the original library does.
Calling JS that uses a relative require from execjs requires os.chdir into the JS directory first — this is the key step that makes it work.

Disclaimer: This article is for educational and security-research purposes only. Do not use it for any commercial or illegal activity. All endpoints/sites have been anonymized; always respect the target's terms of service and applicable laws.

JS Reverse Engineering Case Study #2 — Reconstructing code / timestamp (a Fixed-Salt MD5 Signature)

FeiHua — Sat, 17 Oct 2026 01:04:12 +0000

JS Reverse Engineering Case Study #2 — Reconstructing `code` / `timestamp` (a Fixed-Salt MD5 Signature)

Part 2 of the "JS Reverse Engineering in Practice — 30 Case Studies" series.
Source code (this case): https://github.com/scool112/openJSreverse (Project2)

Note on sanitization: This is a sanitized, educational write-up. All real domains, endpoints and site-specific constants (including the salt) have been replaced with generic placeholders (example.com, <FIXED_SALT>). No production endpoint is disclosed. The purpose is to explain the technique, not to enable abuse of any specific service.

1. Goal & Background

The target this time is a public crypto market-cap ranking site (referred to as "Site B"). I wanted its coin ranking list.

Target site: https://www.example.com (a crypto ranking site)
Target endpoint: https://api.example.com/<ranking-endpoint>
Parameters to reconstruct: code and timestamp (two query parameters)
Difficulty: ⭐⭐⭐ — the signature itself is a clear MD5; the work is getting the webpack-bundled, obfuscated export to run.

The reverse-engineering target is again a request signature, but much milder than the previous case. The JS is a webpack build with two-letter function names (Fk, xZ, ...), but once you untangle the logic it is a single MD5. My method is the same — emulate the environment and call the exported function — but this time I also read the formula out and verified it.

2. Traffic Analysis

Open https://www.example.com, press F12 → Network → Fetch/XHR, and browse the ranking list. You will see a request to the ranking endpoint.

Look at the Payload (query string):

pages=2,1
sizes=100,100
subject=market_cap
language=en_US
legal_currency=USD
code=<hex string>
timestamp=<ms timestamp>
platform=web_pc
v=0.1.0
extra_param=

Apart from code and timestamp, the other parameters are plain business values. timestamp is clearly a millisecond timestamp (it changes over time), and code is a hex string that changes together with timestamp — obviously a signature derived from it.

📷 [Figure 1 — screenshot suggestion] The Network panel: the ranking request's query string.

Conclusion: the thing to reconstruct is the relationship code = f(timestamp). Everything else can be copied verbatim.

3. Locating the Signature Entry Point

In the Sources panel, globally search for the parameter names code / timestamp, or for the endpoint path. The hit lands in the site's main JS (webpack build). Since it is split into modules, my trick was to search for the object-literal timestamp:, which jumps straight to where the signature object is built.

In the bundle I found the key lines:

// Anonymized excerpt from the reconstructed JS
r.d(t, { rQ: function () { return b }, /* ... */ xZ: function () { return k }, Fk: function () { return w } });
var /* ... deps ... */ v = r(<HASH_MODULE>),
    p = Date.now().toString(),
    d = {
        timestamp: p,
        code: v.V8.hashStr(p + "<FIXED_SALT>" + p.substring(0, 6)),
        platform: "web_pc",
        v: "0.1.0"
    };

This single block is very informative:

p = Date.now().toString() — the current millisecond timestamp (the timestamp in the query);
code = v.V8.hashStr(p + "<FIXED_SALT>" + p.substring(0, 6)) — the signature: join (timestamp + fixed salt + first 6 chars of timestamp) and run it through hashStr;
platform: "web_pc", v: "0.1.0" — hard-coded constants.

v is a webpack module id whose default export is a V8 class. Fk (aliased to w) is the function that serializes the parameter object into a query string.

📷 [Figure 2 — screenshot suggestion] In the Sources panel: where code / timestamp are built, and the hashStr call stack.

4. Restoring the JS & Emulating the Environment

First, confirm what V8.hashStr actually is. Digging into that module:

// Anonymized excerpt — the hash module
<HASH_MODULE>: function (t, e, r) {
    "use strict";
    r.d(e, { V8: function () { return s } });
    class s {
        constructor() {
            this._dataLength = 0;
            this._bufferLength = 0;
            this._state = new Int32Array(4);
            this._buffer = new ArrayBuffer(68);
            this._buffer8 = new Uint8Array(this._buffer, 0, 68);
            this._buffer32 = new Uint32Array(this._buffer, 0, 17);
            this.start();
        }
        static hashStr(t, e = false) {
            return this.onePassHasher.start().appendStr(t).end(e);
        }
        // ...
        static _md5cycle(t, e) {
            let r = t[0], s = t[1], n = t[2], i = t[3];
            r += (s & n | ~s & i) + e[0] - 680876936 | 0;
            r = (r << 7 | r >>> 25) + s | 0;
            // ...
        }
    }
}

Seeing _md5cycle and the classic MD5 constants (-680876936, -389564586, 606105819, ...) confirms that V8 is an incremental MD5 implementation (128-bit output = 4×32-bit state words; a 68-byte buffer = one 64-byte block + 4-byte length). Therefore:

code = MD5(timestamp + "<FIXED_SALT>" + timestamp.substring(0, 6))

The algorithm is clear. To turn it into a query, we still need to see how Fk joins the object into a string:

// Anonymized excerpt — the serializer (Fk, aka w)
w = function (n) {
    var t = new URLSearchParams, /* ... */
        e = true, i = void 0;
    try {
        for (var u, a = Object.entries(n)[Symbol.iterator](); !( /* ... */ ); ) {
            // append key=value into URLSearchParams
        }
    }
    // ...
};

It simply uses URLSearchParams to join the object into key=value&.... Finally, the external entry point is get_code:

// Anonymized excerpt — the exported helper
function get_code(page) {
    a = BB(<BUSINESS_MODULE>);
    s = BB(<SIGN_MODULE>);
    n = {
        "pages": page + ",1",   // page-dependent
        "sizes": "100,100",
        "subject": "market_cap",
        "language": "en_US",
        "legal_currency": "USD"
    };
    t = (0, s.Fk)((0, a.Z)({}, n, (0, s.xZ)(n?.extra_param)));
    var t_s = t.toString();
    var timestamp = t_s.split("timestamp=")[1].split("&")[0];
    var code = t_s.split("code=")[1].split("&timestamp")[0];
    return { timestamp, code };
}

Here BB(...) is webpack's __webpack_require__; it loads the utility module and the signature module that contains Fk / xZ. get_code merges the business params with the signature object, hands them to Fk to build the full query, then splits the string to extract timestamp and code.

The emulation cost is nearly zero: this code depends on nothing from document / window (the timestamp comes from Date.now()), so as long as Node can require the bundle dependencies, execjs runs it directly.

5. Python Implementation

The Python script: read JS → compile → call get_code(page) → take code / timestamp into the query.

# Anonymized Python (URLs replaced with placeholders)
import requests
import execjs

def spy(page: int):
    with open("bundle.js", encoding="utf-8") as f:
        js_code = f.read()

    js = execjs.compile(js_code)
    arg = js.call("get_code", str(page))   # note: pass page as a STRING
    code = arg["code"]
    timestamp = arg["timestamp"]

    headers = {
        "accept": "*/*",
        "accept-language": "en-US,en;q=0.9",
        "origin": "https://www.example.com",
        "referer": "https://www.example.com/",
        "user-agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/138.0.0.0 Safari/537.36",
    }
    url = "https://api.example.com/<ranking-endpoint>"
    params = {
        "pages": "2,1",
        "sizes": "100,100",
        "subject": "market_cap",
        "language": "en_US",
        "legal_currency": "USD",
        "code": code,
        "timestamp": timestamp,
        "platform": "web_pc",
        "v": "0.1.0",
        "extra_param": "",
    }
    response = requests.get(url, headers=headers, params=params)
    print(response.text)

spy(4)

Key points:

get_code expects a string page number (str(page)) because it does page + ",1" string concatenation internally;
the returned arg is a dict — read arg["code"] / arg["timestamp"];
the remaining params (subject / language / legal_currency ...) match the browser.

6. Result

Running the script prints the params (note code / timestamp differ every run), followed by the returned coin list:

{'pages': '2,1', 'sizes': '100,100', 'subject': 'market_cap', 'language': 'en_US', 'legal_currency': 'USD', 'code': '<hex>', 'timestamp': '<ms>', 'platform': 'web_pc', 'v': '0.1.0', 'extra_param': ''}
{"data":{"tickerList":[{"symbol":"BTC","price_usd":...,"market_cap_usd":...}, ...]},"code":0}
<Response [200]>

As long as the list comes back with complete fields, the signature chain is fully working.

📷 [Figure 3 — screenshot suggestion] The terminal output: the retrieved ranking data.

7. Pitfalls & Notes

The page number must be a string. get_code does page + ",1", so passing a number may behave unexpectedly under execjs. Use str(page) consistently.
timestamp is a millisecond string. Date.now().toString() is a string; substring(0, 6) takes the first 6 digits. Don't switch to seconds or a number type.
Do not change the fixed salt. It is a constant baked into the bundle; changing it breaks the signature.
hashStr is not a plain lowercase MD5 hex. It is an incremental MD5 and may output an upper-case variant or one seeded by the second argument (hashStr(t, e = false)). The safest path is to call the original function rather than substitute another MD5 library.
webpack module ids change. After a re-deploy, ids such as BB(<SIGN_MODULE>) may become invalid; re-locate Fk / hashStr by search.
Rate-limit. Market data updates quickly, but still keep the request rate low and respect the site's terms.

8. Takeaways

code = MD5(timestamp + "<FIXED_SALT>" + timestamp.substring(0,6)) — the "fixed salt + timestamp" pattern is one of the most common signatures; searching for the timestamp literal often hits it immediately.
Identify a JS hash library by its constants: _md5cycle / -680876936 means MD5; SHA-family implementations use different init values (e.g. 1779033703).
If you can run the original function, don't re-implement the algorithm. Since the signature is timestamp-driven, letting execjs compute it fresh each time is more robust than reimplementing the hash in Python.

Disclaimer: This article is for educational and security-research purposes only. Do not use it for any commercial or illegal activity. All endpoints/sites have been anonymized; always respect the target's terms of service and applicable laws.

JS Reverse Engineering Case Study #1

FeiHua — Fri, 16 Oct 2026 14:28:01 +0000

JS Reverse Engineering Case Study #1 — Reconstructing an Obfuscated `analysis` Request Signature (Environment Emulation + execjs)

Part 1 of the "JS Reverse Engineering in Practice — 30 Case Studies" series.
Source code (this case): https://github.com/scool112/openJSreverse (Project1)

Note on sanitization: This is a sanitized, educational write-up. Every real domain, endpoint and interface path has been replaced with generic placeholders (example.com). No production endpoint or site-specific constant is disclosed. The goal is to explain the technique, not to enable abuse of any specific service.

1. Goal & Background

Recently I kept coming across a common anti-crawler pattern on data-driven sites: the request looks plain, but one query parameter is an opaque signature string. If it is missing or wrong, the server rejects the call.

This first case is exactly that. The target is a public app-ranking site (referred to as "Site A" in this article). I wanted the "delisted apps" ranking list, and its list endpoint carries a signature parameter named analysis.

Target site: https://www.example.com (an app-ranking site)
Target endpoint: https://api.example.com/<ranking-endpoint>
Parameter to reconstruct: analysis (the rest are plain business parameters)
Difficulty: ⭐⭐⭐⭐ — the algorithm itself is not the hard part. The hard part is that the target bundle is heavily obfuscated, so the pragmatic strategy is: emulate the browser environment and call the site's own exported get_analysis().

The reverse-engineering target here is a classic parameter signature. Unlike a plain MD5 that you can read at a glance, this one was processed with a javascript-obfuscator-style transformation (string table + member-expression obfuscation). Reading variable names by eye is basically hopeless. So instead of fighting the obfuscation, I chose to emulate the environment and run the original function.

2. Traffic Analysis

Open https://www.example.com in a browser, press F12, switch to the Network panel, filter by Fetch/XHR, and then toggle the ranking tab / flip a page. You will see a request to the list endpoint.

Open that request and look at the Payload (query string):

analysis=<opaque signature string>
option=<n>
sdate=
edate=

option selects the ranking type, and sdate / edate are the date range — all plain text. The only unreadable value is analysis: a mixed-case string that looks like Base64 but behaves like an encrypted result. It changes every time the ranking type or date changes, which means it is tightly bound to the request data — i.e. a real signature.

Now look at the request headers: Origin and Referer both point to Site A, and the request carries login cookies. So this endpoint also requires a logged-in session — a correct analysis alone is not enough.

📷 [Figure 1 — screenshot suggestion] The Network panel: the list request's Payload and the Cookie request header.

Conclusion: The request is a GET with plain parameters; the whole challenge is reconstructing how analysis is generated.

3. Locating the Signature Entry Point

Since this is a parameter signature, I went to the Sources panel and did a global search for the parameter name analysis (or for nearby business fields such as option / sdate). The search lands in a very large obfuscated bundle (the site's main package).

At first I tried to read it directly. Variable names were all single/double letters like n2 / t2 / e2 / R, and strings were packed into a string array, restored through a "index lookup" function such as n(12,13,14,...) — the classic javascript-obfuscator pattern. Restoring it line by line is far too expensive, so I switched strategy: can I just extract the exported function and run it?

Following where analysis is assigned, I found the export:

// Anonymized excerpt from the reconstructed JS (start/end of the bundle)
var AA;
var get_analysis;
// ...

    get_analysis = get_T;
}(function (a) {
    return function () {
        for (var n = arguments, t = "", e = 0, r = n.length; e < r; e++)
            t += a[n[e]];
        return t;
    };
}(["p", "u", "s", "h", "w", "e", "b", "a", "c", "k", /* ... */]));

In other words, after the whole bundle runs, a global get_analysis appears, pointing at the internal, heavily obfuscated get_T. That is exactly the entry point I want.

📷 [Figure 2 — screenshot suggestion] In the Sources panel: the assignment of analysis and a breakpoint on the get_T call stack.

4. Restoring the JS & Emulating the Environment

Early inside get_T, it accesses document.cookie (it mixes session state into the signature), and Node has no document. So the first emulation step is to fake a global.document at the very top of the file and inject the cookies:

// Reconstructed JS (cookies replaced with placeholders — use YOUR OWN session cookies)
var AA;
var get_analysis;

global.document = {
    cookie: "SESSIONID=<your-session-id>; TOKEN_A=<your-token-a>; TOKEN_B=<your-token-b>; ts=<your-ts>"
};

Next is the restored core function get_T. It packs the parameter object into an array, sorts and joins it, then applies a hash / symmetric encryption, and finally toString()s the result into analysis. The (obfuscated) shape is:

// Obfuscated variable names kept as-is (anonymized)
function get_T() {
    var i = AA(21725), r = AA(9669), o = AA[d7](r), /* ... */ c = AA(C);
    // ... build an array `a` from `t.params`, sort it, join with a separator ...
    // ... append url + timestamp + fixed constants ...
    // e = encode(encrypt(a, key));
    return e.toString();
}
get_analysis = get_T;

From this shape you can see the approximate construction of analysis:

Walk the params object (edate / option / sdate) into an array a;
Sort the array and join it with a separator;
Append the URL, a timestamp, and a set of fixed constants;
Apply the symmetric encryption / encoding referenced inside the expression, and output e.toString().

Those constants are hidden behind the string-table restore function n(...). Reversing them one by one by hand is not worth it. So my approach is: don't reconstruct the algorithm — run the whole bundle and call its own get_analysis.

To run it under Node / execjs, I did two emulation things:

Fake global.document (shown above);
The bundle already ends with a self-test call to get_analysis() in a comment, confirming it is meant to be called exactly like that.

5. Python Implementation

The Python script is short: read the JS → execjs.compile → call get_analysis() → put it into the query.

# Anonymized Python (URLs and cookies replaced with placeholders)
import requests
import execjs

with open("bundle.js", encoding="utf-8") as f:
    js_code = f.read()

js = execjs.compile(js_code)
analysis = js.call("get_analysis")

headers = {
    "Accept": "application/json, text/plain, */*",
    "Accept-Language": "en-US,en;q=0.9",
    "Origin": "https://www.example.com",
    "Referer": "https://www.example.com/",
    "Sec-Fetch-Mode": "cors",
    "Sec-Fetch-Site": "same-site",
    "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/138.0.0.0 Safari/537.36",
}

cookies = {
    "SESSIONID": "<your-session-id>",
    "TOKEN_A": "<your-token-a>",
    "TOKEN_B": "<your-token-b>",
    "ts": "<your-ts>",
}

url = "https://api.example.com/<ranking-endpoint>"
params = {
    "analysis": analysis,   # computed by the restored JS
    "option": "<n>",
    "sdate": "",
    "edate": "",
}

response = requests.get(url, headers=headers, cookies=cookies, params=params)
print(response.text)

A few details:

js.call("get_analysis") takes no arguments and returns the full analysis string;
The cookies must be the same logged-in session as the one you injected into document.cookie (both are placeholders here — replace them with your own);
Keep option and the empty dates consistent with the browser request.

6. Result

Running the script prints the computed params (note analysis differs every run) and then the JSON returned by the endpoint:

{'analysis': '<computed-signature>', 'option': '<n>', 'sdate': '', 'edate': ''}
{"code":0,"msg":"ok","data":{"list":[{"appName":"...","rank":"..."}, ...]}}
<Response [200]>

As long as the server returns code:0 with a populated data.list, the analysis signature is correct. If you get an auth/signature error instead, first suspect an expired cookie or a mismatched parameter.

📷 [Figure 3 — screenshot suggestion] The terminal output: the computed analysis and the returned JSON data.

7. Pitfalls & Notes

document must be emulated. get_T reads document.cookie, so a bare execjs.compile throws document is not defined. Forgetting to inject global.document cost me quite some time.
Cookies are a live session. The session token is timestamped and expires. The cookies in the JS and in the Python request must match, and both must be yours (placeholders in the repo). An expired cookie will be rejected even if the signature is perfect.
Don't try to de-obfuscate the string table by hand. The n(12,13,14,...) lookup can be automated with AST tooling, but for a single parameter it is not worth it — emulating the environment and calling the original function is the fastest route.
The signature is bound to the parameters. Change option / sdate and you must recompute analysis.
Use UTF-8 consistently. open(..., encoding="utf-8") matters: on Windows the default encoding can corrupt the JS and break parsing.
Rate-limit. This is a logged-in data endpoint — keep the request rate low and respect the site's terms and local laws.

8. Takeaways

For heavily obfuscated signatures, the best move is usually "emulate the environment and run the original function", not "reconstruct the algorithm" — you only need to fake the few globals it actually touches (document, window, ...).
The essence of analysis is "sorted params → joined string → hash → symmetric encryption → encoding"; the entry point is the site's own exported get_analysis.
execjs calling an exported JS function + requests with a logged-in cookie is the fastest combo for this kind of obfuscated signature.

Disclaimer: This article is for educational and security-research purposes only. Do not use it for any commercial or illegal activity. All endpoints/sites have been anonymized; always respect the target's terms of service and applicable laws.

DEV Community: FeiHua

JS Reverse Engineering Case Study #3 — Reconstructing Request-Header Signatures

JS Reverse Engineering Case Study #3 — Reconstructing Request-Header Signatures (Content-Md5 + HMAC-SHA1) with Carved-Out Crypto Modules and execjs

1. Goal & Background

2. Traffic Analysis

3. Locating the Signature Entry Point

4. Restoring the JS & Emulating the Environment

5. Python Implementation

6. Result

7. Pitfalls & Notes

8. Takeaways

JS Reverse Engineering Case Study #2 — Reconstructing code / timestamp (a Fixed-Salt MD5 Signature)

JS Reverse Engineering Case Study #2 — Reconstructing code / timestamp (a Fixed-Salt MD5 Signature)

1. Goal & Background

2. Traffic Analysis

3. Locating the Signature Entry Point

4. Restoring the JS & Emulating the Environment

5. Python Implementation

6. Result

7. Pitfalls & Notes

8. Takeaways

JS Reverse Engineering Case Study #1

JS Reverse Engineering Case Study #1 — Reconstructing an Obfuscated analysis Request Signature (Environment Emulation + execjs)

1. Goal & Background

2. Traffic Analysis

3. Locating the Signature Entry Point

4. Restoring the JS & Emulating the Environment

5. Python Implementation

6. Result

7. Pitfalls & Notes

8. Takeaways

JS Reverse Engineering Case Study #3 — Reconstructing Request-Header Signatures (`Content-Md5` + HMAC-SHA1) with Carved-Out Crypto Modules and `execjs`

JS Reverse Engineering Case Study #2 — Reconstructing `code` / `timestamp` (a Fixed-Salt MD5 Signature)

JS Reverse Engineering Case Study #1 — Reconstructing an Obfuscated `analysis` Request Signature (Environment Emulation + execjs)