Die definitive forensische Referenz zu Amcache.hve: jeder Schlüssel, jeder Wert, jeder Zeitstempel

Amcache.hve ist die ergiebigste Einzelquelle für Ausführungs­artefakte auf einem modernen Windows-Host. Sie ist zugleich eine der am häufigsten missverstandenen. Dieser Beitrag ist die Referenz, die ich mir gewünscht hätte, als ich begann, Hives von kompromittierten Maschinen zu ziehen: jeder Unterschlüssel, jeder Wert, jeder Zeitstempel, wie das Schema in jedem Windows-Release aussah und — nicht minder wichtig — welche Behauptungen über Amcache nicht wirklich zutreffen.

Wenn Sie nach Dokumentation auf Tool-Ebene und nicht zum Artefakt selbst suchen, lesen Sie die Vollständige Anleitung zu AmcacheParser und die Referenz der Ausgabespalten.


1. Was Amcache.hve tatsächlich ist#

Amcache.hve ist eine Registry-Hive, die vom Subsystem Application Compatibility / Program Compatibility Assistant von Windows geschrieben wird. Sie ist ihrem Zweck nach kein Sicherheits­artefakt. Microsoft nutzt sie, um Kompatibilitäts­telemetrie in das Customer Experience Improvement Program und in den Compatibility Appraiser einzuspeisen — beide entscheiden mit, welche installierte Software bei einem Upgrade brechen könnte.

Der Grund, warum sie für die DFIR relevant ist, ist ein Seiteneffekt dieses Zwecks: Um zu beurteilen, ob ein Programm sicher aktualisiert werden kann, muss Windows Programme, Treiber, Geräte und Dateien auf der Maschine enumerieren. Diese Enumeration wird — mit Hashes, Pfaden, Herstellern, Größen und Zeitstempeln — in Amcache.hve abgelegt.

Pfad#

C:\Windows\AppCompat\Programs\Amcache.hve

Daneben liegt ein .LOG1/.LOG2-Transaktions­log-Paar. Beide Logs müssen vor dem Parsen in die Hive eingespielt werden, wenn die Hive nicht sauber ausgehängt wurde. Die meisten modernen Tools (AmcacheParser, der Browser-Parser, RegRipper) erledigen das für Sie, aber löschen Sie die .LOG-Dateien niemals vor der Triage — sie können die Schreibvorgänge enthalten, in denen Ihre Beweise stecken.

Wer sie schreibt#

  • compatTelRunner.exe — gesteuert durch die geplante Aufgabe \Microsoft\Windows\Application Experience\Microsoft Compatibility Appraiser.
  • Außerdem von aeinv.dll (Application Experience Inventory) und vom breiteren CompatTelemetry-Stack berührt.

Standardmäßig läuft der Appraiser täglich und bei Anmeldung, doch die Taktung variiert je nach Windows-Build und Gruppenrichtlinie. Gehen Sie nicht davon aus, dass Amcache-Daten in Echtzeit entstehen. Eine fünf Minuten vor dem Herunterfahren ausgeführte Binärdatei taucht möglicherweise gar nicht auf; eine eine Stunde vorher ausgeführte erscheint möglicherweise mit einem KeyLastWriteTimestamp, der den Appraiser-Lauf widerspiegelt — nicht die Ausführung.

Sicherung#

Die Hive ist zur Laufzeit vom Betriebssystem geöffnet. Um eine Live-Kopie zu erfassen, benötigen Sie Raw-NTFS-Zugriff:

  • KAPE mit dem Target Amcache
  • Velociraptor Windows.Registry.Amcache
  • FTK Imager → File System → C:\Windows\AppCompat\Programs
  • RawCopy64.exe / CopyRawFiles.ps1
  • Aus einem E01/AFF4/VHDX-Image lesen Sie die Datei einfach normal

Ein Shadow-Copy-Snapshot (vssadmin list shadows) liefert Ihnen oft eine frühere Hive, die Beweise enthält, die in der aktuellen bereits verdrängt wurden.


2. Schema-Entwicklung: Windows 7 bis Windows 11#

Das Amcache-Schema hat sich erheblich verändert. Wenn Sie in einen Fall gehen und auf einer Windows-7-Hive Schlüssel aus Windows 10 1607 erwarten, werden Sie das Artefakt für leer halten. Das ist es nicht — es sieht nur anders aus.

