为了测试“启用：动态代码安全性”选项，我将新的配置选项应用于 %windir%\schemas\CodeIntegrity\ExamplePolicies 的AllowAll.xml策略，产生了以下简单的策略：

<?xml version="1.0" encoding="utf-8"?><SiPolicy xmlns="urn:schemas-microsoft-com:sipolicy">  <VersionEx>1.0.0.0</VersionEx>  <PolicyTypeID>{A244370E-44C9-4C06-B551-F6016E563076}</PolicyTypeID>  <PlatformID>{2E07F7E4-194C-4D20-B7C9-6F44A6C5A234}</PlatformID>  <Rules>    <Rule>      <Option>Enabled:Unsigned System Integrity Policy</Option>    </Rule>    <Rule>      <Option>Enabled:Advanced Boot Options Menu</Option>    </Rule>    <Rule>      <Option>Enabled:UMCI</Option>    </Rule>    <Rule>      <Option>Enabled:Update Policy No Reboot</Option>    </Rule>    <Rule>      <Option>Enabled:Dynamic Code Security</Option>    </Rule>  </Rules>  <!--EKUS-->  <EKUs />  <!--File Rules-->  <FileRules>    <Allow ID="ID_ALLOW_A_1" FileName="*" />    <Allow ID="ID_ALLOW_A_2" FileName="*" />  </FileRules>  <!--Signers-->  <Signers />  <!--Driver Signing Scenarios-->  <SigningScenarios>    <SigningScenario Value="131" ID="ID_SIGNINGSCENARIO_DRIVERS_1" FriendlyName="Auto generated policy on 08-17-2015">      <ProductSigners>        <FileRulesRef>          <FileRuleRef RuleID="ID_ALLOW_A_1" />        </FileRulesRef>      </ProductSigners>    </SigningScenario>    <SigningScenario Value="12" ID="ID_SIGNINGSCENARIO_WINDOWS" FriendlyName="Auto generated policy on 08-17-2015">      <ProductSigners>        <FileRulesRef>          <FileRuleRef RuleID="ID_ALLOW_A_2" />        </FileRulesRef>      </ProductSigners>    </SigningScenario>  </SigningScenarios>  <UpdatePolicySigners />

该策略允许执行所有用户模式和内核模式代码。在这一点上，我不确定这个宽松的策略是否会产生任何明显的执行差异，但是值得一试。我用以下PowerShell命令启用了该策略，然后重新启动：

ConvertFrom-CIPolicy -XmlFilePath。\ AllowAll_Modified.xml -BinaryFilePath C：\ Windows \ System 32 \ CodeIntegrity \ SIPolicy.p7b

我的第一个强制测试：调用Add-Type（用来触发原始竞争条件绕过）。如果启用了WDAC功能后，C＃编译和受信任代码（即每个策略批准）的加载就可以正常工作。在我的博客文章中，我导入了“ PSDiagnostics”模块，触发竞争条件，因为它是调用Add-Type的已签名模块。但是，在启用“动态代码安全性”的情况下，尝试导入模块失败。

（“动态代码安全性”功能导致PowerShell触发异常）

为了取证该错误和“动态代码安全性”的启用有关，我在没有执行Device Guard、以及使用未经修改的AllowAll.xml策略执行Device Guard这两种情况下，测试PSDiagnostics模块是否加载成功。安全研究的一项重要技能是应用程序根本原因分析，其中包括切分问题。所以，我可以确认的内容如下：

• 在代码完整性策略中启用“动态代码安全性”会中断受信任代码对Add-Type的调用，原因不明。这和我的假设相反，因为调用Add-Type的受信任代码应该是可以执行的。但从研究的角度来看，这个异常可以让我识别在代码“动态代码安全性”中的执行位置。

找出在上述截图中引发异常的代码，第一件事是获取异常的堆栈跟踪。这里有两个例外，所以我会转储这两个的堆栈跟踪：

（在触发两个异常后，没有堆栈跟踪）

打开.NET反编译器和调试器，查找异常的根源之前，应该先验证C＃编译。为此，用procmon来验证是否删除了编译文件（即临时.cs和.dll文件）。编译的发生与否有助于缩小调查范围。

