在安全行业的想象里，air-gapped（物理隔离）系统差不多是堡垒般的存在：不连外网、封掉无线、接入要审批，防火墙、入侵检测和加密在这里全都失去用武之地，因为根本没有网络可防。

问题在于，只要这台机器被人塞进过一次带毒的U盘、在供应链环节被投过一次毒，或者被内部人员动过手脚，恶意代码就已经在隔离区里安了家。

接下来它只剩一个问题要解决：数据怎么出去。

韩国高丽大学（Korea University）与78ResearchLab的研究团队在arXiv发布的SPECTER给出了一个相当刁钻的答案：走USB的供电线路。

全程不往USB数据线里塞一个字节，不做任何固件改造，靠充电状态、外设指示灯、一根贴在USB线上的天线，把密钥和凭据一点一点搬出去。

隐蔽信道这个大家族

先说covert channel（隐蔽信道）。它指利用系统中某个不承担通信用途的机制传递信息，绕开既定的信息流安全策略，这个概念从1973年被Lampson提出至今已经五十多年，围绕它的研究一直没断过。在更早的联网场景里，网络协议、文件系统、时间行为都被人拿来藏过信道；到了物理隔离环境，研究者只能去物理世界找信号，CPU发热、磁场、电流、声波、光，全部被试了一遍。

热信号方向有BitWhisper，让两台机器的CPU交替工作，靠温度变化互相传话，速率1~8bit/h；MAGNETO调制CPU负载产生低频磁场，让旁边手机的磁力计当接收机，最高5bit/s；PowerHammer更直接，调制电流把数据写进电力线，速率能做到10bit/s甚至1000bit/s。

声学方向有MOSQUITO和CASPER，前者把接在机器上的被动扬声器或耳机改造成发射器，用近超声频率通信，速率10~166bit/s；后者利用主板内置的小喇叭发出人耳听不见的声音，最高20bit/s。

USB方向最有名的是USBee，它把USB数据总线当成射频发射机，用刻意构造的数据传输模式制造电磁辐射，旁边的软件定义无线电（SDR）负责接收，速率160~640bit/s。注意它的信号生成依赖USB数据传输本身，这是它与SPECTER最本质的差别。

还有一条路线打手机的主意。Spolaor等人在2017年证明，被攻陷的充电桩可以透过CPU活动引起的功耗变化偷走手机里的数据，速率1.25bit/s；2025年的CovertPower把速率提到最高10bit/s。这两条路径里发信的都是手机，目标数据也躺在手机上，充电桩那头的功率监测器是接收端。研究团队还讨论过从充电端反向给手机发握手信号的可能，但把实现留给了后续工作。

表1把上述代表性工作放在一起，SPECTER的位置一目了然：信号源是主机侧的USB电源控制，不依靠计算负载调制，也不涉及USB数据编码，报告速率0.2~1.0bit/s，接收端可以是手机、目视观察者或SDR。

表1｜代表性物理隐蔽信道对比

注：速率均为各研究实验条件下的报告值；负载调制指通过刻意改变计算负载来产生信号，USB数据编码指把隐蔽信号放进USB数据传输的载荷，常规USB控制活动不计入此分类；SPECTER的速率覆盖充电状态与外设状态两种接收。

黑鸟此前多次介绍过关于隔离网络的相关工作，本次公布的手段与前人工作的三点不同。其一，发射端是气隙主机本身，信道搬运的是主机上存放的数据；其二，信号由主机侧USB电源管理或设备状态操作产生，不需要在移动设备上制造计算负载；其三，它提供三条彼此独立的接收路径，攻击者按手头条件任选其一，且不需要改装任何外设固件。

供电线路本身就是一面镜子

要看懂SPECTER，得先弄清USB的构造。

USB 2.0靠D+和D-两根差分线传数据，SuperSpeed模式另配专用的差分对；供电走VBUS和GND，标称电压5V。按标准功率规则，配置完成的USB 2.0设备可以取电500mA，USB 3.x可以取900mA，更激进的充电能力由单独的规范定义。

Type-C引入CC引脚，负责连接检测、角色识别和电流通告，配合USB Power Delivery（USB PD）可以协商更高功率。

监控产品的注意力几乎都压在数据线上：USB数据流量、文件拷贝、外设接入记录。可供电线路的状态同样是可观测的物理事件，设备被系统挂起、恢复、禁用、启用时，充电指示灯会变，外设指示灯会变，线缆附近的电磁场也会变。

SPECTER的全部戏法，就是把这几个会变的东西变成编码位。需要划清的界限是：它不往D+和D-上放payload，不碰Type-C的CC和SBU信号，也不依赖PD协商。Type-A与Type-C在试验中没有表现出定性差异，最终效果取决于主控、集线器、驱动和所接设备，而不是接口形状本身。

