Acquisizione Forense - Forenser Srl

Android: come raccogliere bug report, Debug Logs e Log anti-intrusioni

forenser on 19 Agosto 2026

Android: come raccogliere bug report, Debug Logs e log anti-intrusione — ***La raccolta tempestiva di bug report, Debug Logs e log anti-intrusione permette di conservare informazioni utili per ricostruire anomalie e possibili eventi di sicurezza su Android***

Durante un’analisi, un incidente o una semplice attività di assistenza tecnica può essere necessario raccogliere informazioni diagnostiche da uno smartphone Android.

A differenza di iPhone e iPad, Android non dispone di un singolo archivio perfettamente equivalente al sysdiagnose, il pacchetto diagnostico unico dei dispositivi Apple. Le fonti principali sono tre:

il bug report, che raccoglie in un archivio lo stato diagnostico del dispositivo;
i Debug Logs, ottenuti tramite logcat, utili per osservare ciò che accade durante un problema;
il Log anti-intrusioni, introdotto con Android 16 per conservare nel tempo eventi rilevanti per la sicurezza.

Sono strumenti complementari e non intercambiabili.

Generare un bug report dal dispositivo

Il bug report è un archivio .zip che raccoglie log di sistema, crash, informazioni sui processi e altri dati tecnici prodotti dai componenti interni del sistema. Le dimensioni possono variare da alcune decine a diverse centinaia di MB, in base al dispositivo e ai dati disponibili.

Può essere utile per analizzare crash, blocchi, errori ANR (le app che si bloccano senza rispondere), consumi energetici anomali, problemi di rete e altri comportamenti inattesi.

Per generarlo direttamente dal dispositivo è necessario attivare le Opzioni sviluppatore, un menu nascosto di funzioni avanzate.

Nella maggior parte dei dispositivi:

aprite Impostazioni > Informazioni sul telefono;
individuate la voce Numero build;
toccatela sette volte;
inserite il PIN, se richiesto.

Successivamente:

aprite Impostazioni > Sistema > Opzioni sviluppatore;
selezionate Crea report bug, Segnalazione bug o una voce equivalente;
se vengono proposte due varianti, il Report interattivo è adatto alla maggior parte dei casi e permette di aggiungere dettagli e screenshot; il Report completo include tutte le sezioni diagnostiche, ma non permette queste integrazioni: sceglietelo quando chi riceverà il file lo richiede espressamente;
avviate la raccolta.

La raccolta richiede qualche minuto: al termine comparirà una notifica attraverso la quale sarà possibile salvare o condividere l’archivio.

Su Pixel e su alcuni altri dispositivi, sempre nelle Opzioni sviluppatore, è disponibile anche la Scorciatoia segnalazione bug: aggiunge la voce al menu di accensione e consente di avviare la raccolta nel momento esatto in cui il problema si manifesta, senza dover navigare nei menu. Sui Pixel recenti il menu si apre premendo insieme Accensione e Volume Su, come indicato nella guida Pixel.

Il nome del file sarà generalmente simile a:

bugreport-BUILD_ID-DATE.zip

dove al posto di BUILD_ID e DATE troverete la versione del software e la data di creazione.

Il percorso e il nome delle opzioni possono variare in base al produttore. La procedura generale è documentata da Android Developers.

Generare il bug report da computer con ADB

Il bug report può essere generato anche da computer, su macOS, Linux o Windows, tramite ADB (Android Debug Bridge): è lo strumento a riga di comando con cui il computer dialoga con un dispositivo Android, ed è incluso negli SDK Platform Tools ufficiali di Google. Non serve installare nulla: scaricate l’archivio, estraetelo e aprite il Terminale nella cartella appena estratta. Su Windows il modo più rapido è digitare cmd nella barra degli indirizzi di quella cartella e premere Invio; su Mac si fa clic destro sulla cartella e si sceglie “Nuovo terminale nella cartella”.

Negli esempi successivi viene utilizzato adb. Su macOS e Linux, se state eseguendo il programma direttamente dalla cartella estratta, sostituitelo con ./adb, per esempio ./adb devices.

Sul dispositivo:

abilitate Debug USB nelle Opzioni sviluppatore: è l’interruttore che consente al computer di comunicare con lo smartphone;
collegate lo smartphone al computer via USB;
sbloccatelo;
confermate la richiesta di autorizzazione che compare sullo schermo: l’impronta RSA mostrata identifica il computer che state autorizzando, quindi accettatela solo se siete voi ad aver appena collegato il dispositivo al vostro computer.

