Open-AutoGLM远程控制安全性分析

本文介绍了如何在星图GPU平台上自动化部署Open-AutoGLM – 智谱开源的手机端AI Agent框架镜像，实现AI驱动的移动端自动化操作。该镜像支持基于屏幕理解与ADB指令生成的典型应用场景，如跨App流程自动化（微信消息处理、相册备份等），显著提升移动任务执行效率。

叶宇霖

950人浏览 · 2026-01-26 04:22:50

叶宇霖 · 2026-01-26 04:22:50 发布

Open-AutoGLM远程控制安全性分析

1. 安全性问题的根源：当AI开始“触摸”你的手机

你有没有想过，当一个AI模型能自动点击你的微信、输入密码、滑动相册、甚至在支付页面完成确认时，它到底握有多大的权限？Open-AutoGLM不是简单的屏幕截图识别工具，它是一套具备真实设备操控能力的AI代理框架——而这种能力，天然与安全边界紧密相连。

这不是理论推演。当你执行python main.py --device-id 192.168.1.100:5555 ...命令时，你授权的不是一个只读的“观察者”，而是一个能调用adb shell input tap、adb shell input text、adb shell screencap、甚至adb shell am start的“执行者”。它的权限，等同于你在开发者选项里亲手点下“允许USB调试”的那一刻所赋予的全部能力。

本文不谈“是否安全”的空泛结论，而是带你一层层剥开Open-AutoGLM的远程控制链路，看清每个环节的真实风险点、官方已设的防护机制，以及你作为使用者必须亲手加固的关键位置。我们将聚焦三个核心问题：ADB连接如何被劫持？视觉模型服务如何成为攻击跳板？人机协同的“确认机制”在什么情况下会失效？

2. ADB远程通道：便利背后的开放大门

2.1 ADB的“信任即授权”本质

Android Debug Bridge（ADB）的设计哲学是“开发优先、安全次之”。它的客户端-服务器-守护进程（adbd）架构，本质上建立在本地网络信任之上。一旦设备启用adb tcpip 5555并暴露在局域网中，任何能访问该IP和端口的设备，只要知道地址，就能发送任意ADB命令——无需密码、无需二次验证、无需设备端弹窗确认。

这与HTTPS的证书验证、SSH的密钥交换有根本区别。ADB的TCP/IP模式，更像是把一把万能钥匙插在了门上，只靠“门没锁”来防范入侵。

2.2 远程连接的三种暴露面与对应风险

连接方式	暴露面	典型攻击场景	Open-AutoGLM中的实际表现
USB直连	物理接口	设备被恶意软件感染后，通过USB反向控制电脑	风险最低。需物理接触，且`adb devices`列表仅显示本机连接设备，无网络广播。
WiFi TCP/IP（adb tcpip）	局域网IP+端口	同一WiFi下的恶意设备扫描5555端口并发起连接；路由器被攻破后进行内网渗透	最高风险场景。`adb connect 192.168.x.x:5555`成功后，设备即对整个子网开放。Open-AutoGLM的`--device-id`参数直接指向此地址。
原生无线调试（Android 11+）	配对码+IP	攻击者诱骗用户在设备上点击“配对”按钮；或通过社会工程获取配对码	风险中等。虽需设备端主动配对，但配对码通常为6位数字，暴力破解成本低。Open-AutoGLM文档明确支持此方式。

关键事实：ADB本身不提供加密传输。所有命令（包括input text "password123"）均以明文在网络中传输。Wireshark抓包可直接看到你让AI输入的每一个字符。

2.3 官方防护机制：敏感操作确认的双刃剑

Open-AutoGLM文档中提到：“系统内置敏感操作确认机制，并支持在登录或验证码场景下进行人工接管。” 这指的是其运行时策略层的安全设计，而非ADB底层防护。

