我正在分析Windows安全修补程序。从未检查过Windows安全修补程序，并且不了解其结构，所以我想自己弄清楚它。 />
_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中被修补。
#1 楼
我刚刚下载了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更新都不使用此增量修补程序，而是包含将要替换的每个文件的完整版本。
评论
有关此“技术”的更多信息-microsoft.com/en-us/download/details.aspx?id=1562
–Refael Ackermann
2015年3月15日在9:12
@RefaelAckermann链接获得404ed
– Arioch
18年2月17日在14:15
web.archive.org/web/20150801180457/http://www.microsoft.com/…标题为“使用二进制增量压缩（BDC）技术更新Windows操作系统”似乎BDC是RDC的先驱
–Refael Ackermann
18年2月18日在21:16
#2 楼
有一个API：https://docs.microsoft.com/zh-cn/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都是托管代码。 TFS可能会利用
mspatchX.dll来解决这些记录。或者，可能存在PA31解码逻辑的托管（读取：易于逆转）实现。敬请期待。
评论
关于猫文件。msdn.microsoft.com/zh-CN/library/windows/hardware/…和msdn.microsoft.com/en-us/library/aa741204%28v=vs.85%29.aspxWindows安全更新不会修补（编辑）磁盘上现有的二进制文件；它们将替换磁盘上的完整二进制文件。
这很有帮助。那么，有没有一种方法我看不到二进制文件中的0-130映射到哪个IE二进制文件？我想我可以按尺寸将它们匹配。
我不确定大小是否会有所帮助，Microsoft非常喜欢在此类内容中使用lz压缩
好决定。我确定有一个简单的约定，即哪个文件映射到哪个文件。