13

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.

MrSynAckSter
  • 1,258
  • 1
  • 10
  • 24
  • 1
    regarding the cat files..

    http://msdn.microsoft.com/en-us/library/windows/hardware/ff537872%28v=vs.85%29.aspx and http://msdn.microsoft.com/en-us/library/aa741204%28v=vs.85%29.aspx

     – evlncrn8 Sep 12 '14 at 16:56
  • Windows security updates don't patch (edit) existing binaries on disk; they replace the full binaries on disk. – Jason Geffner Sep 12 '14 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. – MrSynAckSter Sep 12 '14 at 17:27
  • im not sure the sizes may help, microsoft are very fond of using lz compression in stuff like this – evlncrn8 Sep 12 '14 at 19:33
  • Good call. I'm sure there's a simple convention which file maps to which file. – MrSynAckSter Sep 12 '14 at 19:34
  • Yeah patching would make Microsoft into hackers lol, What if people have different versions of the file patching would require different addresses and maybe completely different code I would think they might of patched because of being lazy and trying to solve the bug ASAP (Jewish you know haha) instead of finding the programmers who made that file opening some archives, locating the files that need recompiling and waiting a day to compile before shipping the file (isn't what I thought microsoft did either). Still interesting how they replace files while they are in use? would require safemode – SSpoke Sep 22 '14 at 02:50
  • i wish there were some DLL cals to expand those files, ratehr than to rely upon external; command-line tool – Arioch Feb 17 '18 at 14:27
  • https://msfn.org/board/topic/171184-microsoft-ipd-intra-package-delta-compression-tool/?do=findComment&comment=1070292 - this forum discusses (among others) the DLLs hat maybe implement IPD unpack. Quote1: "Two years ago I had a hard time getting Expand too, so I pulled them from a laptop running Windows 7. The files you need are dpx.dll, expand.exe, expand.exe.mui and msdelta.dll." – Arioch Feb 17 '18 at 14:31
  • Quote2: My guess is that there (as usual/normal when MS is incolved) a misunderstanding or overlapping of names.

    IPD is a "nice new name" for a "generic" approach, "Delta Compression".

    There are two basic MS "engines" for it:

    http://msdn.microsoft.com/en-us/library/bb417345.aspx

    the good ol' PatchAPI (please read as "mspatchc.dll" for creation and "mspatcha.dll" for expansion) and the new MSDELTA (please read as "msdelta.dll").

     – Arioch Feb 17 '18 at 14:31

2 Answers2

6

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.

Ale
  • 165
  • 4
  • 1
    A bit more information about this "technology" - http://www.microsoft.com/en-us/download/details.aspx?id=1562 – Refael Ackermann Mar 15 '15 at 09:12
  • @RefaelAckermann link got 404ed – Arioch Feb 17 '18 at 14:15
  • https://web.archive.org/web/20150801180457/http://www.microsoft.com/en-us/download/details.aspx?id=1562 The title was "Using Binary Delta Compression (BDC) Technology to Update Windows Operating Systems" Seems like BDC was the precursor to RDC – Refael Ackermann Feb 18 '18 at 21:16
1

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.

Seva Alekseyev
  • 111
  • 4