Aprire una console seriale sul proprio cellulare

Qualche tempo fa ho scritto un breve articolo sui comandi AT nel mondo dei cellulari. Mediante questi comandi è possibile interfacciarsi al modem del telefono attraverso una console seriale, e attraverso questo accedere a una serie di funzionalità che variano da telefono a telefono e possono includere cose tipo fare chiamate, mandare sms, leggere gli sms nella memoria e così via. Però prima di questo è necessario creare la connessione tra il computer e il telefono: vediamo un pò come si fa.

Siccome i cavi sono sempre scomodi, tenteremo di instaurare questa connessione via bluetooth. Per prima cosa bisogna verificare che il computer abbia un adattatore bluetooth configurato a dovere e pure il cellulare (che deve avere il bluetooth attivo e in modalità “visibile a tutti”).

Lavoreremo sotto Ubuntu Linux (non voglio nemmeno immaginare quanto potrebbe essere complicato tentare di fare quello che sto per fare sotto winzozz ). Dovremo avere installato lo stack bluetooth e i pacchetti bluez-sdp e bluez-util:

mario@ninfa:-$ sudo apt-get install bluez-utils bluez-sdp
mario@ninfa:-$ sudo /etc/init.d/bluetooth restart

Per prima cosa scopriamo l’indirizzo bluetooth (univoco) del nostro telefono:

mario@ninfa:-$ hcitool scan

scanning…
00:11:22:33:44:55    Mario

Il tool di ricerca ha individuato un telefono di nome Mario e indirizzo univoco 00:11:22:33:44:55 (segnamolo da qualche parte, sarà con quello che il computer potrà identificare il telefono). Passiamo ad esaminare i servizi a disposizione sul telefono:

mario@ninfa:-$ sdptool browse 00:11:22:33:44:55

Il risultato sarà un sacco di testo, che rappresenta una voluminosa e dettagliata descrizione di tutti i servizi messi a disposizione dal telefono mediante bluetooth (si va dallo scambio di file fino alla connessione dell’auricolare). Quello che interessa a noi in questo caso è il servizio di Dial Up Networking, corrispondete al modem:

[...un sacco di roba...]

Service Name: Dial-up Networking
Service RecHandle: 0×10002
Service Class ID List:
“Dialup Networking” (0×1103)
“Generic Networking” (0×1201)
Protocol Descriptor List:
“L2CAP” (0×0100)
“RFCOMM” (0×0003)
Channel: 2
Profile Descriptor List:
“Dialup Networking” (0×1103)
Version: 0×0100

[...un sacco di roba...]

Nel testo ho evidenziato l’informazione importante: il canale da usare per la comunicazione. NB: su alcuni telefoni esiste anche il servizio “serial console”, ma non sono sicuro di quale sia la sua funzione. Vale la pena di fare qualche prova se il canale indicato sopra non funziona.

Una volta scelto il canale, predisponiamo il computer per la connessione. Modifichiamo il file hcid.conf, quello che sovrintende alle connessioni bluetooth del computer:

mario@ninfa:-$ sudo vim /etc/bluetooth/hcid.conf

Per cominciare, bisogna impostare la modalità di autenticazione tra telefono e computer. Come sappiamo, l’autenticazione su bluetooth avviene mediante impostazione di un PIN. Potremmo configurare Linux per domandare il PIN ogni volta che instaura una connessione, ma al momento non vale la pena di perderci tempo: imposteremo un PIN unico per il computer; teniamo presente di stare attenti, dato che un PIN statico significa che chiunque lo conosca si può collegare ai servizi bluetooth del nostro computer!

In questo caso sarà sufficiente verificare che la riga security del file abbia questo aspetto:

security auto;

e che la riga passkey riporti il PIN statico da noi scelto (in questo caso quattro zeri):

passkey “0000″;

Salviamo e chiudiamo il file. Riavviamo il sistema bluetooth:

mario@ninfa:-$ sudo /etc/init.d/bluetooth restart

Inizializzazione della comunicazione

