WAC 2.0.3

WAC 2.0.3 — bugfix release

Fixed: the fingerprints of a data file cited by an artefact were those of its working copy

With --binary, an artefact that cites a file — the files a Prefetch says its program loaded — gives that file's MD5, SHA-1 and SHA-256. For a document or a data file of the exhibit store, WAC read them in the file's working copy. The conversion changes some of those copies:

• a registry hive is replayed with its transaction logs. Its fingerprints were those of a content that never was on the examined machine.
• an ESE database (WebCache, SRUM) is replayed during the conversion, and was read before or after that change depending on the order of the artefacts. Two conversions of one collection then gave two different SHA-256.

A document or data file of the exhibit store now gets the fingerprints the manifest recorded when it was taken: those of the file as collected, the same from one conversion to the next. Executables are unaffected: the conversion never changes them.

The exhibit store is not affected. Converting a collection again with 2.0.3 (--convert=<folder>) gives the right fingerprints.

How it is checked

A new check of the test cycle confronts every file cited by a Prefetch with the manifest's SHA-256. On a Windows 8.1 test cycle run before the fix (on the development version 3.0, which also replays the search index), it fails: 3 cited files out of 970 had another SHA-256, and not the same one from one conversion to the next. After the fix, all of them match.

Files

Same as 2.0.2: WAC.exe (Windows 10 and 11, x64, standalone), wac.yml, verify-exhibits.ps1|.sh, verifier-consigne.ps1|.sh, raw_hive_test.exe, SHA256SUMS.