Reverse Engineering Community Abuzz! AI Tool REA in Action: APK Verification Code Reverse Engineering

Recently, an AI reverse engineering project called REA has become popular on GitHub, claiming to be able to "reverse engineer everything" and garnering 223k stars. This number is quite exaggerated and has sparked widespread discussion in the reverse engineering community. I watched a practical video by a Bilibili creator, who tested it with an APK software. The goal was clear: find out the generation logic of the login verification code, the algorithm used, and why it changes every 30 seconds. This article is based on this practical case and discusses what REA can actually do, how effective it is, and where its boundaries lie.

What is REA? What problem does it aim to solve?

The traditional APK reverse engineering process roughly involves first decompiling Java code with JDX (JADX), then using IDA to handle native libraries, and then manually searching for method names and strings, tracing up the call chain layer by layer. When the codebase is large, it's easy to get lost in the vast sea of classes and methods, and the conclusions reached often lack a traceable evidence chain.

REA is positioned as an analysis tool for reverse engineering. It can convert targets such as JADX decompilation results and native programs into searchable, traceable analysis objects, helping analysts quickly locate key code, sort out call chains, and retain key evidence for important conclusions. In short, it doesn't simply disassemble the APK for you to see, but attempts to answer "where is the functionality, how does data flow, and why is it judged this way."

JADX is an open-source Android decompilation tool that can restore DEX bytecode in an APK to readable Java source code, and supports resource file decoding, global search, call graph viewing, and other features. It is one of the most commonly used entry tools in Android reverse engineering analysis, usually used in conjunction with apktool (for resource decompilation).

IDA Pro is the industry-standard binary reverse engineering analysis platform, supporting disassembly and decompilation (Hex-Rays) for multiple instruction sets such as x86, ARM, MIPS, etc. It is commonly used to analyze native libraries (.so files) or standalone binary programs in APKs. In APK reverse engineering scenarios, when key logic is moved to the native layer, IDA is almost a must-have tool.

The division of labor between the two is clear: JADX is for the Java/Kotlin layer, and IDA is for the machine code layer. REA's positioning is not to replace them, but to unify their outputs into searchable, traceable analysis objects, reducing the cognitive cost of switching back and forth between layers.

In Practice: Letting REA Analyze an APK's Verification Code Logic

The creator prepared an APK software (taking a UK application as an example) and directly gave REA a prompt, asking it to answer three questions: where the verification code is generated, what algorithm is used, and why it changes every 30 seconds.

This process requires some waiting. During this time, the creator also mentioned that tools like JDX are still necessary—REA integrates some dirty work, but the underlying tools still need to be installed.

After waiting, REA completed the analysis of the entire project. From the analysis process it displayed, it located the complete verification code generation content by searching for clues such as propagated names and periodic phases. The analysis results showed that this APK uses the standard RFC 6238 TOTP algorithm (time-based one-time password), padding with zeros on the left when the result is less than 6 digits; it changes every 30 seconds because the HMAC value remains unchanged within the same 30-second window, and after crossing the boundary, the counter increments by one, and the HMAC result changes accordingly.

Several basic concepts are involved here: HMAC is a hash-based message authentication code algorithm, and TOTP is a time-based one-time password standard. For reverse engineering research, basic knowledge of hash algorithms and symmetric encryption algorithms is important; otherwise, even if the tool gives a conclusion, you may not be able to judge whether it is correct.

HMAC (Hash-based Message Authentication Code) is an algorithm that uses a cryptographic hash function (such as SHA-1, SHA-256) and a key to jointly compute a message authentication code, defined in RFC 2104. Its core structure is HMAC(K, m) = H((K ⊕ opad) ‖ H((K ⊕ ipad) ‖ m)), which can verify message integrity and source authenticity over insecure channels.

TOTP (Time-based One-Time Password) is defined in RFC 6238 and is a time-dimension extension of HOTP (RFC 4226). Its calculation method is: divide the current Unix timestamp by the time step (usually 30 seconds) to get a counter C, then compute HMAC-SHA1(K, C), extract a 31-bit integer through dynamic truncation, and take modulo 10^6 to get a 6-digit verification code. Since C remains unchanged within the same 30-second window, the HMAC output remains unchanged, and the verification code remains stable; after crossing the window boundary, C increments by one, and the verification code refreshes accordingly. Understanding these two RFCs is the foundation for judging whether REA's conclusions are correct.

