APK逆向侦察实战3步快速识别加壳、SDK与代码真实位置apk-reverse完整指南【免费下载链接】apk-reverseSuitable for Android APK reverse engineering analysis项目地址: https://gitcode.com/gh_mirrors/ap/apk-reverse拿到一个 APK是先反编译乱翻还是先花 10 分钟侦察apk-reverse这个开源逆向工程技能库的答案是后者——它的核心理念是侦察阶段花掉的 10 分钟能防止后面几小时的错误工作。这篇文章带你走完这套侦察实战流程识别是否加壳、清点内置 SDK、定位代码真实位置让你动刀之前就知道自己在面对什么。为什么侦察是 APK 逆向的第一课 逆向新手最常犯的错误是跳过侦察直接开干。典型后果有几种对加壳应用直接改 dex改完发现应用根本跑不到你改的代码白忙数小时误判代码位置以为代码在 dex 里实际是 Flutter / Native工具链完全用错没分清 SDK 归属把广告 SDK 自带的检测逻辑当成应用自己的防篡改方向直接跑偏apk-reverse仓库里的 recon.md 把侦察拆成了可执行的问题清单本文按这个清单逐步展开。准备工作先跑环境体检脚本侦察前建议先跑一次环境体检确认你手头工具链是完整的。apk-reverse提供了开箱即用的体检脚本python skills/apk-reverse/scripts/doctor.py它会报告哪些工具已安装、哪些脚本可以实际运行、你的环境里是否存在会污染实验结果的因素时钟偏差、残留的代理转发等。详见 doctor.py 的脚本说明以及 toolchain.md 中对工具不在 PATH ≠ 没安装这类坑的讲解。第一步确认应用身份Identity侦察的第一个产出是应用身份档案包名、版本号、min/target SDK、权限列表、声明的组件。新手最容易踩的坑不要从二进制 manifest 里肉眼抠包名。真实的 AXML 字符串表里充满了长得像包名的类名碎片——recon 文档里记录过一个真实案例手动解析看到com.app.offline其实是服务类前缀而真实包名是com.vendor.app。包名搞错后面所有pm list packages、/data/data/pkg命令全部扑空你会误以为工具坏了。正确做法是双源交叉验证要求两个独立来源结果一致来源命令取什么ddc单文件 dex 反编译工具无 JVM 依赖ddc info app.apkpackage、label、launcherAndroid SDK 的aaptaapt dump badging app.apk \| head包名、版本、权限⚠️ 两者不一致时先解决分歧再继续否则整个侦察都会走偏。记录下来的最小身份档案包名 / 版本名 / versionCode / min target SDK / 主要权限。第二步判断是否加壳Packer 识别实战️加壳是补丁看起来完全正确却毫无效果的头号原因packers.md 把它当成独立阶段来处理。核心手法看 manifest 里的application android:name再用文件大小和结构佐证——而不是靠猜名字。一张表看懂加壳特征你看到的迹象结论application指向应用自己的类如com.example.app.App未加壳dex 可直接编辑厂商壳类com.stub.StubApp、com.secneo...、com.tencent.StubShell等已加壳需要先脱壳无意义短名如com.bc41appComponentFactory指向另一个短类dex 级全量壳壳用与应用无关的名字注册自己的 Applicationclasses.dex只有几十 KB 且全是壳类真实代码不在磁盘上lib/abi/下有libDexHelper.so、libjiagu*.so、libshell*.so壳的 native 部分负责解密加载 payloadassets/下有大型高熵 blob甚至伪装成 JPEG魔数合法但解不出图加密的 payloadassets/里有第二个.apk或.jar包装/加载器型构建配合一条命令看大小分布快速形成直觉unzip -l app.apk | sort -k1 -n | tail -20最大的几个条目是什么是 assets 大 blob、是 native 库、还是正常的 dex——答案本身就是一条关键证据。两个容易误判的场景干净形态也是结论application是自己的类、单个正常 dex、没有 native 库——直接记下未加壳这一行证据就继续。多数真实目标就是这种形态明确记录下来可以防止后续步骤反复重开这个问题。未加壳 ≠ 可编辑还有一类隐形加固Application是自己的、dex 完全可读但整类被改成native声明、私有加载器带着内嵌校验 payload。这个形态的完整识别方法见 code-virtualization-and-custom-linkers.md而Java2C 还是提取壳的区分表在 java2c-and-jni-sinking.md。脱壳后如何确认真实 dex如果你确认目标加壳并完成了内存 dump不要相信任何单个 dump 文件。dex_dump_validate.py 可以帮你去重、校验 header 完整性、用空壳函数体比例区分真实 dump 和提取壳骨架。人工检查的最小规则按内容哈希去重绝不按文件大小同大小不等于同内容校验dex\n魔数、file_size字段与真实大小一致用业务包前缀命中数识别哪个 dump 是应用自己的 dex业务 dex 会同时命中应用包名几百次和广告 SDK 前缀几千次纯 SDK 插件 dex 则零命中应用包名python skills/apk-reverse/scripts/dex_strings.py dump_dir --find Lcom/example/app/ --per-file第三步定位代码真实位置框架识别速查表️代码在哪决定了后面用什么工具链。recon 文档给出了这张速查表包内特征代码位置普通classes*.dex应用类可见Dex——可用 dexlib2/smali 补丁libflutter.solibapp.soFlutter (Dart AOT)——dex 里只有薄壳libil2cpp.soassets/bin/Data/Unity (IL2CPP)——nativelibmono*.soassets/bin/Data/Managed/Unity (Mono)——assets 下的托管 DLLlibreactnativejni.soassets/index.android.bundleReact Native——assets 下的 JS bundlelibhermes.soHermes 字节码几乎所有逻辑都在.so里Native——完全不同的工具链对 Kotlin/Java 应用还有一步省时技巧找出应用代码在哪个 dex 文件里。多 dex 应用中应用代码往往只占其中一两个其余都是 SDK。定位之后重打包时通常只需替换一两个 dex 文件把改动面压到最小。深入阅读Flutter 场景下哪一层拥有 UI、无符号时怎么找逻辑framework-runtimes.mdDart AOT 的版本对齐、对象池与定位方法dart-aot.md哪些 ABI 和库真正被加载并执行而不是看 manifest 说什么native-and-so.md配合 lib_map.py 查看进程实际映射第四步SDK 与库清点 用一条命令跨所有 dex 提取字符串、按厂商标记分组一次看清广告、统计、崩溃上报、归因和防篡改 SDKpython skills/apk-reverse/scripts/dex_strings.py dex_dir --find anythink|openadsdk|com.qq.e|umeng|buglydex_strings.py 无需反编译器即可工作dex 字符串是明文 MUTF-8直接扫原始字节即可秒级出结果。常见厂商标记速查类别典型标记广告网络/聚合openadsdk、TTAdSdk、Pangle、com.qq.e、GDTAd、anythink、ksad、mobads、sigmob统计/崩溃/归因umeng、bugly、crashsdk、appsflyer、adjust身份/设备 IDoaid、msa、SupplementaryDID防篡改/root/hook 检测libsgcore、libInno、libqmcheat以及frida、xposed、magisk等字符串媒体栈libmpv、libavcodec、libplayer⚠️ 重要原则字符串 ≠ 行为recon 文档特别强调一条容易误判的规则字符串表里出现厂商标记不代表应用真的启用了该功能。frida、xposed这类字符串经常只是某个 SDK 自带的检测列表。一切以运行时的行为证据为准判断方法见 verification.md。顺带记录签名与 API 表面 侦察收尾时再花两分钟把这两项也记下来能帮你避开后面的大坑签名/防篡改检查只在应用自己的包里搜getPackageInfo、signatures、checkSignature这类关键词。注意误报——okhttp3内部就有SuppressSignatureCheck、verifySignature那是 TLS 基础设施不是防篡改。确认是否应用代码在调用它如果只有库内部引用就与你无关。API 表面python skills/apk-reverse/scripts/dex_strings.py dex_dir --urls一次性收集 base URL、CDN 主机、路径常量。留意两种模式动态网关真实 API 主机在运行时获取如 DoH 查 DNS TXT 记录dex 里的硬编码主机只是回退弱请求签名认证只是Authorization: Bearer加静态头说明重打包客户端在请求层面无法被服务器区分——这对后续判断服务器端还是客户端说了算很关键侦察输出模板写下来才算完成 ✅apk-reverse要求动刀前必须有一份文字档案recon.md 给出最小模板最小内容如下包名 / 版本 / ABI 是否加壳附证据 如加壳壳家族、脱壳方法、保留的 dump sha256 代码位置dex / flutter / native 应用代码在哪些 dex 文件 广告 SDK 及应用的封装类 统计/崩溃 SDK 防篡改存在吗在哪应用侧还是库内部 API base 关键端点 设备计划root 真机 / 模拟器 / 仅静态这份档案的价值在于每个结论都带证据后面的补丁决策、失败归因都要回溯到这里。配合 SKILL.md 中的四道门G1–G4侦察证据是分内之事而不是可选项。延伸阅读 主题文档侦察全流程本文依据recon.md 与 recon.md加壳/加固深入packers.md脱壳后 dump 校验advanced-unpacking.md失败案例目录必读pitfalls.md证据记录与验证矩阵docs/tool-verification/README.md基准测试回归矩阵tests/benchmark.md总结用三句话回顾 apk-reverse 的侦察方法论10 分钟换几小时身份、加壳、代码位置、SDK 四项侦察先做完再决定动手方案证据优先于直觉双源验证包名、按大小和结构判壳、按行为而非字符串下结论写下来一份带证据的侦察档案是后续每一步失败归因的锚点掌握这套流程你就能在逆向任务的起点建立正确的地图——这正是一个好的逆向工程师和一个只会点反编译按钮的人之间的差距。【免费下载链接】apk-reverseSuitable for Android APK reverse engineering analysis项目地址: https://gitcode.com/gh_mirrors/ap/apk-reverse创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考