Dal computer verificate che il dispositivo sia visibile:

adb devices

Se tutto è a posto comparirà il numero di serie dello smartphone seguito dalla parola device. Se invece compare unauthorized, sbloccate lo smartphone e confermate l’autorizzazione.

A questo punto avviate la generazione:

adb bugreport

Non serve altro: ADB chiede al dispositivo di generare il bug report, attende che sia pronto e salva l’archivio .zip nella cartella in cui vi trovate. L’operazione può richiedere alcuni minuti.

Se sono collegati più dispositivi, indicate quale usare con il numero di serie mostrato da adb devices:

adb -s NUMERO_SERIALE bugreport

Conservate il file .zip originale senza estrarlo, modificarlo o ricomprimerlo.

Raccogliere i Debug Logs con logcat

I Debug Logs sono i messaggi prodotti in tempo reale dal sistema operativo e dalle applicazioni. Android li conserva in aree di memoria di dimensione limitata, i buffer: quando si riempiono, i dati più vecchi vengono sovrascritti dai nuovi.

Per questo motivo devono essere raccolti il prima possibile.

Si presentano due situazioni tipiche.

Il problema è riproducibile: avviate la registrazione con:

adb logcat -b all -v threadtime > debug-logs.txt

Lasciate il comando in esecuzione, riproducete il problema e interrompete la raccolta premendo Ctrl+C.

Il problema è appena avvenuto e non potete (o non volete) riprodurlo: salvate ciò che il dispositivo ha ancora in memoria; in questo caso il comando termina da solo:

adb logcat -b all -v threadtime -d > debug-logs.txt

In entrambi i casi il file debug-logs.txt viene creato nella cartella in cui vi trovate. I due comandi sono identici a parte l’ultima opzione: chiedono di leggere tutti i buffer disponibili (-b all) con data, ora, priorità, PID e TID (-v threadtime), e la -d del secondo dice a logcat di salvare quanto già presente e fermarsi, invece di restare in ascolto.

Su Windows eseguite questi comandi dal Prompt dei comandi (cmd.exe): Windows PowerShell 5.1 salva il file in una codifica (UTF-16LE) che alcuni strumenti di analisi non leggono correttamente, mentre PowerShell 7 usa UTF-8 e non ha questo problema.

I Debug Logs servono a osservare un errore mentre avviene; il bug report fotografa invece lo stato complessivo del dispositivo. La sintassi completa di logcat è descritta nella documentazione ufficiale Android.

Il nuovo Log anti-intrusioni di Android 16

Con Android 16 Google ha introdotto Intrusion Logging, chiamato nell’interfaccia italiana Log anti-intrusioni.

La funzione fa parte della modalità Protezione avanzata ed è stata sviluppata anche con il contributo dell’Amnesty International Security Lab.

A differenza del bug report e dei Debug Logs, conserva nel tempo eventi selezionati appositamente per le analisi di sicurezza, tra cui:

avvio dei processi delle applicazioni;
installazioni, aggiornamenti e disinstallazioni;
interrogazioni DNS (la traduzione dei nomi dei siti in indirizzi) e connessioni verso indirizzi IP;
attività e comandi ADB;
trasferimenti di file tramite USB;
modifiche ai certificati;
blocchi e sblocchi del dispositivo.

I log vengono crittografati sul dispositivo e archiviati nell’Account Google scelto dall’utente. Google dichiara di non poterli leggere. Vengono conservati per 12 mesi e non possono essere eliminati manualmente prima della scadenza.

La funzione deve essere attivata prima dell’evento da analizzare: non permette di recuperare retroattivamente informazioni relative al periodo in cui era disabilitata.

Attivare ed esportare il Log anti-intrusioni

L’attivazione viene proposta durante la configurazione della modalità Protezione avanzata; è comunque possibile intervenire in un secondo momento:

aprite Impostazioni > Sicurezza e privacy;
selezionate Protezione avanzata;
attivate Protezione del dispositivo;
abilitate Log anti-intrusioni durante la configurazione oppure aprite successivamente la relativa voce;
scegliete l’Account Google nel quale conservare i log crittografati;
riavviate il dispositivo, se richiesto.

I nomi e l’ordine delle voci possono variare in base al produttore e alla versione di Android.

Quando è necessario esportare i dati:

aprite Impostazioni > Sicurezza e privacy > Protezione avanzata > Log anti-intrusioni;
selezionate Log accessi;
individuate il dispositivo interessato;
toccate Scarica e decripta;
confermate con PIN o autenticazione biometrica.

I file saranno disponibili nel gestore file, normalmente nella cartella:

Download/Intrusion Logging/

La disponibilità della funzione dipende dal dispositivo e dagli aggiornamenti installati. Le procedure ufficiali e le implicazioni per la privacy sono riportate nella guida di Google e nell’approfondimento di Amnesty International.

Alcuni limiti da conoscere

La recente analisi pubblicata da iVerify conferma il valore del Log anti-intrusioni, ma evidenzia anche alcuni limiti:

non registra ogni attività del dispositivo;
il caricamento non è in tempo reale: le ultime 12-24 ore potrebbero mancare;
la cronologia delle reti Wi-Fi non viene registrata;
le installazioni non indicano la provenienza dell’app (Play Store, installazione manuale da file APK o ADB);
delle sessioni ADB interattive registra l’apertura, non i comandi digitati;
gli spegnimenti non lasciano traccia: l’orario va dedotto dai vuoti di attività.

Come condividere i file

Tutte e tre le raccolte possono contenere dati personali: app installate, identificatori del dispositivo, attività di sistema e connessioni di rete. Condividetele solo con il destinatario previsto, tramite un canale cifrato oppure un link o un archivio protetti da password, comunicata separatamente.

Accompagnate i file con data e ora esatta dell’anomalia (con fuso orario), modello del dispositivo, versione di Android, una breve descrizione dell’accaduto e l’orario della raccolta.

Come accortezza generale, bug report e Debug Logs vanno raccolti il prima possibile dopo il problema; il Log anti-intrusioni, invece, va abilitato preventivamente.

DRIFT Linux: prime osservazioni sul nuovo tool forense

forenser on 24 Aprile 2026

Estratti dell’interfaccia desktop di DRIFT

È stata recentemente rilasciata DRIFT Linux, una nuova distribuzione italiana per la Digital Forensics, ideata da Massimiliano Dal Cero e basata su Ubuntu 24.04 LTS (Noble). Il progetto si propone come ambiente operativo pensato per le attività forensi sul campo.

Allo stato attuale, DRIFT è concepita principalmente come sistema live avviabile da chiavetta USB, mentre eventuali soluzioni installabili sono previste per versioni successive. Dalla pagina di download emerge inoltre una struttura già piuttosto chiara del progetto: sono disponibili le varianti DRIFT Fast 2026.01 e DRIFT Fast XS 2026.01, mentre Fast Micro e una versione installabile denominata Paddock risultano annunciate come prossime. Questo lascia intendere una distribuzione pensata non come immagine unica, ma come famiglia di strumenti destinata a differenziarsi in base ai diversi scenari operativi.

Secondo quanto riportato sul sito ufficiale, DRIFT Linux si presenta come un ambiente operativo orientato all’uso sul campo, con particolare attenzione alla preservazione delle evidenze digitali, alla gestione controllata dei dispositivi collegati e alla disponibilità immediata di strumenti utili nelle fasi di acquisizione e prima analisi. Abbiamo avuto modo di testarla nei primi giorni successivi al rilascio: in questo articolo ne riportiamo alcune caratteristiche tecniche, soffermandoci sulle principali fasi operative dei moduli esaminati.

Cos’è una distribuzione Linux forense e perché si usa

Una distribuzione Linux forense è un sistema operativo progettato per svolgere attività di acquisizione e analisi cercando di preservare, per quanto possibile, l’integrità dei dati originali. Spesso viene eseguita in modalità live, ad esempio da chiavetta USB, così da ridurre l’interazione con il sistema oggetto di esame e operare in un ambiente controllato.

A differenza di un sistema operativo generico, una distro forense integra di norma strumenti e accorgimenti pensati per limitare le alterazioni indesiderate: accesso ai supporti in sola lettura, gestione controllata delle connessioni, produzione di log e raccolta tracciabile delle evidenze. Questo approccio riduce il rischio di contaminazione accidentale dei dati e contribuisce a rafforzare l’integrità, la tracciabilità e la verificabilità tecnica delle evidenze digitali.

Le caratteristiche di DRIFT Linux che abbiamo testato

Secure Boot Ready

