（4）测试代码应当具有影响所在执行体或运行场景输出矢量内容或控制其输出的能力。

（5）凡是测试代码功能两两不相同的测试例称为“差模测试例”，两两相同的称为“共模测试例”。

（6）所有执行体或运行场景F内原则上都还可以设置测试接口，但是同时驻留测试代码的数量f需满足n≤f≤F/2，n当前服务场景的余度数。

（7）实验阶段需开启系统管理界面以便整个实验过程可观察。

由于被测对象的异构执行体或运行场景软硬件支撑环境常常只有可执行目标代码甚至只是物理器件，测试例不仅构造困难而且往往不可注入，即使能够植入，功能验证也颇具挑战性。所以，在应用程序源代码层面上构建测试例接口、设计调用功能是可能的选择。测试接口应设计成具有通过可归一化攻击表面输入通道及合规方法请求激活的“后门功能”，能够借助攻击表面接收上传的测试代码，并可通过应用程序实施在线控制注入测试代码的执行。当然，有条件情况下也不排除在其他层面（例如操作系统层面）设置测试接口及相关功能的做法。需要指出的是，除了测试接口代码外，上传的目标对象测试代码应当是内存驻留型的可执行代码，以便灵活的定义或改变测试功能，增强注入测试的完备性。

在应用层设置实验接口及通过攻击表面注入测试代码还可达成另外二个目的：一是实验效果具有置信度。事实上，无论基于什么层面漏洞后门的攻击，只要能精确控制目标对象执行体或运行场景输出矢量的表达，也就是攻击所能达成的最高目标了。因而只要保证应用软件按约定的要求调用测试接口功能，激活注入的测试代码，就能直接或间接的威胁系统设定的安全目标；二是可通过系统管理界面观察执行体或运行场景异构资源配置情况。变化注入测试代码可以验证运行环境的CPU类型、OS版本或其他相关环境信息等，并可为测试代码确定目标执行环境。以拟态构造为背景说明如下：

4.1 差模注入实验

前提：假如一个被测目标功能函数满足I【p1,p2,p3,…,pn】O，其中，所有功能pi相同，即p1=p2=…=pn。但是所有pi的实现算法都不相同，即pc1≠pc2≠…≠pci。如果存在一个测试例e1可以使p1产生正常响应序列之外的输出矢量s1。以此类推，测试例e2 e3 ei可以使p2 p3 pi产生输出矢量s2 s3 si且s1≠s2≠s3≠si。那么，按照冗余构造理论定义，将相互之间没有配合关系的测试例e1 e2 e3 ei通过攻击表面分别注入p1 p2 p3 pi执行体或防御场景，在I【P】O的拟态界上不应该出现任何si。被测对象的防御功能应该能够清晰的表明，除了不能自动恢复的停机-制瘫事件之外，从机理上说，只要是不存在协同关系的“独狼式攻击”差模测试例，且该测试例一旦产生裁决器可感知的动作，并能在下一个测试例激活前可被策略性的清除或移除，对差模测试例的抑制效果应相当可观，例如拟态构可达到100%。

图1中是一个3余度拟态功能的实验场景，所有落在A、B、C三个执行体区域内的差模（功能各不相同的）测试例都应该设计成能被多模裁决环节感知的场景。如果目标对象采用的是拟态构造的反馈控制策略和迭代收敛后向验证机制，实验的预期结果应该是：问题执行体或运行场景本身要么被替换或重构重组，要么附着有注入测试例的执行体或运行场景被清洗复位或重启。相关实验场景、操作过程及响应结果应该是可观察的。

4.2 时间协同差模实验

在差模测试例注入实验的基础上，将f个差模测试例均匀分布在拟态构造内n个执行体的m种防御场景上（m≥n），差模测试例数量f与m的占比F=f/m﹡100%，满足34%≤F≤50%。实验者通过攻击表面连续地发出f个测试例的激活指令，观察目标对象在服务功能和性能上会有什么样的表现。重点关注，①实验过程中是否会产生差模逃逸；②实验对象在此过程中，其服务功能和性能的劣化程度；③反复地发送f个测试例的激活指令，测量实验对象的问题规避机制需要多长时间才能使相关防御场景不再被调用。

实验方案：①抽样测试执行体防御场景恢复时间以便确定f个测试例的连续激活策略；②在占比F为34%、40%、50%的情况下，确定f个测试例在m种场景中的部署策略（例如均匀分布）；③在实验过程中，测量目标对象服务功能和性能，验证可靠性与可用性设计指标，重点是测量同一组时间协同差模测试例从“攻击可达到攻击不可达”的时间，检验目标对象问题场景规避机制的有效性；④其他方法和操作参照差模测试例注入实验。需要指出的是，F的相关取值均应高于经典异构冗余构造（DRS）故障容忍极限f≤(n-1)/2。例如，当n=m=3时，DRS允许f≤1，对应的占比F≤33.3%。而时间协同差模测试例的实验取值，F=34%、40%、50%则分别对应DRS在n=3、5以及冗余度无限大时的最坏情况。