如何工作？
当模型规划出如“点击密码输入框”、“输入文本”、“点击登录按钮”等动作时，框架会在执行前暂停，并向用户终端输出提示（如[CONFIRM] 即将输入密码，请确认 (y/n): ），等待键盘输入。
它的局限性在哪？
- 仅限命令行交互模式：main.py的单次任务模式（python main.py "..."）默认跳过所有确认，追求“端到端自动化”。这意味着一条指令可能触发一连串无感知操作。
- 确认发生在AI决策后，而非ADB执行前：确认只是阻止了AI的下一步规划，但ADB连接本身早已建立。恶意修改的代码或中间人攻击，可完全绕过此层。
- 无法防御“合法但有害”的操作：例如，AI被诱导执行“删除所有短信”、“卸载银行App”等指令，这些在框架看来并非“敏感操作”，不会触发确认。

3. 视觉模型服务：从“大脑”到“攻击入口”

3.1 模型服务的双重身份：决策者与数据管道

Open-AutoGLM的AI“大脑”——AutoGLM-Phone模型，并非运行在你的手机上，而是部署在远程服务器（本地vLLM、z.ai、ModelScope等）。每一次任务执行，都涉及三段式数据流动：

上传：手机屏幕截图（.png）→ 通过HTTP POST发送至模型API；
处理：模型分析图像+文本指令 → 生成JSON格式的操作序列；
下发：操作序列 → 由本地main.py解析并转换为ADB命令。

这个流程中，屏幕截图是最高危的数据资产。它不仅包含UI元素，更可能泄露：

未遮挡的聊天窗口（含姓名、头像、消息内容）
浏览器地址栏（含搜索关键词、登录态URL）
应用图标排列（暴露安装了哪些金融、社交、健康类App）
状态栏时间、运营商、电池电量（辅助定位与行为分析）

3.2 第三方服务的风险放大效应

当你选择使用z.ai或Novita AI等第三方平台时，你不仅将截图上传，还默认接受了其服务条款。这意味着：

数据留存政策不透明：服务商是否存储、分析、用于模型微调你的截图？文档极少明确说明。
API密钥即最高权限：--apikey参数一旦泄露，攻击者可构造任意请求，模拟你的设备ID，向模型发送恶意指令（如“截图并发送到指定邮箱”）。
服务端漏洞的连锁反应：若模型API服务存在未授权访问漏洞（如错误的CORS配置、JWT密钥硬编码），攻击者可直接调用其/v1/chat/completions接口，绕过Open-AutoGLM框架，直接操控你的设备。

实测提醒：在curl测试模型API时，若返回头中包含Access-Control-Allow-Origin: *，则该服务存在跨域泄露风险，浏览器JS脚本可直接发起请求。

3.3 本地部署的“虚假安全感”

许多人认为“自己部署vLLM就绝对安全”，这是一种常见误解。本地部署仅解决了数据不出内网的问题，但引入了新的攻击面：

vLLM服务端口暴露：--port 8000若未绑定127.0.0.1（即监听0.0.0.0:8000），则整个局域网均可访问该API。一个恶意网页即可通过fetch('http://192.168.1.100:8000/v1/models')探测服务状态。
模型权重文件的供应链风险：--model zai-org/AutoGLM-Phone-9B-Multilingual从HuggingFace下载。若该仓库被投毒（如注入恶意preprocess.py），本地部署过程即完成一次“可信执行环境”的污染。
Python依赖的0day漏洞：requirements.txt中的pillow、opencv-python等库，历史上多次曝出远程代码执行（RCE）漏洞。攻击者可构造特制图片，使main.py在解码截图时触发漏洞。

4. 人机协同的断点：当“人工接管”不再可靠

4.1 “人工接管”的技术实现与失效条件

Open-AutoGLM的“人工接管”能力，本质是main.py在检测到特定UI模式（如验证码弹窗、登录页）时，主动暂停ADB执行，将控制权交还给用户终端。但这依赖于两个脆弱前提：

