AI-Assisted GeeTest Four-Image CAPTCHA Reverse Engineering: A Complete Efficiency Guide

Introduction: An Efficiency Revolution in CAPTCHA Reverse Engineering

For developers working in web scraping and automation, GeeTest's four-image click CAPTCHA has always been a tough nut to crack. Not only does it change dynamically, but it also involves multiple encrypted interfaces and heavily obfuscated code — pure manual reverse engineering often takes over two hours of analysis, traffic capture, and call chain tracing.

Background: GeeTest's Technical Protection Architecture GeeTest is one of China's leading behavior-based CAPTCHA service providers. Its four-image click CAPTCHA belongs to the fourth-generation (GeeTest v4) product line. Compared to earlier slider CAPTCHAs, click-based CAPTCHAs introduce image recognition interference, dynamic coordinate encryption, and device fingerprint collection, significantly raising the bar for automated solving. GeeTest's protection system typically operates on three levels: front-end JS obfuscation (usually OB obfuscation / Webpack bundling), dynamic parameter encryption (the w value differs on every request), and server-side risk control (device fingerprint comparison, behavioral trajectory analysis). It is precisely these three overlapping layers that make traditional manual reverse engineering so time-consuming.

Recently, a content creator on Bilibili shared a practical "AI-assisted reverse engineering" workflow. The core idea is to hand the obfuscated code and captured traffic data to an AI, letting it automatically handle parameter identification, encryption logic analysis, and code generation — compressing the entire process to just a few minutes. This article breaks down the key steps and technical details of that methodology.

Step 1: Identify Key Interfaces and Request Parameters

The first step in analyzing any CAPTCHA is observing the network requests. Open the F12 developer panel (Network tab) and refresh the CAPTCHA — you'll see a packet named GeeLoad. After successfully passing the CAPTCHA, another request called GeeWiFi is triggered.

Technical Note: F12 DevTools and Network Traffic Capture The browser DevTools Network panel is the standard entry point for web reverse engineering. After pressing F12, switch to the Network tab and check "Preserve log" and the "XHR/Fetch" filter to capture all async requests between the page and the server. For CAPTCHA analysis, focus on: Request Headers (containing Cookie, User-Agent, and other environment info), Request Payload (the POST body data, where encrypted parameters usually hide), and the Response (server return values). Modern browsers also support the "Copy as cURL" feature, which lets you export requests directly to the terminal for reproduction — a great way to quickly verify whether parameters are correct.

These two interfaces form the core verification chain:

• GeeLoad: Initialization, returns a large amount of base data
• GeeWiFi: Submits the verification, carries the key encrypted parameters

When inspecting the request headers, there's no obvious encryption information. The real key lies in the Payload. Here you'll find several suspicious values: lot_num, payload, token, and most importantly, the w value — followed by a long string of encrypted characters.

Distinguishing "Server-Returned" from "Client-Generated" Values

This is a critically important — yet often overlooked — judgment step in reverse engineering. The content creator's approach: perform a global search on each suspicious value to determine whether it was returned by the server or generated by front-end JS.

Through searching, the findings are:

• lot_num, payload, and token can all be found in the GeeLoad interface response — meaning they are server-issued and don't need to be reverse-engineered
• Only the w value cannot be found in the GeeLoad response; it only appears as a request parameter in GeeWiFi — this is the encrypted core that actually needs to be reverse-engineered

This judgment directly determines the workload ahead. Clearly separating server-side data from client-side encrypted data lets you focus on the real challenge.

Step 2: Trace the Encrypted Generation of the w Value

Once w is locked in, the next step is finding where it's generated. Two methods are recommended:

Method 1: Keyword Search

Searching for w alone is too broad. Adding a colon (w:) narrows it down, targeting assignment/generation patterns in the code. This approach can identify several w assignment points, one of which directly exposes the request parameter assembly logic.

Method 2: Event Breakpoints and Call Stack Tracing (Recommended for Beginners)

For developers less familiar with search techniques, a more intuitive approach is recommended: setting breakpoints on event listeners.

Technical Note: Call Stack Tracing The call stack is the data structure a computer uses to track function call relationships during program execution. When function A calls function B, which then calls function C, frames for A→B→C are pushed onto the stack in sequence, then popped off as each function completes. After a breakpoint is triggered, the browser DevTools "Sources" panel displays the full current call stack, and developers can click each frame to jump to the corresponding code. For CAPTCHA reverse engineering, tracing inward from the user click event (the outermost layer) along the call stack essentially reconstructs the full execution path: "click → event handler → parameter assembly → encryption function." This is more efficient than blind global searching and less likely to miss intermediate data transformation steps.

In practice: set a breakpoint on the click event, trigger the CAPTCHA, and the code will pause at the breakpoint. Then trace back up the call stack frame by frame. Since these functions are called in a nested stack, a bit of patience will eventually lead you to the real generation location of the w value, as well as the sources of encrypted data like lot_number, pow_msg, and pow_sign.

Step 3: Analyze the Parameter Structure of the Encryption Function

Once the generation location is found, you can see that the encryption function for w takes two parameters.

By observing the first parameter in the console, you'll find it contains dynamic values like payload and pow_msg that change over time (tied to timestamps). The second parameter contains a key oxHash (hash value), which also changes dynamically.

