本帖最后由 B100D1E55 于 2026-1-19 16:34 编辑
**本文讨论的TDT特指基于PMU性能计数器采样（性能遥测）的查杀技术，目前实装的检测包含勒索程序和挖矿软件两种，和TDT其他技术例如AMS（GPU内存扫描加速）等技术并无关联
Intel TDT技术最早大概可以追溯到NYU的Karri组在2011年发表的“Are Hardware Performance Counters a Cost Effective Way for Integrity Checking of Programs?”。从基础的通过计数器进行程序完整性验证，到后来通过计数器检测控制流篡改，再到矿潮开始专精于时间序列检测勒索和挖矿，最后在2021年实际落地到消费端产品，期间花了十年时间（而Karri本人也在2022年被Intel授予杰出研究者名号）。
我本人最早接触这个概念是十年前某会议海报展上看到Columbia另一个组做了基于性能计数器的安卓恶意app检测，原理大同小异：不同的应用程序在硬件微架构层面也展现出不同的特性，通过收集这些情报构建时间序列喂给机器学习模型就有可能从硬件层信息检测到异常程序行为。 这里做个小实验，在Mac上通过收集和TDT技术收集的同类别（或近似类别）计数器，包含L1指令/数据缓存失误率，微指令提交速度，寄存器重命名气泡等类别然后运行如下三个程序： - 第一个是模拟勒索程序通过AES加密覆盖文件夹下所有文件并添加后缀
- 第二个程序除了把第一个程序的加密函数替换成对称块循环XOR输出（即输出源文件）外和第一个程序其他行为一致
- 第三个程序修改第一个程序的行为，仅对同个文件夹下的单个文件进行反复加密操作而不是文件遍历
针对上面几个程序肉眼便能观测到微架构运行层面的不同特性，即使AES内也包含了大量XOR操作，和纯XOR块运算相比展现了非常不同的行为特征 回顾过去的十年，虽然TDT是首款消费产品通过硬件辅助检测恶意软件的技术，但其实硬件甄别执行程序类别在TDT之前就存在了：在GPU领域最典型的两个代表就是Furmark和挖矿。
本质上来说Furmark的计算核非常小且几乎都是乘加或者乘法指令，而传统渲染虽然也大量应用类似指令但密集度远不及Furmark Furmark 回顾Furmark的历史，最早是因为它power-virus属性成名（也就是能让显卡运行在最高功耗上），因此被很多网友用来测试显卡稳定性。早年大概是GTX400时代曾出现过用Furmark烤机导致显卡VRM烧毁的情况，因此NVIDIA先是在驱动层面通过判识文件名的方法来强制限制Furmark在GPU上的速率，后期则在新一代产品使用改进的电源管理模块+分流电阻从硬件层面封堵了power-virus烧毁显卡的可能性，是硬件功耗特性检测程序特性的代表。有趣的是睿频之类瞬时峰值有时候仍能超过Furmark的功耗，说明他们主要对长时间执行的异常类别程序行为进行了特殊处理从而避免降低实际性能
Crypto 再回顾矿卡时期，NVIDIA为了解决消费市场供货短缺问题曾经推出过LHR(low hashing rate)系列显卡。这类显卡在运行挖矿类程序时会自动降低速率，而这种检测自然不可能通过文件名识别之类容易被绕过的方法实现。根据后人逆向发现NVIDIA的方法是驱动读取PMU性能计数器，和固件握手对接GPU的微控制器，当计数器显示出强挖矿特征时在固件层面插入让硬件空转的等待指令强行降低显卡挖矿率。 之所以能通过性能计数器侦测以太坊类挖矿算法是因为其传统图形负载特性大不相同：以太坊需要从一个巨大的DAG文件里面随机访问数据，这种访存行为其实对GPU非常不友好。在GPU执行的时候这类应用访存比重远高于实际计算的负载。相比之下传统图形负载对缓存/内存的访问是块状的，具有较好的空间/时间局部性。因此PMU如果能侦测到大量随机内存访问，例如高缓存失误率+高bank-conflict，辅以对计算负载的侦测就很容易能辨认出挖矿程序并进行相应处置。 由此可见硬件层面反推程序类别并不是天方夜谭，反过来也有不少研究着力于发掘硬件功耗特征和性能计数器是否能作为测信道泄露软件信息。但需要注意的是以上两个案例均是用于检测持续的负载，且这些负载行为特征性强也易于和普通程序区分。我猜测这也是为什么最终TDT落地的时候主打检测勒索和挖矿这两种类别
TDT的数据收集使用PMU计数器侦测的另一个优点在于它不需要多少实际硬件投入。PMU本身是为了开发者性能调优和芯片厂性能debug而打造，因此就算没有TDT也是产品必须包含的功能。我认为排除软件方面的差异性，每个当代处理器厂商理论上都能搓出现在的TDT这样的产品，只不过Intel早早开始进行软件方面研究和投入打响了第一炮罢了。 然而PMU本身受硬件设计限制带宽并不是很高：当代芯片一般可以定义数百项性能计数器，但由于实际物理设计等考量每次只能请求五六个计数器的内容。这些计数器的触发信号通过巨大的多路复用器合并到少数几条很窄的总线上触发计数器，每次请求时通过对复用器进行编程随后获取计数器信息。这样的设计使得TDT这类技术在计数器选择的灵活度上非常有限，相信他们在开发模型的时候使用PCA等手段提取主要特征种类进行训练 - 第一代：在Coffee Lake/Comet Lake时期(均属于Skylake架构家族)，除了基本的计数器例如核心周期数/指令执行数之外仅包含了额外四种计数器，涵盖分支指令数量、缓存失误、前端uop缓存提供指令数几种
- 第二代：到了Tiger Lake/Ice Lake/Rocket Lake时期（均属于SunnyCove架构家族），浮动特征扩增到八种，额外覆盖了BTB修正、派发宽度、后端阻塞、执行端口压力等特征
- 第三代：到了Alder Lake/Raptor Lake时期（均属于GoldenCove架构家族），由于P/E核的出现需要对两种核分别定义特征群以及训练模型。其中E核侧重提取对L2/Stores的压力以及前端阻塞特征，而P核侧重于提取L1和乱序执行相关的特征。每种核心提取特征仍旧不超过8种
TDT的数据处理TDT组件对每个符合监控条件的进程都构建了一个时间序列，步骤如下（可能有不准确的地方） - 按照固定间隔获取PMU读数，根据处理器架构不同构建一个长度为10~20的特征向量。其中一部分特征来自于一个基线窗口的PMU数据
- 对特征向量的每一个元素使用一个normalizer模型进行计算，得出pdf/cdf/sigma三个参数
- pdf：根据学到的分布来看，这个数值本身出现的概率有多大
- cdf：在历史分布中有多少比例的数值小于这个值
- sigma：这个值偏离正常水平有多少个标准差
- 在积累了一定量的扩增后向量，将其输入到一个随机森林模型得出每个时间点上的恶意概率
- 将这些每个时间点上的恶意概率构建一个时间序列，对时间序列上的数值进行时域上的最终整合，得分超过一定阈值的判黑
- 最终，还需要经过一系列压误报逻辑（例如白名单剔除）将鉴定传回给安全软件
TDT的模型和推理代价TDT为每次大的微架构更新都提供了单独的模型（对于AlderLake这种P/E核产品还得分别提供模型），每个种类分为一个normalizer模型和一个随机森林决策树模型。由于这些算法网上资料很多这里不再赘述。 同时每个类别的恶意家族有单独检测模型，目前分为勒索程序/挖矿程序/勒索+挖矿混合模型三种。似乎挖矿检测只做到了第二代
值得一提的是不同架构模型规模大有不同。从很浅的分析来看虽然三代架构的勒索程序决策树数量都在100这个量级，但第一代估测平均深度只有4（假定是比较平衡的结构），总节点只有不到2000个（模型大小只有600KB左右）。而从第二代开始平均树深度达到了12，而节点数量超过了20万，这个数字到了第三代进一步扩增到了30万以上，P+E核就有60万以上。也就是说大概率不同产品的TDT能力不是生而平等的，越新的硬件恐怕检测能力越强
对于第一代这种模型推理负担应该是非常小的，但是到了后来几代推理就会有一定性能开销。因此Intel提供了GPU加速来缓解推理带来的性能影响。由于第二代开始模型对节点的编码变为了更紧凑的格式，TDT还提供了两个不同的GPU加速核应对紧凑和非紧凑的编码模式。基本执行模式是每个GPU线程负责一个特征向量点的决策树查找，每查找到叶节点后将数值累积起来最后综合所有树得出恶意概率。 总体来说这种负载虽然在访存方面类似于指针追逐的模式对GPU并不友好，但控制流一致性还行。最重要的是这个加速核所需的寄存器数量极少（A卡上大概每个线程只需要10个），就算是集显的硬件规模也可以轻松填满渲染引擎的任务槽掩盖访存带来的气泡问题。又因为决策树查找本身计算比较廉价，大多就是比较/位移之类的操作，和Furmark那种fma能耗完全不是一个量级，因此就算是移动平台应该也不会对功耗/续航有多少影响。
对类TDT技术的评价从前文可见，TDT这类技术本身非常独立，它不需要高于硬件层语义的输入而仅通过微架构状态以及类似异常侦测的方法来检测（这也是它PR中的卖点之一）。从直觉来思考，勒索程序似乎的确能在这些选取的计数器上展现一些独特的模式，例如它通常在“文件系统大量操作”和“紧凑的加密循环”两种阶段之间反复切换 - 指令缓存命中特征：勒索软件在加密阶段往往是很小的热点循环反复跑，所以指令足迹稳定、命中率极高、波动很小。虽然其他程序也可以有类似特征，但机学判断中可结合其他特征共同判别
- 数据缓存命中特征：勒索加密常对文件缓冲做流式读写：如果缓冲很大可能更流式而缺少复用，如果缓冲较小可能更多热点特征。它和指令缓存/停顿信号协同判断就能甄别出诸如读取-加密-写回的行为模式
- 指令退休率：也就是看CPU是不是在等待某些外部事件。勒索在文件枚举、打开、写回、重命名、等时候更容易出现停顿上升。在纯加密计算阶段通常停顿更低、更平稳……如果两者呈现周期性波动则变得可疑
- 寄存器重命名卡顿：加密阶段如果把流水线推得很满，可能出现这种资源型卡顿。而文件系统阶段更像等I/O锁之类的行为，重命名类卡顿未必高。它的价值在于区分“等外部世界”和“内部资源堵塞”。
然而对这种性能计数器侦测恶意软件技术的批评声并非没有。其实我在最早接触这个概念的时候也对此类技术到底是不是”蛇油“颇有疑问：虽然能绕过API监测的方式从更底层收集数据，但也无可避免地丢失了高抽象层的语义，而对未知程序的泛化能力（特别是误报方面）更有待商榷
- 此类研究很多有把”相关“当”因果“来对待的嫌疑。很多工作看到“某些计数器事件和恶意样本分类结果相关”，就直接推到“这些事件捕获了恶意行为本质”。就算挑出的事件里有些（比如内存行为）在统计上“看起来可用”，也很难解释为什么 kernel 里的各种事件能映射到用户态恶意行为——也就是“你能分出来，但你说不清你分的是啥”。他们认为低层微架构事件与高层软件行为之间不存在可靠的因果关系，以前那些“强阳性结果”来自过于乐观/不现实的实验设定。
- 很多性能计数器侦测论文之所以看起来效果惊艳，根源在于训练集与测试集的划分方式过于乐观，导致评估目标被悄悄换成了“记住程序长什么样”，而不是“泛化到没见过的新程序/新样本”。这些计数器特征里很容易包含某个程序的稳定“指纹”（程序结构、库调用、初始化路径、常见分支形状、缓存/分支预测特征等），当同一程序的 trace 在训练与测试中同时存在时，模型可以通过“识别这个程序”而不是“识别恶意行为”来得到很高的分数。换句话说，这些研究更像是在考“同一批程序的重复测量能不能互相匹配”，而不是在考“遇到新程序能不能判断恶意”。而当作者改用更严谨的划分方式+交叉验证后检测率出现显著下降，并且标准差显著增大（侦测稳定性显著变差）
- 在前两点基础上，作者自己的实验表明这类侦测在现实中误报情况堪忧，而机器学习分拣的鲁棒性也很差——将勒索代码嵌入正常软件后降低加密频率就可以躲避侦测
除此之外有意思的一个小点是作者认为微架构层判别无法理解高层语义导致完全无法判断一些更微妙的情况。例如作者提到：勒索和普通加密保护程序区别仅在于密钥在谁的手上，而这点通过微架构行为统计上的分析完全无法判识（而密钥上传之类的行为软件层面可以一定程度上侦测到）。 COMODO甚至在TDT设置页提醒用户TDT潜在误报风险，建议不要打开自动查杀功能 个人看法 我个人对以上一些质疑是有些赞同的，这就类似于当年对纯静态查杀的抨击一样，很多时候不解包看里面的内容很难想象有什么表层特征能非常可靠地判断具体是不是毒。但我认为对于作者提到的最后一个案例持保留意见。不能因为没法完美判别是不是恶意程序就全面否定从这个硬件维度进行判识的价值。 真要严格来说对程序是否恶意的判断本质上可以归类为停机问题，也就是说当今没有任何一个图灵机能完美判断一个样本是不是毒。但发现了这点并不代表做杀毒软件就没意义了，现实应用中很多情况我们追求的是”足够接近标准答案“而不是”100%完美鉴定器“，因为没法完美判识而否定存在价值则有点因噎废食了。实际上就算在软件层，判断程序的意图也并不总是一件容易的事。例如正规远控也能被恶意程序释放或者被诈骗集团利用，这种更高抽象层的判定就算是API等也不总能启发准确，也因此很多厂商索性将这种双刃剑程序归类到PUSA供用户自行判断。 从个人视角来看，我认为微架构层的遥控信息在增加判识输入维度上自然是有价值的，但具体能为当今的各类安全产品查杀带来多大的改善仍有待商榷。要知道当年绕过NVIDIA LHR的简单方法就是人为放慢程序挖矿速度让其降低到固件侦测的阈值下，而对于TDT来说倘若没有对抗时域上数据抖动之类的算法，类似的手段我估计也能用来逃逸相关检出。总体来说它并不能被看做是一套比当今已有杀软体系更优越的技术，只能说是在此基础上的一些补足。未来或许摒弃掉独立系统的概念，将性能计数器信息融入软件层协同侦测是更务实可靠的路线。 Intel TDT每个大的架构演进都需要重新选定合适的计数器并训练相关模型，这也给厂商带来了额外的研发负担。我好奇他们财政吃紧的当今是否能将这个项目继续开发下去，但凭心而论我内心挺佩服Intel作为PC头部厂商能不断尝试这些新技术并且最后推广到大量安全产品上的执行力。哪怕他们一些领域市占率逐步下滑，这种执行力和对ISV的号召力仍旧是其他厂商所没有的。
TDT的实战测试我从Skylake架构之后再没买过Intel平台的PC，最后的一台是Coffee Lake勉强够格开启ESET的TDT功能。本来是打算大篇幅写一下测试情况的，但最终这章基本腰斩了，原因是我的测试没有一个能触发ESET的TDT报毒。 为了验证是否测试方法有误，我检视了他们内部工作逻辑排除了几乎所有可能让报毒被压制的条件但仍旧找不到任何一个报毒的案例。由于TDT当年宣传能检测到虚拟机内的勒索软件，且TDT组件内也有专门针对虚拟机的一些处理，我也测试了虚拟机加密情况然而仍旧一无所获。 测试ESET难度在于它自己的软件勒索护盾已经拦了我很多样本，也没有其他特别方法能单独绕过软件勒索护盾测试TDT。我测过的案例包括但不限于以下情况（win11 x64）： - 基于powershell的AES加密仿勒索脚本，实机运行（我做了修改让它逃逸出RS软件报法，但也不触发TDT）
- 基于powershell的仿勒索脚本（行为更恶劣更明显），虚拟机内通过文件共享对实机加密
- 基于powershell的仿勒索脚本（行为更恶劣更明显），虚拟机内对虚拟机加密
- 使用恶意lnk触发脚本启动并运行虚拟机内仿勒索程序
- 使用2020左右年流行的勒索（cerber/ryuk/sodinokibi等）虚拟机内执行
- 基于C#的仿勒索程序实机运行
- 基于C#的仿勒索程序虚拟机内对实机加密
- 基于C#的仿勒索程序虚拟机内对虚拟机加密
算上我做的各种变种子类，以上数十种测试TDT全部歇菜完全不报。作为对照我甚至精选了以上一些情况测试了COMODO的TDT组件仍然是一个都不报 为了排除掉机子TDT没运行成功可能性，我又进一步检视了内存dump发现TDT已处于正常运行状态。总之能尝试的方法我都尝试了，做到这份上都不报只能说Coffee Lake平台的TDT在今日大概是形同虚设吧。我翻遍了kafan过往记录只看过少数一两次既不是勒索也不是挖矿的TDT检出，很可能是歪打正着实质为误报的检出。而23年SE Labs测试Intel TDT极高的勒索检出率到底测试集是什么、测试本身又是怎么做的、模型是啥时候的……这些就很耐人寻味了
总而言之以上测试只能说明第一代TDT检测能力极为有限，或许是模型老旧、或许是训练方法奇特、或许是第一代计数器太少模型太小？我肯定不会为了测TDT买专门买个Intel的PC，但有人愿意过一段时间给我提供一个Alder Lake时期的测试平台，因此未来有机会测试并有新发现的话我再回来更新这篇文章吧
2026-01-08：测试结果更新 重新评估了测试手段后心想要不狠一点实机测名气最大的那些勒索程序吧，这样总能落在他们的模型训练集里面。于是决定使用实机+影子系统的手段来测试。在毒组@Jerry.lin的帮助下重新收集了化石勒索样本进行测试，特此感谢 测试使用Comodo，主要因为Comodo不像ESET一样组件联动因此可以单独测试第一代TDT模型在Coffeelake上的检出率（我惊恐地发现有一个GandCrab的8x样本包Comodo今日的扫描引擎一个都扫不出来，难道老毒就被从库剔除掉了？？？）。
防御成功的标准是TDT弹窗，哪怕很多文件已经被加密；已经没法成功执行加密的样本已经被剔除。我觉得这个标准已经很宽松了
以下是测试结果
| 家族 | 流行时期 | 防御结果 | | Dharma | 2016 | 失败 | | Hermes | 2017-2 | 失败 | | Wannacry | 2017-5 | 成功 | | Wannacry（实机检测虚拟机）* | 2017-5 | 失败 | | GandCrab | 2018-1 | 失败 | | Ryuk | 2018-8 | 失败 | | Sodinokibi | 2019-4 | 失败 | | LockBit | 2019-9 | 成功 | | LockBit（加VMP壳） | 2019-9 | 成功 | | Blackout | 2024 | 失败 |
在测试前我心想：如果wannacry都检测不出来那我机子和TDT其中一个必然有问题吧……好在最大名鼎鼎的wannacry真的被TDT检测并隔离了。
TDT引擎记录了查杀事件
但总体来说这个结果有点搞笑了。或许这一代TDT真的到头来就是“记住程序长什么样”而不是对勒索行为的实际泛化。粗估模型的生成时间是2021年，但大量21年前的流行家族一个都捉不出来。这种检测质量更像一个学生demo的水平而不是官方宣传的那么神通广大
*TDT信誓旦旦说能检测VM内隐藏的勒索，结果也没检测出来：用常理想想，对于多核虚拟机来说假定勒索单线程执行则将定期在不同vCPU内迁移，而对宿主机来说TDT的序列记录基于进程树，那它又怎么能知道加密线程从哪个核心迁移到哪个从而读取正确的计数器呢？就算读取了正确的虚拟机核心又怎么把勒索从整个虚拟系统的噪声中分离出来呢？在上面的测试案例中我还特地放水只使用单核VM并且静置系统到空载为止才开始执行样本，结果照样是检测不出来
更糟的是真检出本身也存在问题：第一它反应速度比较慢，开始弹窗的时候不少文件已经被加密了。第二它检测不稳定，当系统噪声一大（例如在另一个查不出的样本执行时）再执行WannaCry那么WannaCry也查不出来了。
总之第一代TDT的实战表现让我大跌眼镜，这种检出率怪不得我样本做到吐血都不会查杀呢……之后有条件测测第三代的检出质量
=============================================
Kafan上的关联阅读：
Microsoft产品:
COMODO产品：
ESET产品：
火绒产品：
金山产品：
TrendMicro产品：
| 
发表于 
）
楼主