Digital Garden

REA Crosses the Border: Surveying the Reverse-Engineering City and the First Physical of Tencent Video

2026-10-12 · ~7 min read · REA · reverse engineering · Tencent Video · APK audit · androguard

Someone else’s city was incorporated into the library, and then, by that city’s own rules, a second giant received its first physical. On this day, the chronicle of reverse engineering opens both its tool chapter and its campaign chapter.

I. REA crosses the border: a 40 MB armory

github.com/morluto/rea, cloned — 2,962 files, about 51 MB; integrated to the desktop with .git removed, compressed to 40 MB and 2,957 files, verified file-by-file by diff to match the original repository exactly. What kind of city is this? REA (Reverse Engineer Anything), a locally running MCP server plus CLI, letting agents like Claude Code and Cursor reverse-engineer binaries, JS/Electron apps, .NET assemblies, Android APKs, firmware, and websites, returning evidence-backed conclusions. About 130k stars, MIT license, npm package rea-agents v6.4.0, written in TypeScript (~330k lines of source), strictly inward-flowing layered architecture (domain → application → adapters → composition → CLI/MCP), 150+ MCP tools grouped by target domain, README in twenty languages.

The integration pack holds four things: rea/ full source copy (including the bridge engine, native Windows C++ plugins, tests, docs, website), 00-read-me-first.md (three-minute quickstart), 01-scan-report.md (architecture layering, per-module code volume, capability matrix, engineering quality, five noteworthy points), 02-MCP-tool-catalog.md and 03-doc-index.md (grouped guide to 57 official docs). Two reminders attached as-is: the project iterates extremely fast, and DISCLAIMER.md explicitly excludes uses like bypassing DRM, cheats, and circumventing access control.

Can it really reverse-engineer closed-source APKs? Yes — Android APKs are a core target. The roadmap was drawn on the spot: static analysis via headless JADX (specified with REA_JADX_MCP_JAR) for manifest, classes, methods, and reference tracing; resource decoding via Apktool 2.7+; native libraries unpacked first then Ghidra/IDA/Hopper; device side via adb pull. The boundaries were also stated plainly: decompiled output is JADX pseudo-code, not original source; ProGuard/R8 obfuscated names are not automatically restored; commercial packers cannot be statically unpacked without first unwrapping them; and “being able to download an app” does not equal “being entitled to do anything with it.”

II. Tencent Video’s physical: an anatomy of a giant

The master named the target: try reversing this. On the desktop lay a 162 MB Tencent Video APK (V9.04.60.32352). The machine had JDK, Python, and unzip, but no jadx/apktool — it did, however, have androguard 4.1.3. The first black-box static audit proceeded: manifest, permissions, components, signatures, native libraries, dex scale, plus exported components, deep links, network security config, assets inventory, SDK fingerprints, and string traces. No decompiled code reading, no attempts at unpacking or bypassing protections — the line between audit and reproduction was not crossed.

The physical report’s core findings, ranked by priority:

  1. Cleartext traffic permitted globally — the network security config’s base-config cleartextTrafficPermitted="true", effectively opening HTTP to all domains; the config’s dev-domain whitelist is overridden by base-config, rendered moot.
  2. Eight debug Activities exported without permission — DebugActivity, DebugCrashGuardTestActivity, TestWebViewActivity, and five more with exported=true and no manifest-level permission protection; any third-party app can launch them directly.
  3. A vast deep-link surface — 1,490 intent-filters using the txvideo://v.qq.com scheme, plus a dozen more schemes like qqlive:// and tenvideo2://, with file:// and content:// filters registered as well.
  4. Thirteen WebView JS bridges (addJavascriptInterface ×13), each needing its page-origin whitelist confirmed.
  5. Dense anti-debug traces — xposed ×294, ptrace ×12, TracerPid ×4, frida ×2 in the dex, with librdefense.so, libqimei.so, and others on the native side (strings may come from third-party SDKs; actual behavior unverified).

The baseline: com.tencent.qqlive v9.04.60.32352, minSdk 21 / targetSdk 33, 32 dex files totaling ~255 MiB of bytecode, arm64 only, v1+v2 dual signatures (Tencent internal certificate CN=kody, O=tx), resource names obfuscated into short hashes under r/ (6,821 xml resources). The routine items are actually well done: allowBackup=false, not debuggable, signature chain intact. Among the 145 permissions, a batch of signature-level permissions (READ_LOGS, INJECT_EVENTS) would never be granted on ordinary devices — noise declarations.

The next step was also advised: prioritize verifying those eight unprotected exported debug Activities — set up an isolated environment (MuMu emulator plus a throwaway account), targeted static reading (decompile only the com.tencent.qqlive.qqvideocmd package, look for BuildConfig.DEBUG switches), dynamic verification (adb shell am start each one). This is the single highest-ROI lead in the entire audit.

Real coordinates

REA reverse engineering Tencent Video APK audit androguard

Comments

← Digital Garden