Windows 更新安全补丁的内部结构如何工作?

逆向工程 视窗 修补 二进制
2021-07-07 03:58:31

不确定在堆栈交换中在哪里问这个问题,所以如果你认为它在错误的地方,请投票关闭。

我正在分析 Windows 安全补丁。从未检查过 Windows 安全补丁,并且不知道它们的结构,我试图自己弄清楚。

在我的补丁(本周的 IE 补丁)中,我有这些文件:

_manifest.cix.xml <- obviously a manifest for the patch. 
Binary files numbered 0 - 130 
Dozens of files with similar names to this: amd64_1d07faac344e137a0d122aad24eb4e6e_31bf3856ad364e35_11.2.9600.17280_none_eaadf6b3ac7d9c33.manifest <- I am assuming that these are architecture specific changes. 
package_1_for_kb2977629~31bf3856ad364e35~amd64~~11.2.1.0.cat <- A catalog of some sort. Not sure how it's used by the update. 
package_1_for_kb2977629~31bf3856ad364e35~amd64~~11.2.1.0.mum <- more information about the update. 

我的问题是:是否有关于所有这些部分如何协同工作的综合文档,如果没有,所有这些部分如何协同工作?

我想,必须发生的是某种机制必须告诉更新二进制文件中要修补的位置,然后编号为 0-130 的文件之一是要覆盖的代码。我确定有一种标准格式,以便我可以解释这些文件。

例如:

<?xml version="1.0" encoding="utf-8"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v3" manifestVersion="1.0">
  <assemblyIdentity name="1d07faac344e137a0d122aad24eb4e6e" version="11.2.9600.17280" processorArchitecture="amd64" language="neutral" buildType="release" publicKeyToken="31bf3856ad364e35" versionScope="nonSxS" />
  <deployment />
  <dependency discoverable="false">
    <dependentAssembly dependencyType="install">
      <assemblyIdentity name="Microsoft-Windows-IE-MemoryAnalyzer" version="11.2.9600.17280" processorArchitecture="amd64" language="neutral" buildType="release" publicKeyToken="31bf3856ad364e35" versionScope="nonSxS" />
    </dependentAssembly>
  </dependency>
</assembly>

似乎暗示我们即将修补程序集 1d07faac344e137a0d122aad24eb4e6e,它可能被命名为“Microsoft-Windows-IE-MemoryAnalyzer。这只是一个猜测!我在这里没有看到任何要修补的代码的参考。我想象一种方式这样做只是按顺序阅读这些清单,并按照读取清单的顺序应用补丁。第一个清单获取二进制文件 0,依此类推。这看起来很糟糕,我敢打赌我错了。

根据文件本身的大小,我认为它们不会重写整个模块,尽管它们可能被压缩。在没有任何参考的情况下,我对它们的结构一无所知。我想会有代码片段,以及重写有问题的 DLL/Exes 的位置的偏移量。当然,我在二进制文件上运行了字符串,但没有找到任何东西。

我最想弄清楚的是,IE 中正在修补哪些特定功能。

2个回答

我刚刚下载了KB2977629补丁文件(IE11-Windows6.1-KB2977629-x64.MSU)。它看起来像是关于哪个文件对应于文件中的内容的信息_manifest_.cix.xml(里面有一条很长的行)。例如,您有:

<File id="214" name="amd64_microsoft-windows-s..-downlevel.binaries_31bf3856ad364e35_6.3.9600.17280_none_5f668c1aff756211\msspellcheckingfacility.exe" length="940032" time="130528725776317394" attr="32"> ... </File>
<Delta>
  <Source type="PA30" name="35"> (...) </Source>
  <Basis file="214"/>
</Delta>

35 似乎是存档中文件之一的名称。这些文件以读取“PA30”的 4 个字节开头,因此它看起来像一种特定的格式。我在专利申请中找到了对该修补系统的一些参考:http : //www.google.com/patents/US20070260653

实际上,大多数 Windows 更新不使用此增量补丁系统,而是包含它们将要替换的每个文件的完整版本。

有一个 API:https : //docs.microsoft.com/en-us/previous-versions/bb417345(v=msdn.10)

实现它的 mspatcha.dll 和 mspatchc.dll 直到 Windows 10 才在 SYSTEM32 下。

但是,找不到该格式的文档。


这是一个有趣的事实:Microsoft Azure DevOps Server(以前称为 Team Foundation Server/TFS)使用 MSPatch 格式来存储版本控制项。如果您查看tbl_Content表格,您会看到一些记录,其中Content字段以明显的PA31签名开头

现在,TFS 都是托管代码。可能是 TFSmspatchX.dll用于解析这些记录。或者,可能会有 PA31 解码逻辑的托管(阅读:易于反转)实现......敬请关注。