前提：主机已经沦陷

SPECTER的威胁模型从恶意代码拿到root（Linux）或管理员（Windows）权限那一刻开始：

这台主机允许USB充电或外设接入，而常规网络出口不可用或被严格限制。初始入侵与提权不在讨论范围内，被感染的可移动介质、供应链投毒、内部人员协助都可能把恶意代码送进来。

攻击者要的不是大文件，而是短小但高价值的东西：加密密钥、登录凭据、认证token。这个定位与后文的速率直接挂钩。

防守方的假设同样值得细看。

网络隔离照常执行，网络活动、文件传输、USB数据流量都在监控之下，主机日志、充电通知、外设状态变化也可见；但没有人会拿示波器天天盯着VBUS波形或近场电磁辐射。论文没有假设攻击者能抹掉这些痕迹，恰恰相反，防守方如果盯着USB电源管理与设备状态事件，是有机会发现异常的。

还有一个容易被忽略的细节：控制操作会产生系统通知、充电提示、屏幕亮起、外设中断，攻击者需要一段无人干预的窗口期才能安心发信。能不能把信息传出去，和能不能不被人察觉地传出去，是两回事。

三条接收路径

三条路径共享同一个主机侧控制机制，差别只在观察端，整体架构见图1。

手机的充电状态会招供

第一种路径最方便，手机插在被攻陷的主机上充电，恶意代码通过USB电源操作改变充电状态，接收端只要读懂电池状态随时间的变化。

Android这边，攻击者部署的是一个普通的用户级应用，它反复读取系统上报的电池状态，不需要root权限，不改操作系统，不动固件。

解码规则很朴素：

一个观测窗口内的所有采样点都显示「正在充电或已充满」，该窗口记为1，否则记为0。使用者指定要收的比特数，应用解出序列并显示。窗口长度是配置参数，发布版本每秒采一次样、取6个点，实验里窗口长度与发射端的符号周期对齐。iOS实验更直接，人工盯着屏幕上的充电标志读结果。也就是说，应用方案要求手机上装着攻击者的软件，人工方案只要求肉眼能看到充电指示。

编码层面，充电状态与外设状态路径都采用state-based（状态式）编码：激活的控制状态代表1，非激活代表0，每个操作之后等待一段时间，连续相同的比特就靠在多个符号周期里维持同一状态来表达。

外设的一举一动都在台上

第二条路径在接收侧连恶意软件都不需要装，一位目视观察者或一台摄像头就够了。普通外设插在主机上，系统层的禁用与启用会让它们出现肉眼可见的变化，比如鼠标LED熄灭、设备停止响应。

控制操作到可见状态的映射完全由设备决定。有的外设反应清晰，有的纹丝不动，有的恢复太慢，撑不起测试间隔下的符号。这条路径需要一台行为合适的外设，还需要一条能看到指示灯或动作的视线，评估只认设备的实际可见响应，不假设每次禁用操作都切断了VBUS供电。

贴着线缆听开关

第三条路径上仪器。主机侧USB控制操作会让线缆附近的电磁活动出现可分辨的波动。研究团队用GQRX查看频谱与瀑布图，在5MHz附近选定一段开关噪声肉眼可辨的区域作为观察点（图2），这是一个依赖具体配置的频点。

接收端用HackRF One，配一只LF-R 400环形天线，天线直接贴在USB线上。分析脚本把交织的I/Q采样构造成复数序列，做短时傅里叶变换（STFT），采样率2.6MS/s，段长8192个采样点，取零频分量的幅度，掐头去尾各丢20帧用于可视化。把保留帧的零频幅度记作Ak，其中的最大值记作Amax，画出来的量是Rk=(Amax-Ak)/Amax，得到一条无量纲的时间轨迹，专门用来对照发射端的控制序列。

这条路径改用event-based（事件式）编码，因为观察对象是「有没有开关突发」：发1，符号开始时把请求的USB状态改变一次；发0，什么都不动。解码同样朴素，符号区间里有对应突发记1，没有记0。Windows RF分支在每个符号的控件操作之后等待1秒，但这个等待参数并不等于物理事件之间精确间隔一秒。

还要划一条边界：开源的RF脚本只做轨迹提取与可视化，自动帧同步、阈值选取、二进制判决都不在脚本功能之内，事件式解码规则与脚本能力是两码事。实验中天线贴着USB鼠标线，结论只适用于这种接触式探测配置。

Ubuntu这边，发射端以root身份向sysfs里的USB电源管理属性写值。设备路径形如/sys/bus/usb/devices/1-1，按总线与端口拓扑定位目标。把power/control写成on，设备恢复运行并禁止自动挂起；写成auto，内核获准把空闲设备挂起。这两个设置管的是运行时电源管理，本身并不等于VBUS被物理切断，最终行为由主控、集线器、驱动和设备共同决定。