Un aspetto emerso sin da subito nel corso dei test riguarda la compatibilità con il sistema di protezione Microsoft Secure Boot. DRIFT Linux si presenta infatti come una distribuzione avviabile anche su sistemi con Secure Boot abilitato, senza richiedere la disattivazione dell’opzione nel BIOS/UEFI. Si tratta di una semplificazione operativa concreta, soprattutto quando si interviene su hardware moderno o in contesti aziendali nei quali modificare le impostazioni di sicurezza potrebbe non essere possibile, consentito o comunque opportuno.

Kernel Write Blocker nativo

Uno degli aspetti più interessanti di DRIFT Linux è il kernel write blocker nativo visibile all’interno dell’applicativo DRIFT Mount Manager. La protezione dell’integrità dei dati è infatti gestita a livello kernel: i dispositivi collegati vengono mantenuti in sola lettura per impostazione predefinita fin dalle prime fasi del boot, riducendo al minimo il rischio di alterazioni accidentali dei supporti originali. Qualora sia necessario abilitarne la scrittura, l’operazione richiede comunque un’azione esplicita da parte dell’operatore, accompagnata da un avviso ben visibile come da immagine sottostante:

DRIFT Mount Manager — Kernel Write Blocker ATTIVO con dialog di sblocco

Connection Panel

Il Connection Panel è un’interfaccia grafica dedicata che consente di visualizzare e gestire in modo diretto lo stato dei servizi di rete. Si tratta di una scelta coerente con quanto indicato dal progetto, che presenta la connettività come una componente da attivare consapevolmente, così da ridurre il rischio di interferenze o alterazioni del contesto tecnico durante le attività di acquisizione e analisi iniziale. Dal punto di vista operativo, questa impostazione appare particolarmente utile perché sposta il controllo verso l’operatore: la rete non viene trattata come una funzione sempre attiva in background, ma come un elemento da governare in modo esplicito in base alle esigenze del caso concreto.

Estratto del Connection Panel

Drift Forensics Web Acquire

Tra i moduli più interessanti della distribuzione figura Web Acquire. Automatizza l’intera catena di acquisizione forense di una pagina web: snapshot della configurazione di rete (IP, routing, DNS), traceroute verso host multipli, cattura PCAP del traffico, esportazione SSL Key Log dal browser per la decifratura HTTPS, registrazione schermo sincronizzata in formato MP4, generazione del valore di hash SHA-256 di tutti i file prodotti e marcatura temporale blockchain tramite OpenTimestamps.

Le schermate dei test mostrano un’interfaccia dedicata, denominata Drift Forensics Web Acquire, nella quale compaiono campi strutturati per nome del caso, numero del caso, analista, pagina iniziale e destinazione. L’impressione è quella di un workflow pensato non soltanto per “salvare” una pagina web, ma per documentare in modo più ampio il contesto tecnico dell’attività svolta.

Estratto del pannello Drift Forensics Web Acquire

Al termine dell’attività viene generato automaticamente un report HTML completo, di cui vengono mostrati due estratti immagine:

Estratti del report HTML prodotto a fine acquisizione web

Guymager

Tra gli strumenti inclusi in DRIFT Linux figura Guymager 0.8.13, impiegato per l’acquisizione forense di supporti fisici.

Per procedere, è necessario aprire il software “DRIFT Mount Manager”, individuare il disco di destinazione e disattivarne il blocco in scrittura tramite l’icona del lucchetto posta accanto al nome del supporto. Successivamente, il dispositivo dovrà essere impostato in modalità “RW”, così da renderlo idoneo a ricevere i file prodotti durante l’acquisizione forense.

Di seguito si riportano alcune schermate relative al test effettuato:

Dopo aver selezionato “Procedi”, a schermo vengono indicati il percorso del dispositivo sbloccato in RW (/dev/sdc1) e la destinazione (/media/drift/RIPRISTINO):

Premendo nuovamente su “Procedi”, viene mostrato il percorso di mount del disco, ovvero in “/media/drift/RIPRISTINO”:

Estratti di DRIFT Mount Manager

Prima di avviare l’acquisizione, Guymager consente di compilare i metadati del caso — numero del caso, numero dell’evidenza, nome dell’esaminatore e note — che verranno associati all’immagine forense generata. Il software supporta i formati EWF/Exx e dd, con calcolo dell’hash in MD5, SHA-1 e SHA-256 e verifica finale dell’acquisizione, utile a confermare la corrispondenza bit-per-bit tra il supporto sorgente e la copia prodotta.

