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~~ <- A catalog of some sort. Not sure how it's used by the update. 
package_1_for_kb2977629~31bf3856ad364e35~amd64~~ <- 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" />

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.

  • 1
  • Windows security updates don't patch (edit) existing binaries on disk; they replace the full binaries on disk. Commented Sep 12, 2014 at 17:24
  • That helps a lot. So is there a way that I am missing to see which 0-130 of the binaries maps to which IE binary file? I suppose I could match them up by sizes. Commented Sep 12, 2014 at 17:27
  • im not sure the sizes may help, microsoft are very fond of using lz compression in stuff like this
    – evlncrn8
    Commented Sep 12, 2014 at 19:33
  • Good call. I'm sure there's a simple convention which file maps to which file. Commented Sep 12, 2014 at 19:34

2 Answers 2


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>
  <Source type="PA30" name="35"> (...) </Source>
  <Basis file="214"/>

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.


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.