[KongchangAI]
· 2 min read· 1,203 words

Breaking Game Coordinate Encryption in One Hour with DeepSeek? A Real-World AI-Assisted Reverse Engineering Case Study

Breaking Game Coordinate Encryption in One Hour with DeepSeek? A Real-World AI-Assisted Reverse Engineering Case Study

A creator demos DeepSeek-assisted game encryption reverse engineering, revealing AI's real strengths and limits in code analysis.

A Bilibili creator claimed to reverse-engineer a game's coordinate encryption algorithm in about one hour using DeepSeek. Analysis shows this wasn't a one-click crack but a multi-round, human-AI collaborative workflow. AI excels at pattern recognition and pseudocode reconstruction but still depends on human debugging for runtime protections like anti-debug and integrity checks. The video raises credibility and compliance concerns, while pointing to a deeper trend: LLMs are systematically lowering the reverse engineering barrier, pushing developers toward server-side validation and defense-in-depth strategies.

A Controversial Demo: AI-Assisted Reverse Engineering

A Bilibili content creator recently published a video claiming to have reverse-engineered a game's coordinate encryption algorithm in roughly one hour using the Chinese large language model DeepSeekAd — and went on to publicly release what they called the "complete algorithm." The video sparked discussion due to its sensitive subject matter and sensationalized framing.

To be clear upfront: this article analyzes the phenomenon purely from the perspective of technical communication and AI capability discussion. It does not involve, endorse, or encourage any cheating or disruptive behavior targeting games. Using AI to assist in reverse-engineering anti-cheat systems or distributing cheat-related code very likely violates game terms of service and may cross legal boundaries. The focus here is strictly on the phenomenon of "AI-assisted code analysis" as demonstrated in the video.

AI-assisted model is DeepSeek

What the Video Actually Showed

According to the creator's narration, the analysis centered on several technical components: key management architecture, encryption function parsing, the logic for converting coordinate ciphertext back to plaintext, and identification of anti-debug mechanisms. The video repeatedly referenced terms like "Seed A," "Seed B," "shift mixing," and "subtraction mixing functions" — all pointing to a custom obfuscation scheme built on seeds and bitwise operations. This type of approach is fairly common in game data protection, designed to raise the difficulty of static reverse engineering.

Detection bypass mechanism found below

The creator emphasized using DeepSeek (mentioning what sounded like a lighter, Flash-style variant) rather than the high-end closed-source models more commonly referenced in the industry. This was framed as a rebuttal to the notion that "using a Chinese model means lower capability" — arguing that tool choice doesn't define the skill of the person using it. That point has some merit: while model capabilities do vary, with a clearly defined task, solid prompt engineering, and human verification, mid-tier models can handle a surprising range of practical analysis work.

Seed-and-bitwise obfuscation encryption is a common lightweight scheme in game data protection. The basic idea: one or more seed values initialize a pseudorandom sequence, which is then used to apply XOR, bit shifts, and addition/subtraction operations to sensitive data like coordinates — transforming plaintext into what appears to be random noise in memory or over the network. Unlike standard cryptographic algorithms such as AES, the security of these custom schemes relies entirely on keeping the algorithm details secret (i.e., "security through obscurity") rather than mathematical intractability. Once a reverse engineer recovers the seed generation logic and operation sequence, the entire protection collapses. This is why game developers typically layer on anti-debug mechanisms and code obfuscation as runtime defenses to raise the practical difficulty of reverse engineering.

Where AI Excels — and Where It Falls Short — in Reverse Engineering

Based on what the video revealed, the creator wasn't asking the model to "one-click crack" anything. Instead, the workflow involved multi-round iteration with sub-agents: references to "compressed once, fifty rounds" and "one sub-agent," along with an admission that "the breakpoint hit a bug" that required the model to specifically investigate. This actually reveals what AI-assisted reverse engineering looks like in practice — it behaves more like a tireless analysis assistant than a fully automated cracking engine.

