简介本资源是一个基于Python的APK静态与动态分析工具集面向Android安全研究人员、逆向工程师及移动应用安全学习者旨在提供轻量级、可扩展的自动化分析能力解决APK权限检测、敏感API识别、组件导出分析、恶意行为初筛等典型安全评估需求。压缩包共46个文件含20个核心Python脚本如static.py、parseDex.py、gen_cm_perms.py等覆盖DEX解析、Manifest提取、敏感方法匹配、权限映射生成等功能、20个.dlist规则列表用于定义敏感API、危险权限、恶意行为特征以及shell脚本、配置文件和说明文档整体仅280KB便于快速部署与二次开发。目前已有773人学习下载资源结构清晰、模块职责明确附带README.md与完整配置体系读者可直接运行工具链完成APK解包→签名验证→静态特征提取→敏感行为标记全流程是入门Android安全分析并构建自有检测脚本的实用起点。1. apkanalysis 不是万能钥匙它真能替代你手动点开 APK 看 manifest 吗去年帮某高校实验室做安卓应用安全基线评估时我手头堆着三百多个教育类 APK要快速筛出哪些偷偷申请了READ_SMS、哪些在后台拉起AccessibilityService、哪些把密钥硬编码进strings.xml。当时第一反应就是扔进 apkanalysis——毕竟名字里带着“analysis”又标榜“静态动态”听起来像把瑞士军刀。结果跑完第一轮发现它连最基础的android:debuggabletrue都漏报了两成更别说对混淆后的R.string.xxx引用链还原失败。后来我才明白apkanalysis 的定位不是“全自动审计平台”而是“帮你省掉重复解包、反编译、grep 的体力活”的脚手架。它不替你思考漏洞逻辑但能把你从unzip -q app.apk -d tmp jadx -d tmp/classes grep -r getSystemService tmp/classes这套流程里解放出来。这篇就带你实打实拆开它它到底在哪个环节替你省力在哪种场景下会翻车如果你正卡在“想批量看几百个 APK 的权限声明但不想写 shell 脚本”或者“想验证某个加固壳是否真的隐藏了 native 层 JNI 函数调用”那它值得你花两小时搭起来但如果你指望它一键输出 CVE 编号和 PoC建议立刻关掉页面去补补 Android 权限模型和 ART 加载机制。2. 静态分析能力拆解它怎么读 manifest、smali 和 resourcesapkanalysis 的静态分析模块不是黑匣子它的核心逻辑非常直白把 APK 当作 ZIP 包解压按标准目录结构提取关键文件再用 Python 做文本/结构化解析。它不依赖 JADX 或 dex2jar 做完整反编译所以速度快、内存占用低但也意味着它看不到 Java 层的语义逻辑。我一般会先用apktool d app.apk -o out手动解包一次对照着看 apkanalysis 的输出是否对得上——这是判断它是否被加固壳干扰的第一步。2.1 Manifest 解析权限、组件、SDK 版本全靠它apkanalysis 会解析AndroidManifest.xml经 apktool 反编译后的 XML提取三类关键信息权限声明不仅抓uses-permission还会检查android:protectionLevel比如识别出WRITE_EXTERNAL_STORAGE在 targetSdkVersion ≥ 30 时已废弃四大组件导出状态重点标记android:exportedtrue且未设android:permission的 Activity这类是典型的组件暴露风险点SDK 兼容性自动计算minSdkVersion、targetSdkVersion并提示是否启用android:hardwareAccelerated影响 WebView 渲染安全性。提示它不会解析meta-data里的自定义配置比如某 SDK 的初始化参数。这类内容需配合resources.arsc解析或手动检查。2.2 Smali 层扫描正则驱动的“关键词狩猎”静态分析的 smali 模块本质是grep的增强版。它预置了 57 条正则规则存于rules/smali_rules.json覆盖常见高危模式invoke-static \{.*\}, Landroid/telephony/TelephonyManager;-getDeviceId\(\)Ljava/lang/String;→ 识别 IMEI 采集const-string v\d, https?://.*→ 提取硬编码 URL注意不处理字符串拼接如https:// host会漏invoke-virtual \{.*\}, Landroid/app/Activity;-startActivity\(→ 统计隐式 Intent 调用频次。这些规则可自由增删。我曾为某金融类项目新增一条匹配Ljavax/crypto/spec/SecretKeySpec;-init后紧跟Ljavax/crypto/Cipher;-init用于定位硬编码 AES 密钥——改完规则文件重跑命令即可生效不用碰 Python 代码。2.3 Resources 解析strings.xml 和 arsc 的边界在哪里strings.xml解析是它的强项能准确提取所有string标签内容并关联到res/values/strings.xml的原始行号。但resources.arsc二进制资源表仅做基础解码只输出资源 ID 到名称的映射如0x7f040001 → app_name不还原字符串值本身。这意味着如果开发者把敏感字符串存在res/values-zh/strings.xml里apkanalysis 能扫到但如果存在resources.arsc的字符串池中某些加固方案会这么做它就完全不可见。我遇到过一个案例某 APK 的 API 密钥被编译进 arsc 的bag类型资源apkanalysis 输出里干干净净最后靠axmlprinter2手动 dump arsc 才揪出来。3. 动态分析模块真相它根本没跑真机只是“模拟执行”很多人看到“动态分析”就默认要连手机、装 Frida、抓 HTTPS 流量。但 apkanalysis 的动态模块dynamic_analyzer.py压根不接触真实设备——它用的是Android Runtime 的字节码模拟器基于 androguard 的 DEX 解析器在 Python 进程内“走一遍” Dalvik 指令流。这带来两个关键事实第一它无法触发 native 层代码so 库、无法响应系统回调如onResume、无法处理多线程竞争第二它只分析Application.onCreate()和Activity.onCreate()的初始执行路径不支持用户交互后的分支逻辑。3.1 模拟执行流程从 DEX 到方法调用链当你执行python dynamic_analyzer.py --apk app.apk --entry MainActivity它实际做三件事用 androguard 加载classes.dex构建 CFG控制流图从MainActivity.onCreate方法开始逐条解析invoke-*指令记录调用栈对每个被调用的方法检查其签名是否匹配预设的“敏感 API 列表”如android.util.Log.e、android.telephony.TelephonyManager.getLine1Number。这个过程不运行任何 Java 字节码只是静态遍历指令。所以它快单个 APK 平均 8 秒但也注定漏报比如方法 A 调用 BB 内部有if (flag) { Log.e(...) }而 flag 的值由网络请求决定——apkanalysis 就不会进入那个if分支。3.2 敏感 API 检测清单哪些能抓哪些注定失效它的敏感 API 列表rules/dynamic_api.json分三级Level 1必报无条件触发如android.app.Activity.startActivityLevel 2条件触发需参数含特定字符串如android.content.Context.getSharedPreferences要求第二个参数含secureLevel 3不支持明确标注NOT_SUPPORTED包括所有android.webkit.WebView相关方法因涉及 JSBridge 交互纯模拟无法覆盖。我测试过 42 个含 WebView 的 APKapkanalysis 对addJavascriptInterface的检出率是 0%——这不是 bug是设计使然。这时候必须切到真机环境用adb logcat | grep JSInterface或 Frida hook。3.3 动态报告的可信度如何交叉验证它的结论它的动态报告JSON 格式包含call_stack和sensitive_apis字段。但别直接信。我的交叉验证法Step 1用jadx-gui打开 APK定位报告中提到的MainActivity.onCreate人工确认该方法是否真调用了TelephonyManager.getDeviceIdStep 2若报告说“未调用”但你怀疑有反射调用用grep -r getDeclaredMethod out/smali/搜 smaliStep 3对 Level 2 的条件触发项检查参数是否真满足条件——比如它报getSharedPreferences(config, MODE_PRIVATE)是 Level 2但参数config不含secure实际应不报。这三步做完你对报告的信任度才从 60% 涨到 90%。记住动态模块的价值不在“发现新漏洞”而在“快速排除明显风险”。4. 避坑指南那些让我重启三次 Python 解释器的典型问题用 apkanalysis 最痛苦的不是功能缺失而是它用 Python 2/3 兼容性、APK 结构变异、规则引擎耦合度高等问题把简单任务变成调试现场。以下是我在 17 个不同加固方案、32 个 targetSdkVersion 跨度16~34的 APK 上踩出的血泪坑按“现象→原因→解决”列清避免你重蹈覆辙。4.1 现象UnicodeDecodeError: utf-8 codec cant decode byte 0xff in position 0原因APK 中resources.arsc或AndroidManifest.xml被加固工具修改了编码如用 GBK 替换 UTF-8而 apkanalysis 默认用open(file, r, encodingutf-8)读取。解决修改static_analyzer.py第 89 行将encodingutf-8改为encodinglatin-1兼容所有字节或提前用iconv -f gbk -t utf-8 AndroidManifest.xml manifest_utf8.xml转码。4.2 现象AttributeError: NoneType object has no attribute getElementsByTagName原因APK 使用了split APK结构如base-master.apkconfig.xx.apk但 apkanalysis 只处理单个 APK 文件AndroidManifest.xml在 base 包里其他 split 包没有导致解析时dom对象为 None。解决用bundletool build-apks合并所有 split APK 为单个 universal APK再喂给 apkanalysis或修改manifest_parser.py增加对split目录的遍历逻辑需重写get_manifest_path()函数。4.3 现象动态分析卡在Loading DEX...超过 5 分钟无响应原因APK 被 VMP 或腾讯云加固DEX 文件被加密androguard 无法正确解析字节码陷入无限循环解密尝试。解决先用dexdump -d classes.dex | head -20检查 DEX 头是否异常正常应有dex\n035\x00若异常用dd ifclasses.dex bs1 skip0x1000 ofdecrypted.dex手动跳过加密头再传给 apkanalysis。4.4 现象smali_rules.json新增规则后不生效原因规则文件被缓存或 JSON 格式错误如末尾多逗号、中文引号Pythonjson.load()报错但被静默吞掉。解决在static_analyzer.py的load_smali_rules()函数开头加print(Loading rules from:, rule_path)并在try-except块里print(e)确保规则 JSON 用在线校验工具如 jsonlint.com验证。4.5 现象报告中permissions字段为空但aapt dump permissions app.apk显示有权限原因aapt版本与 APK targetSdkVersion 不匹配如用 aapt2 解析 targetSdk21 的 APK 会漏权限。解决统一用aapt1Android SDK Build-Tools 28.0.3 附带或改用androguard的APK类直接读取manifest的uses-permission节点需修改manifest_parser.py的权限提取逻辑。5. 实战对比apkanalysis vs 手动分析 vs 商业工具什么场景选谁光说原理不够得看它在真实工作流里站什么位置。我拿某教育类 APKtargetSdk33使用 360 加固含 native so做了三组对比分析耗时、关键风险检出率、人力成本。表格里数字是三次测试的平均值单位为秒/百分比。分析维度apkanalysisv2.3.1手动分析JADX grep aapt商业工具某国产移动安全平台 v5.2解包 manifest 解析4.2s18.7s2.1s权限声明完整性92.3%漏 2 个自定义 permission100%98.1%硬编码 URL 检出率67.5%漏拼接字符串100%89.4%Native so 符号表分析0%不支持100%readelf -Ws libxxx.so100%AccessibilityService 检测100%manifest 层100%100%单 APK 总耗时12.8s217s约 3.6 分钟8.3s100 个 APK 批量处理21m13s并行 4 进程36h无法并行需人工干预14m52s需购买并发 license从表里能看出清晰的分工逻辑选 apkanalysis当你要在 CI/CD 流水线里加一道“基础合规门禁”比如“禁止 targetSdk 30”、“禁止 debuggabletrue”它 12 秒给出报告脚本一跑就是一百个必须手动分析当你接到通报说“某 APK 存在热更新后门”需要逆向libxxx.so里的JNI_OnLoad函数看它是否下载并dlopen远程 so——apkanalysis 连 so 文件都懒得解压买商业工具当甲方要求出具等保 2.0 报告需要自动生成“风险等级-处置建议-截图证据”三件套且法务要求责任可追溯商业工具带操作日志审计这时 apkanalysis 的纯文本报告就不够看了。我现在的标准动作是先用 apkanalysis 过一遍全部 APK生成 CSV 报告按high_risk_count排序再对 top 10 高风险 APK用 JADX 深度分析 Frida 动态验证。这样既保证覆盖面又不失深度。6. 我的定制化改造让 apkanalysis 成为你的专属分析流水线原版 apkanalysis 是个好用的螺丝刀但真正干活得把它焊进自己的流水线里。过去半年我在三个项目中做了这些改造每一步都经过生产环境验证现在分享给你直接抄作业。6.1 增加 Gradle 构建产物自动接入能力原版只能分析本地 APK 文件但我们 CI 流水线产出的是app-release-unsigned-aligned.apk且每次构建版本号不同。我加了一个gradle_hook.py# gradle_hook.py import os import re import subprocess def find_latest_apk(build_dir): # 匹配 app-*.apk按修改时间取最新 apks [f for f in os.listdir(build_dir) if f.endswith(.apk)] if not apks: raise FileNotFoundError(No APK found in build dir) latest max(apks, keylambda x: os.path.getmtime(os.path.join(build_dir, x))) return os.path.join(build_dir, latest) if __name__ __main__: build_dir ./app/build/outputs/apk/release/ apk_path find_latest_apk(build_dir) print(fFound APK: {apk_path}) # 调用 apkanalysis 主程序 subprocess.run([python, apkanalysis.py, --apk, apk_path, --output, report.json])把它塞进 Jenkins 的 Post-build Steps每次构建完自动触发分析报告存入 Nexus 仓库。从此再也不用手动下载 APK。6.2 输出格式升级从 JSON 到可审计的 Markdown 报告原版 JSON 报告给开发看太晦涩。我用pandoc和 Jinja2 模板生成 Markdown# report_template.md.j2 ## 安全分析报告{{ apk_name }} - **构建时间**{{ build_time }} - **风险摘要** {% for risk in high_risks %} - {{ risk.type }}{{ risk.description }}位置{{ risk.location }} {% endfor %} ### 权限详情 | 权限名 | 保护等级 | 是否危险 | |--------|----------|----------| {% for perm in permissions %} | {{ perm.name }} | {{ perm.protection }} | {{ ✅ if perm.is_dangerous else ❌ }} | {% endfor %}用 Python 渲染后转 PDFpandoc report.md -o report.pdf --pdf-enginexelatex。法务部说这份报告可以直接归档。6.3 规则引擎热加载不重启服务更新检测逻辑原版改smali_rules.json要重启进程。我用watchdog库监听规则文件变化# rule_watcher.py from watchdog.observers import Observer from watchdog.events import FileSystemEventHandler import json class RuleHandler(FileSystemEventHandler): def on_modified(self, event): if event.src_path.endswith(smali_rules.json): with open(event.src_path) as f: new_rules json.load(f) # 更新全局规则变量 global SMALI_RULES SMALI_RULES new_rules print(Rules reloaded!) observer Observer() observer.schedule(RuleHandler(), path./rules/, recursiveFalse) observer.start()集成进主程序后运维同学改完规则3 秒内生效再也不用半夜叫我重启服务。从那以后我每次接到新 APK 分析需求第一反应不是打开 jadx而是敲python apkanalysis.py --apk xxx.apk --auto-report。它不会替我思考漏洞的本质但它把重复劳动压缩到 10%让我能把精力留给真正需要人脑的地方——比如看懂那段混淆后的a.b.c.d.e()到底在干啥。希望帮到你。本文还有配套的精品资源点击获取