运行procmon、为powershell.exe进程及其任何子进程过滤“进程创建”和“ WriteFile”操作后，可以确认没有创建编译工件：

（在procmon.exe中查看C＃编译文件对应的进程）

为了验证提供的csc.exe的命令行参数是否正确，需要检查procmon跟踪中的临时.cmdline文件（该文件为csc.exe提供大量参数）的内容。因为这些文件很快就会被删除，所以我运行下面这行代码来获取文件：

while ($true) { ls $Env:TEMP\*.cmdline | cp -Destination C:\Test\ }

这是.cmdline文件的内容：

/t:library /utf8output /EnforceCodeIntegrity /R:"System.dll" /R:"C:\Windows\Microsoft.Net\assembly\GAC_MSIL\System.Management.Automation\v4.0_3.0.0.0__31bf3856ad364e35\System.Management.Automation.dll" /R:"System.Core.dll" /out:"C:\Users\UnprivilegedUser\AppData\Local\Temp\jz24g5tn.dll" /debug- /optimize+ /warnaserror /optimize+  "C:\Users\UnprivilegedUser\AppData\Local\Temp\jz24g5tn.0.cs"

/EnforceCodeIntegrity选择与代码完整性的执行有关。这是一个很好的线索。

现在有几个调查途径：逆向csc.exe，确定/EnforceCodeIntegrity执行方式，或者识别提供/EnforceCodeIntegrity选择给csc.exe的.NET代码…或者两者都调查一遍。最简单的方法是识别提供选择的.NET代码。但在执行这个操作前，需要检查一下是否有记录命令行选择。csc.exe的内置提供了一些上下文：

配置操作系统，检查编译输入的代码完整性，使用执行代码完整性的程序启用加载编译集。

要记住，在做安全性研究/逆向工程时，找到正确答案的方法不止一个。您只需要跟踪面包屑（向多个方向转向），直到您到达森林中的一片空地（是的，就跟着隐喻一起走）即可为您提供到达最终目的地所需的清晰度。逆向工程相当于收集拼图碎片，但你对拼图的完成状态没有清晰的概念。

用.NET反编译器dnSpy来查找/EnforceCodeIntegrity字符串。成功。它找到并反编译了Microsoft.CSharp.CSharpCodeGenerator.CmdArgsFromParametersSystem.dll里的以下代码片段：

if (FileIntegrity.IsEnabled){    stringBuilder.Append("/EnforceCodeIntegrity ");}

现在，识别让FileIntegrity.IsEnabled正确返回的条件，因为.cmdline文件里有/EnforceCodeIntegrity，所以可以推断出这是正确的。

单击“ IsEnabled”，观察其引用（右键单击，选择“ 分析”），你会看到它已设置为以下代码：

private static readonly Lazy<bool> s_lazyIsEnabled = new Lazy<bool>(delegate(){    Version version = Environment.OSVersion.Version;    if (version.Major < 6 || (version.Major == 6 && version.Minor < 2))    {        return false;    }    bool result;    using (SafeLibraryHandle safeLibraryHandle = SafeLibraryHandle.LoadLibraryEx("wldp.dll", IntPtr.Zero, 2048))    {        if (safeLibraryHandle.IsInvalid)        {            result = false;        }        else        {            IntPtr moduleHandle = UnsafeNativeMethods.GetModuleHandle("wldp.dll");            if (!(moduleHandle != IntPtr.Zero) || !(IntPtr.Zero != UnsafeNativeMethods.GetProcAddress(moduleHandle, "WldpIsDynamicCodePolicyEnabled")) || !(IntPtr.Zero != UnsafeNativeMethods.GetProcAddress(moduleHandle, "WldpSetDynamicCodeTrust")) || !(IntPtr.Zero != UnsafeNativeMethods.GetProcAddress(moduleHandle, "WldpQueryDynamicCodeTrust")))            {                result = false;            }            else            {                int num = 0;                int errorCode = UnsafeNativeMethods.WldpIsDynamicCodePolicyEnabled(out num);                Marshal.ThrowExceptionForHR(errorCode, new IntPtr(-1));                result = (num != 0);            }        }    }    return result;});