Return edge discovered

AI's strengths in this kind of task are concentrated in a few areas: rapidly reading large volumes of disassembly or pseudocode, recognizing common encryption and obfuscation patterns, inferring function intent from variable names and control flow, and generating more readable reconstructed code. Its weaknesses are equally clear: hardware breakpoints and runtime protections like code integrity checks require actual execution environment feedback that AI simply cannot provide, leading to plausible-sounding but unverifiable inferences — exactly the "breakpoint bug" the creator ran into.

In other words, the genuinely hard part — bypassing runtime detection — still depends heavily on hands-on debugging experience. AI only helps accelerate comprehension. The "fifty rounds of compression" and "repeatedly sending the sub-agent to investigate" described in the video hint that this was far from the "breezy one-hour job" the title implies.

Anti-debug and code integrity check mechanisms represent a runtime protection layer in anti-cheat systems that operates on a fundamentally different level than static encryption obfuscation. Anti-debug techniques detect the presence of a debugger (e.g., IsDebuggerPresent calls, timing-based detection, reading hardware breakpoint registers) and trigger abnormal behavior or intentional crashes, preventing stable execution under analysis. Integrity checks compute hashes or checksums of critical code sections at runtime — if a breakpoint instruction (0xCC) or any other modification is detected in memory, the protection logic fires. What both have in common is strong dependence on the execution environment: they must be dynamically triggered and observed within a real process context. Since large language models can only analyze static disassembly text and cannot simulate actual runtime state, they face a fundamental limitation at this layer.

Taking a Sober Look at "World-First" Hype

Here is the complete algorithm

Videos like this tend to carry heavy clickbait energy — phrases like "insane," "fully open-sourced," and "world's first reveal" are standard traffic-bait. From a credibility standpoint, a few things warrant skepticism:

  • No verifiable evidence: The video relies primarily on narration and screenshots, with no reproducible complete logs. The "one hour" claim cannot be substantiated.
  • Loose use of terminology: The transcript contains numerous phonetic garbles and verbal slips that vaguely gesture at concepts like anti-debugging and integrity checks, raising questions about technical depth.
  • Legal and compliance risk: Publicly releasing a game's encryption algorithm or distributing code that bypasses detection mechanisms may constitute circumvention of software protection measures. Responsibility lies with both the distributor and the user.

The Trend That Actually Matters

Setting aside the video's specific controversies, it reflects a real shift underway: large language models are actively lowering the barrier to reverse engineering and code analysis. Pseudocode analysis that once took a senior engineer several days can now be significantly accelerated with AI assistance. This is a double-edged sword for the security community — white-hat researchers can find vulnerabilities and audit code faster, but malicious actors may also identify attack surfaces more quickly.

For developers, the implication is clear: code obfuscation and static encryption alone are increasingly insufficient against AI-assisted analysis. Runtime protections, server-side validation, and behavioral detection as part of a defense-in-depth strategy are becoming more critical. For general readers, the takeaway is to approach "AI cracking" hype with rational skepticism — neither uncritically impressed nor tempted to imitate — and to remain clear-eyed about the compliance boundaries involved.

Defense in Depth rests on the principle of never relying on a single protective layer, but instead stacking multiple mechanisms so that bypassing one doesn't hand an attacker complete access. In the game security context, this means moving critical logic like coordinate validation and behavioral anomaly detection to the server side, treating all client-submitted data as untrusted input by default — combined with behavior-layer detection such as speed/position plausibility checks and statistical models that identify anomalies based on effect rather than code. As AI-assisted reverse engineering makes static obfuscation increasingly penetrable, the architectural philosophy of "even if the client algorithm is fully recovered, the server will still detect anomalous behavior" offers more long-term value than continuously escalating client-side encryption complexity.

#DeepSeek#reverse engineering#AI-assisted code analysis#game encryption#anti-cheat#LLM security#defense in depth
Share:

Related articles