Il passo successivo è creare il binding tra cellulare e computer. Per questo è necessario utilizzare la “ricerca dispositivi bluetooth” del telefono, individuare il computer e iniziare la connessione. Verrà richiesto il PIN, e noi inseriremo quello specificato prima (nell’esempio 0000). NB: questo passaggio è facoltativo: nel caso venga inizializzata la comunicazione (mediante i comandi descritti in seguito) senza un binding preventivo, questo dovrebbe essere comunque avviato automaticamente; in ogni caso durante il binding verrà richiesto il PIN.

A questo punto dobbiamo creare la connessione tra una console seriale e il canale desiderato sul telefono.

mario@ninfa:-$ sudo rfcomm bind rfcomm0 00:11:22:33:44:55 1

dove:

• rfcomm0 è il nome della console seriale
• 00:11:22:33:44:55 è l’indirizzo fisico del cellulare
• 1 è il canale (sostituire col valore trovato prima)

Per verificare l’avvenuta connessione è sufficiente utilizzare ancora il comando rfcomm:

mario@ninfa:-$ rfcomm

rfcomm0: 00:11:22:33:44:55 channel 1 clean

A questo punto la connessione è attiva. Non ci resta che accedervi, ad esempio così:

mario@ninfa:-$ screen /dev/rfcomm0

Si aprirà una console completamente vuota, dato che il modem non ha prompt. Per verificare il funzionamento basta inviare il comando AT seguito dal tasto invio; il telefono dovrebbe rispondere con un OK. Funziona!!!!

Per chiudere la comunicazione basta un control+c.

Per un elenco dei comandi AT con cui si può giocherellare vi lascio questo link, con un elenco di comandi supportati da Nokia (e parzialmente anche da altri telefoni). Tenete sempre presente che solo una parte di essi sarà utilizzabile, dipende dal modello del vostro telefono. E tenete presente di andarci piano, e fare prove a ragion veduta, perchè sennò rischiate di incasinarvi il telefonino!

Rendere le impostazioni permanenti

Un’ultima cosa: per rendere le impostazioni di comunicazione permanenti, bisogna modificare il file /dev/bluetooth/rfcomm.conf:

mario@ninfa:-$ sudo vim /etc/bluetooth/rfcomm.conf

e aggiungervi una sezione simile a questa:

rfcomm0 {
bind no;
device 00:11:22:33:44:55;
channel 1;
comment “il mio telefonino bello bello”;
}


Ovviamente i valori di device e channel devono essere impostati correttamente. Salviamo e chiudiamo il file. A questo punto per avviare la connessione è sufficiente digitare:

mario@ninfa:-$ sudo rfcomm bind /dev/rfcomm0

E per terminarla:

mario@ninfa:-$ sudo rfcomm release /dev/rfcomm0

Senza doversi ricordare indirizzo o canale. Comodo, no? Esiste infine una terza strada: nel file rfcomm.conf modificato prima, nella riga bind della sezione che abbiamo aggiunto mettiamo yes invece di no: in questo modo il computer tenterà automaticamente di connettersi al cellulare ogni volta che questo sarà vicino e col bluetooth attivo. Per questi esperimenti è in effetti inutile, ma potrebbe risultare utile in futuro.

Beh, per ora è tutto, spero di essermi spiegato bene. Se avete dubbi non esitate a scrivere nei commenti, farò il possibile per rispondere. Ciao a tutti!

Controllare un telefono mediante comandi AT

I comandi AT (o comandi Hayes ) costituiscono un set di comandi (sotto forma di brevi stringhe di testo ASCII) per il controllo di dispositivi di comunicazione. Vennero introdotti dalla Hayes Communications nel 1977 come protocollo standard per controllare il loro Smartmodem ; prima dell’introduzione di tale prodotto, infatti, i modem analogici venivano controllati mediante interfacce hardware dedicate, che mal si prestavano a essere inserite nei microcomputer, che in quel periodo stavano conoscendo una forte diffusione. I comandi AT rivoluzionarono questo paradigma, permettendo il controllo di dispositivi quali modem attraverso una semplice linea seriale ed un set di comandi standard. Il set di comandi AT col passare del tempo divenne uno standard di fatto e venne utilizzato come sistema di interfacciamento per un gran numero di modem analogici. Il set prevede comandi per vari tipi di operazioni inerenti la linea telefonica e per il controllo dei registri interni del dispositivo connesso.