这是基于对wldp.dll函数的所有引用进行研究的线索/路径的重大发现。因为我之前已经逆逆向了wldp.dll（Windows锁定策略），因为用户模式代码用DLL 来获取WDAC执行状态/策略。上面代码段的wldp.dll函数是1803的新功能，所以我要进行逆向。

有很多代码都是逆向的。那么，应该从哪里开始？如果想找到问题答案，你要时常提醒自己，你做逆向的目标是什么。自己操作越多，目标就会有所转换，或者更加广泛。我的第一个目标是确认启用“动态代码安全性”会缓解我报告和写过的Device Guard绕过。当缓解措施没有效果后，下一个目标便是找出失效的根本原因。目前的重点仍然是找出受信任代码无法调用Add-Type的原因。

所以，找到Add-Type问题的根本原因后，我会做个记录，以便到时返回wldp.dll函数，了解它们的执行方式。

‘c:\Windows\Microsoft.NET\assembly\GAC_MSIL\System.Management.Automation\v4.0_3.0.0.0__31bf3856ad364e35\System.Management.Automation.dll’ could notbe opened — ‘Common Language Runtime Internal error: 0xd0000428’

/R:"C:\Windows\Microsoft.Net\assembly\GAC_MSIL\System.Management.Automation\v4.0_3.0.0.0__31bf3856ad364e35\System.Management.Automation.dll"

从WldpIsDynamicCodePolicyEnabled开始，用加载符合把它加载到IDA，生成一个相对简单的函数（目前暂时不加注释）：

（IDA中未注释的WldpIsDynamicCodePolicyEnabled函数）

这个函数仅包含NtQuerySystemInformation的简单调用以及某种比较。目前尚不清楚从NtQuerySystemInformation检索什么类型的信息。确定检索的信息，可以通过第一个参数（RCX- x64 ABI中函数的第一个参数）-0xA4（十进制164）查看传递的枚举值。虽然该枚举值没有被记录，但可以转储SYSTEM_INFORMATION_CLASS枚举，提供上下文。以下是WinDbg执行的命令：

dt ole32!SYSTEM_INFORMATION_CLASS

把枚举转储到WinDbg后，0xA4解析为“ SystemCodeIntegrityPolicyInformation”。这个枚举值指定NtQuerySystemInformation返回结构的类型。但其返回的结构也没有记载。为了确定可能的返回结构类型，我认为应该在加载的符号中搜索包含字符串“ CODEINTEGRITY”和“ INFORMATION”的结构。

dt ole32!*CODEINTEGRITY*INFORMATION*

它返回了一个不错的候选结构定义——ole32！SYSTEM_CODEINTEGRITYPOLICY_INFORMATION。那么，要如何得知它是不是正确的结构？这需要把WinDbg报告的结构大小和传递给NtQuerySystemInformation —0x20的大小进行比较：

dt -v ole32!SYSTEM_CODEINTEGRITYPOLICY_INFORMATIONstruct _SYSTEM_CODEINTEGRITYPOLICY_INFORMATION, 4 elements, 0x20 bytes   +0x000 Options          : Uint4B   +0x004 HVCIOptions      : Uint4B   +0x008 Version          : Uint8B   +0x010 PolicyGuid       : struct _GUID, 4 elements, 0x10 bytes

大小匹配，可以确信这是正确的结构，并且结构名称和枚举值匹配。现在有足够的信息把结构应用到IDA的函数，接下来就可以把重点放在执行从NtQuerySystemInformation返回的数据比较的函数：

（WldpIsDynamicCodePolicyEnabled带注释的基本块，用于验证已配置的代码完整性选项）

那么，“选项”字段指的是什么？为什么将其与0x110进行比较？这个字段也没有记录下来，但有时可以在.NET代码中查找枚举和结构定义，从而进行规避。System.Management.Automation.dll代码有一些值：