Windows-Version Amcache vorhanden? Dominantes Schema
Windows 7 RTM / SP1 (vor KB2952664) Nein (nutzt RecentFileCache.bcf) n/a
Windows 7 SP1 + KB2952664 (2015) Ja Root\File\{VolumeGUID}\{FileRef} + Root\Programs
Windows 8 / 8.1 Ja Root\File + Root\Programs
Windows 10 1507 – 1511 Ja Root\File + Root\Programs (Übergang)
Windows 10 1607 (Anniversary) Ja Root\InventoryApplicationFile und die breitere Inventory*-Familie eingeführt
Windows 10 1703 – 1809 Ja Inventory-Schema stabil; kleinere Feldergänzungen
Windows 10 1903 – 22H2 Ja Inventory-Schema, LongPathHash, zusätzliche Treiberfelder
Windows 11 21H2 / 22H2 / 23H2 / 24H2 Ja Inventory-Schema, erweiterte Geräte­einträge, mehr PnP-Details

Der Sprung mit 1607 ist der größte. Pre-1607-Hives haben eine Handvoll Schlüssel mit vielleicht einem Dutzend Werten je Schlüssel. Post-1607-Hives enthalten zehn oder mehr Inventory*-Top-Level-Container mit reichhaltigen, verschachtelten Daten.

Altschema (Win7 → Win10 1511)#

Root\
  File\
    {Volume GUID, e.g. "{abcd1234-...}"}\
      {NTFS File Reference, e.g. "0000abcd00000001"}\
        ... values ...
  Programs\
    {ProgramId}\
      ... values ...
  Orphan\
  Generic\

Die interessanten Werte unter jedem File\{Vol}\{FileRef}-Unterschlüssel waren nummeriert (0, 1, 2, ... 101, ...). Die Zuordnung ist in Willi Ballenthins ursprünglicher Recherche von 2013/2015 gut dokumentiert und im Mandiant-Blog reproduziert. Die wichtigsten Felder:

Wert Bedeutung
0 Produktname
1 Firmenname
2 PE FileVersion
3 Sprachcode (LCID)
5 BinaryFileVersion
6 BinaryProductVersion
c FileDescription
f PE LinkDate (FILETIME)
11 Letzte Änderung (FILETIME)
12 Erstellt (FILETIME)
15 Vollständiger Pfad
17 Letzte Änderung (alternativer FILETIME-Slot)
100 ProgramId
101 FileId (SHA-1 mit 0000-Präfix)

Modernes Schema (Win10 1607+)#

Root\
  InventoryApplication\
    {ProgramId}\          ← installed-program record
  InventoryApplicationFile\
    {Name|FileId}\        ← per-file record
  InventoryApplicationShortcut\
  InventoryApplicationFramework\
  InventoryApplicationDriver\
  InventoryDeviceContainer\
  InventoryDevicePnp\
  InventoryDeviceInterface\
  InventoryDriverBinary\
  InventoryDriverPackage\
  InventoryMiscellaneousUUPInfo\
  Programs\               ← legacy, often still present
  File\                   ← legacy, often empty on modern OS
  Orphan\
  Generic\

Jeder moderne Unterschlüssel trägt benannte Werte (nicht numerische), was sie deutlich leichter lesbar macht. Der Rest dieses Beitrags ist die Feld-für-Feld-Referenz zu diesen modernen Werten.


3. Root\InventoryApplicationFile — das Arbeitstier#

Ein Unterschlüssel pro Datei, die Windows inventarisiert hat. Hier tauchen typischerweise Angreifer-Binaries, side-geladene DLLs und Ad-hoc-Tooling auf.

Wert Typ Bedeutung Forensische Anmerkung
Name string Dateiname z. B. mimikatz.exe
LowerCaseLongPath string Vollständiger Pfad (in Kleinbuchstaben) Der einzelne nützlichste Pivot.
LongPathHash string Hash, den Windows intern zur Pfad-Deduplikation verwendet Nützlich, um Einträge über Neustarts hinweg zu verknüpfen.
FileId string "0000" + SHA-1(erste 31 MiB) Für VT-/TI-Lookups das 0000-Präfix entfernen.
Publisher string X.509 CN oder PE-Firmen-Ressource Leer = unsigniert.
Version string PE FileVersion
BinFileVersion string PE VS_FIXEDFILEINFO.dwFileVersion
BinProductVersion string PE VS_FIXEDFILEINFO.dwProductVersion
ProductName string PE-Ressource ProductName
ProductVersion string PE-Ressource ProductVersion
LinkDate string oder FILETIME PE TimeDateStamp Vom Angreifer kontrolliert. Zum Gruppieren, nicht zum Datieren.
BinaryType string pe32, pe64, pe32_arm64, pe32_managed, ... Beim Threat Hunting auf native PE filtern.
Size dword/qword Dateigröße in Byte
Language dword LCID der PE-Ressource
IsPeFile dword (0/1) Ist dies eine PE? Hier fast immer 1.
IsOsComponent dword (0/1) Mit Windows ausgelieferte Binärdatei Auf 0 filtern, um Rauschen zu reduzieren.
ProgramId string 44-stelliger Identitäts-Hash der übergeordneten Anwendung Leer/Null = „nicht zugeordnete" Datei.
Usn qword Sequenznummer des USN-Journals zum Inventarisierungs­zeitpunkt
AppxPackageFullName string Vollständiger Name des UWP-Pakets Für Store-Apps gefüllt.
AppxPackageRelativeId string Paketrelative ID des UWP-Pakets