In seguito, data l’enorme diffusione di questo standard, nacque anche lo standard ETSI GSM 07.07 (3GPP TS 27.007), che definì una serie di comandi AT per il controllo di telefoni GSM. Questo standard oltre a permettere il controllo da remoto del telefono, almeno per quanto riguarda le operazioni inerenti la linea telefonica, in linea teorica permette anche l’accesso a molte delle informazioni contenute nella memoria del dispositivo e nella SIM card. In realtà, purtroppo, su molti di questi comandi non si può fare affidamento in quanto si tratta di funzionalità facoltative, non sempre implementate dal produttore. Nella pratica, comunque, la maggioranza dei telefoni GSM in commercio è in grado di fornire le seguenti informazioni:

• Produttore del telefono, modello e informazioni sulla versione.
• Identificativo IMEI del telefono.
• Identificativo IMSI della SIM card.
• Rubrica telefonica.
• Log delle chiamate.
• Messaggi ricevuti e inviati.

Il protocollo AT prende la forma di una comunicazione seriale di tipo comando-risposta. Il client invia un comando (terminato da un carattere di carriage return e opzionalmente da un new line ) e riceve una risposta.

In figura è rappresentato l’invio di un sms mediante microsoft hyperterminal, attraverso un nokia 3310 connesso al computer mediante cavo seriale. Fiko, no?

Il formato a sette bit degli SMS

I messaggi SMS sono brevi messaggi di testo (160 caratteri al massimo); la loro codifica è documentata dagli standard GSM 03.40 e GSM 03.38 pubblicati dall’Etsi (European Telecommunications Standards Institute); la caratteristica più dolorosa di questa codifica è il fatto che ciascun carattere del messaggio è rappresentato  da sette bit. Esistono altre due modalità di trasmissione, a 8 bit (non visualizzabile come testo, normalmente utilizzata per trasmissione di dati) e a 16 bit unicode (un set di caratteri esteso, che però limita la lunghezza massima del messaggio a 70 caratteri). Ma la codifica più usata resta quella a 7 bit.

La conversione da caratteri ascii di sette bit a byte (da inserire nella stringa di trasmissione per esempio) è lievemente macchinosa.

Per esempio, per il testo “Mario”:

scrivo i valori ascii dei singoli caratteri: 4D 61 72 69 6F
in ascii binario: 01001101 01100001 01110010 01101001 01101111
in ascii in settetti (elimino lo zero msb): 1001101 1100001 1110010 1101001 1101111

Per completare i byte aggiungo in testa a ciascuno il numero necessario di bit estratti dagli lsb del byte successivo:

prima: 1001101 - 1100001 - 1110010 - 1101001 - 1101111
dopo: 11001101 - 10110000 - 00111100 - 11111101 – 00000110 (aggiungo zeri di padding)
in hex: CD B0 3C FD 06

I byte sopra elencati saranno dunque i valori da inserire per trasmettere il testo “Mario”.

Gli sms vengono normalmente inviati all’interno di una PDU (protocol description unit). Una stringa PDU contiene il testo del messaggio in codifica a 7 bit più una serie di informazioni accessorie come il mittente, il destinatario, in numero del centro messaggi, il timestamp e così via, sempre seguendo le linee guida delle specifiche etsi. Per una descrizione con esempi di tale standard vi rimando a questa pagina.

Scalpel: data carving facile e multipiattaforma

Giocherellando per la tesi, ho scovato un’interessante utility per il data carving. Per dirla in breve, data carving significa “scavare alla ricerca di dati”, ovvero tentare di identificare e isolare determinate informazioni all’interno di un blocco più esteso. Un esempio concreto è il tentare di isolare singoli files all’interno di un’immagine binaria, ad esempio una copia bit-a-bit di una partizione.

