TL;DR. Usa l'AppCompatCacheParser di Eric Zimmerman per il casework. Massima copertura OS, output CSV, ben collaudato. Usa Velociraptor per il triage live a livello di flotta. Usa il Mandiant Shim Cache Parser quando ti serve una semplice referenza in Python. Usa questo strumento quando vuoi zero installazione e zero upload. Cross-valida le discrepanze. Il formato è abbastanza pignolo da far sì che due parser vedano occasionalmente le cose in modo diverso.
Ci sono quattro strumenti aperti che contano per il parsing dello ShimCache. Ognuno ha la sua nicchia. L'errore che vedo fare agli analisti junior è scegliere uno e trattarlo come la risposta per ogni caso. La risposta giusta dipende dal fatto che tu stia scalando, scriptando o fissando un singolo hive alle 2 di notte.
I quattro parser che contano
| Strumento | Linguaggio | Distribuzione | Migliore per |
|---|---|---|---|
| Mandiant Shim Cache Parser | Python | Sorgente su GitHub | Leggere il formato, scriptare analisi personalizzate |
| Eric Zimmerman AppCompatCacheParser | C# / .NET | Binario singolo | Casework. Più affidabile per i report di produzione. |
Velociraptor Windows.Registry.AppCompatCache | VQL | Server Velociraptor | Raccolta live su scala flotta |
| Shimcache Parser (questo strumento) | Rust → WebAssembly | Solo browser, nessuna installazione | Triage rapido senza setup, i dati non lasciano la macchina |
Quando ricorrere a quale
AppCompatCacheParser di Eric Zimmerman
Lo standard de facto per l'analisi offline. Copre ogni variante di Windows da XP a Windows 11, rigioca automaticamente i log di transazione SYSTEM e produce CSV che entra pulito in Timeline Explorer. Se il tuo output va in un report finale, è ciò che i revisori si aspettano che tu abbia usato.
AppCompatCacheParser.exe -f SYSTEM --csv .
Avvertenze: binario solo Windows, richiede .NET Framework o Core, non pensato per triage ad hoc dal browser.
Velociraptor
Quando devi tirare lo ShimCache da decine o migliaia di host, Velociraptor vince. L'artefatto legge la cache in memoria direttamente dagli endpoint in esecuzione, che è la stessa vista che l'OS avrebbe scaricato allo shutdown ma senza aspettare lo shutdown. Vedi estrarre lo ShimCache da un dump di memoria per il razionale.
Avvertenze: richiede infrastruttura Velociraptor. Eccessivo per analisi una tantum.
Mandiant Shim Cache Parser
Il proof-of-concept Python originale. Meno raffinato dello strumento di EZ ma utile quando vuoi leggere il codice per capire esattamente come viene decodificato il formato, o per scriptare analisi personalizzate attorno. L'output è testo semplice; integralo con altre pipeline Python.
python ShimCacheParser.py -t -h /path/to/SYSTEM
Avvertenze: richiede Python 2.x o un fork di compatibilità. L'output CSV / JSON è meno raffinato di quello di EZ.
Questo Shimcache Parser
Esiste per due casi che gli altri non coprono bene:
- Triage senza installazione. Apri la pagina, trascina un hive, vedi le voci. Utile quando sei su un host senza tooling DFIR installato, o stai analizzando su un laptop o macchina di prestito.
- Analisi sensibile alla fiducia. L'hive viene parsato interamente nel tuo browser via WebAssembly. Il file non lascia mai la pagina, non raggiunge mai un server, non compare in nessun log. Conta quando l'hive appartiene a un cliente o a un caso in cui l'upload non è accettabile.
Compromessi: nessuna interfaccia a riga di comando, nessun hook di automazione. Usalo per triage guidato dall'umano, non per pipeline. Per le pipeline, lo strumento di EZ è la risposta giusta.
Cross-validazione quando i parser non concordano
Il formato binario non perdona. La referenza del layout Windows 10/11 mostra perché un singolo errore di conteggio offset può cascare per il resto del blob. In pratica i parser di solito concordano, ma gli hive del mondo reale a volte trasportano dati leggermente fuori spec, e i parser non concordano su:
- Rilevamento del bitness su hive Win7. L'header non dice in modo non ambiguo x86 vs x64, quindi i parser scelgono euristicamente. Una coppia di strumenti che producono percorsi diversi sullo stesso hive è il tuo indizio.
- Normalizzazione dei percorsi. Escape dei backslash, maiuscole/minuscole della lettera di drive, marker
\??\iniziali. Parser diversi normalizzano in modi diversi. - Voci vuote o placeholder. Alcuni strumenti emettono righe vuote per slot inutilizzati; altri le saltano.
Quando conta, lancia due parser e fai diff. Le combinazioni a cui ricorro:
- EZ + questo strumento per un cross-check rapido.
- EZ + Mandiant per una sanity check "Python vs C#".
- EZ + Velociraptor per un confronto "live in memoria vs hive su disco".
Insidie comuni
- Non dimenticare i log di transazione.
SYSTEM.LOG1eSYSTEM.LOG2portano scritture in sospeso; senza di essi stai leggendo un hive obsoleto. Lo strumento di EZ li rigioca automaticamente. Alcuni altri no. Vedi acquisire un hive SYSTEM. - Non confrontare direttamente ShimCache su disco e in memoria. Sono fonti di verità diverse. Su disco hai solo lo stato dell'ultimo shutdown pulito. In memoria hai la sessione corrente. Trattali come complementari.
- Non assumere l'esecuzione. Nessun parser può risolvere questo. La cache registra esame, non esecuzione.
Letture aggiuntive
- AppCompatCacheParser di Eric Zimmerman. parser di riferimento.
- Shim Cache Parser di Mandiant. implementazione Python originale.
- Velociraptor
Windows.Registry.AppCompatCache. artefatto VQL. - Windows 10/11 AppCompatCache deep dive su Ø Security. spiega perché i parser a volte non concordano.