好今天的内容是第2天。第1天我们盘了整体路线今天开始真正动手碰工具。在Android逆向这条路上ADBAndroid Debug Bridge是你每天要敲几百次的命令不需要犹豫也不需要觉得它太基础所以跳过——我见过太多人一上来就喊Frida、Xposed结果连目标应用的安装包都拉不出来、日志里全是权限错误问题恰恰出在ADB没玩明白。这篇就把ADB的高频命令和它在逆向实战里的用法彻底讲透。1. 先弄清ADB的定位它解决的核心问题不是调试而是完全控制1.1 一句话理解ADB的架构ADB是个典型的C/S架构工具由三部分组成Client端就是你电脑上敲的adb命令Server端电脑后台自动启动的守护进程负责监听5037端口管理Client和设备的通信Daemon端adbd运行在Android设备内部的守护进程真正在设备上执行命令。我习惯用一个类比去理解它ADB就像一个远程遥控器加文件保险柜钥匙的组合体。遥控器让你能隔空指挥手机做各种操作保险柜钥匙让你能打开App的数据目录、拿走它的安装包、看它的日志。而这套组合的核心价值在于——它不需要在手机上额外装任何App只要打开USB调试电脑就能和手机建立信任通道。1.2 为什么逆向工作流里ADB是绝对的前置依赖很多刚入坑的朋友会有个误区觉得我后面用Frida、用Objection就够了ADB只是连一下设备。实际上恰恰相反你在逆向里遇到的绝大多数问题最后都要回到ADB来解决想抓目标应用的APK安装包需要adb pull从系统目录拉出来想看App运行时的日志、崩溃信息需要adb logcat想模拟点击、滑动、输入需要adb shell input想检查App加载的so文件是否落地、加固壳是否释放子包需要adb shell ls去翻data目录想绕过反调试或动态修改参数往往也要先用ADB把设备控制权拿稳。说白了ADB是你在Android设备上所有后续操作的地基。地基不稳后面搭什么都塌。2. 连接与授权90%的ADB问题都出在这一步的细节上2.1 安装别只看能敲命令版本冲突才是大坑先说最简单的装ADB。Windows上最稳妥的做法是下载Google官方的platform-tools解压后把路径加到系统PATH环境变量里。但这里有个高频问题直接对应一个搜索热词——检测到电脑上同时运行了多个版本的adb服务。这个报错我见过至少几十次了典型场景是电脑里装了Android Studio自带的platform-tools又装了某个脚本工具内置的旧版adb还可能在某个国产手机助手目录下藏了一份更老的adb.exe。多个版本混在一起Server端口被抢占连设备就会出现adb server version (X) doesnt match this client (Y)这类错误。我建议的解决办法很简单粗暴全盘搜索adb.exe把非官方路径下的adb文件全部清理掉保留Android Studio自带的那份即可在系统环境变量PATH中只保留一个platform-tools路径重启终端跑adb version确认版本一致。还有一个容易被忽略的点手机上开启USB调试后插上数据线Windows第一次会识别出一个名为Android Composite ADB Interface的设备。如果设备管理器里这个设备带着黄色感叹号说明USB驱动没装好这时候adb devices列表会显示一堆问号。解决方法是装对应厂商的USB驱动或者直接换一根数据线——很多杂牌线只有充电能力根本没有数据传输通道这个问题在Windows上极其常见而Mac/Linux上反而很少遇到。2.2 adb unauthorized到底在卡你什么授权机制的完整排查链路adb unauthorized怎么解决是另一个高频搜索词。很多人第一次插上手机敲adb devices看到unauthorized就慌了以为手机坏了。其实这是Android的安全机制在起作用——手机屏幕上弹出了一个允许USB调试吗的确认框你没点允许电脑永远无法接管设备。但这个授权的坑远不止点一下允许这么简单。真正常见的情况是你点了始终允许但授权记录被清掉了手机开发者选项里有个撤销USB调试授权一旦触发所有电脑都需要重新授权换了一台电脑或者换了数据线Android的授权是绑定电脑RSA指纹的换电脑必重新授权手机屏幕碎了/黑屏没法弹窗这时候很麻烦只能想办法进recovery模式或找备用屏幕这块按下不表。如果你遇到的是第一次插上就持续unauthorized按这个顺序排查拔掉数据线关闭USB调试再重新打开重新插线在电脑端跑adb kill-server再adb start-server强制重启服务手机端如果有弹窗果断勾选始终允许并点击允许检查开发者选项里是否开了USB调试安全设置——部分MIUI、ColorOS有额外的一层开关不开的话每次都会回到unauthorized状态。我之前帮人远程排查过一个问题手机厂商定制系统把USB调试和USB安装分成了两个开关只打开前者还不够必须同时打开USB调试安全设置才能完全授权。这类问题在纯原生Android上不存在但在国产定制ROM上非常普遍。2.3 没有USB线也能连无线调试的正确打开方式逆向工作里有一类设备是不方便插线的比如电视盒子、车机、VR一体机。搜索热词里那些中兴盒子adb二维码识别器吉利车机强制进入adb模式quest2 adb驱动其实指向同一个需求怎么在没有USB线的情况下完成ADB连接。无线ADB的标准操作分两种情况Android 11及以上的原生系统开发者选项里直接有无线调试开关开启后手机会显示一个IP:端口和配对码电脑端执行adb pair IP:端口 配对码完成握手然后adb connect IP:端口正式连接。这套流程是Google官方的非常干净。Android 10及以下的老系统需要USB线先连接一次执行adb tcpip 5555然后拔掉线执行adb connect 设备IP:5555。所谓无线其实还是靠第一次有线连接激活的。实战经验提醒无线调试最大的问题是连接不稳定。设备休眠、Wi-Fi网络切换、IP地址变化都会导致连接突然断开。我的习惯是拿到设备IP后先在电脑端ping一下确认网络通无线调试状态下少跑大数据量的pull/push操作如果确实要传大文件尽量切回有线。3. 高频命令的实战拆解逆向干活就靠这几板斧3.1 设备信息先摸清你手里这台机器的底细连接成功后第一件事永远是确认设备状态和基本信息。我自己固定的命令习惯是这样的adb devices -l这条命令输出里除了序列号还会带上设备型号、品牌、系统版本这些关键信息。device状态表示已正常连接unauthorized表示未授权offline表示连接异常。看到offline的时候我的第一反应永远是重启adb服务而不是盲目换线——大概率是Server状态错乱了。确认设备在线之后我通常会用几条命令快速摸清设备底细adb shell getprop ro.product.model adb shell getprop ro.build.version.release adb shell wm size adb shell wm densitygetprop是读取系统属性的命令后面跟的ro.product.model是设备型号、ro.build.version.release是Android版本号。wm size和wm density则是获取当前屏幕分辨率和像素密度。这几条信息看着简单但在后续逆向决策里很关键——Android版本直接决定了你能不能用新版Frida、能不能绕过某些系统限制屏幕分辨率决定了你模拟点击的坐标该怎么算。3.2 包管理三板斧install、pm list、am start包管理是逆向工作里使用频率最高的一组命令我把它们称为三板斧。第一板斧安装APKadb install -r -t target.apk-r代表覆盖安装保留数据-t代表允许安装测试包这两个参数是逆向调试时的标配。如果遇到签名冲突报错INSTALL_FAILED_UPDATE_INCOMPATIBLE先卸载旧版本再装如果报INSTALL_FAILED_TEST_ONLY说明APK是testOnly标志的必须加-t参数。这里有个容易忽略的细节逆向过程中我们经常要安装重打包后的APK但目标是系统应用的时候直接装会失败。这时候要么用-r加--user 0指定安装用户要么把APK push到/system分区用root权限安装。前一种方式更简单对初学者更友好。第二板斧查包信息adb shell pm list packages adb shell pm path 目标包名pm list packages可以带过滤参数比如-3表示只看第三方应用-s只看系统应用。在逆向场景里我几乎不看全量列表都是先过滤出第三方应用再结合包名关键词去筛选目标。pm path则用于查询某个应用安装包在系统中的具体路径比如adb shell pm path com.example.target输出通常是package:/data/app/~~哈希/com.example.target-随机后缀/base.apk。有了这个路径我们就能用后面的adb pull把APK从设备里完整拉出来做静态分析。第三板斧启动与停止adb shell am start -n 包名/具体Activity adb shell am force-stop 包名这里有个实用技巧很多新手不知道Activity该怎么写可以用adb shell dumpsys package 包名去查输出里找到android.intent.action.MAIN对应的Activity就是桌面入口。比如查到了MainActivity启动命令就是am start -n com.example.target/.MainActivity。当你想清掉应用重来am force-stop比手动滑动退后台更干净直接杀掉整个进程可以保证下一次启动是从冷启动开始。3.3 文件交互pull和push是逆向的搬砖基本功adb pull 设备路径 本地路径 adb push 本地路径 设备路径这两条命令是Android逆向的搬砖工具。最常见的场景就是把刚才pm path查到的base.apk拉到电脑上adb pull /data/app/~~哈希/com.example.target-随机后缀/base.apk ./target.apk这里有个必须强调的权限前提/data/app这个目录在不同Android版本上访问权限不一样。Android 8之前普通adb shell用户就能直接访问Android 9及以上系统收紧权限普通shell用户通常无法直接pull这个目录下的APK。解决办法有三个如果设备已rootadb root后重新执行pull如果目标应用本身是debuggable用adb shell run-as 包名进入应用私有目录再拷贝到可读路径用adb backup提取应用数据包但这个方案在Android 12以上基本失效了。还有个逆向中特别实用的场景想判断一个App是否把dex或so文件释放到了私有目录可以这样操作adb shell run-as com.example.target ls -lR /data/data/com.example.target但凡看到files/下出现分外的子目录、密密麻麻的dex文件基本可以断定这个App用了壳或动态加载方案后续分析方向就该往脱壳上靠。3.4 logcat日志不干净信息量减一半日志抓取是动态分析的核心但90%的新手都用错了。adb logcat直接裸跑会刷屏刷到你怀疑人生正确打开方式是先用-c清空缓冲区再用级别过滤和标签过滤锁定目标adb logcat -c adb logcat -v time *:E*:E表示只输出Error级别以上的日志级别还可以换成W警告、I信息、D调试。实际逆向中我更常用的组合是按目标应用进程过滤adb logcat --pid$(adb shell pidof 包名)这条命令先动态拿目标进程的PID再按PID过滤日志——效果堪比给日志通道装了个定向喇叭只让那个App的日志进来其他进程的全部静音。如果你同时开了Frida和Xposed还能通过logcat看到注入脚本的报错信息排查问题效率翻倍。另外一个实用参数是-b切换缓冲区。默认logcat缓冲区分main、events、crash三个子区想看崩溃栈就用adb logcat -b crash我在分析一个App崩溃原因时经常是先开崩溃缓冲区抓栈再开主缓冲区看上下文两条命令交替用。4. 设备交互实战把一个完整的逆向排查流程走一遍4.1 场景新拿到一台设备目标App闪退怎么用ADB定位光讲命令没意思我拿一个真实高频场景来串一遍设备上装了目标App一点就闪退。这时候ADB的正确用法是第一步确认包名和进程状态adb shell pidof 目标包名如果没有输出说明App已经崩透了如果有PID说明它还挂着App只是弹了个崩溃框。第二步抓崩溃日志adb logcat -b crash -d crash.txt-d表示抓完立即结束适合把日志重定向到本地文件来分析。打开crash.txt翻到最后的AndroidRuntime FATAL EXCEPTION段就是崩溃根因所在。第三步冷启动复现观察完整日志adb logcat -c adb shell am force-stop 目标包名 adb shell am start -n 目标包名/.MainActivity adb logcat -v time *:E这套组合拳能覆盖绝大多数闪退问题的定位。相比直接用Android Studio去debugADB这种命令行方式更轻量也更适合逆向工作流中目标App根本不让调试的场景。4.2 模拟操作与屏幕控制wm命令有多好用动态分析的时候经常需要模拟点击、滑动、输入。对应的命令是adb shell input tap x y adb shell input swipe x1 y1 x2 y2 时长 adb shell input text 要输入的内容这里的坐标是绝对屏幕坐标单位是像素。所以前面第3章里那个wm size命令的用途就体现出来了——不知道屏幕分辨率就不知道坐标范围。搜索热词里那条adb shell wm设置应用屏幕方向对应的完整命令其实是adb shell wm size 1080x1920 adb shell wm density 420 adb shell settings put system user_rotation 1wm size可以直接修改当前屏幕的逻辑分辨率wm density修改像素密度settings put system user_rotation则是把屏幕方向固定为横屏1是横屏0是竖屏。在分析一个只在横屏下运行的App时这句命令能免去每次手动旋转屏幕的麻烦。避坑提醒wm size和wm density的修改是即时生效的但副作用也大——如果把分辨率改得太夸张手机UI会彻底错乱。我的习惯是改之前先用原始值做记录分析完立刻恢复。4.3 多设备会场参数-s的用法逆向工程师桌上同时摆三四台测试设备很常见所有不区分设备的指令会变得混乱。解决方式是给adb命令加-s参数指定设备序列号adb -s 设备序列号 shell wm size adb -s 设备序列号 install target.apk先用adb devices拿到所有设备的序列号再在任何命令前加-s 序列号就能精准指挥某一台设备。批量操作的时候可以写一个简单的shell循环脚本把设备序列号遍历一遍逐台执行同一套指令效率会高很多。4.4 命令行里的ADB从哪调出来cmd和PowerShell的环境细节cmd怎么调出adb这个搜索热词暴露了一个大问题很多新手从零开始看教程连编译环境都没配好。完整路径是这样的方式A推荐把platform-tools完整路径加入系统环境变量PATH之后在任何cmd或PowerShell窗口直接敲adb都能被识别方式B临时用不配环境变量每次在当前目录下用完整路径调用比如D:\platform-tools\adb.exe devices方式C快速验证直接在platform-tools目录下打开命令行窗口然后.\adb version验证可用性。就我个人体验来说环境变量配好之后日常用Windows Terminal搭配PowerShell把adb当常规命令用是最顺畅的。不要在环境变量这件事上省时间配好之后再也不用为调不出adb烦恼。5. 建立你自己的ADB速查习惯比背命令更值钱的是场景感5.1 不要背命令要建场景-命令对应表ADB的命令数量并没有想象中那么多真正高频的也就二三十条。但如果你只是零散地背命令很容易陷入背了忘、忘了背的死循环。我比较推荐的做法是按场景去组织命令比如场景核心命令组合说明连不上设备adb kill-server adb devices强制重启服务解决离线问题提取目标APKpm path 包名pull 路径先找路径再拉文件定位崩溃原因logcat -b crash -d直达崩溃缓冲区模拟用户操作input tap/swipe/text结合wm size计算坐标清理应用状态am force-stop 包名彻底杀掉进程冷启动复现判断加固壳run-as 包名 ls -lR看私有目录文件每个场景后面跟一句什么时候用比单纯列命令杀伤力强十倍。我给身边同事做的速查表也是按这个格式放在工位上随查随用。5.2 对抗命令失效的三个保命思路第一个保命思路是关于设备状态的ADB连接出现异常时不要纠结于某一条命令有没有写对先走adb kill-server→ 手机重启ADB调试开关 → 重新插线这条老路能解决七成问题。第二个保命思路是在权限上的日常在data目录下执行ls、pull频繁遇到Permission denied基本都绕不开root或run-as这个坎。建议第一时间确认设备是否允许adb root如果不行再去判断目标应用是否debuggable。不要试图用一些非常规技巧绕过权限检查纯属浪费时间。第三个保命思路是脚本化adb devices的输出格式在跑脚本时不一定好解析可以用adb devices | grep device$来过滤出真正处于正常状态的设备行避免把unauthorized的设备也统计进去。另外凡是需要反复执行的重复操作我都建议写成shell脚本而不是每次都手敲——脚本里加set -e任何一步出错立即停止不会把问题扩大。5.3 常见问题速查一份可以直接抄的清单最后把这一路走来最常遇到的问题整理成清单都是真实会踩到的坑问题ADB命令提示不是内部或外部命令说明platform-tools没加PATH或当前cmd窗口没刷新重新打开命令行窗口即可。问题adb devices里显示offline优先adb kill-server再adb start-server不行就换数据线。问题能连上但install报INSTALL_FAILED_INSUFFICIENT_STORAGE设备存储满了先清理缓存adb shell pm list packages -d找找被禁用应用。问题logcat持续刷屏找不到自己想要的日志加上进程PID过滤或者把*:E级别收紧先看Error再往前翻上下文。问题run-as 包名报Package xxx is not debuggable目标应用不可调试要么换root方案要么改用Frida的spawn模式启动。问题无线调试连上之后过一会儿就断多半是Wi-Fi休眠策略导致的把设备的Wi-Fi设置为永不休眠或者干脆在有线模式下完成大工程。这些坑有一个共同特点都不是ADB本身的问题而是环境、权限、设备状态的问题。理解了ADB的运行机制和Android的调试授权逻辑之后大部分问题都能一眼看穿本质。我自己学ADB的过程走了不少弯路最深的体会是这门工具的高频命令其实不用背真正值钱的是什么时候想起用它。在逆向分析里ADB不是终点而是所有后续动态分析的起点。哪怕你后面熟练掌握了Frida脚本、掌握了一百种脱壳姿势ADB依然是每一轮实测里的那根地基桩桩打得稳上面所有操作才不会歪。今天把ADB的设备交互部分打通下一步就可以往真正的逆向核心技术走了——下一章我准备聊聊静态分析阶段最常用到的APK结构拆解和Manifest信息挖掘。先把今天这几条命令实际跑一编熟悉到形成肌肉记忆你会发现后面所有工具的接入都顺滑得多。