Per identificare files il modo più semplice è cercare headers e footers specifici: ogni tipo di file inizia con una determinata sequenza di caratteri che lo identifica, e spesso termina con una sequenza altrettanto specifica. Non devo fare altro che ritagliare quello che c’è attorno, e ho il file che stavo cercando.

… altroaltroaltro <header> file da estrarre <footer> altroaltroaltro …

Questa procedura può servire a vari scopi: ad esempio, per estrarre files da un disco danneggiato di cui riesco comunque ad avere un’immagine, seppure incompleta (e quindi impossibile da montare). Oppure per estrarre files da immagini che non posso montare: ad esempio per la tesi devo estrarre files da dump della memoria fisica di cellulari, e questa è l’unica strada percorribile.

Scalpel fa esattamente questo: esamina un’immagine binaria alla ricerca di header e footer specificati, e dove li trova estrae il contenuto e ne crea un file. Installarlo è facile: sotto Ubuntu linux è presente nel portage, basta fare:

sudo apt-get install scalpel

Ma la parte divertente è senz’altro la possibilità di installarlo anche sotto mac, essendo open source e quindi allegramente compilabile. Basta scaricare i sorgenti dal sito, scompattarli e compilare:

tar -xzf scalpel-xyz.tar.gz

cd scalpel-xyz

make bsd

Una volta pronto l’eseguibile, bisogna dedicare un pò di attenzione al file di configurazione. Nella cartella dei sorgenti è disponibile un file denominato scalpel.conf, che andrà modificato (facciamone prima una copia di backup, che non fa mai male). Questo file altro non è che un descrittore di tutti i possibili files che il sistema è in grado di estrarre, descritti come segue:

png  y  20000000  \x50\x4e\x47?  \xff\xfc\xfd\xfe

Il primo campo (png) è l’estensione che avrà il file una volta estratto. Il secondo campo è un booleano y/n che indica se header e footer sono case sensitive. Il terzo campo è la dimensione massima che può avere un file di questo tipo (se ci sono errori nel carving, almeno a un certo punto il sistema sa di doversi fermare). Il quarto e quinto campo sono rispettivamente header e footer da cercare.