internal enum CodeIntegrityPolicyOptions : uint{  CODEINTEGRITYPOLICY_OPTION_ENABLED = 1u,  CODEINTEGRITYPOLICY_OPTION_AUDIT_ENABLED,  CODEINTEGRITYPOLICY_OPTION_WHQL_SIGNED_ENABLED = 4u,  CODEINTEGRITYPOLICY_OPTION_EV_WHQL_SIGNED_ENABLED = 8u,  CODEINTEGRITYPOLICY_OPTION_UMCI_ENABLED = 16u,  CODEINTEGRITYPOLICY_OPTION_SCRIPT_ENFORCEMENT_DISABLED = 32u,  CODEINTEGRITYPOLICY_OPTION_HOST_POLICY_ENFORCEMENT_ENABLED = 64u,  CODEINTEGRITYPOLICY_OPTION_POLICY_ALLOW_UNSIGNED = 128u}

0x110引用的0x10（16）转换为“ CODEINTEGRITYPOLICY_OPTION_UMCI_ENABLED”，但该枚举中没有0x100。我只能假定添加了0x100（256），.NET枚举没有更新，没有需要该值。如果同时启用UMCI和“动态代码安全性”选项，“ DynamicCodePolicy”也要跟着启用，即对二进制0x10和0x100进行运算，结果为0x110。这似乎很直观，因为缓解和我们在本文中谈论的功能有关，动态代码执行仅与用户模式代码强制（UMCI）场景相关。

WldpSetDynamicCodeTrust也是一个非常简单的函数。它不是调用NtQuerySystemInformation，而是调用NtSetSystemInformation，如果想了解该函数，那就要确定给NtSetSystemInformation的枚举值和结构类型。

（执行IDA中未注释的WldpSetDynamicCodeTrust）

因此，第一个需要解析的参数（通过RCX传递）枚举值为0xC7。使用上面讨论过的发现进程，0xC7解析为“ SystemCodeIntegrityVerificationInformation”，它对应另一个未记录的结构：SYSTEM_CODEINTEGRITYVERIFICATION_INFORMATION。

dt -v ole32!SYSTEM_CODEINTEGRITYVERIFICATION_INFORMATIONstruct _SYSTEM_CODEINTEGRITYVERIFICATION_INFORMATION, 3 elements, 0x18 bytes   +0x000 FileHandle       : Ptr64 to Void   +0x008 ImageSize        : Uint4B   +0x010 Image            : Ptr64 to Void

所以，我们只能看到WldpSetDynamicCodeTrust接收作为参数的文件句柄，并将其传递给NtSetSystemInformation。如果要查看NtSetSystemInformation的执行，你会发现它只是一个syscall。所以，想要知道SystemCodeIntegrityVerificationInformation过渡到内核后会执行什么操作，我们要逆内核代码。一个办法是用内核调试器跟踪内核的syscall，另一个是找到可能和“动态代码信任”功能相关的代码，在该功能上设置断点，看结果是不是这个函数。尝试第二个方法应该能很快就得到结果。

寻找相关功能可以从ntoskrnl.exe开始，因为它是在内核执行NtSetSystemInformation的模块。根据我的经验，代码完整性/图像验证功能是在ci.dll（ci-代码完整性）执行。那是我第一个想看的地方，所以我把它加载到IDA，应用符号搜索名称中带有“ DynamicCode”的函数。

搜索后显示以下函数：

• SIPolicyDynamicCodeSecurityEnabled

• CiValidateDynamicCodePages

• CipQueryDynamicCodeTrustClaim

• CiSetDynamicCodeTrustClaim

• CiHvciValidateDynamicCodePages

CiSetDynamicCodeTrustClaim函数并不复杂，它只执行一个操作 —— 在接收到的文件句柄（FILE_OBJECT）上设置NTFS扩展属性。

（CiSetDynamicCodeTrustClaim设置NTFS扩展属性）

“ $ Kernel.Purge.TrustClaim”扩展属性名称是新的，我很好奇和该扩展属性关联的数据。

FsRtlSetKernelEaFile的第二个参数采用FILE_FULL_EA_INFORMATION结构。在IDA中可以看到它的填充方式，但把它转储到WinDbg也很有用：

