How do the internals of a Windows update security patch work?

Question

Wasn't sure where to ask this on stack exchange, so vote to close if you think it is in the wrong place.

I am analyzing a Windows security patch. Having never examined a windows security patch, and being unaware of their structure I am trying to figure it out for myself.

In the patch I have (this week's I.E patch) I have these files:

_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. 

My question is: Is there comprehensive documentation for how all of these parts work together, if not, how do all of these parts work together?

I imagine, what has to happen is that some mechanism has to tell the update where in the binary to patch, and then one of those files numbered 0-130 is the code to overwrite. I'm sure there is a standard format so that I can interpret these files.

For instance:

<?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>

Would seem to suggest that we are about to patch assembly 1d07faac344e137a0d122aad24eb4e6e which might be named "Microsoft-Windows-IE-MemoryAnalyzer. That's just a guess! I don't see any reference in here to the code to patch. I imagine one way of doing that is to just read through these manifests in order, and apply the patches in the order the manifests are read. First manifest gets binary file 0 and so on. That seems janky, and I bet I'm wrong about that.

Based on the size of the files themselves, I would imagine that they aren't rewriting the whole module, although they might be compressed. Without any reference I haven't a clue as to their structure. I imagine there would be snippets of code, and offsets for where to rewrite the DLLs/Exes in question. Of course I ran strings on the binaries, but didn't find anything.

What I would most like to figure out through this is which particular functions are being patched in IE.

Answer 1

I just downloaded the KB2977629 patch file (IE11-Windows6.1-KB2977629-x64.MSU). It looks like the information about which file corresponds to what is inside the _manifest_.cix.xml file (there is a single, very long, line inside). You have for example:

<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 seems to be the name of one of the files in the archive. These files begin with 4 bytes that read "PA30", so it looks like a specific format. I've found some reference to this patching system in a patent application: http://www.google.com/patents/US20070260653.

Actually, most Windows updates do not use this delta patching system, but rather contain the full versions of each file they are going to replace.

Answer 2

There's an API: https://docs.microsoft.com/en-us/previous-versions/bb417345(v=msdn.10)

The mspatcha.dll and mspatchc.dll, which implement it, are under SYSTEM32 as late as of Windows 10.

Couldn't find the docs for the format, though.

---

Here's a fun fact: Microsoft Azure DevOps Server (formerly known as Team Foundation Server/TFS) uses the MSPatch format to store version controlled items. If you look at the tbl_Content table, you'll see some records where the Content field starts with the telling PA31 signature.

Now, TFS is all managed code. It could be that TFS taps into mspatchX.dll for resolving those records. Or alternatively, there might be a managed (read: easy to reverse) implementation of the PA31 decoding logic... Stay tuned.

---

UPD: TFS makes a P/Invoke call into msdelta.dll. Here is a managed API wrapper, reverse engineered out of TFS' code: https://gist.github.com/sevaa/a49457319946379b60e885f6b5a9f5ca The debug symbols for msdelta.dll are out on the MS Symbol server. References to the source files can be seen at https://windows-internals.com/source/files.html under base/compress/msdelta.