Nel file di configurazione sono presenti una serie di possibili descrittori di file, in origine tutti commentati (le righe che cominciano con #). Prima di eseguire il carving bisogna togliere il # dall’inizio delle righe corrispondenti ai file che stiamo cercando.

A questo punto lanciamo il programma:

./scalpel -o cartella_risultati -c file_configurazione dumpfile

Il software esamina il file dumpfile e ne estrae tutte le occorrenze di files, descritti nel file_configurazione; tutto quello che riesce a estrarre viene piazzato in cartella_risultati. Tale cartella deve essere vuota, altrimenti il programma non funziona (può anche non esistere, in tal caso viene creata al momento).

Et voilà! Il gioco è fatto!

Processing of image file complete. Cleaning up…
Done.
Scalpel is done, files carved = 294, elapsed = 3 seconds.

Mobile Phone Forensics

Negli ultimi anni l’utilizzo di telefoni cellulari è cresciuto in maniera esplosiva, e tale tendenza sembra doversi mantenere anche negli anni a venire. Tale fatto può essere attribuito all’aumento delle loro funzionalità: la maggior parte dei telefoni moderni, infatti, oltre alla classica funzione di fare e ricevere telefonate, ha sviluppato delle funzionalità tipiche dei PDA (Personal Digital Assistant); tali dispositivi vengono quindi denominati smartphones.

Tra le funzionalità aggiunte a questi dispositivi spiccano la gestione di informazioni PIM (Personal Information Manager (quali contatti di rubrica o calendari), la navigazione Internet e l’utilizzo di materiale multimediale.

Sempre più spesso, inoltre, tali dispositivi hanno a disposizione un vero e proprio sistema operativo (come ad esempio Linux, Windows Mobile o Symbian); la differenza più interessante (almeno agli occhi dell’utente) tra questi sistemi operativi e i firmware dedicati delle precedenti generazioni di telefoni è la possibilità di installare applicazioni di terze parti.

La sempre maggiore diffusione di questi dispositivi, unita alla loro sempre maggiore capacità di contenere informazioni personali, ha significato un sempre maggiore coinvolgimento di questi in investigazioni digitali. Uno smartphone può essere coinvolto in diversi modi in un crimine: può essere uno strumento, un bersaglio o un modo per custodire informazioni legate al crimine stesso. Per questo motivo le forze dell’ordine stanno prendendo sempre più in considerazione l’importanza dei dati recuperati da questo genere di dispositivi, i quali per loro natura contengono numerose tracce dell’attività dell’utente.

Naturalmente per questo tipo di indagini è necessario utilizzare appositi strumenti per garantire l’integrità del materiale recuperato; in caso contrario questo potrebbe essere danneggiato e non più riconosciuto a fini legali.

Esistono in commercio e in letteratura numerosi strumenti (hardware e software) dedicati all’estrazione di dati da smartphones. Normalmente tutti questi prevedono l’utilizzo di un computer host per eseguire l’estrazione e conservare i dati. Inoltre normalmente di tratta di software e hardware particolarmente costoso, e poco adatto ad un’indagine sulla scena. Da qui nasce l’esigenza di studiare procedure per la conservazione e il trasporto del dispositivo tra il luogo del ritrovamento e il laboratorio in cui si procede all’analisi.

Esistono due famiglie di metodi per l’estrazione di dati da un dispositivo sotto analisi: l’estrazione fisica e l’estrazione logica.

L’estrazione logica consiste nell’utilizzo da parte degli investigatori di strumenti software messi a disposizione dalla piattaforma embedded per estrarre elementi di informazione. Rientrano in questa famiglia i sistemi di sincronizzazione (locali o remoti), i bus locali previsti dal produttore per la connessione a un computer host e le applicazioni dedicate installate sul dispositivo. Hanno il vantaggio di un costo più limitato e di una difficoltà tecnica più ridotta (l’hardware si limita al massimo a un cavo di connessione tra il dispositivo e un computer host, e tutto il resto è svolto mediante software dedicato). Spesso tale tipo di analisi può (in caso di necessità) essere svolta anche sul campo. Lo svantaggio è che i dati vengono serviti attraverso il sistema operativo e i protocolli di comunicazione ad alto livello, il che significa che non sempre è possibile garantire che non abbiano subito modifiche durante il processo di acquisizione. Inoltre il sistema operativo stesso potrebbe prevedere sistemi di sicurezza (come nel caso del Symbian) per prevenire l’accesso a dati riservati.

L’estrazione fisica invece consiste nell’utilizzo di sistemi a più basso livello per tentare di estrarre dall’hardware del dispositivo l’immagine della memoria di massa e/o della memoria volatile come dump esadecimale. Rientrano in questa categoria bus a basso livello (JTAG) e strumenti di programmazione dei singoli integrati di memoria. Questo sistema ha il vantaggio di acquisire in blocco tutto il contenuto del telefono, senza alcuna eccezione e aggirando qualunque sistema di sicurezza previsto dal sistema operativo. Il rovescio della medaglia è però l’estrema complessità di questa procedura e la necessità di strumenti di lavoro costosi e difficili da utilizzare per personale non esperto. Inoltre una volta estratta l’immagine della memoria o della flash deve essere interpretata per ricavarne i dati richiesti e renderli disponibili in un formato comprensibile: tale procedura è tutt’altro che banale o standard (ogni dispositivo ha un suo sistema di gestione dello spazio di archiviazione). Fortunatamente esistono degli strumenti software che si occupano di questo tipo di analisi, ma si tratta perlopiù di software estremamente specializzato e quindi costoso, oltre che di difficile utilizzo.