Zwei FileId-Formate#

In freier Wildbahn koexistieren zwei Formate:

  • 0000 + 40 Hex-Zeichen — SHA-1 der ersten 31 MiB der Datei. Das ist das dominante Format ab Windows 8.
  • 0001 + 32 Hex-Zeichen — MD5; selten und überwiegend historisch.

Wenn Sie zu Threat-Intel-Feeds pivotieren, prüfen Sie immer das Präfix und entfernen Sie es. Den unbearbeiteten FileId an VirusTotal zu schicken, liefert null Treffer und verbrennt eine relevante Menge Triage-Zeit.

„Unassociated" vs. „associated"#

Eine Datei mit nicht-leerem ProgramId, der auf einen existierenden InventoryApplication-Unterschlüssel zeigt, ist „associated" — Windows hat sie mit einem installierten Produkt verknüpft. Eine Datei mit leerem oder null-ProgramId ist „unassociated" und konnte keiner registrierten Anwendung zugeordnet werden.

Angreifer-Tooling ist fast immer unassociated. Das Filtern von InventoryApplicationFile auf unassociated-Einträge mit einem LowerCaseLongPath unter \Users\, \AppData\, \ProgramData\, \Temp\ oder \PerfLogs\ ist der günstigste und produktivste Triage-Filter in einem typischen Commodity-Malware-Fall.


4. Root\InventoryApplication — Einträge installierter Programme#

