AI-Accelerated Reverse Engineering: Cracking SM2/SM4 Encrypted Freelance Jobs in 30 Minutes

How AI Is Reshaping the Reverse Engineering Workflow for Web Scrapers

In the world of Python scraping freelance work — a grind-heavy, detail-intensive field — reverse engineering encrypted parameters is almost always the most time-consuming part of the job. A Bilibili creator known as "老詹 (James)" walked through a real freelance project demonstrating how large language models like DeepSeek^Ad can compress what used to take several hours of reverse engineering work into under 30 minutes.

The value of this case goes beyond the technical steps themselves. It points to a broader industry shift: AI is transforming scraping reverse engineering from "picking through code line by line" into a high-efficiency collaboration model built on "precise localization + model-generated output". This article breaks down the full workflow and core methodology.

Project Background: A Freelance Job with SM-Series Encryption

This particular engagement was a website maintenance request — the target site had been updated, and the encryption parameters used in data collection needed to be re-analyzed. Market rates for this type of work typically fall in the 500–800 RMB range, making it a mid-difficulty freelance job.

The core challenges were all at the API layer:

• The API uses POST requests with multiple encrypted parameters
• Parameters include ABCode, an ENCdata field in the request body, and SyData
• The encryption scheme combines SM2 (asymmetric) and SM4 (symmetric) — both part of China's national cryptography standards

It's worth noting that the SM-series algorithms are a set of commercial cryptographic standards developed and promoted by China's State Cryptography Administration. SM2 is based on elliptic curve cryptography (ECC), offering security equivalent to RSA-3072 with higher computational efficiency, and is primarily used for digital signatures and key exchange. SM4 is a symmetric block cipher with both a block size and key length of 128 bits, structurally similar to AES. In web API security contexts, the two are frequently combined: SM2 handles the session key exchange, while SM4 encrypts the actual request body — forming a two-layer protection scheme of "asymmetric handshake + symmetric encryption." This combination is increasingly common on compliance-sensitive government and financial websites.

In short, the core task was to reverse engineer several encrypted header fields prefixed with x-tif, as well as the encrypted request body.

Reverse Engineering: From Packet Capture to Locating the Encryption

Step 1: Bypassing the Infinite Debug Anti-Debugging Trap

Upon opening DevTools, the first obstacle was the classic infinite debug anti-debugging mechanism. This is a well-known pattern in scraping reverse engineering, and it can be bypassed by pasting a specific snippet into the console — no significant time investment needed.

The infinite debug technique works by inserting setInterval or debugger statements into the code to trigger breakpoints in a loop. Once it detects that DevTools is open, it continuously fires the debugger, making the page impossible to interact with. Common bypasses include: right-clicking the breakpoint in the Sources panel and selecting "Never pause here"; overwriting Function.prototype.constructor to neutralize debugger statements; or injecting code into the console to kill all timers (e.g., for(var i=1;i<99999;i++) window.clearInterval(i)). This kind of anti-debugging has no effect on regular users — it specifically targets analysts with DevTools open, and serves as the first line of defense for protecting a site's JS logic.

Once the anti-debugging was bypassed, navigating the page made it easy to capture the relevant network requests and lock in the target parameters.

Step 2: Call Stack Backtrace — Finding the Encryption Entry Point

Because the code was obfuscated, a conventional global search for parameters like signet wasn't going to work. The approach here was to start from the initiator (call stack) and use a systematic backtrace method:

1. Set a breakpoint at the point where the request is sent
2. Step through the call stack, checking at each step whether the headers already contain encrypted x-tif values
3. If the encrypted value is already present at the current step, step back one level
4. Keep backtracking until you find the exact point where the value doesn't yet exist — but will be generated in the very next step

This led to a critical function that had been processed by Obfuscator (OB obfuscation). OB obfuscation is one of the most widely used code protection tools on the web today. Its core techniques include: extracting all string literals into a centralized array and accessing them via index offsets through a rotation function; replacing variable and function names with random hashes; and inserting large amounts of dead code and control flow flattening logic. The telltale signature is a large string array accessed through index lookups — the obfuscated code is logically equivalent to the original, but nearly unreadable. Manually deobfuscating even a moderately complex function can take tens of minutes or even hours.

The Problem with Manual Code Extraction: Deobfuscation Is Pure Grunt Work

After locating the key section, the next step was to manually "extract" it — copying obfuscated fragments piece by piece into PyCharm for reconstruction. This process is tedious:

• Timestamp parameters are relatively straightforward — a string replacement plus getTime handling does the job
• But signet involves a loop over a six-element array (shift pop + function callback), requiring a trace into the result of every popped element
• Any undefined strings need to be hunted down individually, and missing assignments require digging into deeper layers