细节藏在发布脚本里。iOS分支向设备power目录写属性，激活设置用on配autosuspend_delay_ms=2000，非激活设置用auto配0；同时还写了level与autosuspend这两个旧式属性，激活用on和2，非激活用auto和0，旧属性是否可用取决于内核版本，全部写入通过sudo tee完成。三星分支同时向/sys/bus/usb/devices//power/与/sys/bus/usb/drivers/usb//power/两条路径发同样的写操作，两条路径可能解析到同一个设备，所以重复写入不代表存在八个独立属性，这只是对发布实现的描述，不是Android设备的通用要求。测试用的Galaxy S22还需要切到非默认的USB模式，才能看到预期的充电状态变化（图A.1）。

Windows这边用微软官方的DevCon工具，按硬件标识符（HWID）下发设备状态命令：devcon disable ""负责禁用，devcon enable ""负责恢复；若使用设备实例标识符，前面要加@。发布实现把enable连着执行了两次，因为在他们的环境里单次执行不能稳定恢复设备的可观测状态。DevCon控制的是操作系统层面的设备状态，充电与外设响应依然取决于具体配置，设备被禁用本身也不被当作VBUS断电的证据。

发射端逐位串行处理输入序列，每完成一个比特的控件操作就等待：Linux手机分支等5秒，Windows分支等1秒。这些是软件等待参数，实际的符号间隔还要叠加命令执行与调度延迟。这些操作过程中可能伴随正常的USB控制活动，但payload从不进USB数据传输。表A.1汇总了开源实现用到的控制机制，两个平台都要求管理员权限。

表A.1｜开源实现使用的USB控制机制

注：Ubuntu条目描述的是脚本分支与访问路径，不代表对应移动操作系统的普遍要求。

发送侧的打包与编码是相互独立的两层。

分帧传输时，包结构从前到后依次是前导码（preamble）、头部、载荷、CRC、尾部，见图3。前导码取101011，是一段双方已知的比特模式，用来定位包的起点；头部标明载荷长度；载荷就是真正要偷走的比特；CRC（循环冗余校验）字段负责错误检测。发射端不做压缩，也不加加密层，信道没有任何确认（ACK）机制，更没有基于反馈的重传。状态式格式的尾部固定为1，让发射端在包结束后回到激活的USB状态。发射器拿到的输入是预先组包完成的序列，它只管按选定规则编码，不解释内部字段。

RF路径的前导码更短，只有101，后面接事件式载荷符号；不带完整包结构的测试序列也套用同一套事件式编码规则。

实验：哪些设备能传，哪些传不动

实验平台是两台普通机器：Ubuntu 22.04.4（64位）桌面机与Windows 10笔记本，都带USB 2.0、USB 3.0 Type-A和Type-C接口，所有实验在无网络连接的受控实验室完成，每条接收路径单独评估。手机是Galaxy S22（Android 14）与iPhone 13 Pro（iOS 17.4.1），前者跑定制的Android解码应用，后者靠人工观察；外设逐一插上，包括USB鼠标、键盘、摄像头、无线耳机dongle和USB hub；RF接收用HackRF One加LF-R 400环形天线贴住鼠标线。各组合的接收结果与信令速率见表2，注意信令速率不等于扣除包帧开销后的净载荷goodput。

表2｜各主机与设备组合的接收结果与信令速率

注：N/O表示该主机与设备组合下未获得可用信道。

充电状态路径在Android和iOS上全部成功，Ubuntu桌面机0.2bit/s，Windows笔记本0.25bit/s，两种手机表现一致。由于两套操作系统分别跑在不同主机上，这个速率差异不能单独归因于操作系统本身。

一个反直觉的观察：反复的电源操作在部分设备组合上会触发可见的充电提示与屏幕亮起，但在电池充满的状态下，屏幕不会被唤醒，充电提示也不出现。这只描述受测配置的屏幕行为，不能推广为信道可检测性的普遍下降。

外设路径的分化就大了。鼠标在Windows笔记本上最争气，设备被禁用时LED熄灭、指针停摆，状态干净利落，跑出全部实验中最高的1.0bit/s。摄像头0.25bit/s，但它的LED只在应用占用摄像头时才亮，想借指示灯收数据，摄像头必须正在被使用，外接与内置型号都一样。USB hub自身的LED全程常亮，接收只能依赖下游设备的行为，同样0.25bit/s。无线耳机dongle在Windows上可以被禁用，音频却照常播放，凑不出可辨识的二进制状态。键盘在两台主机上都没能给出可重复、可分辨的状态变化。Ubuntu桌面机更干脆，所有受测外设全部N/O。