Ein Unterschlüssel pro registrierter Anwendung (MSI-Installationen, Einträge unter „Programme hinzufügen/entfernen", Store-Apps usw.).

Wert Bedeutung
Name Anzeigename
Version Anwendungsversion
Publisher Publisher-Zeichenkette
RootDirPath Installationsverzeichnis
Source MSI, AddRemoveProgram, WindowsUpdate, ...
InstallDate Installationsdatum (string oder FILETIME)
Type Application, OptionalFeature, ...
Language LCID
MsiPackageCode MSI-Paket-GUID
MsiProductCode MSI-Produkt-GUID
RegistryKeyPath Uninstall-Schlüssel (SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\...)
UninstallString Kommandozeile zur Deinstallation
OSVersionAtInstallTime Windows-Version zum Installations­zeitpunkt
InstallDateArpLastModified Datum der letzten Änderung in „Programme hinzufügen/entfernen"
PackageFullName UWP Full Name (falls zutreffend)

InstallDateArpLastModified wird zu wenig genutzt. Weichen InstallDate und der ARP-Last-Modified-Wert eines Eintrags um Monate voneinander ab, sehen Sie möglicherweise eine ersetzte Binärdatei (denken Sie an DLL-Side-Loading über einen legitimen Installer, den die IT zurückgelassen hat).


5. Root\InventoryDriverBinary — Kernelmodus-Artefakte#

Die mit Abstand beste Quelle für BYOVD-Hunts (bring-your-own-vulnerable-driver).

Wert Bedeutung
DriverName Dateiname des Treibers
DriverInBox True, wenn mit Windows ausgeliefert
DriverIsKernelMode True für Ring-0-Treiber
DriverSigned Behauptetes Signed-Flag (nicht blind vertrauen — Zertifikat separat prüfen)
DriverType Bit-Flags: legacy / PnP / Service / Dateisystem / ...
DriverVersion Versions-Zeichenkette des Treibers
DriverCompany Firmen-Zeichenkette
Product Produktname
ProductVersion Produktversion
WdfVersion Windows Driver Framework Version, falls anwendbar
Service Name des dahinterliegenden Dienstes
Inf .inf-Dateiname
DriverPackageStrongName Strong Name
DriverTimeStamp PE-Link-Datum des Treibers
ImageSize Image-Größe in Byte
Hash SHA-1 des Treibers

Für BYOVD: Aufsteigend nach DriverTimeStamp sortieren, DriverSigned auf true filtern, dann den KeyLastWriteTimestamp jedes Eintrags betrachten. Alte, signierte, kürzlich inventarisierte Treiber sind die Menge mit dem höchsten Signal-Rausch-Verhältnis. Querverweise mit loldrivers.io für bekannte missbrauchte Namen und Hashes.


6. Root\InventoryDeviceContainer und Root\InventoryDevicePnp#

InventoryDeviceContainer ist die für Benutzer sichtbare Geräteliste: „Brother HL-L2350DW", „Logitech BRIO", „Samsung Galaxy S22". Ein Unterschlüssel pro logischem Gerät. Bemerkenswerte Werte: Categories, DiscoveryMethod, FriendlyName, Manufacturer, ModelName, ModelNumber, IsConnected, IsPaired, Icon.

InventoryDevicePnp ist die technische Enumeration: ein Unterschlüssel pro Geräte-Schnittstelle, mit BusReportedDescription, DeviceClass, DeviceId, InstanceId, Manufacturer, Service, DriverName.

Verknüpfen Sie beide über InstanceId, um sowohl den Marketingnamen als auch die PnP-Hardware-IDs zu erhalten. Das ist oft die günstigste Antwort auf die Frage „War Gerät X jemals an diesem Host angeschlossen?" ohne sich durch Setup-Logs zu wühlen.


7. Root\InventoryApplicationShortcut und weitere kleinere Schlüssel#

  • InventoryApplicationShortcut — ein Unterschlüssel pro .lnk, das Windows kennt. Trägt ShortcutPath, TargetPath und den übergeordneten ProgramId. Nützlich für „was war an $DATUM in der Taskleiste angeheftet?"
  • InventoryApplicationFramework — Einträge zu .NET-/Runtime-Frameworks.
  • InventoryApplicationDriver — Brücke zwischen einer installierten Anwendung und dem mit ihr ausgelieferten Treiber.
  • InventoryDriverPackage — Einträge auf INF-Paket-Ebene.
  • InventoryMiscellaneousUUPInfo — Staging-Informationen der Unified Update Platform; selten relevant.

8. Zeitstempel: der Teil, den alle falsch verstehen#

Amcache stellt mindestens fünf verschiedene Arten von „wann" bereit, die jeweils Unterschiedliches bedeuten. Sie falsch zu lesen ist der häufigste Fehler in Amcache-Befunden.

Zeitstempel Quelle Was er tatsächlich aussagt
KeyLastWriteTimestamp Letzter Schreibvorgang des Registry-Unterschlüssels Das, was „wann Amcache dies beobachtet hat" am nächsten kommt. Ihr maßgeblicher Pivot.
LinkDate PE-Header TimeDateStamp Wann Compiler/Linker die Binärdatei stempelten. Vom Angreifer kontrolliert, häufig gefälscht.
InstallDate (InventoryApplication) Was auch immer der Installer geschrieben hat Best Effort; spiegelt das Installer-Verhalten wider, nicht zwingend die Grundwahrheit.
InstallDateArpLastModified Letzte Änderung des Schlüssels in „Programme hinzufügen/entfernen" Nützlich, um Ersetzungen einer bestehenden Anwendung zu erkennen.
DriverTimeStamp PE-Link-Datum eines Treibers Gleiche Vorbehalte wie bei LinkDate.

Der Stolperstein KeyLastWriteTimestamp#

KeyLastWriteTimestamp ist der Zeitpunkt, zu dem der Registry-Schlüssel zuletzt geschrieben wurde, was dem Zeitpunkt entspricht, zu dem der Appraiser den Eintrag zuletzt berührt hat. Wenn Windows die Datei vergangenen Dienstag wegen einer Metadatenänderung neu bewertet hat, wird der Zeitstempel Dienstag anzeigen — nicht das Datum, an dem die Datei zuerst beobachtet wurde.

Das bedeutet:

  • Sie dürfen nicht annehmen, KeyLastWriteTimestamp sei „first seen".
  • Sie dürfen annehmen, dass es „zuletzt vom Appraiser berührt" ist.
  • Für „first seen" korrelieren Sie mit Shadow Copies früherer Amcache-Hives oder mit dem im Usn referenzierten USN-Journal-Eintrag.

Der Mythos „Amcache = Ausführung"#

In vielen älteren Blog-Beiträgen werden Sie lesen, dass „Amcache Ausführung beweist". Das lässt sich nicht sicher behaupten. Maxim Suhanovs Recherche (2018, „Windows ShellBag and Amcache forensics: just stop relying on single-source signals") zeigte, dass der Compatibility Appraiser Dateien inventarisiert, die nicht ausgeführt wurden — zum Beispiel ausführbare Dateien in Verzeichnissen, die der Appraiser gescannt hat.

