1. 开篇为什么学逆向第一天先啃 ADB 这碗饭如果你决定踏上 Android 逆向这条路那 ADBAndroid Debug Bridge安卓调试桥就是你必须先握在手里的第一把钥匙。很多人一上来就急着学 smali、Frida、脱壳结果连设备都连不上、日志抓不下来、文件pull不出来卡在环境这一关直接劝退。我见过不少新手在群里问adb devices 看不到设备怎么办一问全是驱动没装、端口被占、版本不对这些基础问题。ADB 的作用说白了就一句话它是电脑和安卓设备之间的官方桥梁。所有逆向操作——安装调试包、抓取应用日志、查看进程状态、复制数据文件、模拟点击输入——几乎都得先通过 ADB 才能进行。它是 Google 免费提供的官方工具怎么用都合规合法也不存在任何灰色问题。这一天的内容我分五块讲环境搭建、连接设备、应用与文件管理、logcat 日志分析、shell 高频排查命令最后附一份实战练习清单。你可以把它当作一份可以直接抄作业的 ADB 命令手册也可以当作从零开始的环境搭建指南。无论你是纯小白还是有点基础想补漏按着走一遍后面 98 天会轻松很多。提示这系列内容面向的是 App 安全分析、学习调试技巧、自研软件调试等正当用途。请只在你自己拥有的设备或已获授权的设备上操作不要用于任何未经许可的场景。2. 环境准备装对工具省掉 90% 的坑2.1 三种安装方式怎么选先说安装 ADB。这里我推荐三条路按优先级排序。方案一直接装 Android Studio最省心如果你以后还要做动态调试、看布局层级、用模拟器那 Android Studio 是绕不开的。装完 Android StudioSDK 自带的 platform-tools 里就有 adb.exe。在 Android Studio 里打开 SDK Manager勾选 Android SDK Platform-Tools 装上就行。Windows 下默认路径类似C:\Users\你的用户名\AppData\Local\Android\Sdk\platform-tools。方案二只下载 Platform-Tools 压缩包轻量快速如果你只想用命令行工具不想背一个几个 GB 的 IDE那就直接去 Google 官方开发者网站下载 Platform-Tools 包。Windows 版解压后就一个文件夹里面有 adb.exe、fastboot.exe 等几个文件足够日常用了。这个方案我一直推荐给只想走命令行路线的朋友干净、无冗余、不占空间。方案三系统包管理器安装Linux 或 macOS 用户可以试试sudo apt install adb或brew install android-platform-tools一条命令装好版本跟着仓库走。不过注意部分 Linux 仓库里的 adb 版本可能偏旧遇到adb server version mismatch这类问题的时候优先排查这个。2.2 环境变量配置与版本校验无论哪种方式安装后建议把 platform-tools 路径加到系统 PATH 环境变量里。Windows 用户操作此电脑右键 → 属性 → 高级系统设置 → 环境变量 → 在 Path 里新增一行 platform-tools 的路径。这样你在任意目录下敲adb都能直接识别不用每次 cd 到工具目录。配置完打开新的命令提示符窗口输adb version看输出。正常情况会打印类似Android Debug Bridge version 1.0.41和版本号。如果提示adb 不是内部或外部命令也不是可运行的程序或批处理文件不用慌八成是环境变量没生效或路径写错。新开一个终端窗口通常能解决因为改完环境变量老窗口不会自动刷新。另外啰嗦一句保持 adb 版本和 device 端协商协议一致。以前踩过坑——电脑上装了两个版本的 adb一个在 Android Studio 目录一个在 platform-tools 目录启动时检测到多个 adb server 直接报版本冲突还连带设备识别不稳定。遇到这种问题建议只保留一个版本其余的删干净或从 PATH 里去掉再执行adb kill-server和adb start-server重启服务。3. 连接设备从 USB 到无线把看不见变成随便连3.1 三种连接方式与调试模式USB 连接这是最基础的方式也是排查其它连接问题的起点。前提是手机开 USB 调试设置 → 关于手机 → 连点版本号 7 次开发者选项就出来了进去打开 USB 调试。有些手机还有仅充电模式下允许 ADB 调试的选项也一并打开。连线后跑adb devices。输出结果有两种典型情况显示设备序列号 device说明连接成功状态正常。显示设备序列号 unauthorized说明手机弹窗允许 USB 调试吗你没点允许或者点了以后没记住授权。解决方法是拔线重插、重新弹窗也可以执行adb kill-server后重新连如果还不行在手机开发者选项里撤销 USB 调试授权后重新授权。无线连接局域网调试USB 线总有不够用或嫌麻烦的时候。Android 11 及以上系统支持无线调试正式功能操作流程是手机和电脑连同一个 Wi-Fi。手机开启无线调试在开发者选项里可以看到 IP 地址和端口。电脑上执行adb pair IP:端口输入手机上显示的配对码。配对成功后执行adb connect IP:端口即可。如果是 Android 10 及以下老系统可以用传统方式先用 USB 连接执行adb tcpip 5555让设备监听 5555 端口拔掉线再执行adb connect 设备IP:5555。这种方式适合模拟器或嵌入式屏幕调试场景前提是网络环境可控别在不可信的公共 Wi-Fi 上这么玩。模拟器连接模拟器一般会自动注册 ADB 端口比如 Android Studio 模拟器默认adb devices就能看到 emulator-5554。遇到连接不上试adb connect localhost:端口手动指定。3.2 adb devices 输出解读与状态判断adb devices是使用频率最高的命令它的输出虽然简单里面信息量不小。状态字段无非三种device在线可用、unauthorized授权未通过、offline设备在线但通信异常。offline多半是 adb server 版本和设备端不匹配或者 USB 线质量差导致数据链路不稳定。遇到 offline先换线、换 USB 口、重启 adb server这个顺序屡试不爽。还有一个隐藏参数-l执行adb devices -l可以看到设备型号、产品名等详细信息当你手头同时插着好几台设备时用这个命令区分谁是谁非常方便。4. 高频命令精讲这些命令每天都用得上4.1 安装与卸载应用不只是 install/uninstall 那么简单adb install和adb uninstall是入门阶段最先接触的命令但细节很多。安装 APK 的基本用法是adb install 路径/你的应用.apk默认行为是如果设备上已有同名应用直接报错提示覆盖安装失败。要覆盖安装必须加-r参数adb install -r 路径/你的应用.apk还有一个我经常用的参数-t允许安装测试包。逆向场景下经常要装各种调试版、Test 版 APK不加-t有时会直接拒绝安装。完整高频组合是adb install -r -t 路径/你的应用.apk另外-d表示允许降级安装用于版本号比现有版本低的 APK调试中回滚版本时能用上。卸载命令相对简单但需要写包名而不是应用名adb uninstall com.example.app如果你想卸载但保留数据比如某些场景要保留数据重新装壳用adb uninstall -k com.example.app。不过大多数逆向分析场景我们反而希望数据干净很少用-k。包名怎么查推荐一个命令adb shell pm list packages | grep 关键字它能列出所有已安装应用的包名配合 grepWindows 下是 findstr过滤关键字。比如想找微信adb shell pm list packages | grep tencent能看到com.tencent.mm。查自有应用也同理。4.2 文件传输pull 和 push 的实战场景文件传输就两条命令adb pull 设备路径 本地路径 adb push 本地路径 设备路径pull 是把设备上的文件复制到电脑push 反过来。逆向中 pull 最常用的场景是拉取应用的私有数据目录。Android 应用的数据存放在/data/data/包名/下包括数据库、SharedPreferences、缓存文件。需要 root 权限才能读取不过这是正规的调试技术配合自己设备或测试设备操作完全没问题在没有 root 的普通手机上会提示权限不足这时候一般先考虑使用 run-as 命令后面讲。举一个实际例子要分析某个应用的本地数据库先执行adb shell run-as com.example.app ls /data/data/com.example.app/databases/ adb exec-out run-as com.example.app cat /data/data/com.example.app/databases/app.db local.db检查完本地数据库文件再决定后续分析方向。push 的场景通常是往设备里塞测试脚本、so 库或配置文件。注意大文件传输时别把终端关了传输完成后会回到提示符传一半断了就重新执行这个没什么捷径。4.3 查看设备信息一条命令干翻多种需求日常调试高频需求是快速了解设备状态。以下命令按用途拆开讲adb shell getprop ro.product.model # 设备型号 adb shell getprop ro.build.version.release # Android 大版本 adb shell wm size # 屏幕分辨率 adb shell wm density # 屏幕像素密度 dpi adb shell dumpsys battery # 电池状态 adb shell df -h # 磁盘占用 adb shell cat /proc/cpuinfo # CPU 信息wm命令还能在调试布局时临时改屏幕方向和尺寸模拟不同机型效果比如adb shell wm size 1080x2340 adb shell wm density 420改完用adb shell wm size reset和adb shell wm density reset恢复。这个在适配测试时挺实用但要注意改完分辨率可能导致界面布局异常心里有个数。dumpsys 是个宝库adb shell dumpsys activity top能看当前前台 Activityadb shell dumpsys package 包名能看应用详细信息adb shell dumpsys window能看窗口层级。逆向分析中这几个命令比很多付费工具都管用。5. logcat 日志分析读懂 App 的心里话5.1 先搞懂 logcat 的基本逻辑Android 系统的日志系统叫 logcat它会输出系统内核、Java 层、Native 层各个模块的日志。执行adb logcat会持续滚动输出信息的数量级别和翻书一样快不加以筛选很难找到目标。logcat 的日志行包含几个关键字段日期时间、进程 IDPID、线程 IDTID、日志级别V/D/I/W/E、标签Tag、内容。Tag 是定位问题的核心线索应用开发者通常用自己的包名或业务名当 Tag看到熟悉的应用名基本就知道这段日志是谁打的。5.2 刷选过滤让日志不再是噪音最常用的过滤方式是按 Tag 过滤adb logcat -s 你的Tag-s是静默模式只显示指定 Tag 的日志。比如分析某个网络库时可以adb logcat -s OkHttp按包名过滤需要用到--pid参数# 先拿包名的 PID adb shell pidof 包名 # 再按 PID 过滤 adb logcat --pid进程ID这个组合拳在分析单个应用时极其好用其它进程的日志全部屏蔽专注看目标应用的输出。按日志级别过滤也很常见adb logcat *:E只看 Error 级别adb logcat *:W看 Warning 及以上。调试崩溃问题先跑 E确认没关键错误再放宽到 W。日志量大的时候你会想让它停在某个时刻别滚屏。配合 grep 管道adb logcat | grep -i 关键字Windows 下用findstradb logcat | findstr 关键字5.3 录制日志与实时抓取现场无法复现问题或需要保留证据时把日志写到文件是常规操作adb logcat -v time logcat_输出.txt-v time会在每行前加时间戳。你可以在终端开着这个命令同时去复现问题复现完按 CtrlC 停掉日志就完整保留了。分析抓回来的文件我习惯先把含有FATAL EXCEPTION、AndroidRuntime、Force finishing这些关键字的行筛出来定位崩溃再往前回看调用前几百行的上下文。实际调试中logcat 还有一个容易被忽略的用法检测应用启动时间和 Activity 切换顺序。执行adb logcat -s ActivityTaskManager:I能看到系统打印的 Activity 启动日志逆向分析 app 页面跳转逻辑时这个命令比手动点按钮再猜测靠谱得多。6. shell 高频调试命令在设备里过日子6.1 进程与内存一眼看清 App 在干嘛ADB 的 shell 模式相当于在设备上开了一个远程终端大量 Linux 命令都可以用。先来几个进程排查adb shell ps -A | grep 包名 adb shell top -n 1 | head adb shell dumpsys meminfo 包名ps -A | grep找进程 PIDtop看 CPU 占用排行dumpsys meminfo看单个应用的 Java 堆、Native 堆、图形内存等详细分布。做个压力测试或内存泄露排查时这三个命令按顺序来就能定位大概方向。6.2 run-as不用 root 也能读应用私有数据如果你手头是一台没有 root 的测试机又想看应用自己的数据目录run-as就是救命稻草。条件是应用必须是 debug 版本或可调试版本adb shell run-as 包名 ls adb shell run-as 包名 cat files/某个文件这条命令的原理是以目标应用的身份执行命令从而绕开权限限制。逆向场景中分析某个自带加密逻辑的应用时run-as配合ls -l看文件权限能帮你判断哪些文件是普通缓存、哪些是敏感配置。不过要说明正式发布版的 App 通常不可调试run-as 会报Package xxx is not debuggable这时候就只能上 root 设备或其它合法途径分析了。6.3 模拟输入与屏幕操作这里要说一个常用但容易误用的能力adb shell input可以模拟点击、滑动、输入文字是 UI 自动化测试和简单交互调试的利器。adb shell input tap x y # 坐标点击 adb shell input swipe x1 y1 x2 y2 # 滑动手势 adb shell input text HelloWorld # 输入英文文本 adb shell input keyevent KEYCODE_BACK # 模拟返回键坐标怎么拿配合adb shell uiautomator dump它能把当前界面的控件层级和坐标导出来分析控件属性后再决定点击哪个坐标。这套方法在实际逆向中常用于自动点击弹窗、绕过引导页、遍历页面按钮等场景。截屏录屏也属于高频需求adb exec-out screencap -p screen.png adb shell screenrecord /sdcard/demo.mp4注意screencap加上exec-out不会输出多余的干扰信息重定向出来的文件就是干净图片我踩过直接用adb shell screencap -p 导致文件损坏的坑推荐用 exec-out 版本。6.4 四大组件信息查询Activity、Service、Broadcast、ContentProvider逆向分析一个 App 的结构时四大组件信息是绕不开的一手资料。ADB shell 里对应的查询命令adb shell dumpsys activity activities # 当前 Activity 栈 adb shell dumpsys activity services # 服务列表 adb shell dumpsys package 包名 # 包信息含注册的组件 adb shell pm query-activities --brief -a ACTION # 按 Intent 动作查询pm query-activities平时用得少但在逆向分析时很有用你想知道系统里哪些 App 能响应某个 Intent比如拨号、打开网页这条命令一目了然。还有adb shell am start -n 包名/完整Activity名直接拉起某个 Activity做入口测试时必用。6.5 设置管理用命令改系统设置adb shell settings命令可以读写系统全局设置不需要 root。举个例子永久关闭动画能让测试环境更干净adb shell settings put global window_animation_scale 0 adb shell settings put global transition_animation_scale 0 adb shell settings put global animator_duration_scale 0还有几类高频 settings改屏幕超时、改 DNS、查询安装来源等。不过提醒一个坑有的设置项被厂商定制改过路径直接 put 可能无效需要先adb shell settings list global看一遍当前完整配置再决定改哪项。7. 实战综合演练用 ADB 搞定一个完整分析流程7.1 场景一抓取 App 启动时崩溃日志假设你拿到一个 App点开就闪退先用 ADB 走一套流程定位问题连接设备并确认在线adb devices。清除旧日志adb logcat -c。启动目标应用adb shell am start -n 包名/入口Activity。等待几秒后抓取日志adb logcat -d crash.txt。用文本编辑器打开搜FATAL EXCEPTION或AndroidRuntime崩溃堆栈就在下方。这套流程比在手机上盲点快得多而且能拿到完整堆栈直接看到崩溃发生在哪个类、哪一行。唯一的注意事项是步骤 3 的入口 Activity 不确定时先用adb shell monkey -p 包名 1随即触发一次启动代替。Monkey 是 Android 自带的压力测试工具用它来拉起应用也可以就是触发次数多时可能乱点慎用。7.2 场景二查看某个 App 的私有文件状态拿到一个应用后先看它的数据目录adb shell run-as 包名 ls -lR /data/data/包名/输出里能看到 databases、shared_prefs、files、cache 等目录。数据库文件如果存在直接 pull 出来在电脑上用 SQLite 工具分析。shared_prefs里的 XML 文件记录了偏好设置很多应用的配置逻辑在这里一目了然。看完文件结构基本就知道这个应用把数据放在哪一层后续加密、解密、篡改的切入点也就有了。7.3 场景三分析 UI 层级跳转逻辑在应用的某个页面执行adb shell uiautomator dump /sdcard/ui.xml adb pull /sdcard/ui.xml然后打开 XML 文件查看控件的 resource-id、text、bounds 等属性。把几个关键页面的 UI 结构都 dump 下来对比分析能看出页面之间通过什么动作跳转、哪些控件是隐藏的、有哪些不显示的 View。对自动化点击和绕过风控非常有用当然你要确保自己有合法授权。7.4 场景四设备指纹与运行环境识别很多应用会读取设备信息来做风控或唯一标识。用下面这些命令收集设备信息adb shell getprop ro.build.fingerprint # 设备指纹 adb shell getprop ro.serialno # 序列号 adb shell getprop ro.product.device # 设备代号 adb shell cat /proc/net/arp # ARP 表 adb shell getprop net.dns1 # DNS 配置这些信息是后期分析设备指纹计算逻辑的一手材料。比如某些 App 会综合 Android ID、MAC 地址、IMSI 等生成设备唯一码而你手上这批信息正好对应其中的几个输入项后续核对算法时直接对照。8. 高频报错排查表老司机的踩坑实录新手在使用 ADB 过程中报错是家常便饭。我整理一张排查表每一行都是亲手踩过的坑。报错信息或现象常见原因解决思路adb: command not found没装 adb 或环境变量没配安装 platform-tools 并配置 PATH重开终端验证adb server version mismatch电脑上有多个版本 adb只保留一个删掉旧的或从 PATH 排除kill-server 后重启error: device unauthorizedUSB 调试授权未通过手机弹窗点允许撤销授权后重新授权换数据线再试error: device offline数据链路异常换线、换 USB 口、adb kill-server 后重连error: device not found驱动未装或连接断开安装厂商 USB 驱动确认开发者选项已开确认 USB 调试已开INSTALL_FAILED_UPDATE_INCOMPATIBLE已存在相同签名或版本更旧的包install 加-r参数覆盖安装INSTALL_FAILED_TEST_ONLY安装的是测试包install 加-t参数允许测试包Security exception: Permission Denial无权限访问某数据或服务用 run-as需可调试或 root 方案adb server staleadb server 状态异常执行adb kill-server再adb start-server端口被占用 5037其它 adb 进程占用了默认端口任务管理器结束残余 adb.exe重启服务还有几个值得单独提醒的细节USB 线不是随便一根都能用。很多普通充电线没有数据线芯或者线芯质量太差导致 dmesg 里大量通信错误。调试用线建议用原装线或者品牌数据线别图便宜。杀毒软件偶尔会拦截 adb server 启动。某些安全软件会把 adb 误判为可疑进程导致 server 起不来或设备连接后被断开。遇到设备反复跳掉的情况检查安全软件信任区是否有 adb.exe。多个设备同时连接时命令后加-s 设备序列号。例如adb -s 设备序列号 install xxx.apk不加-s时 adb 会报错提示设备不唯一。9. 第七天加餐concentrate 在什么方向继续深入说句实在话ADB 命令本身不难难的是把命令组合成一套分析套路。今天我讲的所有命令单独拿出来都可以在文档里查到但把它们按场景串起来才是逆向分析里真正值钱的东西。我强烈建议你今天就把上面四个实战场景完整跑一遍哪怕只是拿一台自己的旧手机试验也要把每个命令敲熟、每步输出的含义看懂。后面几天的学习方向大致是按照这个依赖关系走ADB 熟练之后下一步是了解 APK 文件结构解包、打包、签名、smali 语法基础、静态分析工具jadx、Bytecode Viewer然后再进入动态调试Frida、Xposed。如果 Day 1 你还在犹豫要不要入坑那 Day 2 这套命令学完基本就算正式上船了。我个人在实际操作中最受益的一个习惯是在电脑上建一个 adb_notes.md 文件每次踩坑后把现象、原因、解决办法记一条。两个月后回头看这些笔记比任何教程都管用因为它们是长在你自己的报错环境里的经验。你有空也可以试试说不定真能坚持成一本自己的逆向 Debug 手册。最后分享一个只会在实战中体会到的细节ADB 命令不是敲一次就完事的它们之间经常需要组合。比如adb shell dumpsys activity top | grep ACTIVITY能快速定位当前界面 Activity这比dumpsys全文输出高效得多adb logcat -c之后接am start再logcat -d是把抓崩溃日志固定成肌肉记忆的流程。等你哪天闭上眼睛都能把这些组合流利地敲出来说明 Day 2 真的过关了。