updates - new file on hd cannot be found in patch.cab

Question

Hello!

Summary:
The .CAB patch files apparently do not contain the same files that are stored to disk by this patch.

Setting:
For security reasons, we're analyzing the source of files that are being changed on a hd. In other words: if files are being changed, we have to find what the source of that new file is.

Occasionally we find files being replaced with apparently new versions, where we're not able to track the source.

Analysis:
Example: control.exe

On 08/11/2020 the file c:\windows\system32\control.exe has been changed on a Win 10 x64 2004 workstation. The file has a checksum that does not match any version of the file we have seen yet.

We check the checksum:

get-filehash -algorithm md5 C:\Windows\System32\control.exe
3011923664DA91ED45B0FA6AE852DD1A

We check the timestamp:

gci "C:\Windows\System32\control.exe"|Select-Object Name,LastWriteTimeUtc
control.exe 11.08.2020 18:50:04

This confirms the file has been replaced that day.

We're assuming that the file was updated by a Windows update. Therefore, we list the update history:

wmic qfe list

We can find that on this day, two updates were installed: KB4570334 and KB4566782. To verify that control.exe is from one of these updates, we now need to unpack the corresponding .cab files and (hopefully) find a file control.exe with the same hash.

So (on another Win10x64) we download those two patches and unpack them using the commands:

c:\Windows\System32\expand.exe Windows10.0-KB4566782-x64_PSFX.cab /f:* .\4566782\

and

c:\Windows\System32\expand.exe /r Windows10.0-KB4570334-x64.cab -f:* .\4570334

The result is that we do find versions of control.exe in the directory we've expanded the patch into, but none of them has the same hash as the file on the hd has!

What are the conclusions? Are we unpacking the wrong way? Are we unpacking on the wrong OS? Are there other sources where the file could be coming from? Is the file inside the patch but with a different name? Any idea?

Help will be appreciated!

Thanks in advance!!!

T.

BTW:
As much as I appreciate any help, let me please ask you to relate to the questions and don't give tips for how I could be verifying the file using different methods like e.g. with signtool. That doesn't help. We're using hash-based whitelisting. We have to find the origin of the file that is being put on our hd. If for example the Windows patching system does not provide the original file in the patch itself and maybe only assembles it at patch execution time, we need to know and figure out how this can be simulated to somehow make a patch produce the file, that eventually is stored on the system.

Answer 1

I found that PSFX updates include a manifest where the sha256 is included in base64.

That's exactly what I was asking for!

Answer 2

Hi
You could try:
fsutil hardlink list c:\Windows\System32\expand.exe
to see which is currently corresponding to which.

Also, you could compare the file size between the ones on your drive and the ones you downloaded (the same version) to see if there are any corrupted files.

If there is any problem try:
sfc\sannnow

I hope this information above can help you.

Answer 3

That method will no longer work, since we switched to the new packaging technology for updates called PSFX starting with 1809 version:
https://techcommunity.microsoft.com/t5/Windows-IT-Pro-Blog/What-s-next-for-Windows-10-and-Windows-Server-quality-updates/ba-p/229461
https://learn.microsoft.com/en-us/windows/deployment/update/psfxwhitepaper

To validate if the update in question shipped a version of the file you want to check, please refer to the file information csv linked in each article.

Thanks,
Andrei

Answer 4

That method will no longer work,

OMG, that changes everything.

new packaging technology for updates called PSFX starting with 1809 version

Would the "full update (also referred to as a latest cumulative update, or LCU)" contain all versions of the file that the PSFX update creates? So would I be able to unpack the LCU update, create a list of all hashes from its contents and then check if the hash of that newly updated version of control.exe is on that list? That way I'd just have to find a different update format (LCU) of the same update to be able to verify the file that's being replaced with the PSFX update? If so, will the LCU be released at the same time as the PSFX?

To validate if the update in question shipped a version of the file you want to check, please refer to the file information csv linked in each article.

I cannot see how the file information csv would help to validate the file. Just because a file is being listed as updated doesn't validate the version of the file that we find on the hd. If the the file information csv contained hashes, it would help, but it doesn't.

Answer 5

I just found out that the LCU updates are only released twice a year and not at the same time when a SSU update is being released. So LCU updates won't help us.

As I understand the PSFX whitepaper, the SSU update contains the diffs to all files which are updated. So if there was a tool (like expand?) which supports the new PSFX format to work with a local RTM baseline version of a file that's about to be updated, that tool should be able to create the new "control.exe", of which I then could calculate the hash and then compare that with the hash of the file in question on the HD of the opriginal computer, right?

Is there such tool or PowerShell module available?

Which code does actually perform the diff?