Technical Note: The Nature of the w Parameter — A Device Fingerprint Bundle The "w parameter" in CAPTCHA systems is essentially a Device Fingerprint Bundle. It typically aggregates multiple browser environment characteristics, including: Canvas fingerprint (hash of WebGL/Canvas rendering results), AudioContext fingerprint, screen resolution and color depth, installed font list, browser plugin information, mouse movement trajectory and click coordinates, as well as timestamps and random nonce values. These data points are mixed through multiple layers of encryption (commonly combinations of AES, RSA, and custom XOR) to produce the final w value. The server decrypts and reconstructs these characteristics upon receiving the request, then compares them against a model of normal user behavior to determine whether the request is from a bot. Therefore, simply "cracking the encryption algorithm" is not enough — the fingerprint data passed in must also conform to the characteristic distribution of a real browser.

These "changing" fields are the focus of reverse engineering:

• Static fields: Can be hardcoded directly as JSON parameters
• Dynamic fields (e.g., timestamp-related payload, hash values): Each one's generation logic must be traced

After mapping everything out, it becomes clear that the final encryption logic is concentrated in a single function, which essentially obfuscates and encrypts several client-side data points into the final w parameter.

Step 4: AI Takes Over — From Obfuscated Code to Runnable Script

This is the core value of this case. Traditional manual reverse engineering — extracting code, reconstructing the environment, debugging — takes at least two hours from start to finish. With AI assistance, that timeline is drastically compressed.

Technical Note: JavaScript Obfuscation and OB Obfuscation Modern web applications widely use JavaScript obfuscation to protect core logic. GeeTest's obfuscation belongs to the industry-common "OB obfuscation" scheme (obfuscator.io). Its main characteristics include: replacing readable variable names with meaningless hexadecimal strings, encoding string content as Base64 or hexadecimal arrays, disrupting function execution order through Control Flow Flattening, and inserting large amounts of dead code and anti-debugging traps. Even experienced reverse engineers need hours to manually restore this kind of obfuscated code. Large language models, pre-trained on massive code corpora, can quickly recognize obfuscation patterns and infer the original logic — this is the core source of value in AI-assisted analysis for this case.

The specific workflow:

1. Export the obfuscated code containing the encryption method as a standalone file
2. Use global text replacement to normalize obfuscated variable names
3. Export the encryption method and fingerprint information via global variables
4. Hand the entire code block along with the captured traffic data to the AI

The AI automatically analyzes the processing flow, maps out the interface call relationships, identifies the core logic of "encrypting and obfuscating into the w parameter," and generates directly runnable calling code. The entire process takes just a few minutes.

Handling AI Compliance Constraints

You may not have noticed, but the content creator specifically warned: asking an AI directly to perform reverse engineering analysis may trigger the model's ethical/compliance constraints, causing it to refuse. The solution lies in carefully designing the Prompt, along with configuring Skills and setting up MCP, to smoothly complete the analysis task.

Deep Dive: Prompt Engineering in Security Research Prompt engineering refers to the technique of carefully designing input instructions to guide large language models toward desired outputs. In AI-assisted reverse engineering scenarios, directly asking a model to "crack a CAPTCHA" often triggers the safety refusal mechanisms instilled during RLHF (Reinforcement Learning from Human Feedback) training. Effective guidance strategies include: framing the task as a "security research / academic analysis" context, using a role-setting framework (e.g., "You are a cybersecurity researcher"), asking step by step (first ask the model to explain the encryption algorithm, then ask it to generate the calling code), and using MCP (Model Context Protocol) tool calls to bypass filters at the pure dialogue layer. This phenomenon reflects a core tension in the current AI security research field: the gap between model capability and deployment compliance still requires industry-level standardized solutions.

This also illustrates that AI-assisted security research currently sits at a delicate balance point between capability and compliance.

Verification Results and Efficiency Comparison

After running the AI-generated script, the verification succeeded, returning a status of "success". Comparing the output in the browser confirmed consistency, and clicking confirm completed the full verification flow. GeeLoad, GeeWiFi, and subsequent registration and UV value requests all returned success statuses.

The efficiency comparison speaks for itself:

Method	Time Required	Characteristics
Traditional manual reverse engineering	2+ hours	Fully manual code extraction and environment reconstruction
AI-assisted reverse engineering	A few minutes	Automatic analysis and code generation

Conclusion: AI Is Reshaping How Reverse Engineering Works

The biggest takeaway from this case is not that "a particular CAPTCHA was cracked," but rather the demonstration of AI's enormous potential as a reverse engineering assistant. It frees developers from the tedious work of tracing call chains and reading obfuscated code, letting them focus on strategic judgment (such as distinguishing server-side from client-side data) while delegating the mechanical labor to AI.

Of course, a realistic perspective is also needed: AI still depends on developers providing accurate traffic data and clear guidance. Prompt engineering and environment configuration still have a learning curve. But it's safe to say that as AI coding capabilities continue to advance, the traditional efficiency barriers in reverse engineering are being rapidly eroded.

Disclaimer: CAPTCHA reverse engineering techniques should only be applied in legitimate security research and authorized testing scenarios. Do not use them for any illegal purposes.