Disinstallazione App con Clock Modificato
Informatica Forense · Analisi Dispositivi Mobili
Quando si analizza un dispositivo mobile nell’ambito di un’indagine, uno degli scenari più insidiosi è quello in cui l’orologio del dispositivo è stato deliberatamente alterato. I timestamp registrati nei log di sistema risultano falsi, e con essi le tracce di operazioni cruciali — come la disinstallazione di un’applicazione. Tuttavia, i dispositivi mobili conservano molteplici strati di dati indipendenti tra loro: incrociandoli, è possibile determinare con precisione quando un evento si è davvero verificato.
Il problema: un orologio non è l’unico cronometro
L’orologio di sistema di uno smartphone — quello che l’utente vede sullo schermo — è un’informazione software, modificabile. Un utente con accesso fisico al dispositivo può impostarlo su qualsiasi data e ora, anche retrodatandolo di giorni o settimane. Tutte le operazioni compiute durante quella sessione verranno registrate con la data falsa.
Il punto critico è che non tutti i meccanismi di registrazione del tempo dipendono dall’orologio di sistema. Alcuni contatori hardware, alcuni log di sistema e alcune fonti di dati indipendenti continuano a funzionare in modo autonomo, inconsapevoli della manipolazione. È in queste fonti che l’investigatore trova la verità.
«Cambiare la data sul display è facile. Cambiare tutti i contatori hardware, tutti i database, tutti i log di sistema in modo coerente è, nella pratica, impossibile.»
Le fonti di prova: cosa si analizza
L’analisi forense di un dispositivo con clock manipolato si articola nell’esame incrociato di diverse categorie di dati. Ciascuna ha caratteristiche proprie e offre un contributo specifico alla ricostruzione della linea temporale reale.
FONTE 01
MobileInstallation Log
Il sistema operativo registra ogni installazione, aggiornamento e disinstallazione di applicazioni in un log dedicato. Ogni riga riporta il nome dell’operazione, l’identificativo univoco dell’app (bundle ID) e il timestamp di sistema al momento dell’evento. In presenza di clock manipolato, questo timestamp è ovviamente falso — ma il log rimane fondamentale: certifica inequivocabilmente che l’operazione è avvenuta e in quale ordine rispetto ad altri eventi, anche se l’ora dichiarata è fasulla. È il punto di partenza dell’analisi.
FONTE 02
File Timesync e Contatore Hardware (MCT)
Il mach_continuous_time (MCT) è un contatore hardware che parte da zero ad ogni avvio del dispositivo e avanza in modo monotono, indipendentemente dall’orologio di sistema. Non può essere retrodatato modificando la data sul display. I file timesync — archivi binari di sistema — registrano periodicamente la corrispondenza tra l’orologio di sistema e il valore MCT. Questa corrispondenza permette all’investigatore di calcolare a che punto del contatore hardware si trovava il dispositivo al momento della disinstallazione, e da lì ricavare il tempo reale trascorso dall’avvio, indipendentemente dalla data mostrata.
FONTE 03
Battery Data Collector (BDC)
Il chip che gestisce la batteria tiene un registro indipendente a livello firmware — uno strato ancora più basso del sistema operativo. In questo registro viene annotato il momento in cui l’orologio del dispositivo si è “riallineato” con l’ora reale (ad esempio a seguito di una sincronizzazione NTP automatica). Questo dato è impossibile da alterare tramite software: opera a un livello hardware che non risponde ai comandi dell’utente. Fornisce un’ancora temporale assoluta e certificata, che permette di calibrare l’intera ricostruzione.
FONTE 04
Knowledge Database (knowledgeC.db)
Il sistema operativo mantiene un database comportamentale che traccia quali applicazioni erano aperte, per quanto tempo, quando il dispositivo era in uso. Ogni record ha un identificatore progressivo (Z_PK) che per costruzione deve sempre aumentare. Se nell’analisi si trovano record con Z_PK crescente ma timestamp decrescente — cioè un’azione “successiva” registrata con orario “precedente” — si ha la prova matematica della manipolazione: l’orologio si è mosso all’indietro mentre il dispositivo continuava a funzionare. La quantità di queste inversioni indica anche la sistematicità e l’entità della manomissione.
FONTE 05
Database Utilizzo Dati (DataUsage.sqlite)
Ogni traffico dati generato dalle applicazioni viene registrato in un database dedicato. In presenza di manipolazione temporale, anche questi record riportano timestamp falsi. Ma l’analisi comparata con le altre fonti permette di collocarli nella linea temporale reale. Significativo è anche il caso opposto: la totale assenza di record per un’applicazione che dovrebbe averne — come accade quando un’app viene disinstallata e i suoi dati vengono cancellati contestualmente.
FONTE 06
Report di Crash (.ips)
Quando un’applicazione viene terminata in modo anomalo dal sistema operativo, viene generato automaticamente un file di diagnostica. Questi file contengono informazioni preziose: il timestamp dell’evento, il fuso orario configurato sul dispositivo (dato che non cambia con la modifica della data), il tipo di terminazione e la durata della sessione in millisecondi. Confermano che l’applicazione era in esecuzione attiva e permettono di verificare la coerenza del fuso orario con gli altri dati.
La metodologia: l’analisi incrociata
Nessuna delle fonti descritte è sufficiente da sola. La robustezza della ricostruzione forense deriva dall’analisi incrociata: ciascuna fonte conferma o vincola le altre, costruendo una catena di prova che non dipende da alcun singolo dato potenzialmente compromesso.
- Si identifica l’evento nel log dichiarato. Il MobileInstallation log certifica che la disinstallazione è avvenuta e riporta il bundle ID dell’applicazione. Il timestamp dichiarato è il punto di partenza, anche se presumibilmente falso.
- Si misura la velocità di avanzamento del clock falso. Confrontando i file timesync si calcola con quale velocità artificiale stava avanzando l’orologio manipolato rispetto al contatore hardware MCT. Una velocità anomala — ad esempio 30 o 40 volte superiore al tempo reale — conferma la manipolazione e ne quantifica l’entità.
- Si ancora l’analisi al tempo reale tramite BDC. Il dato firmware del Battery Data Collector, non manipolabile, fornisce un punto di riferimento assoluto: a che ora il dispositivo era sincronizzato con l’ora reale. Da questo punto, sommando o sottraendo il tempo MCT misurato, si risale all’ora reale di qualsiasi evento.
- Si verifica la coerenza con le anomalie del database comportamentale. Il numero e la distribuzione delle inversioni Z_PK nel knowledge database confermano l’entità della manipolazione e circoscrivono i periodi in cui l’orologio era falso.
- Si produce una linea temporale reale certificata. L’incrocio di tutte le fonti permette di costruire una sequenza di eventi con orari reali, distinguendo nettamente i timestamp falsi da quelli verificabili tramite dati hardware indipendenti.
Un indicatore rivelatore della manipolazione è la presenza nei file timesync di record con data corrispondente all’origine dell’epoca Unix (1° gennaio 1970, ore 00:00 UTC): si tratta dell’impronta lasciata da un azzeramento forzato dell’orologio a un valore base, operazione che non ha alcuna giustificazione tecnica legittima in un dispositivo in uso normale.
La solidità della ricostruzione
La manipolazione dell’orologio di un dispositivo è un’operazione relativamente semplice, ma le sue tracce sono pervasive e difficili da occultare completamente. Il sistema operativo, i chip hardware, i database applicativi e i log di sistema lavorano in modo parzialmente indipendente: produrre una falsificazione coerente su tutti questi livelli richiederebbe un intervento tecnico di straordinaria complessità, ben oltre la portata di un utilizzo ordinario del dispositivo.
In ambito forense, la convergenza di fonti indipendenti verso la stessa ricostruzione — specialmente quando alcune di esse operano a livello hardware e non sono accessibili al software di sistema — costituisce una prova robusta e affidabile. La data dichiarata dal log può essere falsa; la fisica del contatore hardware non mente.