Target Endpoint and Initialization

The target for this analysis is the login portal of a major e-commerce platform. The primary objective is to intercept and decrypt the h5st signature parameter (version 4.7.4) and handle the accompanying CAPTCHA verification.

Base64 encoded target: aHR0cHM6Ly9wYXNzcG9ydC5qZC5jb20vbmV3L2xvZ2luLmFzcHg=

Request Parameter Analysis

The core of the login request relies on two encrypted parameters: aksParamsU and aksParamsB. The latter, aksParamsB, is essentially a concatenation of various request arguments. Identifying the generation point for this string requires tracing the data flow backward from the network request.

Static and Semi-Static Fields

Several fields can be treated as constants or derived from the initial page load using regular expressions or DOM parsing:

• Initialization Data: sa_token, uuid, pubKey, and slideAppId are fetched from the login page source.
• Fixed Values: _t, loginType, useSlideAuthCode, pageSource, pageLocation, firstShowAccountLoginPage, rm, and _stk generally remain static across sessions.

CAPTCHA Integration

The authcode and seqSid parameters are specific to the slider verification mechanism.

• seqSid: Retrieved from the jseqf.html endpoint.
• authcode: This is the validation token returned upon successfully solving the slider challenge presented in slide/s.html.

Note: The slider logic detects interaction timing. Introducing artificial delays in the solver script is often necessary to mimic human behavior and pass detection.

Credential Encryption

The username and password are sent as loginname and nloginpwd. The password is encrypted using JSEncrypt. To replicate this, the full JSEncrypt library must be extracted and the environment properly simulated (polyfilling missing browser globals).

Fingerprinting (fp, eid, eid2)

The fp (fingerprint) parameter can be temporarily hardcoded. However, eid and eid2 are dynamic, returned by the jsTk.do endpoint. This request requires two specific parameters: a and d.

• Parameter d (Environment Check): This array performs basic environment validation. Components other than the timestamp can often be fixed.
• Parameter a (State Check): This involves retrieving cookie values and the fp. Like d, these can often be fixed provided consistency is maintained with previous requests.

Both a and d pass through a common encryption function before transmission. Extracting this function is necessary for successful jsTk.do requests.

H5ST Token Generation (Version 4.7.4)

The h5st generation logic is heavily obfuscated using VMP (Virtual Machine Protection). Reverse engineering this requires extracting the protected code segments.

Dynamic Algorithm Retrieval

The process begins by locating the entry point, often hidden within a regex execution. The code dynamically fetches algorithm definitions via a request_algo call. Testing reveals six potential hashing algorithms: SHA256, SHA512, HmacMD5, MD5, HmacSHA256, and HmacSHA512. All implementations are custom-modified versions of the standards.

Multiple runs may be required to capture all variations of these modified algorithms.

Signature Construction

The generation process involves a specific string concatenation scheme:

1. Retrieve the algo result from the VMP execution.
2. Concatenation Step 1: [algo_result] + "loginname:[username]" + [algo_result]. Hash this string using the modified MD5 algorithm.
3. Concatenation Step 2: [algo_result] + "appid:[appid]&functionId:[functionId]" + [algo_result]. Hash this string using the modified MD5 algorithm.

Finally, the h5st signature is assembled using the hashed results from Step 1 and Step 2, combined with the timestamp (t), formatted timestamp (r), and other intermediate parameters (n, a).