reversing-react-native-apps

逆向分析 React Native 应用

React Native 应用是披着原生外壳的 JavaScript。这是个好消息——应用逻辑会以 bundle 的形式打包发布，你可以直接阅读；除非 bundle 被编译成 Hermes 字节码，这种情况下你需要反编译器，而版本兼容问题会成为整个任务的核心。

适用场景

• jadx 显示 ReactActivity、ReactNativeHost，但几乎没有应用逻辑
• APK 包含 assets/index.android.bundle 或 lib/*/libhermes.so
• IPA 包含 main.jsbundle
• 你需要在 RN 应用中查找 API 端点、密钥或业务逻辑
• 你需要修补或 Hook JavaScript 层的行为

不适用场景

• Flutter（libapp.so、libflutter.so）——使用 reversing-flutter-apps
• Unity（global-metadata.dat）——使用 reversing-unity-il2cpp
• 原生 Java/Kotlin 应用——使用 testing-mobile-applications
• 用 C/C++ 编写的原生模块——使用 analyzing-binaries

识别 Bundle 格式

这项检查决定了任务耗时是 10 分钟还是一天。

unzip -j target.apk 'assets/index.android.bundle' -d ./out
file ./out/index.android.bundle
xxd ./out/index.android.bundle | head -2

起始字节	格式	路径
可读的 JS（var __BUNDLE_START、__d(function）	纯 JavaScript	美化格式后直接阅读
二进制，Hermes 魔数（c6 1f bc 03，小端序）	Hermes 字节码	反编译——见下文

# Plain bundle: beautify, then it reads like any minified web app
npx js-beautify index.android.bundle -o bundle.js
rg -n 'https?://|api[_-]?key|Bearer |secret|token' bundle.js | head -50

纯 bundle 就像一份大礼。模块边界会以 __d(function(...) 注册的形式保留下来；有时还会意外附带 source map（index.android.bundle.map——务必检查），整个应用逻辑都清晰可见。

Hermes 字节码

Hermes 会将 JS 编译为自己的字节码（HBC）。字节码版本嵌入在文件头中，并且会随 React Native 版本变化。这是实际操作中最大的障碍：支持 HBC 74 的工具会拒绝处理 HBC 96，或错误解析它。

# Read the version out of the header before choosing a tool
hbctool disasm index.android.bundle ./disasm     # HBC 59, 62, 74 ONLY
hermes-dec ...                                    # decompiler; wider version support

上游 hbctool 只支持 3 种字节码版本——59、62 和 74。其他版本都会在解析时失败。先检查文件头中的版本，不要把解析错误误认为“bundle 受到了保护”；对于当前的 React Native 版本，字节码版本通常会高于 74，此时应使用 hermes-dec，或使用与相应 Hermes 标签匹配的 hermesc 构建版本。

工具	提供内容	注意事项
hbctool	反汇编和重新汇编——你可以修补并重新打包	支持的 HBC 版本有限
hermes-dec	反编译后的伪 JavaScript	只读；输出为近似结果
hasmer	反汇编/汇编，支持其他版本	hbctool 不支持该版本时可以尝试

如果所有工具都拒绝处理该版本，可靠的备用方案是根据应用使用的 React Native 版本构建相应的 hermesc，并使用其工具链。这个方法更慢，但版本匹配正确。

如何利用输出。 即使反编译并不完美，也足以回答关键问题：字符串表会完整保留，因此可以直接找回端点、密钥和功能标志：

strings -n 6 index.android.bundle | rg -i 'https?://|api|token|secret|firebase' | sort -u

Hermes 字符串表是文件中一段平坦、可读的区域。先查看它，再进行反编译——它通常能直接解答问题。

运行时分析

在 RN 应用上使用 Frida 往往比静态分析更快，因为关键边界在于 JavaScript 调用原生代码的位置。

# Enumerate the native modules the JS side can reach
frida -U -f com.target.app -l rn-enumerate-modules.js

# Hook the bridge: every JS↔native call, with arguments
# (target the ReactNative bridge / TurboModule dispatch)
objection -g com.target.app explore

值得 Hook 的位置：JS 运行时中的 fetch/XMLHttpRequest、原生网络模块（Android 上为 OkHttp——可使用标准的证书固定绕过方法进行 Hook）、AsyncStorage 的读取和写入，以及应用定义的任何 NativeModules.*。

这里的 TLS 拦截很常见——与 Flutter 不同，RN 使用平台的 HTTP 栈，因此常见的系统 CA 加代理设置即可生效，也适用标准的证书固定绕过方法。如果拦截失败，应怀疑原生模块中的证书固定，而不是单独的信任存储。

常见问题所在

React Native 应用中常见的问题主要集中在以下几类：

• 包中包含密钥。 API 密钥、Firebase 配置和第三方令牌被打包进 JS，理由是“代码已经编译了”。Hermes 并不提供加密。
• 客户端授权。 角色检查和功能门控在 JS 中实现，很容易被修改，或直接调用 API 绕过。
• 将 AsyncStorage 用作凭据存储。 默认不加密；令牌和个人身份信息经常被存储在其中。
• 权限过大的原生模块。 自定义桥接方法向 JS 暴露文件系统或 Shell 访问能力，任何注入的脚本都可以调用。
• 调试文件。 Source map、开发模式包和 console.log 输出遗留在发布版本中。

修补和重新打包

hbctool disasm index.android.bundle ./work
# edit ./work/instruction.hasm and ./work/metadata.json
hbctool asm ./work index.android.bundle.patched
# replace in the APK, then re-sign
apktool b target -o patched.apk && apksigner sign --ks debug.keystore patched.apk

只修补必要的部分，并且必须获得授权。重新打包会触发加固应用的完整性检查；如果应用会验证自己的包，应钩住该检查，而不是通过编辑来绕过它。

应当摒弃的自我安慰

• “包是二进制文件，所以逻辑受到了保护。” Hermes 是编译器，不是保护机制。光是字符串表通常就会暴露 API。
• “jadx 什么也没找到，所以代码被混淆了。” dex 中什么也没有。去 assets/ 里找。
• “没有工具支持这个 HBC 版本，走不通了。” 使用对应 React Native 版本构建 hermesc，或读取字符串表。
• “密钥只在客户端使用。” 它在包中，所以是公开的。将包中的每个密钥都视为已泄露。
• “应用会强制执行角色检查。” 应用就是客户端。绕过角色检查调用 API，在服务端验证该检查。

参考资料

• testing-mobile-applications — 更广泛的评估、存储和平台问题
• testing-apis — 后端，真正的问题都在这里
• reversing-flutter-apps — 另一个常见的跨平台框架
• hbctool、hermes-dec、hasmer、Frida/objection、jadx、apktool