Was Amcache verlässlich beweist:

  • Die Datei existierte zum Inventarisierungs­zeitpunkt auf dem System.
  • Ihr Hash, Pfad, Publisher und ihre PE-Metadaten zu diesem Zeitpunkt.

Was Amcache aus sich heraus nicht beweist:

  • Dass die Datei ausgeführt wurde.
  • Wann die Datei erstmals auf der Festplatte abgelegt wurde.
  • Dass der Benutzer (und nicht das System) verantwortlich ist.

Für Ausführungsnachweise korrelieren Sie mit Prefetch, Sysmon EventID 1, Security 4688, ShimCache, BAM/DAM, UserAssist oder SRUM. Amcache ist ein fantastisches Triage-Artefakt und ein starkes unterstützendes Artefakt, aber ein schwacher alleiniger Ausführungszeuge.


9. ProgramId und FileId: wie die Identifikatoren funktionieren#

ProgramId (44 Zeichen)#

Ein Hash, abgeleitet aus Name, Version, Publisher und Sprache der Anwendung. Der genaue Algorithmus wurde von Microsoft nicht formal dokumentiert, doch die praktischen Konsequenzen sind:

  • Das gleiche Produkt auf zwei Maschinen installiert hat (üblicherweise) denselben ProgramId.
  • Ein Point-Release-Upgrade ändert ihn (üblicherweise).
  • Er ist kein Content-Hash — zwei unterschiedliche Binaries desselben Produkts teilen sich einen ProgramId.

Verwenden Sie ProgramId zum Pivotieren, niemals zur Identifikation einer Datei.

FileId (44 Zeichen mit 0000-Präfix)#

Dies ist ein Content-Hash:

FileId = "0000" + SHA1(first 31 MiB of file content)

Für Dateien kleiner als 31 MiB ist FileId[4:] ein vollständiger SHA-1 der Datei und stimmt mit dem von jedem anderen Tool gemeldeten SHA-1 überein. Für Dateien größer als 31 MiB ist FileId[4:] ein SHA-1 der ersten 31 MiB — er stimmt nicht mit einem SHA-1 der vollständigen Datei überein.

Das ist wichtig: Ein 200-MB-gepackter Installer hat einen FileId, der nicht mit dem SHA-1 der vollständigen Datei übereinstimmt, und ein VT-Lookup nach dem vollen Hash kann fehlschlagen, während ein Lookup nach dem Amcache-Wert trifft (und umgekehrt). Im Zweifel beides suchen.


10. Anti-Forensik und Manipulation#

Amcache kann manipuliert werden. Die Hive liegt auf der Festplatte und lässt sich offline verändern. Bekannte Muster:

  • Selektives Löschen von Schlüsseln durch einen Akteur mit SYSTEM-Rechten zwischen Appraiser-Läufen.
  • Schreibvorgänge im Stil von Set-ItemProperty, um irreführende LinkDate- oder Publisher-Werte für eine Binärdatei zu platzieren, die der Angreifer harmlos wirken lassen will.
  • Hive-Ersetzung durch eine von einer sauberen Maschine gesammelten Hive.
  • Deaktivieren der geplanten Appraiser-Aufgabe (sichtbar im Verlauf der Aufgabenplanung und in Microsoft-Windows-Application-Experience-Ereignisprotokollen).

Defensive Korroborationen:

  • Die .LOG1-/.LOG2-Dateien enthalten oft den Zustand vor der Manipulation.
  • Volume Shadow Copies von Amcache.hve aus früheren Tagen liefern Ihnen ein Vorher/Nachher.
  • Das USN-Journal protokolliert Schreibvorgänge auf die Hive-Datei selbst.
  • Das Ereignisprotokoll Microsoft-Windows-Application-Experience/Program-Telemetry zeichnet Appraiser-Läufe auf.

Wenn eine Hive zu aufgeräumt wirkt — spärliche InventoryApplicationFile-Einträge, keine unassociated-Zeilen, perfekte Publisher-Abdeckung — sollten Sie misstrauisch werden. Ein normaler Windows-Desktop sammelt im Laufe seines Lebens Tausende von Dateieinträgen an.