结论写得很直白：外设接收能否成立，取决于主机配置与设备可见行为的组合，对某个设备有效的禁用操作，换一个设备可能什么都观察不到。

RF路径用6bit测试序列110101与48bit载荷各演示了一次。图4是6bit序列的接收轨迹，红框区间对应1，绿框对应0，框是后期人工加的标注；图5是48bit载荷，蓝色轨迹是处理后的RF记录，红线是人工添加的视觉参考。这两次演示中解码序列都与发送序列一致，长样本里还夹着短促的噪声突发。论文专门提醒：这两例没有出错只说明样本干净，不构成信道整体的误码率结论，探测距离、天线朝向敏感性、不同环境条件下的稳健性都还没有被表征。

速率慢，但偷的是密钥

把数字放在一起看：充电状态0.2~0.25bit/s，外设最高1.0bit/s。以0.25bit/s计，传完一个128位AES密钥大约要八分半钟，一段4096位RSA私钥要花上好几个小时。这正是论文反复强调的定位：这类信道瞄准短小的高价值秘密，不做批量数据搬运。

约束不止速率。每条路径都有各自的准入条件，Android接收要在手机上装攻击者控制的应用，iOS靠人眼盯屏幕；外设路径需要合适设备加视线；RF路径需要SDR和贴住线缆的天线。实验全部在选定的主机与设备组合上完成，同样的操作换一套主控、驱动或外设未必有同样的响应。评估给出的是信令速率与个例接收结果，没有系统的比特误码率、包错误率或有效载荷吞吐估计。

检测层面同样有代价。反复的控制操作会留下主机通知、充电指示、屏幕活动、外设中断这些痕迹，信道能否隐蔽，取决于所选配置的可观测效应与防守方的监控能力。

论文实现已开源在GitHub仓库 hjchoi17/SPECTER，包含主机端发射脚本final_send.py、RF接收脚本RF_receive.py与Android应用charging_receive.apk，README覆盖三种接收配置的搭建步骤。发射器要求先显式配置设备标识符，以降低误执行风险。

防守方该做什么

论文给出的防御方向可以概括成一句话：把USB电源管理与设备状态事件当作安全遥测（security-relevant telemetry）来看待，而不是无害的系统杂音。

落到操作层面，可以审计同一设备上反复出现的enable、disable、suspend、resume操作，把这些事件与应用活动、充电状态、外设状态观察做关联，找出值得调查的模式。关联分析需要区分刻意发信与正常设备管理、重连、省电行为，否则告警会把运维团队淹没。

策略层面可以考虑限制软件控制的USB状态切换、限制未使用端口、部署设备白名单、限制敏感主机附近使用个人手机。论文特别点了一句：SPECTER利用的可以是一个完全良性的外设，所以允许某台设备接入，并没有堵住事后用主机侧控制操作发信的路。主机侧监控与强制手段的有效性，最终还取决于特权沦陷后这些机制本身是否仍然可信。

异常检测方向，IoT网络里的学习型监控可以参考，但搬到USB事件序列上需要合适的特征、按设备建立的基线，以及正常工作负载下的评估。论文没有验证任何检测器、限速策略或通用判定阈值，这些候选防御的效果与运维成本都需要单独评估。

未来工作列了三块：在更广的主机、主控与设备上通过重复传输刻画误码率、包错误率、同步失败、更长载荷的表现以及扣除帧开销后的goodput；考察RF探测距离、摆放位置、天线朝向与环境干扰；在企业和工业负载下，把主机级监控同时放到刻意发信与正常USB活动上评估，包括误报、对正常设备操作的影响，以及监控机制在特权攻击者面前的完整性。

SPECTER有意思的地方恰恰是它的慢。0.2bit/s，五秒一个比特，像滴水一样把密钥运出堡垒，低速率反而精准划定了它的威胁模型：

偷的不是文件，是密钥、凭据和token，而这些恰好是隔离网络里最值钱的资产。

对防守方而言，这个思路很有现实的启发。

很多 USB 安全策略只盯着数据流量，却忽略了电源管理这条同样可以泄露信息的侧信道。

设备挂起、唤醒、禁用、重新启用，这些行为本身都会留下系统日志，只是以往很少被当作安全告警信号看待。

物理隔离网络从来不是安全的终点。

网线存在电磁辐射、指示灯可以闪烁、扬声器能够发声、磁场会产生扰动，如今就连供电线路的通断状态，都可以被用来编码传递信息。

只要设备仍和物理世界相连，它产生的各类可观测物理信号，就值得大家持续关注。

声明：本文来自黑鸟，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。