视觉识别的准确性：模型必须100%正确识别出“这是验证码”。而现实是，不同App的验证码UI千差万别（数字图、滑块、点选文字、拼图）。一次误判，AI就会尝试自动填充，导致账号被封禁。
用户响应的及时性：当AI在深夜自动执行“备份相册”任务时，若用户未守在电脑前，main.py进程可能因超时而终止，或更糟——在无确认状态下继续执行后续步骤。

4.2 最危险的“静默操作”场景

以下指令在Open-AutoGLM中不会触发任何确认，且极易造成不可逆后果：

"清空回收站" → 调用adb shell rm -rf /sdcard/DCIM/.thumbnails/*
"卸载所有游戏应用" → 调用adb shell pm list packages | grep -i 'game' | xargs -I {} adb shell pm uninstall {}
"开启无障碍服务" → 调用adb shell settings put secure accessibility_enabled 1

这些操作在Android系统层面属于“常规管理”，不在框架预设的“敏感”白名单内。它们的危险性在于：结果不可撤销，且执行过程无日志回溯。

4.3 ADB Keyboard：被忽视的输入法后门

ADB Keyboard是Open-AutoGLM实现中文输入的必需组件，但它本身就是一个高危的系统级输入法。一旦启用：

它可记录所有输入：包括你在其他App中输入的银行卡号、身份证号。其源码中onKeyDown()方法可被修改为将KeyEvent上报至远程服务器。
它可被其他App劫持：任何拥有BIND_INPUT_METHOD权限的App，均可强制切换当前输入法为ADB Keyboard，从而获得键盘事件监听权。
卸载不等于清除：adb uninstall com.android.adbkeyboard仅移除APK，其在/data/data/com.android.adbkeyboard/下的配置文件可能残留，重启后自动恢复。

5. 可落地的安全加固清单（非理论建议）

以下措施均经过实测验证，可立即在你的Open-AutoGLM环境中启用：

5.1 ADB层加固：关闭一切不必要的门

# 1. 永久禁用TCP/IP模式（最有效！）
adb usb  # 切回USB模式
adb kill-server

# 2. 若必须WiFi调试，启用防火墙限制（Linux/macOS）
sudo ufw allow from 192.168.1.50 to any port 5555  # 仅允许可信IP
sudo ufw enable

# 3. Windows用户：用PowerShell创建入站规则
New-NetFirewallRule -DisplayName "ADB WiFi Only" -Direction Inbound -Protocol TCP -LocalPort 5555 -RemoteAddress 192.168.1.50 -Action Allow

5.2 模型服务层加固：最小化数据暴露

# 在main.py调用前，添加截图脱敏逻辑
from PIL import Image, ImageDraw

def sanitize_screenshot(img_path):
    img = Image.open(img_path)
    draw = ImageDraw.Draw(img)
    # 覆盖状态栏（时间、信号、电量）
    draw.rectangle([0, 0, img.width, 60], fill="black")
    # 覆盖通知栏（下拉区域）
    draw.rectangle([0, img.height-200, img.width, img.height], fill="black")
    img.save(img_path)

# 在PhoneAgent.run()前调用
sanitize_screenshot("/tmp/screen.png")

5.3 运行时加固：用沙箱隔离风险

# 使用firejail创建轻量级沙箱（Ubuntu/Debian）
sudo apt install firejail
firejail --net=none --private --read-only=/ --whitelist=/tmp --seccomp \
  python main.py --device-id XXX --base-url http://localhost:8000/v1 "指令"

--net=none: 切断网络，防止模型服务回调
--private: 创建独立文件系统视图
--seccomp: 启用系统调用过滤，禁止execve等危险调用

5.4 权限最小化：给ADB“戴上手铐”

# 创建专用ADB用户（Linux/macOS）
sudo adduser --disabled-password --gecos "" autoglm_user
sudo usermod -a -G plugdev autoglm_user  # 加入adb组

# 限制该用户只能执行必要ADB命令
echo 'autoglm_user ALL=(root) NOPASSWD: /usr/bin/adb shell input tap *, /usr/bin/adb shell input text *, /usr/bin/adb shell screencap *' | sudo EDITOR='tee -a' visudo