护网红队碰到移动端目标最常用的思路就是从 APK 反编译审计开始一路摸到服务端接口最后 Getshell。这个过程看着玄乎其实链路非常清晰客户端代码里藏着服务端地址、接口参数、加密逻辑、密钥信息甚至可以直接让你拿到后台管理权限。很多时候你费尽心思去扫端口、猜路径不如老老实实把 APK 翻一遍收获往往比想象中大得多。这篇文章就把我实际测试中的完整思路和操作记录下来从反编译到 Getshell 的每一步都讲清楚适合正在做攻防演练的朋友参考也适合开发安全岗的同学反向自查自己公司的 APP 有没有类似问题。1. 链路拆解为什么 APK 会变成 Getshell 的起点1.1 移动应用为什么是红队眼里的“软柿子”如果说 Web 站点是攻防演练里的正面战场那移动应用基本就是侧门和后门扎堆的地方。很多企业把大量精力放在 Web 防火墙、主机加固、态势感知上却忽略了自家 APP 暴露出来的接口和逻辑往往比 Web 站更裸。一个很残酷的现实是移动端 APP 更新频率高动不动就发版而每次发版都意味着有新的接口、新的业务逻辑被塞进包体里。安全团队跟进的速度常常跟不上业务上线的速度遗留下的老接口、测试接口、调试接口就成了红队最容易突破的点。另一个原因是移动端代码天然不可信。无论你做了多少混淆、加固只要 APP 要跑在用户设备上代码和资源就一定会到达客户端。攻击者手里拿着 APK 就相当于拿到了服务端的“半套源码”配合抓包工具完全可以还原出完整的 API 调用链。加上很多开发为了方便把接口地址、签名密钥、云服务密钥直接写死在客户端这种硬编码问题我用十个手指都数不过来。1.2 攻击面到底从哪里来从 APK 出发做安全测试攻击面通常分成三层。第一层是 APP 自身。包括组件导出、任意调试开关、不当权限申请、硬编码敏感信息、不安全的文件存储等等。这一层一般是静态审计和动态调试的重点但说实话单靠 APP 自身漏洞很难直接 Getshell更多是作为信息收集的突破口。第二层是客户端与服务端的接口。这才是 Getshell 的主战场。APP 里的每个接口都需要过一遍鉴权、越权、注入、上传、逻辑漏洞的测试。红队真正要做的是顺着客户端摸出服务端的技术栈、接口风格、鉴权方式、身份认证体系然后像打 Web 一样去测接口。第三层是供应链和第三方组件。APK 里集成的第三方 SDK、开源组件可能带有已知漏洞比如某个旧版本的推送 SDK 或者地图 SDK 存在反序列化问题。这类问题有时候能成为抓手的捷径。1.3 “Getshell”不是目的验证危害才是很多刚入行的朋友一听说 Getshell 就肾上腺素飙升觉得拿到一个主机权限就完事了。其实在护网场景下Getshell 只是一个里程碑它的意义在于通过一条从客户端到服务端的完整利用链证明攻击者可以拿到敏感数据、控制业务服务器、横向移动。红队报告里最有分量的不是“我执行了 whoami”而是“我通过 APP 的某个接口打到了管理后台最终在数据库服务器上获取了权限”。所以整条链路的逻辑要完整每一步都要能从防守方的角度解释风险。2. 反编译与静态审计的实操要点2.1 工具准备与选型做 APK 反编译审计我的工具链比较固定apktool负责解包资源和 smali 代码jadx-gui负责把 dex 转成 Java 代码方便人读Burp Suite负责抓包改包frida负责动态调试和脱壳。如果你是在 Linux 服务器上跑jadx命令行版本配合 grep 也挺好用Windows 上我更喜欢jadx-gui的图形界面搜索关键字更直观。工具版本上有个坑要提一下。新版 Android 的 APK 使用 v2/v3 签名旧版apktool解包时偶尔会报签名错误。建议直接用最新版本apktool2.9 以上的版本对 AAPT2 的支持已经比较成熟。遇到某些商业壳解包后 smali 目录下大部分类都被抽空jadx打开也是一堆空壳类基本就可以判断是加固了直接上frida脱壳或者运行时 dump 内存。注意反编译仅适用于你自己拥有或被授权测试的目标。未经授权对他人 APP 做逆向和测试在合规层面有严重问题这一点没有商量的余地。2.2 第一步必须看 AndroidManifest.xml拿到 APK 之后别急着在代码里翻关键字。第一步永远是AndroidManifest.xml。用apktool d app.apk解包之后这个文件就是整个应用的“地图”。我会按顺序看几类东西application节点的name属性至少能看出有没有自定义 Application 类有的调试后门就藏在这里。uses-permission权限声明要跟实际功能对应。一个普通的记账 APP 要短信、通讯录、定位权限本身就值得留意。activity/service/receiver节点的android:exported属性。重点找exportedtrue的组件尤其是不带任何权限限制的组件。这类组件可以被任意应用拉起轻则信息泄露重则直接调用内部功能。android:debuggabletrue和android:backuptrue这两个标志。前者意味着 APP 可以被调试器附加后者意味着应用数据可以被adb backup拉出来。这两个标志在企业客户端的生产包里出现基本等于给红队发了张通行证。AndroidManifest.xml里另一个高频出问题的点是网络配置。打开network_security_config如果配置了cleartextTrafficPermittedtrue或者干脆没配置那所有 HTTP 明文请求都可以被中间人抓包改包。很多 APP 在测试环境开了明文流量上线时忘记关这种低级错误在移动端出现的频率远比你想象的高。2.3 代码里的敏感信息定位Manifest 看完下一步就是用jadx-gui打开反编译出的代码开始搜关键字。我一般会从这几个方向入手接口地址相关http://、https://、api、baseUrl、server、host、test。密钥相关secret、key、token、accessKey、privateKey、signature。存储相关SharedPreferences、getExternalStorageDirectory、getCacheDir、sqlite、realm。安全组件相关EncryptUtils、AES、DES、RSA、MD5、sign。调试后门相关stetho、bugly、log、debug、backdoor。实际搜索的时候要配合代码上下文来看。比如搜secret可能会搜出一堆无关的变量但如果你看到某个类里写着private static final String SECRET_KEY a3f0...;那基本可以确定是某个接口的签名密钥。这类硬编码问题在金融类、政务类 APP 里也不少别抱侥幸心理。BuildConfig类是个宝矿。很多团队会把环境切换开关放在BuildConfig里比如DEBUG、API_BASE_URL、SECRET。当你看到一个 APP 的BuildConfig里同时存在DEBUGtrue和多个接口环境就可以在抓包时尝试切换 Host往往能找到未授权或弱鉴权的测试环境。2.4 混淆与加固代码怎么看遇到混淆代码是最头疼的类名和方法名全被改成a.b.c直接读源码效率极低。我一般先看有没有保留注释、异常字符串、日志输出。很多混淆配置只是改了符号名却保留了Log.d的 TAG 和异常 message这些字符串往往能帮我定位功能模块。如果是加固的 APP反编译看不到关键逻辑这时候不要犹豫直接上frida。objection工具可以一键 dump 内存中的 dex。运行时 dump 出来的 dex 虽然没法完美还原加固前的代码但核心逻辑和方法调用基本都能看到。另外frida还能直接 hook 关键函数比如看加密方法的输入输出省去逆向算法的功夫。测试中我经常直接在java.perform里 hook 一个cipher.doFinal把明文、密文一起打出来比自己费劲还原算法快得多。3. 从客户端代码找到服务端突破口3.1 接口鉴权与越权测试APK 静态审计的核心产出是一张接口清单和一套请求参数模板。拿到这些之后就可以稳稳地在 Burp 里开始测接口了。我习惯先用 App 正常登录一次把所有流量完整过一遍 Burp然后逐个接口做越权和鉴权测试。越权测试的经典姿势是用 A 用户的身份去操作 B 用户的资源。比如把请求里的userId10001改成userId10002或者把订单号、手机号、身份证号换了接着请求。移动端 APP 在登录后拿到的 token 通常只做身份认证不做数据归属校验导致水平越权极其普遍。你通过 APP 发现一个getUserInfo接口参数是id那么遍历 id 很可能拿到一批用户敏感信息。垂直越权也一样前端隐藏了管理员入口但接口本身没有做角色校验把普通用户的 token 丢到管理端接口上照样能调用。这类问题在代码审计阶段往往就能看出端倪。搜索RequiresRole、checkPermission、isAdmin这类关键词如果发现只有前端跳转判断而接口调用本身没有任何权限校验那这个接口基本就是越权漏洞。当然这只是代码层面的预判最终要以线上测试结果为准。3.2 签名机制与参数篡改很多 APP 为了防篡改会给请求参数加一个sign一般是把所有参数按字典序排列拼上密钥以后做 MD5 或 HMAC。服务端验签通过才会处理请求。这套机制本身没毛病但问题在于密钥必须用在客户端所以密钥一定会出现在 APK 里。我在审计中经常能看到这样的代码private static String getSign(HashMapString, String params) { String secretKey kLm8Ae1d9Gq0XzR7; // 硬编码密钥 String sorted new TreeMap(params).keySet().stream() .map(k - k params.get(k)) .collect(Collectors.joining()); return MD5.encode(sorted secretKey secretKey); }拿到这个逻辑之后Burp 的每一个改包请求都能算出合法的签名服务端验签形同虚设。更严重的是如果同一个密钥还用在管理后台接口的签名上那改包的空间就更大了。做这类测试时建议写个小脚本把签名算法在本地实现一遍或者用 Burp 的Turbo Intruder扩展自动生成签名效率会高很多。3.3 从接口测试到注入与上传接口列表确定好之后就该流程化地做注入和上传测试了。常见的注入点其实很有规律登录接口的参数、列表接口的分页参数、导出功能的文件名参数、订单号的查询参数。移动端 APP 和后端交互时参数格式化通常跟 Web 端一致所以 SQL 注入、XSS、XXE、文件上传这些 Web 漏洞在接口层普遍存在。我印象最深的是一次模拟测试某个 APP 的联系人同步接口userid参数直接拼接进 SQL 查询连编码转换都没做用sqlmap一把梭就直接扫出了注入点。然后顺着注入点读文件、写文件最后通过INTO OUTFILE写了一个 PHP 一句话到网站目录虽然当时权限比较低但已经足够证明服务器可以被完全控制。文件上传是另外一个高频 Getshell 入口。移动端的头像上传、OCR 识别、文件转发功能都是上传点。我一般先看代码里有没有校验Content-Type和后缀名的逻辑如果没有就直接传一个带.php或.jsp后缀的文件试试。即使被文件名重命名坑了也可以尝试.php5、.phtml、x.php.jpg、xx%00.jpg这类绕过方式。3.4 权限提升与内网判断接口层 Getshell 之后权限通常很低可能是www-data或者tomcat用户。这时候要快速确认几件事当前用户是否有 sudo 权限、系统上有没有常见的提权漏洞、内网网段有哪些、有没有跳板机的迹象。命令无非是id、sudo -l、uname -a、cat /etc/passwd、ip addr、arp -a。我曾经遇到过一种情况通过 APP 的导出功能打下来一个 Tomcatwww-data用户翻遍了目录什么敏感数据都没有。本来已经打算收工了结果顺手试了试sudo -l发现当前用户可以无密码执行某个运维脚本。最后通过这个脚本的反引号命令注入直接拿到了root权限。整个过程完全没用到内核漏洞靠的就是几个基础命令的排查习惯。4. 一次完整的模拟测试记录从 APK 到 Getshell4.1 目标与授权用一次模拟项目来完整走一遍链路。目标是某企业内部业务系统的 Android 端 APP安装包 15MB 左右未加固无混淆迹象授权范围明确包含该 APP 及其关联服务端。测试周期两天原则上是只验证风险不破坏业务数据。4.2 静态定位阶段先用apktool解包apktool d com.example.sysapp.apk -o sysapp_src解包比较顺利也没看到libjiagu.so这类加固特征于是直接上jadx-gui打开com.example.sysapp.apk。在搜索框输入http很快定位到一个叫ApiConstant的类public class ApiConstant { public static final String BASE_URL http://192.168.3.18:8080/appapi/; public static final String UPLOAD_URL http://192.168.3.18:8080/upload; }注意这里用的是内网 IP 的 HTTP 地址而且没有配置证书校验意味着测试机上只要连上能访问该网段的网络就可以直接抓明文包。继续往下看发现所有接口都定义在UserApi和AdminApi两个接口类里。UserApi里面有login、getUserInfo、getOrderList、exportData等接口AdminApi里有userManage、exportAllUsers。exportAllUsers这个接口名让我多看了一眼继续在jadx里搜它所在的方法发现请求路径是/appapi/admin/exportAllUsers。代码里只看到了GET注解没有任何权限验证。从命名推断这是一个全量用户导出接口大概率是管理端功能但这里的实现完全没做鉴权。4.3 接口测试与漏洞利用配置好 Burp 代理在手机或模拟器里正常登录 APP跑了一遍正常业务流程把请求都记录下来。然后直接在 Burp 的 Repeater 里请求GET /appapi/admin/exportAllUsers HTTP/1.1 Host: 192.168.3.18:8080让我意外的是这个接口真的返回了一个 JSON 数组里面包含大量用户账号、手机号、邮箱字段。没有带任何 Token也没有任何身份校验直接就是一个未授权访问的信息泄露接口。接着测试上传接口。UPLOAD_URL指向/upload代码里对应的上传逻辑在FileUploadActivity用的是MultipartFormData没有看到校验文件和扩展名的逻辑。用 Burp 构造一个包含 PHP 文件的请求发过去返回{code:0,path:/uploads/20250318_1425_test.php}。很明显上传后的文件直接落在 Web 目录下没有经过内容校验。用浏览器访问http://192.168.3.18:8080/uploads/20250318_1425_test.php直接返回了 PHP 的执行效果。到这里其实已经证明可以 Getshell 了但为了验证严重性我继续走了下一步。4.4 权限提升与影响确认确认能执行 PHP 代码后上传了一个简单的命令执行脚本然后通过它执行id和cat /etc/passwd。当前用户是www-dataWeb 服务的默认账户权限不高。查看服务器的 IP 和同网段主机列表发现这台机器能访问一个192.168.3.x的网段。我顺手在/var/www/下面翻到一份数据库连接配置里面对应的是另一台内网数据库服务器的地址账号密码均为明文。最终虽然没有直接打到那台数据库服务器的操作系统权限但配合前面的未授权导出的用户数据已经可以影响大量核心业务数据。从整个利用链来看一个 APK 反编译审计最终不只是把测试机的 PHP 执行拿了下来而是完整穿透了“客户端—服务端接口—上传—内网信息收集”这几层。防守方在看到这个报告后至少能清楚地知道一个移动端入口可以通向多么严重的风险面。5. 避坑指南与常见问题速查5.1 反编译过程中的高频问题apktool解包失败经常是因为 APK 使用了较新的资源表格式或者 AAPT2 编译的资源存在兼容问题。换成最新版apktool、加-s参数只解包资源不解码 dex都能绕开一部分问题。jadx-gui内存不足导致卡顿是因为某些大型 APP 的方法数极多把堆内存调到 4GB 以上会好很多命令是java -Xmx4g -jar jadx-gui.jar还有一类情况是AndroidManifest.xml解码乱码或报错。这通常不是文件损坏而是apktool无法完整解析 AOSP 的新二进制 XML 格式。遇到这种情况可以先尝试jadx直接读 APK它能直接解析 Manifest 并展示成可读文本。5.2 代码审计中容易忽略的盲区千万别只看业务逻辑代码很多后门和风险藏在Application类的onCreate方法里可能有远程配置拉取、初始化调试组件。Service组件里尤其是有bindService跨进程调用的场景。BroadcastReceiver里动态注册的广播接收器如果处理了外部 Intent可能被拉起并执行操作。WebView的addJavascriptInterface如果注册了原生方法给 JS 调用配合远程 URL 可控可以直接让 JS 调用任意系统能力。第三方统计、推送、热更新 SDK。热更新框架本身就是一个远程代码执行通道如果更新地址可以被污染甚至不需要其他漏洞。每次审计建议专门拨出一段时间只翻这些“非业务”代码区域收获往往比业务逻辑更多。5.3 测试节奏与注意事项测试中最大的坑不是技术而是把自己陷在细节里。建议给每个阶段设定明确的时间上限APK 反编译静态审计花费的时间不超过 40%接口测试和漏洞利用花掉更多的比例剩下时间留给权限提升和报告梳理。如果某个加固壳或者混淆代码盯着看了两小时还没思路直接换工具链或者换一个突破口不要在单点上死磕。另一个容易被忽视的问题是测试数据的污染。给服务器传 webshell、写文件、改数据时一定要避开生产环境里的真实业务数据。即使授权了也应该优先选择测试账号、测试环境。万一造成业务中断就算最终报告写得再漂亮那也是事故而不是成果。5.4 问题排查速查表症状可能原因处理方式apktool 解包报错APK 签名或资源表兼容问题升级 apktool 到最新版本必要时加-sjadx 打开卡顿内存不足加大-Xmx参数关闭多余标签页反编译后类名全是 a/b/c启用了混淆配合日志 TAG、字符串、异常信息辅助定位核心类被抽空加固了使用 frida 内存 dump 或动态调试还原逻辑接口请求都被重定向到登录全局鉴权拦截检查 APP 是否有自动加签逻辑尝试绕过 token 校验上传文件无法解析扩展名被黑名单拦截尝试多种后缀、解析差异、双扩展名绕过6. 红队视角的几个总结习惯个人向做这类测试我始终有一个原则每条利用链都要用“如果我是防守方要怎样才能发现和阻止”的角度去复盘。从 APK 反编译到 Getshell中间其实暴露了很多可以拦截的机会点比如服务端上传接口没有做内容检测、管理端接口没有做鉴权、客户端硬编码密钥没有做一些扫描。红队能拿到权限不是因为单个漏洞厉害而是防守方在多个环节都有缺失。如果你是在企业里做安全工作建议自己也试着用这条路径测一遍自家 APP。很多团队整天盯着 SOC 告警却没人真正打开过自家 APK 里的ApiConstant类看一看。个人经验是拿自己 APP 走一遍反编译审计半小时就能发现几个开发都不知道的敏感信息接口。这个习惯一旦养成防御水位比单纯堆设备高得多。最后分享一个小技巧审计完 APK 以后把反编译出来的代码保留一段时间不要测试完就删。因为你在审计过程中发现的接口清单、签名逻辑、密钥位置在写报告和做复盘时都要反复引用。我自己习惯把这类项目单独建一个目录按目标、工具、发现、利用链四个子目录整理后续查旧项目时能省大量时间。 
长河君 · 2026/10/16 16:00:52 · 阅读 1.2k 从APK反编译到Getshell：移动端渗透测试实战链路解析
护网红队碰到移动端目标最常用的思路就是从 APK 反编译审计开始一路摸到服务端接口最后 Getshell。这个过程看着玄乎其实链路非常清晰客户端代码里藏着服务端地址、接口参数、加密逻辑、密钥信息甚至可以直接让你拿到后台管理权限。很多时候你费尽心思去扫端口、猜路径不如老老实实把 APK 翻一遍收获往往比想象中大得多。这篇文章就把我实际测试中的完整思路和操作记录下来从反编译到 Getshell 的每一步都讲清楚适合正在做攻防演练的朋友参考也适合开发安全岗的同学反向自查自己公司的 APP 有没有类似问题。1. 链路拆解为什么 APK 会变成 Getshell 的起点1.1 移动应用为什么是红队眼里的“软柿子”如果说 Web 站点是攻防演练里的正面战场那移动应用基本就是侧门和后门扎堆的地方。很多企业把大量精力放在 Web 防火墙、主机加固、态势感知上却忽略了自家 APP 暴露出来的接口和逻辑往往比 Web 站更裸。一个很残酷的现实是移动端 APP 更新频率高动不动就发版而每次发版都意味着有新的接口、新的业务逻辑被塞进包体里。安全团队跟进的速度常常跟不上业务上线的速度遗留下的老接口、测试接口、调试接口就成了红队最容易突破的点。另一个原因是移动端代码天然不可信。无论你做了多少混淆、加固只要 APP 要跑在用户设备上代码和资源就一定会到达客户端。攻击者手里拿着 APK 就相当于拿到了服务端的“半套源码”配合抓包工具完全可以还原出完整的 API 调用链。加上很多开发为了方便把接口地址、签名密钥、云服务密钥直接写死在客户端这种硬编码问题我用十个手指都数不过来。1.2 攻击面到底从哪里来从 APK 出发做安全测试攻击面通常分成三层。第一层是 APP 自身。包括组件导出、任意调试开关、不当权限申请、硬编码敏感信息、不安全的文件存储等等。这一层一般是静态审计和动态调试的重点但说实话单靠 APP 自身漏洞很难直接 Getshell更多是作为信息收集的突破口。第二层是客户端与服务端的接口。这才是 Getshell 的主战场。APP 里的每个接口都需要过一遍鉴权、越权、注入、上传、逻辑漏洞的测试。红队真正要做的是顺着客户端摸出服务端的技术栈、接口风格、鉴权方式、身份认证体系然后像打 Web 一样去测接口。第三层是供应链和第三方组件。APK 里集成的第三方 SDK、开源组件可能带有已知漏洞比如某个旧版本的推送 SDK 或者地图 SDK 存在反序列化问题。这类问题有时候能成为抓手的捷径。1.3 “Getshell”不是目的验证危害才是很多刚入行的朋友一听说 Getshell 就肾上腺素飙升觉得拿到一个主机权限就完事了。其实在护网场景下Getshell 只是一个里程碑它的意义在于通过一条从客户端到服务端的完整利用链证明攻击者可以拿到敏感数据、控制业务服务器、横向移动。红队报告里最有分量的不是“我执行了 whoami”而是“我通过 APP 的某个接口打到了管理后台最终在数据库服务器上获取了权限”。所以整条链路的逻辑要完整每一步都要能从防守方的角度解释风险。2. 反编译与静态审计的实操要点2.1 工具准备与选型做 APK 反编译审计我的工具链比较固定apktool负责解包资源和 smali 代码jadx-gui负责把 dex 转成 Java 代码方便人读Burp Suite负责抓包改包frida负责动态调试和脱壳。如果你是在 Linux 服务器上跑jadx命令行版本配合 grep 也挺好用Windows 上我更喜欢jadx-gui的图形界面搜索关键字更直观。工具版本上有个坑要提一下。新版 Android 的 APK 使用 v2/v3 签名旧版apktool解包时偶尔会报签名错误。建议直接用最新版本apktool2.9 以上的版本对 AAPT2 的支持已经比较成熟。遇到某些商业壳解包后 smali 目录下大部分类都被抽空jadx打开也是一堆空壳类基本就可以判断是加固了直接上frida脱壳或者运行时 dump 内存。注意反编译仅适用于你自己拥有或被授权测试的目标。未经授权对他人 APP 做逆向和测试在合规层面有严重问题这一点没有商量的余地。2.2 第一步必须看 AndroidManifest.xml拿到 APK 之后别急着在代码里翻关键字。第一步永远是AndroidManifest.xml。用apktool d app.apk解包之后这个文件就是整个应用的“地图”。我会按顺序看几类东西application节点的name属性至少能看出有没有自定义 Application 类有的调试后门就藏在这里。uses-permission权限声明要跟实际功能对应。一个普通的记账 APP 要短信、通讯录、定位权限本身就值得留意。activity/service/receiver节点的android:exported属性。重点找exportedtrue的组件尤其是不带任何权限限制的组件。这类组件可以被任意应用拉起轻则信息泄露重则直接调用内部功能。android:debuggabletrue和android:backuptrue这两个标志。前者意味着 APP 可以被调试器附加后者意味着应用数据可以被adb backup拉出来。这两个标志在企业客户端的生产包里出现基本等于给红队发了张通行证。AndroidManifest.xml里另一个高频出问题的点是网络配置。打开network_security_config如果配置了cleartextTrafficPermittedtrue或者干脆没配置那所有 HTTP 明文请求都可以被中间人抓包改包。很多 APP 在测试环境开了明文流量上线时忘记关这种低级错误在移动端出现的频率远比你想象的高。2.3 代码里的敏感信息定位Manifest 看完下一步就是用jadx-gui打开反编译出的代码开始搜关键字。我一般会从这几个方向入手接口地址相关http://、https://、api、baseUrl、server、host、test。密钥相关secret、key、token、accessKey、privateKey、signature。存储相关SharedPreferences、getExternalStorageDirectory、getCacheDir、sqlite、realm。安全组件相关EncryptUtils、AES、DES、RSA、MD5、sign。调试后门相关stetho、bugly、log、debug、backdoor。实际搜索的时候要配合代码上下文来看。比如搜secret可能会搜出一堆无关的变量但如果你看到某个类里写着private static final String SECRET_KEY a3f0...;那基本可以确定是某个接口的签名密钥。这类硬编码问题在金融类、政务类 APP 里也不少别抱侥幸心理。BuildConfig类是个宝矿。很多团队会把环境切换开关放在BuildConfig里比如DEBUG、API_BASE_URL、SECRET。当你看到一个 APP 的BuildConfig里同时存在DEBUGtrue和多个接口环境就可以在抓包时尝试切换 Host往往能找到未授权或弱鉴权的测试环境。2.4 混淆与加固代码怎么看遇到混淆代码是最头疼的类名和方法名全被改成a.b.c直接读源码效率极低。我一般先看有没有保留注释、异常字符串、日志输出。很多混淆配置只是改了符号名却保留了Log.d的 TAG 和异常 message这些字符串往往能帮我定位功能模块。如果是加固的 APP反编译看不到关键逻辑这时候不要犹豫直接上frida。objection工具可以一键 dump 内存中的 dex。运行时 dump 出来的 dex 虽然没法完美还原加固前的代码但核心逻辑和方法调用基本都能看到。另外frida还能直接 hook 关键函数比如看加密方法的输入输出省去逆向算法的功夫。测试中我经常直接在java.perform里 hook 一个cipher.doFinal把明文、密文一起打出来比自己费劲还原算法快得多。3. 从客户端代码找到服务端突破口3.1 接口鉴权与越权测试APK 静态审计的核心产出是一张接口清单和一套请求参数模板。拿到这些之后就可以稳稳地在 Burp 里开始测接口了。我习惯先用 App 正常登录一次把所有流量完整过一遍 Burp然后逐个接口做越权和鉴权测试。越权测试的经典姿势是用 A 用户的身份去操作 B 用户的资源。比如把请求里的userId10001改成userId10002或者把订单号、手机号、身份证号换了接着请求。移动端 APP 在登录后拿到的 token 通常只做身份认证不做数据归属校验导致水平越权极其普遍。你通过 APP 发现一个getUserInfo接口参数是id那么遍历 id 很可能拿到一批用户敏感信息。垂直越权也一样前端隐藏了管理员入口但接口本身没有做角色校验把普通用户的 token 丢到管理端接口上照样能调用。这类问题在代码审计阶段往往就能看出端倪。搜索RequiresRole、checkPermission、isAdmin这类关键词如果发现只有前端跳转判断而接口调用本身没有任何权限校验那这个接口基本就是越权漏洞。当然这只是代码层面的预判最终要以线上测试结果为准。3.2 签名机制与参数篡改很多 APP 为了防篡改会给请求参数加一个sign一般是把所有参数按字典序排列拼上密钥以后做 MD5 或 HMAC。服务端验签通过才会处理请求。这套机制本身没毛病但问题在于密钥必须用在客户端所以密钥一定会出现在 APK 里。我在审计中经常能看到这样的代码private static String getSign(HashMapString, String params) { String secretKey kLm8Ae1d9Gq0XzR7; // 硬编码密钥 String sorted new TreeMap(params).keySet().stream() .map(k - k params.get(k)) .collect(Collectors.joining()); return MD5.encode(sorted secretKey secretKey); }拿到这个逻辑之后Burp 的每一个改包请求都能算出合法的签名服务端验签形同虚设。更严重的是如果同一个密钥还用在管理后台接口的签名上那改包的空间就更大了。做这类测试时建议写个小脚本把签名算法在本地实现一遍或者用 Burp 的Turbo Intruder扩展自动生成签名效率会高很多。3.3 从接口测试到注入与上传接口列表确定好之后就该流程化地做注入和上传测试了。常见的注入点其实很有规律登录接口的参数、列表接口的分页参数、导出功能的文件名参数、订单号的查询参数。移动端 APP 和后端交互时参数格式化通常跟 Web 端一致所以 SQL 注入、XSS、XXE、文件上传这些 Web 漏洞在接口层普遍存在。我印象最深的是一次模拟测试某个 APP 的联系人同步接口userid参数直接拼接进 SQL 查询连编码转换都没做用sqlmap一把梭就直接扫出了注入点。然后顺着注入点读文件、写文件最后通过INTO OUTFILE写了一个 PHP 一句话到网站目录虽然当时权限比较低但已经足够证明服务器可以被完全控制。文件上传是另外一个高频 Getshell 入口。移动端的头像上传、OCR 识别、文件转发功能都是上传点。我一般先看代码里有没有校验Content-Type和后缀名的逻辑如果没有就直接传一个带.php或.jsp后缀的文件试试。即使被文件名重命名坑了也可以尝试.php5、.phtml、x.php.jpg、xx%00.jpg这类绕过方式。3.4 权限提升与内网判断接口层 Getshell 之后权限通常很低可能是www-data或者tomcat用户。这时候要快速确认几件事当前用户是否有 sudo 权限、系统上有没有常见的提权漏洞、内网网段有哪些、有没有跳板机的迹象。命令无非是id、sudo -l、uname -a、cat /etc/passwd、ip addr、arp -a。我曾经遇到过一种情况通过 APP 的导出功能打下来一个 Tomcatwww-data用户翻遍了目录什么敏感数据都没有。本来已经打算收工了结果顺手试了试sudo -l发现当前用户可以无密码执行某个运维脚本。最后通过这个脚本的反引号命令注入直接拿到了root权限。整个过程完全没用到内核漏洞靠的就是几个基础命令的排查习惯。4. 一次完整的模拟测试记录从 APK 到 Getshell4.1 目标与授权用一次模拟项目来完整走一遍链路。目标是某企业内部业务系统的 Android 端 APP安装包 15MB 左右未加固无混淆迹象授权范围明确包含该 APP 及其关联服务端。测试周期两天原则上是只验证风险不破坏业务数据。4.2 静态定位阶段先用apktool解包apktool d com.example.sysapp.apk -o sysapp_src解包比较顺利也没看到libjiagu.so这类加固特征于是直接上jadx-gui打开com.example.sysapp.apk。在搜索框输入http很快定位到一个叫ApiConstant的类public class ApiConstant { public static final String BASE_URL http://192.168.3.18:8080/appapi/; public static final String UPLOAD_URL http://192.168.3.18:8080/upload; }注意这里用的是内网 IP 的 HTTP 地址而且没有配置证书校验意味着测试机上只要连上能访问该网段的网络就可以直接抓明文包。继续往下看发现所有接口都定义在UserApi和AdminApi两个接口类里。UserApi里面有login、getUserInfo、getOrderList、exportData等接口AdminApi里有userManage、exportAllUsers。exportAllUsers这个接口名让我多看了一眼继续在jadx里搜它所在的方法发现请求路径是/appapi/admin/exportAllUsers。代码里只看到了GET注解没有任何权限验证。从命名推断这是一个全量用户导出接口大概率是管理端功能但这里的实现完全没做鉴权。4.3 接口测试与漏洞利用配置好 Burp 代理在手机或模拟器里正常登录 APP跑了一遍正常业务流程把请求都记录下来。然后直接在 Burp 的 Repeater 里请求GET /appapi/admin/exportAllUsers HTTP/1.1 Host: 192.168.3.18:8080让我意外的是这个接口真的返回了一个 JSON 数组里面包含大量用户账号、手机号、邮箱字段。没有带任何 Token也没有任何身份校验直接就是一个未授权访问的信息泄露接口。接着测试上传接口。UPLOAD_URL指向/upload代码里对应的上传逻辑在FileUploadActivity用的是MultipartFormData没有看到校验文件和扩展名的逻辑。用 Burp 构造一个包含 PHP 文件的请求发过去返回{code:0,path:/uploads/20250318_1425_test.php}。很明显上传后的文件直接落在 Web 目录下没有经过内容校验。用浏览器访问http://192.168.3.18:8080/uploads/20250318_1425_test.php直接返回了 PHP 的执行效果。到这里其实已经证明可以 Getshell 了但为了验证严重性我继续走了下一步。4.4 权限提升与影响确认确认能执行 PHP 代码后上传了一个简单的命令执行脚本然后通过它执行id和cat /etc/passwd。当前用户是www-dataWeb 服务的默认账户权限不高。查看服务器的 IP 和同网段主机列表发现这台机器能访问一个192.168.3.x的网段。我顺手在/var/www/下面翻到一份数据库连接配置里面对应的是另一台内网数据库服务器的地址账号密码均为明文。最终虽然没有直接打到那台数据库服务器的操作系统权限但配合前面的未授权导出的用户数据已经可以影响大量核心业务数据。从整个利用链来看一个 APK 反编译审计最终不只是把测试机的 PHP 执行拿了下来而是完整穿透了“客户端—服务端接口—上传—内网信息收集”这几层。防守方在看到这个报告后至少能清楚地知道一个移动端入口可以通向多么严重的风险面。5. 避坑指南与常见问题速查5.1 反编译过程中的高频问题apktool解包失败经常是因为 APK 使用了较新的资源表格式或者 AAPT2 编译的资源存在兼容问题。换成最新版apktool、加-s参数只解包资源不解码 dex都能绕开一部分问题。jadx-gui内存不足导致卡顿是因为某些大型 APP 的方法数极多把堆内存调到 4GB 以上会好很多命令是java -Xmx4g -jar jadx-gui.jar还有一类情况是AndroidManifest.xml解码乱码或报错。这通常不是文件损坏而是apktool无法完整解析 AOSP 的新二进制 XML 格式。遇到这种情况可以先尝试jadx直接读 APK它能直接解析 Manifest 并展示成可读文本。5.2 代码审计中容易忽略的盲区千万别只看业务逻辑代码很多后门和风险藏在Application类的onCreate方法里可能有远程配置拉取、初始化调试组件。Service组件里尤其是有bindService跨进程调用的场景。BroadcastReceiver里动态注册的广播接收器如果处理了外部 Intent可能被拉起并执行操作。WebView的addJavascriptInterface如果注册了原生方法给 JS 调用配合远程 URL 可控可以直接让 JS 调用任意系统能力。第三方统计、推送、热更新 SDK。热更新框架本身就是一个远程代码执行通道如果更新地址可以被污染甚至不需要其他漏洞。每次审计建议专门拨出一段时间只翻这些“非业务”代码区域收获往往比业务逻辑更多。5.3 测试节奏与注意事项测试中最大的坑不是技术而是把自己陷在细节里。建议给每个阶段设定明确的时间上限APK 反编译静态审计花费的时间不超过 40%接口测试和漏洞利用花掉更多的比例剩下时间留给权限提升和报告梳理。如果某个加固壳或者混淆代码盯着看了两小时还没思路直接换工具链或者换一个突破口不要在单点上死磕。另一个容易被忽视的问题是测试数据的污染。给服务器传 webshell、写文件、改数据时一定要避开生产环境里的真实业务数据。即使授权了也应该优先选择测试账号、测试环境。万一造成业务中断就算最终报告写得再漂亮那也是事故而不是成果。5.4 问题排查速查表症状可能原因处理方式apktool 解包报错APK 签名或资源表兼容问题升级 apktool 到最新版本必要时加-sjadx 打开卡顿内存不足加大-Xmx参数关闭多余标签页反编译后类名全是 a/b/c启用了混淆配合日志 TAG、字符串、异常信息辅助定位核心类被抽空加固了使用 frida 内存 dump 或动态调试还原逻辑接口请求都被重定向到登录全局鉴权拦截检查 APP 是否有自动加签逻辑尝试绕过 token 校验上传文件无法解析扩展名被黑名单拦截尝试多种后缀、解析差异、双扩展名绕过6. 红队视角的几个总结习惯个人向做这类测试我始终有一个原则每条利用链都要用“如果我是防守方要怎样才能发现和阻止”的角度去复盘。从 APK 反编译到 Getshell中间其实暴露了很多可以拦截的机会点比如服务端上传接口没有做内容检测、管理端接口没有做鉴权、客户端硬编码密钥没有做一些扫描。红队能拿到权限不是因为单个漏洞厉害而是防守方在多个环节都有缺失。如果你是在企业里做安全工作建议自己也试着用这条路径测一遍自家 APP。很多团队整天盯着 SOC 告警却没人真正打开过自家 APK 里的ApiConstant类看一看。个人经验是拿自己 APP 走一遍反编译审计半小时就能发现几个开发都不知道的敏感信息接口。这个习惯一旦养成防御水位比单纯堆设备高得多。最后分享一个小技巧审计完 APK 以后把反编译出来的代码保留一段时间不要测试完就删。因为你在审计过程中发现的接口清单、签名逻辑、密钥位置在写报告和做复盘时都要反复引用。我自己习惯把这类项目单独建一个目录按目标、工具、发现、利用链四个子目录整理后续查旧项目时能省大量时间。