The role of reverse engineering in understanding artifacts: when documentation is the enemy and the decompiler is a friend

In brief

What a forensic expert bases an artifact's interpretation on: someone else's results or one's own experiment. The main idea — a vendor's documentation diverges from the code for four different reasons, each shown through a Windows case: NTFS timestamps marked reserved, "scoped" shadow copies, the FAT specification, the prefetch files "OP-…pf". The method is "straight from the code": strings in the binaries, symbols, a decompiler, a black box. The talk is technical, with no product; there were no questions.

Key points

• An interpretation can be justified by someone else's results (an article, a book, documentation) or by one's own experiment; the occasion was an argument in Telegram chats a year ago. Vendors, Microsoft among them, "can deceive people" — in quotation marks, with no malice.
• Case 1 (NTFS): in the documentation for $STANDARD_INFORMATION and $FILE_NAME the timestamps are marked as reserved fields — the vendor hides its internal structures "from clumsy hands".
• Case 2: when encryption runs over the network through shares the shadow copies survive, but from Windows 8 on they hold zeros instead of documents and browser history, although the VSS documentation promises all the allocated space.
• The answer is the scoped shadow copy: from Windows 8 on, user files are excluded (a 16 KB block against a 4 KB cluster, which is why part of the data survives). Not documented, but Microsoft explained it to two customers in private replies.
• The mechanism: copy-on-write, then srtasks.exe walks the MFT and, by extension, excludes those files from the bitmap; on server versions of Windows there is no scoping.
• Case 3 (FAT): Microsoft's specification for the EFI System Partition was written from the code of the 95/98/Millennium branch; the NT/XP/10/11 driver does not follow it, and Linux drivers modify the logic of the error check.
• Case 4 (Prefetch): there are four hypotheses about the files "OP-…-….pf", three of them "made up"; the fourth comes from Process Hacker on GitHub, where the constant 5 from an old Windows SDK is named PrefetcherBootControl — hence the version about booting.
• The correct answer has long been in the Microsoft blog about ASP.NET: the file is generated by calls to OperationStart/OperationEnd ("Operation Based Prefetching"), but it is said only in passing.
• The route from the code: the strings of the name template in System32, filtering by symbols, the only occurrence — ntoskrnl.exe (PfSnBeginScenario, PfSnEndProcessTrace, PfSnOperationProcess from PfSnSetPrefetcherInformation with PrefetcherInformationClass = 5).
• A black box in Python: the files have nothing to do with the boot of the OS; the trace runs from OperationStart to OperationEnd, only one at a time within a process, the threshold is 32 I/O requests, page faults (see below).

Tools, artifacts, technologies

• Microsoft documentation, NTFS ($STANDARD_INFORMATION, $FILE_NAME) — criticized — the timestamps marked reserved, VSS not following the code, FAT following the Windows 95 code.
• VSS, scoped shadow copy, srtasks.exe, MFT, a hex editor, Chrome history — the mechanism and the demonstration — 16 KB against 4 KB.
• The FAT specification, EFI System Partition — criticized — Linux drivers modify the error check.
• Prefetch "OP-…-….pf", OperationStart/OperationEnd, Python — the artifact, the API and black-box testing.
• ntoskrnl.exe, symbols, System32, a decompiler — the route of the analysis — PfSnBeginScenario, PfSnEndProcessTrace, PfSnSetPrefetcherInformation, PfSnOperationProcess, PrefetcherInformationClass = 5; the decompiler is not named.
• Process Hacker (GitHub), the Microsoft blog about ASP.NET — the sources — the out-of-date constant PrefetcherBootControl; the correct answer "in passing", the post is not named.

Legal and organizational context

No laws, articles, agencies or methodologies were mentioned; the terminology — "forensic expert", "interpretation of some artifacts, traces … anomalies", "expert experiment". There is one organizational storyline: Microsoft explained the scoped shadow copy to at least two customers in private replies, and this never made it into the public documentation.

Questions from the audience

There were no questions. The remark "At least it was honest. He never once said the word business" (the attribution is not established), then the moderator: "I think you've broken my audience again."

The speaker's position

Blind trust in documentation is a problem, not a solution: the justification has to be one's own experiment, and the source of truth is the code. Skepticism toward every text by someone else, Microsoft blogs included. He names the limitations himself: the NTFS example is extreme, the exclusion from copies works "with an asterisk", three of the four hypotheses about prefetch are "made up". The tone is a lecture with self-irony, with no selling.

Quotes

• "…can deceive people. Deceive, in quotation marks, naturally."
• "The vendor is protecting its internal structures from so-called clumsy hands."
• "But let's try to take the hardest route, straight from the code."
• "the boot process doesn't come into it in any way at all"