4.3 N-1模注入实验

该实验是为了检验可归一化攻击表面内一旦产生n-1共模有感逃逸（n为当前服务集冗余度），检验该构造或算法是否具有从逃逸状态下恢复的能力，证明该构造或算法是否能在出现共模逃逸事件时仍然具有预期的概率属性。尽管n-1共模逃逸在安全性量化设计中属于小概率或极小概率事件，但是目标对象工程实现中如果不能达成共模逃逸的解脱功能，则发生首次逃逸事件后，该攻击经验将可复制且不再属于概率问题了。n-1共模逃逸实验不仅要验证冗余功能的正确性还要测试恢复过程的持续时间，后者可量化评价抗共模逃逸性能高低。同理，整个实验过程和效果应当是可观察的。

n-1模测试例注入实验规定，如果目标算法或构造当前服务集内的执行体或防御场景数量为n，假定存在一个测试例ti可分别注入到n-1个执行体或防御场景内，并能以某种方式通过攻击表面激活且可产生n-1个相同输出矢量si。按照冗余构造定义，在可归一化的I【P】O界面上，此时虽然能出现大概率的共模逃逸现象，但是裁决器却可感知到多模输出矢量间存在不一致状态。换言之，n-1共模逃逸属于可感知的逃逸。假如构造内设计有反馈控制环节，则根据预先设计的后向验证策略（为了区别差模场景和n-1共模场景间的不同需要引入辅助判决策略），决定怎样通过渐进或迭代收敛方式改变攻击表面内的防御场景，使之退化成差模实验形态，最终被移除或清除，如拟态构造那样。

图2中是一个3余度拟态构造的抗n-1共模逃逸场景示意。显示了共模测试例a、b、c分别注入到执行体（防御场景）A和B的交集区、A和C的交集区、B和C的交集区的情况，以及这些测试例从执行体或运行场景内移除或清除的路径（不同颜色虚线所示）。假定n-1共模测试例能够注入任意2个执行体或运行场景的功能交集内，且可通过攻击表面输入通道合规的激励消息使之产生相同的输出矢量。按照拟态防御定义，裁决器此时能感知到多模输出矢量中存在不一致的情况，但不能直接甄别出问题执行体或运行场景，需要通过后向验证机制区分并消除注入的测试例影响：首先，对输出矢量不一致的执行体或运行场景作清除重启或替换操作，如果裁决器状态仍未改变，则在输出矢量相同的执行体或运行场景中按照某种策略选择一个对象实施前述操作。其次，观察裁决器状态，如果发生状态逆转则就会退化为差模状态，此时只要再对服务集内未更新过的执行体重复上述操作，注入的测试例将会被从当前服务集内清除或移出。因此，按照拟态防御定义，即便n-1共模攻击成功，其逃逸状态也不具有稳定鲁棒性。

需要指出的是，即使n-1模测试例在攻击表面意义上能被同时激活，由于拟态构造固有机制原因可能会被识别为差模攻击，因而不能保证n-1模逃逸状态的稳定呈现，需要反复注入和激励直到出现实验期望的n-1模逃逸状态为止。整个实验过程应当是可观察的。

由此不难看出，拟态构造的系统具有“即使逃逸成功也无法稳定维持”的特性，虽然不可能替代传统信息安全手段的全部作用，但是却具有后者所不具备的柔韧性或弹性功能。尤其是对企图利用差模攻击获取敏感信息或者破坏信息完整性的攻击者而言，拟态防御可能比一般的加密措施更具有比较优势，因为拟态防御不属于可计算问题，所以也不会陷入“一旦被暴力破解就全线崩溃”的困境。

4.4 N模注入实验

按照拟态构造定义，拟态构造存在极小概率的n模逃逸情况且可量化设计。但与n-1模逃逸情况不同，从机理上说拟态构造对于n模逃逸是不能感知的，需要通过外部或内部的某种策略，扰动反馈控制环路，改变拟态括号内的当前运行环境，使之转变为n-1模的可感知形态，并进入相应的解脱或恢复进程，确保n模逃逸即使发生，仍属于概率性事件。这一功能需要通过注入测试例的白盒方式进行检验，并根据设定的环路扰动策略，测量验证解脱恢复过程的标称时间。

