Android病毒分析实战：从恶意样本到静态与动态检测全流程

我遇到过太多刚接触样本分析的朋友上来就把 APK 拖进模拟器点一下然后盯着 Logcat 看到天亮最后什么结论都摸不着。Android 病毒分析和普通 App 逆向不一样的地方在于恶意样本会刻意伪装、加密、对抗分析环境你不动点脑子很难让它自己交代问题。这篇文章是 Android 病毒分析实战系列的第一篇我会把一套完整的分析流程从头到尾梳理一遍拿到样本后的信息收集、分析环境搭建、静态初筛、动态行为观察还有高频问题的排查思路。适合刚接触移动安全方向、想在 APK 里找恶意逻辑的开发者也适合做应用安全自查的同学参考。1. 开局思路信息收集比急着运行更重要1.1 恶意样本的初判清单拿到一个疑似病毒 APK我习惯先把它当成一个需要写报告的“案件现场”而不是一个可以随便双击的程序。第一步是建立一个完整的证据清单先记录以下几项文件原始名称、大小、来源渠道哪个网站、哪条链接、通过什么方式流转过来的MD5、SHA-1、SHA-256 哈希值应用的包名、版本号、目标 SDK 版本签名信息、签名证书指纹安装包能否直接解压解压后的 dex、so、assets 文件列表。这些信息里哈希值是最先要做的因为很多威胁情报平台可以直接凭哈希判断样本是否已经被公开分析过。如果命中已有的结论可能分析到一半就能快速定位方向。包名也很值得看有些恶意样本会伪装成系统应用、或者借用一个熟悉的包名诱导用户安装签名证书指纹则可以帮助判断不同样本之间有没有关联同一个作者经常会用同一个签名证书给多个恶意应用签名这在溯源时非常有用。1.2 静态、动态、溯源的分工与顺序分析恶意样本的整体流程可以分成三段静态分析、动态分析、溯源判定。静态分析指的是不解压、不运行直接对 APK 包内部做检查。它的优点是安全、快速能快速定位权限、入口、敏感调用等线索缺点是遇到加固样本或加密逻辑时基本看不到真实代码。动态分析则是把样本放进隔离环境里跑起来观察它的行为比如连了哪个域名、读了哪些文件、有没有释放子包。它可以突破混淆和加密带来的阻碍缺点是耗时长、有风险如果环境不够干净分析机本身也可能被污染。溯源判定是最后一步把静态、动态得到的特征进行归纳形成 IOC失陷指标再判断它属于哪一类恶意家族。大多数样本的常规顺序是先做静态初筛再做动态验证。这就像先看说明书再开机器先低成本地掌握整体方向再针对可疑点做精细化验证。但也要提醒一句如果样本有明显的加固特征静态分析常常会卡住此时不要钻牛角尖直接跳到动态分析反而更快。2. 搭建分析环境虚拟机、抓包与Hook设施2.1 直接准备一个干净的沙箱环境分析病毒样本最怕的就是环境不干净。我自己最开始吃过一次亏在常用的开发模拟器里装了一个样本结果样本在系统目录里写了一些东西之后跑其他 App 一直报异常前后排查了半天才发现是上一个样本留下的“后遗症”。所以我现在固定用一套方案准备一台专用的分析模拟器系统版本固定好打开网络隔离预装好抓包工具、监控脚本和 Frida 插桩环境确认一切正常后保存一个干净快照。每次分析样本前从快照恢复环境分析结束后再从快照恢复。这样一来每个样本都在一个全新的环境里运行互相不干扰。另一个要点是强隔离。如果是处理高危样本推荐用虚拟机加网络隔离的方式前期可以先让样本访问网络观察它的通信行为确认没问题之后再做拦截动作。如果在真实手机上做分析务必要用一台专门的测试机不要插 SIM 卡、不要登录个人账号更不要把重要资料放在上面。样本一旦读取联系人、短信或者相册你存在机器里的所有资料都可能成为它的“战利品”。2.2 流量转发与 HTTPS 证书处理动态分析时最关键的事情之一是能“看到”样本对外发送了什么数据。常规做法是让模拟器里的流量经过一个抓包工具把所有请求记录成可阅读的日志。这里有个容易卡住新手的坎Android 7 之后系统默认不信任用户安装的 CA 证书也就是说你装好抓包工具抓 HTTP 没问题但抓 HTTPS 时会发现所有流量都是加密的、打不开。原因在于证书这条信任链没打通——抓包工具想解密流量需要手机端信任它的证书但 Android 现在不认用户级证书了。解决办法有两种。第一种是把抓包工具的 CA 证书导入到系统证书目录里这需要模拟器已经 root并且系统版本支持修改系统分区第二种是直接使用一个预先定制好的系统镜像把证书烧录进去省的每次重新配置。配置完成后把模拟器里的网络设置改成手动转发指向抓包工具所在机器的监听端口即可。还有一类样本会做 SSL Pinning也就是在代码里固定了服务端证书只信任自己指定的证书。这样即使你装好 CA它也不走你的通道流量照样看不到。这种情况只能用 Frida 等插桩工具在运行时把证书校验函数的结果改成“直接通过”才能继续抓包。这个技巧我后面动态分析部分还会再提。2.3 Frida动态插桩的万能工具Frida 是 Android 恶意样本分析里我非常依赖的工具。它的原理简单说就是注入一段脚本到目标进程里在运行时拦截函数调用、修改返回值、打印参数几乎能做到“在进程内部装一个监视器”。Frida 的安装和基础使用不复杂可以用命令行先验证环境是否正常# 查看目标设备是否在线 frida-ps -U如果能看到设备上运行的应用列表说明 Frida 服务已经正常。# 对指定包名进程启动交互式 Hook frida -U -f com.sample.malware -l monitor.js接入之后可以在 monitor.js 里写一些简单的 Hook 逻辑查看某个函数是否被调用参数是什么。这样即使样本把关键逻辑藏在很深的调用链里只要触发点在你的监控范围内就能抓到它的“尾巴”。3. 静态分析实操从APK结构到关键函数定位3.1 反编译与加固识别静态分析的第一步是把 APK 解包之后再反编译。常用的工具有解包工具、JADX、GDA 等它们能把 dex 字节码还原成接近源码的 Java 代码。用这类工具打开一个样本不要急着看代码先注意三件事入口入口是否正常看 AndroidManifest.xml 里的 Application 类、MainActivity 等入口是不是包名对应有没有指向一个陌生的类dex 文件大小是否异常正常的 dex 通常会有一个合理的体积如果 dex 特别小只有几 KB或者代码目录里没有业务逻辑大概率是加壳了是否存在可疑的 so 文件加壳样本常常会在 lib 目录下放一个用于解密、还原的 native 模块这个 so 文件在静态分析时可以先记下来后面动态阶段要重点盯它。如果发现是加固样本不要硬着头皮只靠静态分析。常见的处理路线是使用开源脱壳工具或者在动态运行时从内存中 dump 出真正执行的 dex。脱壳不是每次都能成功后面我会在常见问题里展开讲。3.2 权限矩阵与敏感 API 关联分析权限是最能直观体现一个样本“内心想法”的地方。我分析样本的时候会先把所有权限列成一张表然后问自己一个这种类型的应用真的需要这些权限吗权限正常场景恶意样本中的常见用途READ_SMS / RECEIVE_SMS短信验证码自动填充读取验证码、拦截通知短信READ_CONTACTS社交应用同步通讯录收集联系人做精准诈骗或名单出售RECORD_AUDIO语音聊天、录音工具后台录音、窃听REQUEST_INSTALL_PACKAGES应用商店安装更新静默安装其他恶意应用SYSTEM_ALERT_WINDOW悬浮窗工具制作点击劫持界面、诱导用户授权QUERY_ALL_PACKAGES应用管家类工具枚举已安装应用判断目标环境看到可疑权限后还要找到对应代码里的调用位置。比如一个应用申请了发送短信权限那就在代码里搜索 sendTextMessage、SmsManager 之类的字符串看有没有真正的短信发送逻辑。光有权限没有调用不一定是坏事有权限又有调用才是重点怀疑对象。3.3 入口 Activity 与动态注册的追踪恶意逻辑喜欢藏在几个位置Application 的 onCreate、MainActivity 的 onCreate、以及通过 JNI 动态注册的 native 方法。Application 是一个优先看的地方因为它会在应用被拉起时最先执行甚至可以在界面没有显示前就启动恶意行为。MainActivity 则常用于判断用户是否点击了某个按钮、或者程序是否在某种条件下才触发恶意逻辑一般会伴随字符串判断、时间判断等。很多进阶样本会把恶意代码放到 so 层通过 JNI 动态注册把 Java 方法名与 native 函数绑定。这样你在纯 Java 层反编译时只能看到一个空的壳方法看不到具体逻辑。这种情况下需要打开 IDA 或者 Ghidra 分析对应的 so 文件或者在动态运行时利用 Frida 观察 so 模块加载后是否有可疑的导出函数。3.4 动态加载与字符串加密对抗恶意样本为了隐藏真实行为常用的两个手段是动态加载和字符串加密。动态加载指的是在运行时通过 DexClassLoader 加载一段额外的 dex 文件这段被加载的 dex 可能在 APK 里不存在而是藏在 assets 目录、服务器下发、或者运行后才解密释放。静态分析时在代码里搜索 DexClassLoader、loadClass 这些关键词能够定位加载点。加载点的上游往往藏着解密函数。字符串加密则更常见。你会看到大量 Base64 编码的长字符串或者一堆混淆后的字节数组真正有意义的域名、路径、命令都藏在这些加密串里。不要慌解题思路是找到这些字符串在代码中被引用的位置找到解密函数手动还原它。一般解密函数会出现在同一个类里或者以 native 方法的形式存在分析时建议先用 Frida hook 住解密函数的输入输出直接让程序替你解密效率往往比人工推演更高。4. 动态行为观察让样本自己揭穿自己4.1 进程、文件、网络三路监控动态分析的思路是让样本自己跑起来同时把它的每个动作记录下来。我的习惯是同时开三路监控。第一路是进程监控观察样本有没有创建子进程、有没有 fork 出新的进程出来做“脏活”。有些样本会在主进程里只做伪装真正恶意的工作放到子进程里执行这样即便静置状态也不容易被发觉。第二路是文件监控观察样本在私有目录、公共目录、甚至系统目录里有没有释放新文件。比如很多样本会把下载好的二次载荷写到 files 目录或 cache 目录然后下次启动时再加载执行有些样本还会修改系统配置文件做开机自启动。第三路是网络监控观察样本解析了哪些域名、连接了哪些 IP、使用了什么协议。网络监控的输出通常会生成一份连接清单里面可能藏着 C2 服务器地址这是后续溯源的重要依据。这三路可以借助系统自带的分析工具和抓包日志配合查看不用太复杂。在 Android 开发者工具里用 Profile 或直接看 logcat 也能获得不少信息。关键是把时间点对齐比如样本启动后的第几秒哪个进程发起了哪个请求这样才容易还原完整的行为链。举个例子一个样本启动后先是读取了自己的配置接着通过某个加密算法生成了一个短字符串然后向后端域名发送一个 HTTP 请求几秒后从服务器返回一段 dex 文件并落盘。这一整套动作如果只看网络日志只能看到“它发了一个包”要结合文件监控和进程监控才能形成完整闭环。4.2 关键函数 Hook 与通信内容还原静态分析定位了可疑函数动态分析就该验证它。Frida 在这里是主力。下面是一个很基础的脚本用来观察某个参数为字符串的函数调用情况同时打印调用栈Java.perform(function () { var targetClass Java.use(com.sample.malware.core.CryptoHelper); targetClass.decode.overload(java.lang.String).implementation function (input) { console.log(decode called, input input); var result this.decode(input); console.log(decode returned result); console.log(Java.use(android.util.Log).getStackTraceString(Java.use(java.lang.Throwable).$new())); return result; }; });运行后如果样本确实调用了这个 decode 函数你就会在控制台上看到它接收的原始字符和还原后的明文。这个办法能直接帮助你快速还原加密的通信参数、路径和指令。Hook 时的注意事项是不要在样本启动前过早注入这样容易触发反调试机制也不要太晚注入否则可能在注入完成前样本已经跑了关键逻辑。稳妥的做法是启动时立即注入、但样本在前几秒内不要着急操作等 Hook 脚本就位后再触发。抓不到流量时也可以借助 Frida。先用脚本定位 SSL 校验相关函数再决定是否静态绕过。这类操作本质上是在分析进程内部做验证不要把它理解成绕过防御它只是让分析者能看到样本发出去的数据方便审计它的行为。4.3 从行为到恶意家族判断动态分析结束后样本的行为已经不是秘密了。接下来要把观察到的行为归类看它符合哪个已知恶意家族的特征。一个样本如果同时具备以下特征申请短信读取权限、运行时动态加载 dex、通信域名是最近注册的、连接端口非常规那它大概率属于一个以短信劫持和远程控制为主的家族。如果样本倾向于枚举已安装应用、收集设备信息、再请求安装未知来源的应用包那它更接近推广类恶意软件。在归类时不要只看单一特征很多正常应用也会有类似的权限申请。判断的关键在于“这些行为组合起来是否合理”。一个工具类应用申请读取短信可能只是为了验证码但如果它同时请求安装未知应用、并且悄悄上传通讯录那就非常可疑了。最终输出分析报告时建议把 IOC 整理成清单恶意包名、证书指纹、C2 域名或 IP、通信协议、特征文件路径等这些可以直接用于预警规则和威胁情报匹配。5. 常见问题与排查技巧实录5.1 样本识别出分析环境后直接退出这是最高频的问题之一。恶意样本为了增大在真实设备上的存活率会在运行时检测模拟器特征、root 环境、调试器状态、Frida 特征等一旦发现就退出或者展示一个正常界面。碰到这种情况我的处理顺序是先确认检测点。用 Frida 的 anti-detection 模块或者直接 hook 几个常见的检测函数比如读取系统属性、检查文件路径逐个确认它是在哪一步退出的。如果模拟器容易被检测出来可以换用一台低版本系统的模拟器或者直接上真机。真机加 Frida 是最接近真实环境的方案。如果样本检测 Frida可以尝试延迟注入让样本先完成早期的环境检测再在后续逻辑执行前把 Hook 挂上去。5.2 脱壳后的 DEX 打开就报错加壳样本在运行时会把真正的 dex 加载到内存分析者用 dump 工具把这个 dex 从内存里抓出来但抓到的文件经常是不完整的。最典型的表现是 JADX 打开时报错或者方法体是空的。几个可行的处理思路多尝试几次内存 dump最好在样本完成第一批解密逻辑之后再抓此时内存里 dex 更完整用脱壳修复工具尝试修复 dex 结构有些工具能自动处理常见的 dex 头部校验和索引问题如果 dump 出的 dex 不完整不妨结合 Frida在运行时直接读取已经完全解密并加载到内存中的类逐一把关键类 dump 出来不追求完整包只求拿到关键逻辑。5.3 抓不到流量Pinning 和系统证书问题这个问题的排查路径我已经在前面提过这里整理成一张速查表现象原因检查方向能看到流量包但数据全是加密的未信任抓包 CA 证书检查系统证书是否已导入、目标 SDK 版本是否 24部分应用流量可见部分不可见应用做了 SSL Pinning使用 Frida 绕过证书校验或直接分析其网络库完全看不到任何流量抓包工具监听端口未生效检查网络设置是否正确、监听端口是否被占用样本启动后通信明显加快可能是行为触发条件被满足结合 UI 操作模拟正常用户点击流程后再观察抓包的最终目的是还原通信内容而不是只看流量大小。如果实在解不开 HTTPS也不要放弃可以从 DNS 请求日志、证书日志等侧信道信息中提取出样本访问的域名列表同样能用于 IOC 提取。5.4 分析环境被污染后的恢复即使有快照也免不了遇到“忘记保存之前干净状态”的情况。这种时候最有效的办法是准备两个独立环境一个专门跑高威胁样本一个专门做日常分析验证。高威胁样本环境用完直接丢弃重来日常分析环境保存比较干净的快照。另外我习惯把每次分析的中间产物解包目录、dump 出的 dex、抓包日志、Hook 脚本按样本哈希建一个目录单独存放。这样即使环境重置分析结果也不会丢后续要看历史样本时直接进目录翻就行。写在最后这套分析流程跑完一个样本是什么、干了什么、通信对象是谁基本能形成一个清晰的清单。我自己在实际分析中最大的心得是分析速度和工具数量不成正比关键在于方法和记录习惯。每拿到一个样本先把信息收集做扎实再决定走静态还是动态路线走一步记一步最后汇总成 IOC 和报告。分析完一批样本后可以把它们的行为特征沉淀成自己的检测规则库后续再遇到类似样本时初判时间会明显缩短。希望这篇文章对正准备入坑 Android 样本分析的朋友有帮助。