困惑BigFix相关 – x64文件

我在企业环境中使用BigFix,并注意到最近一轮针对2016年的微软补丁在一小部分资产上失败了。 我可以通过使用修改的相关性创buildCustom Copy Fixlet来解决这个问题,但是我必须使用的相关性并不总是一致的,即使大多数文件都位于C:\Windows\Sytem32

例如:MS16-031 – 我的扫描平台正在查找的条件是基于Ntdll.dll的版本号。 我创build一个具有相关性的自定义Fixlet:

((version of x64 file "C:\Windows\System32\Ntdll.dll") as string) < VersionNumberGoesHere

这很好,因为我创build了一个以前使用相关性来查找Ntdll.dll的BigFix Analysis:

if (exists x64 file "C:\Windows\System32\Ntdll.dll") then ((version of x64 file "C:\Windows\System32\Ntdll.dll") as string) else "Does Not Exist"

我能够确认Custom Fixlet的相关性恰好与Analysis相关。 出于某种原因,这不是两个镜像,但它非常接近,Custom Fixlet列表是扫描结果中标记的所有机器,所以我很高兴。

问题出现在这里:对于C:\Windows\System32 某些文件,我必须使用完全不同的语法才能根据扫描结果获取正在查找的正确版本号信息。 也就是说,我可以使用上面列出的方法,但它所提供的版本信息甚至与扫描程序所要查找的内容并不相近。 如果我要使用上面列出的方法,假设扫描仪正在寻找类似于“版本号6.1.7600.16385”的东西,我将看到的结果会改为“1.1.11302.0”。 这仍然是某种明显的版本编号,但与我的扫描平台所引用的types完全不同。

例如:MS16-027 – 要查找mfds.dll的文件版本信息以进行分析,我必须使用:

value "FileVersion" of version block 1 of file "mfds.dll" of system folder

对于Custom Fixlet,我必须使用:

value "FileVersion" of version block 1 of file "mfds.dll" of system folder != VersionNumberGoesHere (OSServicePatch_gdr.LongStringOfNumbers)

我已经对BigFix的Action Script语法进行了一些阅读,但是似乎x64 file (command)file (command)可能导致基于32位系统与64位系统的path不同的结果,但是,我认为这只适用于位于C:\Program FilesC:\Program Files (x86) ? 情况不是这样吗? 如果是的话,System32的64位版本在哪里,为什么两者之间的结果如此不同呢?

只是为了澄清,这是一个关于BigFix相关性的问题,而不是BigFix ActionScript。

我会说,尽pipeBigFix的相关性有一点点的学习曲线,并且使得复杂性的源头有时候很难找出来,但是你所遇到的问题更多地与文件如何具有许多不同types的版本的复杂性有关信息加上微软WindowsOnWindowsredirect的工作方式。


文件版本信息根据读取地点不同而变化的一个简单的原因就是有多个地方可以放置文件版本,而且它们可以完全匹配,也可以不同。 这取决于文件的创build者以及他们如何传达版本信息的含义。

versions of files "mfds.dll"的相关versions of files "mfds.dll"读取一个位置,而values "FileVersion" of version blocks of files "mfds.dll"的相关values "FileVersion" of version blocks of files "mfds.dll"读取不同的位置。

看这里:

 Q: (values "FileVersion" of version blocks of it, (it as string) of versions of it) of files "mfds.dll" of (system folders) A: 10.0.14342.1000 (rs1_release.160506-1708), 10.0.14342.1000 T: 3.677 ms I: plural ( string, string ) 

我不认为你所看到的差异是由于filex64 file之间的差异造成的,但是理解很多原因很重要。

对于这个问题的目的,假设我们正在谈论一个64位Windows计算机,你应该假设这适用于Windows Vista或更高版本,但也可能适用于Windows XP 64位。

由于BigFix客户端是一个32位的进程,所有对特殊x64位的文件读取实际上是由窗口redirect到32位的。

BigFix相关性中的filesx64 files什么区别? 在大多数文件的情况下,使用filesx64 files将实际上读取相同的文件。 这是因为使用x64 files告诉BigFix在禁用WindowsOnWindows(WoW)redirect的情况下读取文件,但是这种redirect仅适用于读取特定path。 一个例子是Program Files ,另一个例子是System32 ,而像C:\Windows\Temp这样的东西根本不受WoWredirect的影响,所以任何读到C:\Windows\Temp的文件都是一样的。

  • 32位位置: C:\Program Files (x86)
  • 64位位置: C:\Program Files
  • 32位的位置: C:\Windows\SysWOW64
  • 64位的位置: C:\Windows\System32
  • 64位位置: C:\Windows\sysnative
    • 特殊的假path,不禁用redirect

我们有微软为64位系统所在的位置有32个名字而感谢,而32位系统所在的位置有64个。 这绝对是一个非常普遍的混乱的来源。

使用这种相关性来查看系统上实际上有2个mfds.dll副本。

(name of it, size of it) of files "mfds.dll" of (system folders; system x64 folders)

因为(system folders; system x64 folders)告知BigFix读取C:\Windows\SysWOW64文件夹以及C:\Windows\System32文件(system folders; system x64 folders)所以此相关性会同时读取两个位置。

疯? 混乱? 等等,它变得更加怪异。

在fixletdebugging器中运行以下相关性pathnames of files "mfds.dll" of (system folders; system x64 folders)

 Q: pathnames of files "mfds.dll" of (system folders; system x64 folders) A: C:\WINDOWS\system32\mfds.dll A: C:\WINDOWS\system32\mfds.dll T: 1.312 ms I: plural string 

注意两个文件的path名是相同的,但这些文件不是相同的文件!

这是WindowsOnWindowsredirect的工作方式。 它位于32位进程,并告诉它从C:\Windows\System32位置读取文件,即使它从C:\Windows\SysWOW64读取,而不是在使用system folders相关性的情况下,那么BigFix 正确报告path名为C:\WINDOWS\system32\mfds.dll 。 然后,在system x64 folders相关的情况下,BigFix(32位进程)告诉Windows它想要禁用redirect来读取位置C:\Windows\System32 ,在这种情况下,它实际上读取位于C:\WINDOWS\system32\mfds.dll正确报告path名。

我想重申一下,这与BigFix无关,一切与微软Windows 32位redirect的Windows 64位实现有关。


对于未来的BigFix问题,我会强烈build议非常活跃的论坛: https : //forum.bigfix.com/