Nel campo Image directory, visibile nell’immagine sottostante, è stato indicato il percorso del supporto esterno precedentemente montato in modalità RW tramite DRIFT Mount Manager — in questo caso “/media/drift/RIPRISTINO” — con l’aggiunta della cartella di destinazione “Copia_F2026_TEST” prevista per il salvataggio dell’immagine forense.

Estratto dell’interfaccia di Guymager che mostra il completamento della copia (Finished)

Nel complesso, DRIFT Linux appare come un progetto che prova a coniugare funzioni dedicate e strumenti già noti nelle prassi di acquisizione forense, con un’impostazione orientata al controllo dell’ambiente operativo e alla preservazione delle evidenze. Pur trattandosi di una prima release, le funzionalità osservate nei test consentono già di coglierne alcuni aspetti di interesse.

Per ulteriori informazioni sul progetto, sulle funzionalità disponibili e sulla documentazione tecnica, è possibile consultare il sito ufficiale di DRIFT Linux: driftlinux.org

Exterro, dietro front per FTK Imager

forenser on 12 Novembre 2024

Nell’articolo pubblicato il 28 ottobre scorso sul nostro sito, avevamo segnalato un importante aggiornamento dell’applicazione FTK Imager, uno degli strumenti più utilizzati del panorama informatico forense.

La novità determinante introdotta con la nuova versione 4.7.3.61 (“Exterro_FTK_Imager_4.7.3.61.exe” con hash MD5 “fb98287965d4e3b9a7e9de50a781dca4”, SHA1 0ff6f6ee8fb640a3de1c5195e764c67df7e6e996, SHA256 f4f56139a6c667dba6f6c09b7dd7c8bc72cbbe6ec8de0a82bb5a49676b6b5ee0) dell’applicazione era la possibilità di gestire la crittografia BitLocker che nel tool si mostrava pienamente supportata nei processi di mounting dell’immagine cifrata (senza necessità di montare il volume logico), anche nel caso di presenza di “clear key” e generazione di copia forense già decifrata.

Nei giorni immediatamente successivi la società ha rimosso il link dalla pagina di download, generando non poco stupore (e anche un pizzico di preoccupazione visto che nel changelog erano presenti fix di vulnerabilità) tra gli utenti:

Successivamente, il 3 novembre, Exterro ha rilasciato su X, dal suo profilo, un comunicato dove spiegava che il rilascio della versione che gestisce BitLocker non è stato sostanzialmente intenzionale, non precisando se la successiva versione dello strumento che sarebbe stata rilasciata il 5 novembre avrebbe incluso ancora tale funzionalità:

Tra il 5 e il 6 novembre Exterro ha annunciato sul suo portale, nella sezione relativa al download di FTK Imager (sbagliando nella sua precisazione ad indicare il numero di versione sostituita, riportando “4.7.3.21” anziché “4.7.3.61”) la pubblicazione della versione 4.7.3.81 (hash MD5 “3815b9c2a6aa8898ecbe55353aaf4b79”, SHA1: “5ae3e1ea937f56367409deebb4b71147a6b883f4”, SHA256 “443843a3923a55d479d6ebb339dfbec12b5c1aabed196bf0541669abbe9b1c51”) che non include la funzionalità di gestione della crittografia:

comunicato-exterro-rilascio-non-intenzionale

Mentre questo “passo indietro” ha oggettivamente scosso la comunità di tecnici che ogni giorno utilizzano lo strumento e si sentivano arricchiti dall’introduzione di una feature così vantaggiosa, ci si chiede se mai si vedrà una nuova pubblicazione dello strumento con inclusa questa funzionalità. È sempre più facile, infatti, imbattersi in dischi che sono crittografati con Bitlocker e possedere un tool che supporti la decifratura/mounting delle immagini cifrate è strategico sia nella fase di produzione di copia forense che di processing e analisi dei dati.

Nel frattempo, si tornerà all’utilizzo di soluzioni alternative come ad esempio Arsenal Image Mounter che già nella versione gratuita include la possibilità di montare immagini forensi di volumi crittografati con BitLocker che utilizzano la “clear key” e agevola il processo di generazione di copia decifrata.

Non è chiaro quale sia il motivo esatto del “dietro front” di Exterro, anche se è facile immaginare che la società possa voler includere tale funzione in una versione più esclusiva (magari a pagamento) dell’applicazione o all’interno della suite di analisi FTK (Forensic Toolkit). Resta anche l’ipotesi che la società voglia mantenere le feature della versione 4.7.3.61 in una “internal build” che non verrà rilasciata al pubblico.