假定注入的n模测试例如果能在3个执行体A∩B∩C的功能交集内产生一致的输出矢量，则拟态裁决环节理论上应当无感。但按照拟态防御定义，即使裁决器未发现输出矢量异常，当前服务集内的执行体或防御场景也可能因为外部控制指令发生强制的、非确定性的替换或清洗重启操作，这意味着n模注入测试条件下的逃逸状态一定是不稳定的，当执行体或防御场景自身具有清洗重启或可重构重组功能时，n模无感逃逸的情况应当随着恢复过程的推移自动转变为n-1模有感逃逸状态，并最终退化为差模情景并被无感移除。换言之，通过攻击表面注入服务集内的n模测试例会因为宿主执行体或运行场景被外部指令策略性的清洗重启或重构重组操作而移除。假如后向验证策略约定，执行体C作例行清洗后再重新加入当前服务集(也可直接重构或替换执行体C)，当C(或替换执行体)输出矢量与A和B仍旧不同时，反馈环路则会优先清洗或替换运行时间最长的执行体(譬如A)。于是，当裁决器发现AC输出矢量不同于B的情况时，表明前述场景中出现过逃逸现象，再对B实施上述操作直至裁决器不再有感。按图3虚线所示迁移轨迹，n模测试例场景会退变为n-1模测试场景，最后会退变到差模测试场景直至全部移除。由此可见，在拟态防御环境内即使攻击者有能力实施n模或跨域协同攻击构成一时的逃逸状态，但是从机理上因为无法获得保持稳定逃逸的能力，从而使攻击成果的鲁棒性利用成为难以克服的挑战。需要指出的是，即使n模测试例在攻击表面意义上能被同时激活，由于拟态构造固有机制原因可能会被识别为差模或n-1模攻击，因而不能保证n模逃逸状态的稳定呈现，需要反复注入和激励直到出现实验期望的n模逃逸状态为止。

4.5 反馈控制环路注入测试

拟态反馈控制环路包括输入分配与代理、输出裁决与代理及反馈控制三个部分。按照拟态防御定义，反馈环路与执行体和拟态括号的输入/输出通道之间只存在“单向联系机制”，且允许反馈控制环路内存在漏洞（事实上也很难杜绝）但不存在恶意代码之前提条件（低复杂度时，工程实践上通常可以满足）。

按照严格的单向联系机理，执行体内的病毒木马等应当无法利用反馈环路中的漏洞注入攻击代码或实现隧道穿越。同理，拟态括号功能对于外部攻击者而言通常是“透明的”，即无论是输入通道上的输入分配与代理环节，还是输出通道的输出裁决与代理环节，或者仅用于内部策略调度的反馈控制环节都应当是“不可见的”。因为理论上，拟态括号既不解析输入激励序列内容也不关心多模输出矢量的语法和语义，所以应当具有威胁目标的不可达性。然而，工程实现上，有时不得不关心输入激励序列的隔离导入和负载均衡等功能而必须引入代理机制，也常常因为拟态裁决无法回避异构冗余执行体多模输出矢量某些可选项值域、通信序列号等不确定性，甚至是计算精度上的差异而使之必须对其语法、语义等作非透明性的预处理。因此，随着括号部件功能复杂性或智能处理能力的增强，未知漏洞存在的可能性也随之增大。但是，如果在设计上能保证拟态括号部件即使存在漏洞也无法被利用，则可以认为满足基本安全性要求。 “白盒验证”方式，就是要检验能否在相关部件上设置“漏洞测试接口”，能否利用“漏洞接口”上传“测试代码”，以及能否利用上传的测试代码实现拟态逃逸。不过，这种方式有时会因为目标对象的实现技术形态而不能实施，例如，用无源光分配器或布线逻辑器件作为输入代理部件时，就无法设置“漏洞测试接口”以及“上传并执行测试代码”。倘诺如此，可以认为输入代理部件具有“漏洞不可利用”的固有属性。同理，如果无法借助从拟态括号规定的输入通道，途径输入代理部件和异构执行体输出，上传“测试代码”到输出代理部件或裁决器上的“测试漏洞”并执行之，则可以认为输出代理部件或裁决器也具有“漏洞不可利用”的属性。显然，这一属性并非是这些部件的固有属性，很大程度上是由于拟态构造效应带来的。需要强调指出的是，任何测试例即使能从拟态界外注入拟态括号相关部件的“测试漏洞”，但只要不能实现拟态逃逸之目的，仍可认为该括号满足“漏洞不可利用”的安全性假设。总之，工程实践上常常需要综合应用相关的安全技术，以确保拟态括号上即使存在设计漏洞也不能使之成为既定安全目标的“防御短板”。

4.6 性能度量

在上述各项测试中要度量测试例从激活到失能的时间，以此来衡量反馈控制环路的收敛速度、作动性能或场景规避精准度是否达到系统设计指标的要求。需要强调指出的是，不论何种形式的共模测试例，拟态防御从机理上都应该能从逃逸状态下自行解脱出来。也许不同设计方案导致的解脱时间有所不同，在实现代价方面也可能有所差异，但共模逃逸的解脱功能则是不可或缺的，因为“即使实现攻击逃逸，也不无法稳定维持”是拟态防御追求的高可用性目标。同理，通过差模测试例的设置也可检验目标对象的可靠性设计效果。