kd> dt OLE32!FILE_FULL_EA_INFORMATION @rdx   +0x000 NextEntryOffset  : 0   +0x004 Flags            : 0 ''   +0x005 EaNameLength     : 0x18 ''   +0x006 EaValueLength    : 0xc   +0x008 EaName           : [1]  "$"kd> dd @rdx+21 L3ffffb48f`f390bed1  00080001 00000000 00000000

示例中的“ dd”（转储dword）命令转储扩展属性的值。目前尚不清楚0x80001值是指什么。“ L3”会命令WinDbg转储3个DWORD值，这些值等于0xC字节 —— EaValueLength字段报告的值。

在用户模式下，调用WldpSetDynamicCodeTrust，内核把扩展属性“ $ Kernel.Purge.TrustClaim”应用于有某种标记的文件，以供后面引用。

最好确认下我们在调试器中命中了CiSetDynamicCodeTrustClaim，查看堆栈框架。如下所示，我们确实从“ MarkAsTrusted” .NET方法（上面有讲过）获得了这个函数：

kd> k # Child-SP          RetAddr           Call Site00 ffff818a`78d97578 fffff806`2349a087 CI!CiSetDynamicCodeTrustClaim01 ffff818a`78d97580 fffff800`e5cb1e06 CI!CiSetInformation+0x2702 ffff818a`78d975b0 fffff800`e57c0223 nt!NtSetSystemInformation+0x17c2fe03 ffff818a`78d97a80 00007ffe`ef53d3c4 nt!KiSystemServiceCopyEnd+0x1304 000000ec`ec88e6d8 00007ffe`eaec4259 ntdll!NtSetSystemInformation+0x1405 000000ec`ec88e6e0 00007ffe`c33d39fa wldp!WldpSetDynamicCodeTrust+0x2906 000000ec`ec88e730 000002a6`acbf0bf8 System_ni!DomainBoundILStubClass.IL_STUB_PInvoke(Int32 ByRef)$##6000000+0x14a07 000000ec`ec88e738 000002a6`acc03880 0x000002a6`acbf0bf808 000000ec`ec88e740 000002a6`acbf0bf8 0x000002a6`acc0388009 000000ec`ec88e748 00007ffe`c4de46d5 0x000002a6`acbf0bf80a 000000ec`ec88e750 00007ffe`c33c96bf clr!ThePreStub+0x550b 000000ec`ec88e800 000002a6`acb4bf50 System_ni!System.CodeDom.Compiler.FileIntegrity.MarkAsTrusted(Microsoft.Win32.SafeHandles.SafeFileHandle)$##6003CEB+0xf

查看IDA，可以看到WldpQueryDynamicCodeTrust执行的操作是逆向：

（WldpQueryDynamicCodeTrust反汇编的带注释的部分）

这个截图显示了WldpQueryDynamicCodeTrust函数的主要部分，它用相同的枚举值调用NtSetSystemInformation，该枚举值在WldpSetDynamicCodeTrust中传递NtQuerySystemInformation。内核设置的扩展属性“ $ Kernel.Purge.TrustClaim”不执行任何验证。相反，它相信内核已经对它进行验证，它只会看NtQuerySystemInformation是否返回错误/警告 —— 错误/警告设置了高位（即大于或等于0x80000000）的返回值。它用的是“ jns ”指令。

为什么用户模式会信任验证扩展属性的内核。首先看一下CipQueryDynamicCodeTrustClaim的执行。我会跳过一些函数执行，仅显示执行扩展属性数据验证的相关部分：

（CipQueryDynamicCodeTrustClaim扩展属性数据验证）

CipQueryDynamicCodeTrustClaim检索“ $ Kernel.Purge.TrustClaim”扩展属性的数据部分。然后，它将前两个字节与1（上面截图的倒数第二个指令）进行比较。如果将其设置为1，那么CipQueryDynamicCodeTrustClaim认为文件是受信任的。所以，这给为什么尽早设置至少一部分扩展属性数据提供了一些上下文：