FTK Imager: novità dell’aggiornamento in download gratuito

forenser on 28 Ottobre 2024

È recente la pubblicazione della nuova versione del tool della società Exterro “FTK Imager”, il “coltellino svizzero” dell’informatica forense che ogni consulente informatico forense ha nel proprio repertorio e utilizza quasi quotidianamente per fare copie forensi, aprire e lavorare su immagini forensi, acquisire la RAM dei PC, estrarre file di sistema, virtualizzare o fare analisi forensi su SSD, HD e supporti di memoria.

Il download della nuova versione è disponibile al link del sito di Exterro https://www.exterro.com/ftk-product-downloads/ftk-imager-4-7-3-61 e introduce funzionalità attese e interessanti. Ricordiamo che il download di FTK Imager e gratuito e può essere effettuato allo stesso link presente nella sezione “Product Downloads”:

Le novità dell’aggiornamento

Il changelog fornito dalla società è piuttosto scarno ed indica come unica novità il miglioramento nel processo di “mounting” delle immagini di Windows 11. Il resto dei cambiamenti interni riguarderebbe la risoluzione di bug:

Installando e avviando lo strumento si possono apprezzare novità molto più interessanti; infatti, è ora possibile montare e navigare immagini forensi di drive che sono crittografati con BitLocker e si possono, con questo aggiornamento, creare ed esportare copie forensi di dischi cifrati in formato non cifrato.

Tale mancanza, in questi anni, è stata sopperita dall’utilizzo di strumenti esterni, come Arsenal Image Mounter, strumento in grado di montare immagini forensi di dischi cifrati con BitLocker, riconoscere la presenza di “clear key”, generare immagini decifrate, etc.

Riconoscimento, mounting e acquisizione di volumi crittografati

Vediamo ora come si concretizzano le novità più importanti, avviando direttamente lo strumento.

Adesso, selezionando “Add evidence Item” o “Create disk Image” e indicando un volume fisico cifrato con BitLocker, abbiamo accesso ad una nuova schermata, che propone l’inserimento della chiave a 48 bit o della password (nel caso di drive esterni):

creazione-immagine-forense-disco-cifrato

Cliccando poi su “OK” si ha accesso al volume fisico come se fosse decifrato.

Come accennato, attraverso questa nuova funzionalità è possibile produrre copia forense del disco crittografato, direttamente in forma decifrata. In questo caso lo strumento avvisa l’utente del fatto che il valore di hash della copia forense del drive in forma decifrata differirà dal valore di hash che si otterrebbe acquisendolo nella sua forma crittografata:

Premendo su “Cancel” anziché su “OK” si procederebbe con l’acquisizione forense del disco nella sua forma cifrata:

creazione-immagine-forense-disco-cifrato-cancel

creazione-immagine-forense-disco-cifrato-sì

In questo caso sarà comunque possibile montare, sempre con FTK Imager, la copia così ottenuta e creare a posteriori la relativa immagine decifrata. Un’ulteriore possibilità sarà montare il drive decifrato sia fisicamente che logicamente, per mezzo dell’opzione “Image Mounting…”:

La versione “portable” standalone

FTK Imager viene distribuito come versione installabile, ma può agevolemente essere convertito in versione portabile o standalone avviando l’installer e copiando su di una pendrive la cartella dove il programma viene installato.

Le librerie DLL necessarie per la sua esecuzione saranno contenute all’interno della cartella “C:\Program Files\AccessData” e sono sufficienti per far girare il tool FTK Imager in modalità portable anche su altri PC senza installarlo, ma avviandolo direttamente da una pendrive o da una risorsa di rete. A questo punto, si otterrà una versione FTK Imager Portable, da utilizzare sul campo, così da evitare di sporcare il sistema con una nuova installazione.

Conclusioni

La nuova funzionalità di mounting di drive e immagini forensi di dischi cifrati con BitLocker nonché la possibilità di creare immagini di drive in formato già decifrato, accontenta i molti utenti che quotidianamente utilizzano FTK Imager per le attività di acquisizione e analisi forense ed altre attività a supporto della perizia informatica. In passato, queste lacune potevano essere colmate mediante l’ausilio di altri strumenti gratuiti, ed ora anche FTK Imager può vantare nel suo già ricco armamentario queste funzionalità, senz’altro molto utili per qualunque Digital Forensics Expert.