Android IoT设备的安全测试与常规移动应用测试最大的区别在于攻击面不再局限于APK。智能家居网关、广告机、收银终端、车载娱乐系统很多都基于Android定制，厂商为了调试方便，常常在生产版本中保留ADB over TCP、串口登录或未加密的升级通道。测试这类设备时，如果只对配套APK做静态扫描，可能无法发现固件中硬编码的密钥、调试后门或暴露在局域网中的服务。因此需要建立一套覆盖设备系统层、应用层、通信层和物理接口的测试流程。
一、信息收集与攻击面识别
拿到一台Android IoT设备，首先要确认设备如何连接网络、是否开放调试端口。可以使用adb connect加设备IP及5555端口测试。如果设备没有开启TCP调试，也可以通过USB连接后执行adb shell getprop命令，查看ro.secure、ro.debuggable、ro.build.type等关键属性。生产设备如果ro.debuggable为1或ro.secure为0，说明系统存在较大的调试权限风险。
同时需要对设备进行网络扫描，确认开放了哪些TCP和UDP端口。下面的命令可以快速发现设备上的HTTP、RTSP、Telnet、ADB等常见服务。
nmap -sV -p 1-65535 192.168.1.100 adb connect 192.168.1.100:5555 adb shell getprop ro.build.version.release adb shell getprop ro.secure adb shell getprop ro.debuggable
如果发现端口5555开放，可以尝试使用adb connect直接连接。部分设备没有授权弹窗，直接就能进入shell，这就可以读取应用数据、查看系统日志，甚至上传可执行文件。即便需要授权，也可以尝试从设备设置中找到开发者选项，或者通过物理按钮进入恢复模式获取root权限。信息收集阶段的目标是确定设备在网络上暴露了哪些入口，以及这些入口是否可以被远程访问。
此外，还可以从设备说明页、固件升级包、手机App接口中找线索。例如配套App里如果硬编码了调试密码，或者设备存在UART串口标识，都可以作为下一步测试的路径。使用adb shell dumpsys package可以列出系统包，快速判断哪些是厂商预装组件，哪些权限过高。
二、Android应用层与系统服务测试
Android IoT设备的系统服务和应用常常因为缺少人工交互而暴露不必要的组件。测试时需要拆包配套APK，用jadx或apktool分析AndroidManifest.xml中的导出组件。可导出的Activity、Service、BroadcastReceiver如果缺少权限保护，可能被其他应用调用，造成敏感操作被滥用。例如一个导出的<service>组件允许外部传入指令执行shell命令，就属于严重漏洞。
下面是一个使用jadx反编译APK的基本流程，重点检查AndroidManifest.xml中android:exported属性和intent-filter配置。
jadx -d output_dir iot_app.apk grep -R "android:exported=\"true\"" output_dir/AndroidManifest.xml
如果发现导出的组件，需要进一步阅读其实现，判断是否有权限校验。某些组件虽然导出了，但在onCreate或onStart中进行了包名校验，但攻击者仍可以通过反射、动态代理或重打包绕过。Frida是动态调试的利器，可以Hook关键方法，输出运行时参数。以下脚本可以监控所有Activity启动，帮助理解应用界面和数据处理逻辑。
Java.perform(function () {
var Activity = Java.use('android.app.Activity');
Activity.onResume.implementation = function () {
console.log('Activity onResume: ' + this.getClass().getName());
this.onResume();
};
});
系统服务方面，ADB shell具有高权限时，可以查看敏感内容。比如检查/data/local/tmp目录是否可写、是否存在su二进制文件、内核版本是否已知CVE。执行adb shell id可以查看当前用户，如果是root或system，说明测试难度会进一步降低。还要关注WebView的配置，IoT设备App如果加载远程网页并使用addJavascriptInterface，可能被中间人注入恶意脚本，导致远程代码执行。
日志泄漏也很常见，开发团队在日志中打印鉴权token、MQTT账号密码或设备序列号。可以通过adb logcat捕获一段时间，再搜索password、token、secret等关键词。下面命令用来过滤敏感信息。
adb logcat -v time | grep -iE "password|token|secret|api_key"
这一阶段的目标不是发现所有可能的问题，而是确认应用层是否存在可远程利用或可联合其他漏洞利用的缺口。例如导出的组件配合调试权限，就能形成完整的攻击链。
三、固件与通信协议测试
很多Android IoT设备的固件更新包可以从官网下载，或者通过抓包获取OTA地址。拿到固件后，首先检查文件类型，常见有bin、img、zip、tar等格式。使用binwalk可以扫描固件中的文件系统和压缩块。如果固件没有加密，可以解包后直接分析启动脚本、system分区的APK和配置文件。
binwalk -Me firmware.bin ls _firmware.bin.extracted/ grep -R "password" _firmware.bin.extracted/etc/ 2>/dev/null
固件中经常出现硬编码的后台管理密码、Wi-Fi默认口令、证书私钥或AWS IoT的AccessKey。有些厂商会把root密码以明文写在启动脚本里，攻击者只要解包固件就能获得。解包后还应关注rc.local、init.rc、shadow文件以及system目录中的APK，因为它们可以还原设备初始配置。
通信协议方面，Android IoT设备与云端或手机App之间可能使用MQTT、CoAP、HTTP或自定义TCP协议。测试时可以将设备流量镜像到电脑，使用Wireshark或tcpdump抓包，确认是否使用TLS。如果使用明文HTTP，可以直接读取请求中的token。对于MQTT，可以尝试匿名订阅主题，验证是否能够控制设备或获取其他用户数据。
mosquitto_sub -h broker_ip -p 1883 -t '#' -v
如果消息被加密，需要从固件或APK中提取证书和密钥，然后配置mitmproxy进行解密。某些设备禁用证书校验或信任用户证书，可以更轻松地查看HTTPS和MQTT over TLS内容。协议分析的输出将帮助后续漏洞验证，比如重放攻击、越权控制和弱认证。
四、漏洞验证与修复建议
测试不应止步于发现问题，还需要验证漏洞的实际影响并给厂商提供修复建议。例如发现ADB over TCP可匿名连接后，可以进一步尝试提取应用数据或安装恶意APK，确认是否造成远程控制。对于协议重放，要记录完整的请求序列，证明攻击者可以在没有密钥的情况下重复发送指令开关设备。漏洞报告宜采用CVSS评分，明确攻击向量、攻击复杂度、所需权限和用户交互等因素。
修复方面，生产设备应关闭ADB over TCP，禁用UART串口调试或将串口输出限制在只读模式。系统属性ro.secure应设置为1，ro.debuggable应设置为0，SELinux必须处于enforce状态。厂商还应避免在固件和APK中硬编码密钥，改用设备独立密钥或安全元件存储。所有网络通信必须启用TLS，并做证书固定，防止中间人攻击。
应用层也要规范导出组件，尽量减少exported为true的组件数量，确实需要导出的必须加上signature或signatureOrSystem级别的权限保护。对涉及敏感操作的组件，应增加运行时权限校验，不能只依赖包名判断。日志输出需要脱敏，生产版本关闭debug日志。另外，IoT设备应具备安全的OTA更新机制，固件镜像需要签名校验，防止被篡改后刷入。
这些措施看起来是基础安全基线，但在大量Android IoT设备中并未落实。安全测试人员如果能按信息收集、应用与系统层、固件与通信协议、漏洞验证四个阶段执行，就可以在较短时间内识别并优先处理那些最容易被攻击者利用的缺口。最终的报告应形成可复现步骤，并附上相应截图和抓包记录，便于研发团队快速定位和修复。
Android IoT安全物联网安全测试Android渗透测试修改时间：2026-09-23 08:40:35