Analysis Report and Interactive Demo

REA generated an analysis report, which traces the call chain, finds the corresponding code locations, and shows the 30-second switching mechanism and the reasons for the judgment, with specific evidence attached. This is more user-friendly than traditional manual analysis—the conclusions are not pulled out of thin air, but supported by code locations and call relationships.

More practically, it also generated a demo page. The page can generate the current verification code and automatically switch after 26 seconds; you can modify the calculation time and adjust the period, and the verification code will change accordingly. In the video, the creator demonstrated the linked changes in the verification code after modifying the algorithm parameters and period. This interactive verification is very helpful for understanding the algorithm logic.

REA's Boundaries: Don't Be Fooled by "Reverse Engineer Everything"

At the end of the video, the creator gave a fairly practical assessment: REA doesn't simply disassemble the APK, but helps analysts find key paths from massive code and uses traceable MD files to tell you the reasons and evidence boundaries. When analyzing some software without particularly high-strength verification, it is indeed very useful.

But for software involving high-strength verification, REA is not as exaggerated as advertised. This judgment is worth taking seriously—AI reverse engineering tools are good at accelerating information retrieval and call chain sorting, but in the face of obfuscation, hardening, anti-debugging, and other countermeasures, human intervention is still required. Tools can lower the threshold, but they cannot replace understanding of underlying principles.

Significance for Reverse Engineering Practice

The emergence of tools like REA reflects a trend: AI is moving from "generating code" to "understanding code," and reverse engineering is exactly an extreme scenario of understanding code. It integrates scattered decompilation tools, search capabilities, and evidence chain management into an interactive interface, allowing analysts to focus on judgment and verification rather than repetitive search labor.

However, we should also be clear-headed: the number 223k stars needs to be viewed with caution (mentioned in the video; specific data should be based on GitHub actuals). Popular projects are often accompanied by hype. What truly determines a tool's value is its stable performance on different hardened samples and the verifiability of its analysis conclusions. For security researchers, REA can be included in the toolbox as an efficiency tool, but core algorithm knowledge, understanding of system fundamentals, and countermeasure experience remain irreplaceable.

Background Supplement

In the context of Android reverse engineering, obfuscation (e.g., ProGuard/R8 replacing class names and method names with meaningless short identifiers), hardening (e.g., Bangcle, Ijiami encrypting DEX with a shell and dynamically decrypting at runtime), and anti-debugging (detecting ptrace, debugger ports, emulator environments, etc.) are the three most common countermeasures. They significantly disrupt the readability of static analysis and the integrity of call chains: obfuscation makes name searches ineffective, hardening makes decompilation results incomplete, and anti-debugging interferes with dynamic analysis. When facing these measures, AI tools often can only provide partial clues rather than complete conclusions, which is exactly where human intervention is needed for judgment and verification.

One-line Summary

REA uses AI to accelerate APK reverse engineering and successfully recovers TOTP verification code logic, but high-strength hardening still requires human effort.

Paragraph Summary

Based on a practical video by a Bilibili creator, this article introduces REA, an AI reverse engineering tool on GitHub that claims to "reverse engineer everything." REA converts JADX decompilation results, native programs, etc. into searchable, traceable analysis objects and retains evidence chains. In practice, the creator asked REA to analyze the login verification code logic of an APK, and REA successfully located the standard RFC 6238 TOTP algorithm, explained the 30-second period mechanism, and generated an analysis report with call chain tracing and an interactive demo page. However, the article also points out REA's boundaries: when facing high-strength countermeasures such as obfuscation, hardening, and anti-debugging, its effectiveness is far less exaggerated than advertised and still requires human intervention. The conclusion is that AI reverse engineering tools excel at accelerating retrieval and call chain sorting, but cannot replace understanding of underlying principles and countermeasure experience, and the 223k stars figure should also be viewed with caution.