11. Artefakt-übergreifende Korroboration#

Amcache ist am stärksten, wenn sie mit ihren Nachbarn verknüpft wird. Die Joins, die sich am häufigsten auszahlen:

Frage Amcache verknüpfen mit
Wurde diese Binärdatei tatsächlich ausgeführt? Prefetch-.pf-Dateien, Sysmon 1, BAM/DAM, ShimCache, UserAssist
Wann wurde sie auf der Festplatte abgelegt? $MFT-Zeitstempel aus $STANDARD_INFORMATION und $FILE_NAME, USN-Journal
Woher kam sie? InstallSource unter Programs, Zone.Identifier ADS, Browserverlauf, Logs des E-Mail-Gateways
Hat sie nach Hause telefoniert? DNS-Logs, Sysmon 3, Firewall-Logs
Welcher Benutzer hat sie ausgeführt? Security 4688, BAM/DAM (pro SID), UserAssist (pro NTUSER)
Früherer Zustand dieser Hive? Shadow Copies, frühere Backups, KAPE-Triage-Sammlungen

Ein Befund, der aus Amcache plus Prefetch plus einem Security 4688 gespeist wird, ist berichtsfähig. Ein Befund allein aus Amcache ist ein Hinweis.


12. Tools, die Amcache lesen#

Kein einzelnes Tool ist für jede Situation das beste. Ein funktionierender DFIR-Betrieb hält mehrere bereit.

Tool Stärken Wann Sie es einsetzen sollten
AmcacheParser (Eric Zimmerman) Kanonisch, gut getestet, KAPE-integriert, CSV-Ausgabe Massenverarbeitung, KAPE-Pipelines, gerichtsfeste Ausgabe
RegRipper (amcache.pl-Plugin) Textberichte, hervorragend für narrative Timelines Wenn Sie eine menschenlesbare Zusammenfassung wollen
Dieser Browser-Parser Keine Installation, läuft vollständig clientseitig per WebAssembly, kein Upload Schnelle Triage, Schulungs-Demos, fremde Laptops, auf denen Sie keine Software installieren dürfen
Velociraptor Windows.Registry.Amcache Flotten-weite Sammlung und Auswertung EDR-artige Sweeps über Hunderte von Hosts
Magnet AXIOM / EnCase GUI + integriertes Case Management Häuser mit kommerzieller Tool-Landschaft
Python python-registry / Rust nt-hive Programmatischer Zugriff Eigene Pipelines, Forschung

Wenn Sie Installationen ganz vermeiden möchten, legen Sie eine Hive auf der Startseite ab und Sie sehen in wenigen Sekunden jeden Schlüssel und jeden Wert. Nichts verlässt den Browser.


13. Weiterführende Literatur (die Quellen, die das Feld tatsächlich voranbringen)#

Das meiste, was über Amcache „bekannt" ist, stammt von einer kleinen Anzahl von Forscherinnen und Forschern. Wenn Sie nur Zeit für vier Dinge haben, lesen Sie diese:

  • Willi Ballenthin (Mandiant) — das ursprüngliche Amcache-Feldmapping für das Altschema. Bleibt die kanonische Referenz für Pre-1607-Hives.
  • Andrea Fortuna — mehrere Beiträge, die das Inventory*-Schema in seiner Entwicklung durch Windows 10 hindurch durchgehen.
  • Maxim Suhanov — Arbeiten zu Registry-Internas und die gründlichste Behandlung dessen, was Amcache beweist und was nicht. Seine Arbeit hat den Mythos „Amcache = Ausführung" zu Fall gebracht.
  • Eric Zimmermans Tool-Notes — lesen Sie die Release Notes zu AmcacheParser; dort werden neue Schemafelder erstmals öffentlich dokumentiert.

Lesen Sie danach Ihre eigenen Hives. Das Schema in freier Wildbahn enthält Felder, die kein einzelner Blog-Beitrag abdeckt, und der einzige verlässliche Weg, herauszufinden, was Ihr Windows-Build aufzeichnet, ist hinzusehen.


Siehe auch#

Sie haben eine Hive, die Sie sich jetzt sofort ansehen möchten? Legen Sie sie auf der Parser-Startseite ab — die Auswertung erfolgt in Ihrem Browser, lokal, in wenigen Sekunden.

Verwandte Beiträge

Zurück zu allen Beiträgen