kd> dd @rdx+21 L3ffffb48f`f390bed1  00080001 00000000 00000000

静态0x0008的用途还尚不明确，但我并不太担心，因为已验证的只是0x0001值。

WldpIsDynamicCodePolicyEnabled，WldpQueryDynamicCodeTrust和WldpSetDynamicCodeTrust在用户和内核模式下执行以下操作：

• WldpIsDynamicCodePolicyEnabled —— 验证是否同时执行了用户模式代码完整性（UMCI）和动态代码安全性（即“ Enabled：Dynamic Code Security”选项）。

• WldpSetDynamicCodeTrust —— 在文件上设置NTFS扩展属性“ $ Kernel.Purge.TrustClaim”。

• WldpQueryDynamicCodeTrust —— 验证是否在文件上设置了“ $ Kernel.Purge.TrustClaim” NTFS扩展属性。

设置和读取文件上的扩展属性是为了缓解.cs竞争条件劫持攻击？其实它是用来让受信任的用户模式代码可以将已删除的.cs文件标记为受信任的，然后可以在之后验证该文件是否来源于受信任的进程。扩展属性用“ $ Kernel.Purge”前缀的好处是，如果文件被覆盖，内核会自动删除扩展属性。也就是说，劫持.cs文件的行为会强制删除扩展属性，从而使文件“不受信任”。从表面上看，这似乎是个不错的缓解措施...假设缓解措施的应用方式正确，即确保将正确的文件标记为受信任的文件，把不应被标记为受信任的文件标为不受信任的文件。

if (!FileIntegrity.IsEnabled){    compilerResults.CompiledAssembly = Assembly.Load(array, null, options.Evidence);    return compilerResults;}if (!FileIntegrity.IsTrusted(fileStream2.SafeFileHandle)){    throw new IOException(SR.GetString("FileIntegrityCheckFailed", new object[]    {        options.OutputAssembly    }));}compilerResults.CompiledAssembly = CodeCompiler.LoadImageSkipIntegrityCheck(array, null, options.Evidence);return compilerResults;

假设我无法绕过“ FileIntegrity.IsEnabled”检查，继续执行FromFileBatch的下一行：

if (!FileIntegrity.IsTrusted(fileStream2.SafeFileHandle)){    throw new IOException(SR.GetString("FileIntegrityCheckFailed", new object[]    {        options.OutputAssembly    }));}

如果未被标记为受信任，则此代码段会引发异常，且不会加载已编译的DLL。第一步是识别是否把已编译的DLL标记为受信任的代码，即在文件上调用WldpSetDynamicCodeTrust。.NET中没有该代码，csc.exe也没有，所以我假设该代码可能在csc.exe加载的DLL中。为了确认下，我在Powershell.exe启动时把WinDbg附加到csc.exe，设置了加载wldp.dll的断点（ sxe ld wldp ），然后在WldpSetDynamicCodeTrust上设置断点。我只有一次到达断点。我登陆了PEWriter::writemscorpehost.dll中的函数。

PEWriter::write 函数（https://github.com/dotnet/coreclr/blob/20275aa647c5733bc5b1929cba3fd1094c67fb1d/src/dlls/mscorpe/pewriter.cpp#L2179-L2276）是开源的。但调用WldpSetDynamicCodeTrust的最新版本不在GitHub上。没关系。过时的源代码能让IDA反汇编更加容易。这是调用WldpSetDynamicCodeTrust的代码部分：

（PEWriter：读取函数调用 WldpSetDynamicCodeTrust）

这里的攻击情形要在调用WldpSetDynamicCodeTrust前覆盖已编译的DLL。这是不可能的，但是，因为PEWriter::write持有DLL的句柄，并且在保持该句柄的同时拒绝覆盖它，其他任何进程都会被拒绝访问。从获得句柄开始，把DLL写入磁盘，再到调用WldpSetDynamicCodeTrust的那一刻起，就不会释放该句柄。另外，mscorpehost.dll用与System.dll相同的LoadLibraryEx缓解措施来调用wldp.dll函数，防止了上一部分所述的攻击。

之前我提到过，还可以劫持已删除的.cmdline文件，删除/EnforceCodeIntegrity选择。但删除这个选择的副作用是，无法把已编译的DLL标记为受信任，但FromFileBatch有望能让该文件被标记为受信任。所以，当FromFileBatch验证DLL的信任时，它不会被标记为受信任，然后引发异常。