Windows 11 Shim Cache Analysys Errors

[pdutton-vc]

Shim cache analysis of data from a Windows 11 or Windows Server 2022 machine fails with an error message (see below). The machines in question are clean, new, updated virtual machines. The same analysis works fine on Windows 10, Windows Server 2016, and Windows Server 2019.

The same error is seen when chainsaw is run from on the machine being analyzed, on a different Windows machine, or when from a mac. The same behavior is seen with or without --tspair. The tests were performed using the sample patterns from https://github.com/WithSecureLabs/chainsaw/blob/master/analysis/shimcache_patterns.txt. Reproducible with latest 2.9.1-2 build from https://github.com/WithSecureLabs/chainsaw/releases/download/v2.9.1-2/chainsaw_all_platforms+rules.zip.

 ---

Example Run:

.\chainsaw\chainsaw_x86_64-pc-windows-msvc.exe --version
chainsaw 2.9.1

.\chainsaw\chainsaw_x86_64-pc-windows-msvc.exe analyse shimcache --regexfile .\shimcache_patterns.txt --amcache .\amcache.hve --tspair .\system.hve

██████╗██╗ ██╗ █████╗ ██╗███╗ ██╗███████╗ █████╗ ██╗ ██╗
██╔════╝██║ ██║██╔══██╗██║████╗ ██║██╔════╝██╔══██╗██║ ██║
██║ ███████║███████║██║██╔██╗ ██║███████╗███████║██║ █╗ ██║
██║ ██╔══██║██╔══██║██║██║╚██╗██║╚════██║██╔══██║██║███╗██║
╚██████╗██║ ██║██║ ██║██║██║ ╚████║███████║██║ ██║╚███╔███╔╝
╚═════╝╚═╝ ╚═╝╚═╝ ╚═╝╚═╝╚═╝ ╚═══╝╚══════╝╚═╝ ╚═╝ ╚══╝╚══╝
By WithSecure Countercept (@FranticTyping, @alexkornitzer)

[+] Regex file with 15 pattern(s) loaded from "\\?\C:\Users\Peter.Dutton\Temp\c\shimcache_patterns.txt"
[+] Windows 10 Creators shimcache hive file loaded from "\\?\C:\Users\Peter.Dutton\Temp\c\system.hve">
[+] Amcache hive file loaded from "\\?\C:\Users\Peter.Dutton\Temp\c\amcache.hve"
[x] Could not get InstallDate for program 0000041b5bbf1730351516f640f1af94ae2500000904

Attaching zipped up amcache and system files: hives.zip

[alexkornitzer]

Thanks for the initial triage and the sample files. I'll try and have a look at this later in the week.

[alexkornitzer]

Forgot to link the issue but this should be fixed in 21ab8c6, and I have bundled that up into release 2.9.2. Looks like Chainsaw was assuming that field would always be present when in fact it is not,