Dichiarazione di non responsabilità: non sono un avvocato, quindi il mio consiglio non è quello di aspettare.
Non esiste un metodo a prova di errore per mantenere la memoria in uno stato specifico. Eppure, c'è un modo di argomentare che un dump della memoria può essere riprodotto e / o sostenere che è possibile dire quali parti della memoria possono essere cambiate.
Strategia proposta
Nel momento in cui si sta facendo un dump di memoria completo, sono in esecuzione diversi processi e un kernel li sta programmando. E, inoltre, è possibile scambiare le pagine di memoria tra la memoria fisica e un'area del disco (scambio).
Quindi la prima cosa di cui hai bisogno è ottenere il dump della memoria e lo swap in un singolo punto nel tempo. In secondo luogo è necessario ottenere lo stato dei registri della CPU (tornerò su di esso in un momento).
Sto pensando in termini di una macchina Linux perché è il sistema operativo con cui ho più familiarità. Per quel SO puoi scaricare /dev/mem e dd le aree di swap, o usare qualcosa come LiME. Per altri sistemi operativi ci sono diverse alternative .
Ora, per essere in grado di sostenere che il dump della memoria può essere riprodotto, è necessario trovare e analizzare la tabella di paging globale (PT). Quella tabella risiede nella memoria e collega l'accesso alla memoria da parte del kernel sulle parti reali della memoria. La posizione del tavolo dovrebbe essere in un registro (non ricordare quale scusa, ma questo è il motivo per cui sono necessari i registri, tutti non solo RAX, RBX, RCX, RDX, R5, R6, RSP, ecc.), Quindi la CPU responsabile per il paging può accedervi.
È possibile sostenere che, se è possibile creare un indice del PT, è possibile stabilire quale parte della memoria può essere aggiornata. Come?
- Il PT tiene anche le pagine nella memoria fisica e nello scambio, quindi il tuo indice copre l'intera memoria.
- DLP (parte del PT) ti dirà quali pagine sono di proprietà del kernel e che sono di proprietà dei processi utente.
Ora, in base a ciò che fa la macchina, puoi dire quali pagine di memoria potrebbero essere state interessate e quali no. Ad esempio, il collegamento di una pen drive (supponendo che la macchina non esegua la regola intelligente udev o simile) dovrebbe solo cambiare le pagine del kernel (beh, quasi, i sistemi virtuali, ad esempio /proc verrebbero anche aggiornati).
Controllo della realtà pessimistica
Sfortunatamente, la maggior parte dei SO oggi eseguirà i demoni che periodicamente esploreranno la parte visibile del kernel degli utenti e agiranno su di essa. Probabilmente le pagine di spazio degli utenti (DLP 3) sono considerevoli. Avrai sicuramente bisogno del controllo fisico della macchina e dell'analisi di ciò che accade (in termini di spazio dell'utente) quando fai qualcosa alla macchina.
Note ottimistiche
Sul lato positivo, quando il dump della memoria è suddiviso in pagine, è possibile riprodurre lo stato della macchina (in buona parte). Ad esempio, puoi avviare una macchina virtuale, avviare un debugger del kernel e sovrascrivere tutte le pagine di memoria una alla volta.
Come ciò potrebbe essere visto da un tribunale, può ancora dipendere da punti forensi più classici. Ad esempio, come si dimostra che il dump della memoria in questione è della macchina che si sostiene che sia. Ma questo è qualcosa che può essere risolto con procedure che documentano esattamente come è stato eseguito il forense sulla macchina.
Riferimenti / correlati