As James put it: "Doing it this way, your efficiency really takes a hit." This is the classic pain point of traditional reverse engineering: deobfuscating code is low-tolerance grunt work, and it's the single biggest time sink in the entire process.

The AI Efficiency Breakthrough: Feed the Obfuscated Code Directly to a Model

This is where the efficiency revolution happens. The obfuscated code fragment — already precisely located — was submitted directly to a large language model (first Tree, then switching to DeepSeek), with a single natural language prompt:

"Help me deobfuscate this code and implement the encrypted parameters for this API."

The results were impressive:

• The model produced a complete deobfuscated version of the code
• It output ready-to-use Python implementation code with clean, concise logic
• The SM2 and SM4 key pairs were extracted in the process
• In some cases, it even generated a JS version for cross-validation

"I didn't write a single line of code — I just asked and got the answer." The generated string output worked immediately, and the signet parameter computed correctly.

The reason this works: leading large language models (such as DeepSeek and GPT-4) were trained on vast amounts of open-source code and technical documentation, enabling them to recognize code patterns for common cryptographic algorithms and reconstruct semantic structure even within obfuscated code. That said, their capabilities have limits — for very long obfuscated bundles (often tens of thousands of lines), model accuracy drops significantly; for custom encryption variants, models may produce outputs that look plausible but contain logical errors (i.e., "hallucinations"). This means that the engineer's ability to precisely isolate the relevant code fragment, filter out noise, and validate the model's output through testing remains an indispensable part of the workflow.

The Core Methodology: Precise Localization Matters More Than Code Generation

AI-assisted efficiency has one prerequisite: you must accurately locate the encryption point before the model can be effective.

For webpack-bundled scenarios (identifiable by loader patterns like 6C27 or Ci56), rather than grinding through the obfuscated loader code, a far more efficient approach is to use CryptoJS as a drop-in replacement — import a ready-made crypto.js, create the corresponding instance, do the string substitution, and it runs.

Webpack is the dominant module bundler in modern frontend development. Its typical fingerprints include structures like (function(modules){...})({...}), numeric or short-string module IDs as keys, and __webpack_require__ as the internal require function. Understanding this structure lets reverse engineers skip the loader logic entirely and focus only on the business logic module they actually need — dramatically reducing the scope of analysis.

Putting It All Together: The Complete Workflow

Let's map out the complete flow James used:

1. Capture packets → Identify target encrypted parameters
2. Bypass anti-debugging → Unlock DevTools access
3. Call stack backtrace → Pinpoint the encryption entry function
4. Extract the obfuscated fragment → Isolate the minimal relevant code
5. Feed to LLM (DeepSeek) → Get deobfuscated code + Python implementation
6. Validate output → Verify that parameters compute correctly
7. Package and deliver → Build the final scraper script

The total time came in at around 30 minutes — a fraction of what traditional manual deobfuscation would require.

Industry Implications: How AI Is Changing the Freelance Scraping Market

This workflow shift has real implications for how scraping engineers approach and price their work:

Time compression: Tasks that once took 4–8 hours now take under an hour, directly improving hourly effective rate

Skill redistribution: The bottleneck shifts from "can you read obfuscated code" to "can you locate the right code to feed the model" — analytical and architectural thinking become more valuable than line-by-line decoding endurance

Quality consistency: Model-generated code tends to be cleanly structured and well-commented, making handoffs and maintenance easier

Capacity scaling: With faster turnaround per job, engineers can handle more projects simultaneously without sacrificing quality

That said, AI assistance doesn't eliminate the need for expertise. Understanding encryption algorithm fundamentals, knowing how to read call stacks, recognizing obfuscation patterns, and validating model output — these remain core competencies. What AI removes is the pure drudgery of mechanical deobfuscation.

Key Takeaways

1. Bypass anti-debugging first — it's quick and unlocks everything downstream
2. Use call stack backtrace to pinpoint the encryption entry point precisely
3. Extract the minimal relevant fragment — don't dump the entire JS file into the model
4. Let the LLM handle deobfuscation and implementation — this is where the biggest time savings come from
5. Always validate the output — test that the generated parameters actually work against the live API
6. Know your bundle type — webpack-bundled code often has faster workarounds than trying to deobfuscate the loader

For scraping engineers working in the freelance market, the message is clear: AI doesn't replace the reverse engineer — it eliminates the most time-consuming, low-creativity parts of the job, freeing up time and mental bandwidth for the work that actually requires human judgment.