AI-Powered Python Reverse Engineering: A Full Retrospective on Using LLMs to Accelerate the Workflow

Introduction: How LLMs Are Reshaping the Reverse Engineering Workflow

Python reverse engineering has always been a high-barrier technical field. When faced with JavaScript code obfuscation and Chinese national cryptographic standards (SM2/SM4), developers typically spend hours in browser DevTools doing breakpoint debugging, call stack tracing, and laboriously reconstructing code line by line. Bilibili creator James (老詹) used a real website maintenance contract (quoted at roughly ¥500–800) as a case study to demonstrate how large language models can dramatically speed up the tedious reverse engineering process.

This article is based on that real-world case. It outlines the specific ways AI can be applied in reverse analysis and offers an objective assessment of the value and risks of this type of "tech side hustle." It's worth noting upfront: reverse engineering third-party websites carries legal and compliance risks. This article discusses technical methodology only and does not constitute operational advice.

The Traditional Reverse Engineering Workflow: Where All the Time Goes

In this case study, a target website's interface made POST requests carrying parameters such as abcode and data (which contained encdata and sindata), using a hybrid national cryptography scheme combining SM2 asymmetric encryption and SM4 symmetric encryption.

Background on Chinese National Cryptographic Standards: SM2 and SM4 are commercial cryptographic standards issued by China's State Cryptography Administration. SM2 is based on elliptic curve cryptography (ECC) with a 256-bit key length — offering security equivalent to RSA-2048 but with greater computational efficiency — and is commonly used for digital signatures and key exchange. SM4 is a block symmetric cipher with both key and block lengths of 128 bits, widely deployed in China's financial and government systems. The two are often used together: SM2 securely transmits the SM4 key, while SM4 efficiently encrypts the actual data, forming a hybrid architecture that balances security and performance.

The encryption algorithms themselves aren't particularly complex. The real challenge lies in precisely locating where the parameters are generated.

Breakpoint Debugging and Call Stack Tracing

The creator first dealt with the common "infinite debugger" anti-debugging technique (bypassed by injecting code into the console), then captured and analyzed the request structure. The real difficulty was a set of encrypted parameters prefixed with x-tif in the headers. These had been processed with OB obfuscation (JavaScript Obfuscator), displaying the classic pattern of a "string array + index-based lookup" that makes global keyword searches completely useless.

Background on OB Obfuscation: JavaScript Obfuscator (OB obfuscation) is one of the most common front-end code protection techniques. Its core strategies include: extracting all strings into an encrypted array and referencing them indirectly through indexes and decoder functions, rendering keyword searches ineffective; replacing variable and function names with meaningless identifiers (e.g., renaming encrypt to _0x3a1b); and inserting control flow flattening logic that breaks a linear code flow into a hard-to-follow state machine. These characteristics make it impossible to locate encryption logic through simple searching — engineers must rely on runtime breakpoints to trace execution step by step.

The x-tif parameters in the request headers

The only option was to fall back to the Initiator's call stack and trace backwards from the last execution step. The approach: set breakpoints at multiple suspicious steps, trigger the request by navigating the page, and observe whether the encrypted x-tif values were already present in the headers object at each step — if a value appears at one step but not the previous one, the encryption window has been identified.

Progressively Narrowing the Location

Through repeated tracing and inspection of the internal structure of Promise objects (the data and headers fields), the logic was eventually narrowed down to a sequence that performed shift operations on an array: six functions were popped and executed in order, with one of them performing the headers assignment.

These two are the same

This process depends entirely on the engineer's experience and patience, systematically eliminating red herrings — a vivid illustration of what traditional reverse engineering looks like in practice.

AI Enters the Picture: From "Reconstructing Code" to "Ask-and-Decrypt"

The key highlight of this case is: once the encryption logic has been located, there's no need to painstakingly reconstruct the obfuscated code line by line — just hand the code snippet directly to an LLM.

LLMs Generating Decryption Code Directly

The creator fed DeepSeek the relevant obfuscated code snippets for parameters like signet and timestamp, along with a clear requirement (e.g., "solve these parameters for this interface and output a Python implementation"). The results were impressive:

The LLM produced working, concise Python code directly;
It simultaneously provided an equivalent JS implementation;
The SM2/SM4 key pair was extracted as well.

This is a timestamp

In the creator's own words: "I didn't write a single line of code myself — I just asked and got it."

After running the output, the generated encrypted strings were confirmed to work correctly.

