Il post seguente è stato tradotto per gentile concessione di Mobile Device Forensics
Sono affascinato da SQLite. Ma prima che possiate dire “Mike hai proprio bisogno di uscire di più e farti una vita! ” considerate questo: i due sistemi operativi per smartphone più popolari attualmente sono IOS e Android e utilizzano database SQLite per memorizzare informazioni importanti, come contatti, SMS e i record delle chiamate. Si tratta di parecchi utenti: sia vittime che carnefici. Vi siete mai chiesti come SQLite strutturi i suoi record? Comprenderne l’architettura è fondamentale per avvalorare l’output degli strumenti di forensic e sapere dove cercare le prove, incluse quelle preziose informazioni eliminate.
Le immagini del database SQLite iniziano sempre con una ben nota signature a 16 byte che, in ASCII, è rappresentata dal “formato SQLite3″ seguito da un byte null. L’header dell’immagine del database è di 100 byte. Una discussione completa sull’header dell’immagine del database si può trovare sulla pagina ufficiale di SQLite .
Tra le altre cose un’immagine del database, serializzata e ben formata, avrà uno schema di database o un layout di tabella. Conoscere lo schema delle tabelle è la parte chiave della conoscenza, in quanto fornirà la guida verso l’header del record e dei conseguenti contenuti dei record.
Come esempio useremo un record del database degli SMS di un iPhone di prima generazione con iOS versione 3.13. Di seguito è riportato una schermata dello schema della tabella dei messaggi, che usa il mio editor Mac SQLite preferito: Base .
Schema
Preso atto dello schema della tabella dei messaggi all’interno del database sms, diamo un’occhiata a un record con un editor esadecimale.
Record SQLite
Il record è strutturato come mostra il grafico sottostante.
Struttura record SQLite
Inoltre il record utilizza i valori della tabella sottostante per rappresentare i valori dei byte.
Valori Header
Prendiamo il nostro esempio e analizziamo l’header del record. Il primo byte, ovviamente, rappresenta la lunghezza del nostro record: in questo caso il record è di 110 byte. Il secondo byte è la nostra chiave.
Lunghezza dei record e chiave
Il byte successivo rappresenta la lunghezza dell’header del nostro record includendo questo byte, che è di 19 byte.
Lunghezza dell’header del record
Il byte successivo è null, il che indica che il valore non è incluso nel record. Questo sarebbe stato rappresentato dal ROWID dello schema. Il byte successivo corrisponde alla riga dell’indirizzo nello schema. Il byte 0×27 è dispari e maggiore di 13. Secondo la nostra tabella questo corrisponde al testo e la lunghezza in byte è calcolata prendendo il valore decimale sottraendo tredici e dividendo per due.
39 -13 = 26 / 2 = 13
Possiamo vedere dal grafico sottostante che l’indirizzo, o il numero di telefono, è in realtà 13 byte di lunghezza.
Lunghezza indirizzo
Il byte successivo, 0×4, corrisponde nello schema alla data dell’SMS. Si tratta di un valore di quattro byte memorizzato in epoch time. Il valore qui è 1296980309 e si traduce in Dom, 06 Feb 2011 09:18:29 GMT+1.
Data e Time Stamp
Il byte successivo, 0×81 è, come indicato nello schema, il messaggio di testo; ma è l’unico. SQLite utilizza un metodo di compressione basato sulla codifica di Huffman per memorizzare i valori maggiori di 127 bit. In questo caso il byte nell’header del record che indica il messaggio di testo è \X81 o 129 e, di conseguenza, maggiore di 127. Dato che il metodo utilizza 2 byte fino ad un valore decimale di 16383, si può assumere che il byte successivo \x0d stia anche per la lunghezza del messaggio di testo. Il metodo per calcolare la lunghezza del messaggio di testo è il seguente: dove X = il valore del primo byte e Y = il valore del secondo byte.
(X-128) x 128 + Y
Dopo aver eseguito il calcolo ecco il risultato:
(129-128) x 128 + 13
\ X142
Per trovare la lunghezza dell’header ora facciamo riferimento alla tabella e calcoliamo normalmente:
(N-13) / 2
(129) / 2
64
Questa, infatti, è la lunghezza del messaggio di testo. Il messaggio è puro esa in ascii.
Lunghezza messaggio
Il byte successivo nell’header è 0×1 e nello schema si riferisce alla riga dei flag. Il valore in questo caso è 0×02, ciò significa che si tratta di un testo in entrata.
Flags
L’ultimo byte significativo compare nell’offset 17 del record e, come indica la nostra tabella, è un valore maggiore di 13 (0×11 = decimale 17).
Poiché il calcolo è N-13/2 il valore che abbiamo qui è 2 byte e si riferisce, nello schema, al paese. Nel nostro esempio è 0x6A 0x6F, o “Jo”, per la Giordania.
Paese
Spero che troverete utile questo post nelle vostre imprese di forensic. Questo post non sarebbe stato possibile senza il generoso aiuto e il consiglio di DC Shafik Punja di Calgary e Sheran Gunasekera di ZenConsult Pte Ltd.
Le ricerche sulla codifica di Huffman nei record di SQLite è stata condotta utilizzando l’articolo Murilo Tito Pereira “Analisi della forensic della cronologia Internet di Firefox 3 e il recupero dei record eliminati di SQLite” pubblicato da Elselvier.
Fonte: SQLite Records
Secondo alcuni ricercatori tedeschi, il 99% dei dispositivi Android potrebbe essere a rischio a causa di una vulnerabilità che potrebbe consentire a soggetti non autorizzati di curiosare sul vostro Google Calendar ed i vostri contatti.
Purtroppo non è sempre possibile aggiornare, visto che dipende dal produttore del cellulare e dal carrier che fornisce l’aggiornamento over the air. 