The reason LLMs perform so well at this stage is that their training data includes vast amounts of cryptographic algorithm implementations, code pattern recognition examples, and cross-language translation samples. Once the human completes the hardest step — locating the right code — the remaining "translation" work falls squarely within an LLM's strengths: recognizing the algorithmic intent behind obfuscated code and re-implementing it cleanly in the target language.

The Critical Prerequisite: Locating the Code Is Still on You

There's a prerequisite that's easy to overlook: AI acceleration only kicks in after a human has already located the relevant parameters. The creator is explicit about this: "If you can track something down to a specific location, there's no need to do what I did — just ask the model directly."

LLMs excel at local code restoration and translation (converting obfuscated JS into equivalent Python or JS logic), while request chain analysis and parameter location still require genuine reverse engineering expertise. This also explains why the same tools produce very different outcomes depending on who's using them.

It calls a function like fax further down

Two Approaches to Handling Obfuscated Code

The case also demonstrated handling the signet parameter (webpack-bundled + OB-obfuscated). Rather than relying on the LLM throughout, the creator used the traditional "environment patching + CryptoJS substitution" approach: importing the CryptoJS library, creating the corresponding crypto objects, and replacing key calls in the obfuscated logic.

Background on Environment Patching: Environment patching is a core technique in JavaScript reverse engineering. It involves simulating browser APIs (such as window, document, and navigator objects) in non-browser environments like Node.js so that obfuscated code can execute normally. Webpack-bundled code typically depends on a module loader and specific runtime objects; if the environment is incomplete, it will throw exceptions or even trigger anti-debugging logic. The difficulty of environment patching scales with how heavily the code depends on browser APIs — simple cases may only require a few basic objects, while complex ones may demand a full DOM tree and event system simulation. It's a meaningful dividing line between junior and senior reverse engineers. By contrast, substituting encryption calls with CryptoJS is a "bypass" rather than a "reconstruction" strategy — when you can identify that the target is using a standard crypto library, this approach is often far more efficient.

This illustrates that in real engineering work, AI and traditional methods are complementary, not mutually exclusive:

String array obfuscation and encryption algorithm translation: Hand to an LLM — extremely efficient;
Webpack loaders and complex runtime environment dependencies: Still require manual environment patching or substitution with established libraries.

A Sober Look at the "Tech Side Hustle" Market

The creator's candid remarks about the market at the end of the video are arguably the most thought-provoking part.

Pricing and the Reshaping of Value

He walked through a range of contracts, with prices spanning from under ¥300 to over ¥1,000, and warned that people unfamiliar with market rates often end up taking low-paying jobs — putting in a lot of work for just a few hundred yuan. This reflects a real dynamic: as AI lowers the barrier to entry in reverse engineering, it simultaneously drives down unit prices for simple reverse engineering work.

The creator put it plainly: "What used to go for ¥1,000 can now get done for ¥100–300." When an LLM can produce decryption code in minutes, entry-level reverse engineering work is rapidly losing value. The work that maintains high value is complex, high-difficulty tasks that require deep analysis and intricate environment reconstruction.

This mirrors a broader pattern in the software industry: the more a task becomes tool-assisted, the faster its market price falls; the ability to handle complex, non-standardized problems retains its value precisely because of its scarcity. For those who want to build a career in this area, deep expertise in complex scenarios — multi-layer nested obfuscation, custom encryption protocols, anti-debugging countermeasures — is the core moat against market devaluation.

Compliance Boundaries and Legal Risks

It must be stated clearly: reverse engineering a third-party website's encryption parameters and collecting non-public data carries real risks of violating terms of service, data security laws, and in some cases criminal statutes under Chinese law. The technical methods discussed in this article should be strictly limited to legitimate use cases:

Security testing of systems you own;
Authorized penetration testing;
Learning and research on cryptographic algorithms.

Using these techniques for unauthorized data scraping or commercial contracts may carry serious legal consequences. Technology itself is neutral — it's up to each practitioner to define their own boundaries.

Conclusion: LLMs Are Capability Amplifiers, Not Capability Substitutes

This case study clearly illustrates the actual role of LLMs in specialized technical work: they amplify existing capabilities rather than conjure capabilities from nothing. For developers who already have reverse engineering localization skills, AI can compress the most tedious code reconstruction work from hours to minutes. For those who lack the fundamentals, even with powerful tools, consistent high-value output remains elusive.

As AI capabilities continue to evolve, the value distribution of technical work is being reshuffled: low-complexity execution tasks are rapidly becoming commoditized, while analytical judgment and architectural design skills grow increasingly scarce. That may be the deepest lesson this case has to offer.