Clonazione di un disco

In questo periodo sto leggendo un libro davvero interessante: Computer Forensics di Ghirardini – Faggioli, Apogeo Editore. Il testo tratta delle tecniche di analisi forense in ambito informatico. Grazie a questo libro ho appreso una nuova tecnica per effettuare il clone di un disco. Avevo già trattato questo argomento in precedenza. Tuttavia questo sistema è molto più accurato ed elegante e merita certamente di essere menzionato tra i miei appunti di informatica, in quanto tale metodologia può rivelarsi davvero utile.
Per prima cosa la copia: viene usato il comando dd che esegue una copia byte per byte a prescindere dal tipo di filesystem utilizzato. Ad esempio il comando:

# dd if=/dev/sda of=/percorso/nome_file.img bs=2048

esegue una copia del disco (device) sda (compresa l’MBR, la struttura delle partizioni e lo spazio non utilizzato) nel file nome_file.img. Ovviamente, invertendo gli argomenti, è possibile ripristinare un’immagine creata precedentemente nel disco.
La destinazione deve risiedere necessariamente in un disco diverso da quello sorgente. Quindi dobbiamo disporre di un altro supporto, interno o esterno, purché abbastanza capiente da contenere il file immagine, che avrà come dimensione finale la dimensione nominale del disco sorgente. Come possiamo fare se non si dispone di un supporto secondario? Gli autori descrivono come trasferire il file immagine in un’altra macchina via rete attraverso il tool netcat. Questo programma è in grado di restare in ascolto su una determinata porta e riportare tutto quello vi passa in un file. Dunque, possiamo procedere in questa maniera: nel computer di destinazione, che farà da server, avviare netcat:

$ netcat -l -p 5959 > nome_file.img

Sul pc client, dove risiede il disco da clonare:

# dd if=/dev/sda bs=2048 | netcat 192.168.0.1 5959

I parametri sono ovviamente a titolo di esempio. Quindi, nel caso reale, dovremo indicare l’indirizzo reale del server e una porta che non sia già usata da un altro programma in quel momento.
Una volta ottenuta l’immagine del disco, è possibile ripristinarla allo stesso modo, oppure montarla attraverso i loop device. Tuttavia dobbiamo ricordarci che quello che abbiamo in mano è la copia raw del disco e non una partizione. Quindi dobbiamo prima analizzare lo schema di partizionamento del disco, poi procedere con il montaggio della partizione di nostro interesse. Quindi:

$ fdisk -u -l nome_file.img

e otterremmo un risultato simile a questo:

Device Boot      Start         End      Blocks   Id  System
nome_file.img1   *          63   113627744    56813841    7  HPFS/NTFS
nome_file.img2       113627745   156296384    21334320    7  HPFS/NTFS

Per montare la partizione dobbiamo calcolare il valore di offset che è dato dal numero di blocco iniziale * 512. Nell’esempio, la partizione nome_file.img1, che è di tipo ntfs inizia dal blocco 63, perciò: 63 * 512 = 32256. Quindi:

# mount -t ntfs -o ro,loop,offset=32256 nome_file.img /percorso/mountpoint

System 7 Full Optional

Come forse molti già sapranno, da molto tempo mamma Apple ha reso disponibili sul prioprio sito le immagini disco di alcuni suoi software storici tra cui il System 7.0.1 in italiano che ho usato per rimettere a nuovo il mio Macintosh Classic. Ovviamente stiamo parlando di parti di software che al giorno d’oggi hanno scarso valore sia economico che di impiego ma che sicuramente fanno la felicità di collezionisti e possessori di vecchi modelli, come me appunto! Girando poi per la rete, ho trovato altri programmi ed estensioni, che al tempo servivano ad aumentare le potenzialità di queste macchine. Vediamone alcune che ho provato sul mio Classic.

Apple Menù Options

Questa estensione rende il menù Apple gerarchico come nei sistemi più recenti. Permette quindi di organizzare le voci in sottomenù. Il software è stato estratto direttamente dal System 7.5.3 e, nonostante gli avvertimenti, funziona egregiamente anche nel 7.0.1.

DragAnyWindow

Freeware. Il nome è molto esplicativo: permette di definire un tasto funzione e spostare le finestre cliccando in qualunque punto. Inoltre visualizza il contenuto della finestra anzichè il solo bordo durante l’operazione di trascinamento.

Joliet Volume Access

Freeware. Permette di leggere i filesystem su CD che usano nomi di file lunghi senza troncarli. Non funziona sempre e con tutti i tipi di CD, quindi occorre sempre prestare una certa attenzione.

PSPrinter 8.2.1

Freeware. Questo driver permette di usare una stampante generica che supporta PostScript e TCP/IP. La versione è alquanto datata ma è l’unica in grado di girare su sistemi così vecchi.

Super Clock! 4.0.4

Freeware. Questa è davvero una chicca. Quanto installai il System 7.0.1 sul Classic, scoprii con rammarico che in questa versione ancora non esisteva l’orologio sulla barrà dei menù. Grazie a questa estensione,  è possibile risolvere questo problema senza tra l’altro appensantire il sistema in termini di prestazioni e risorse.

WindowShade 1.2

Freeware. Un’altra piccola estensione che permette di “arrotolare” la finestra su stessa, semplicemente facendo doppio-click sulla barra del titolo. Parlando in termini “winzozziani” è come ridurla a icona.
Tutti questi componenti posso essere scaricati dal sito fenestrated.net e più precisamente in questa pagina.

Un server FTP

Accedere ai file sul nostro server da remoto è più semplice se su di esso installiamo un servizio FTP. Questo protocollo è nato appositamente per lo scambio dei file da remoto e, sebbene esponga la nostra linux-box a qualche rischio di sicurezza in più, rende il suo utilizzo da remoto ancora più flessibile.
Un’installazione standard (ovvero senza particolari configurazioni) richiede pochissimo tempo. Innanzitutto installiamo il servizio vsftpd:

$ sudo apt-get install vsftpd

Quindi editiamo il file di configurazione /etc/vsftpd.conf e impostiamo i parametri che seguono:

#Disabilita il login anonimo
anonymous_enable=NO
#Abilita l'autenticazione basandosi sugli utenti locali
local_enable=YES
#Abilita la scrittura dei file per gli utenti accreditati
write_enable=YES

Per rendere effettive le modifiche non resta che riavviare il servizio e poi siamo subito pronti per accedere al nostro server via FTP!

Soluzioni a linea di comando per il backup in Mac OS X

Fare il backup del proprio hard drive è un po’ come andare dal dentista: importante ma sgradevole, tanto da rimandarlo o dimenticarsene. Proprio per questo, il miglior modo per tenere al sicuro i propri dati è di programmare dei backup in modo regolare. Esistono in commercio diverse soluzioni, tra cui il software Apple .mac Backup, che però necessita la sottoscrizione del relativo servizio a pagamento e che l’utente si sia autenticato.
La tradizionale alternativa UNIX consiste nell’eseguire programmi di backup a linea di comand in uno script di cron, ma molti amministratori ignorano la varietà di opzioni disponibili per backup non controllati sotto Mac OS X.
Questo articolo tratta di alcuni aspetti inerenti la gestione dei backup e delle particolari considerazioni per i sistemi Mac OS X, la varietà delle opzioni che permettono la creazione delle copie e i trabocchetti nei quali si può cadere quando si sviluppa un sistema di backup. L’articolo non copre i flags BSD e i sistemi precedenti a Mac OS v10.4 (Tiger). Inoltre, per semplicità, si presumerà che nei filesystem per i quali si intende effettuare le copie, non siano attivi gli ACL (se si usa Mac OS X Server o fsaclctl). Ci sono alcune questioni su come questi programmi di backup interagiscono con gli ACL che esulano l’obiettivo di questo articolo e pertanto non verranno trattate. E’ possibile comunque consultare la documentazione di ogni programma in maniera più approfondita.

Un po’ di storia, dump e tar

Lo scopo principale di un backup è quello di riprodurre, nella maniera più accurata possibile, lo stato di un filesystem. Nella maggior parte dei casi la duplicazione del contenuto di un file non è sufficiente; la gerarchia del filesystem, i permessi, le date e le altre informazioni devono anch’esse essere preservate. I due principali programmi di backup UNIX, dump e tar, hanno approcci differenti sotto questo aspetto.Il programma dump legge la struttura sottostante il filesystem e ne produce una copia esatta. Fin dagli inizi di UNIX, dump esegue una scansione della tabella degli inode, crea una lista completa di tutti i file del disco e della struttura dei filesystem, analizza le directory e quindi il contenuto dei file. Questo approccio è dovuto alla particolare struttura di un filesystem UNIX, che è differente da un filesystem HFS+. Al contrario, tar usa le API del filesystem per creare l’immagine di una directory e dei file in esso contenuti. Questo approccio risulta più semplice e più portabile ma il formato del file tar non gestisce direttamente le peculiarità di Mac OS X come ad esempio le resource forks e i metadati del filesystem.
In tutti i casi, backup affidabili generalmente richiedono un filesystem inerte, ovvero un filesystem che non venga modificato durante il processo di copia. Per esempio, un file che viene spostato da una directory ad un’altra durante la creazione del backup, potrebbe risultare in entrambe all’interno del backup, o (peggio) in nessuna. Potrebbero verificarsi anche altri tipi errori, alcuni meno evidenti. Un file molto grande che viene riscritto durante il processo di copia, potrebbe venire troncato prima della fine o contenere dati non coerenti dove alcune parti provengono dalla versione originale e altre dalla versione modificata del file, con conseguente perdita di dati.
Sfortunatamente, i moderni sistemi sono spesso attivi 24 ore su 24, 7 giorni su 7, rendendo così impossibile la programmazione dei backup. Tuttavia, in una situazione del genere, una precisa strategia di backup diventa particolarmente importante, vista la più alta probabilità che un data copia di backup si corrompa in qualche modo. Inoltre potrebbe essere utile se si considerano strategie di backup che non operino a livello di filesystem; ad esempio, l’esportazione delle tabelle da un database è un operazione assicurata che produce un’immagine valida di quel databas, che può essere così tranquillamente copiato.

Considerazioni in merito a HFS/HFS+

Il filesystem HFS+ usato in Mac OS X ha una serie di funzionalità e caratteristiche molto diverse da quelle di un tradizionale filesystem UNIX. Più semplicemente, un programma di backup che si basa sulle API del filesystem, per questioni di portabilità, non è in grado di creare copie valide di un filesystem HFS+.
Innanzitutto ogni cosa ha una sua resource fork. Le resource fork vengono ignorate dalle API UNIX tradizionali, in quanto gestiscono solo la data fork di un file. Ci sono poi altre questioni che possono mettere in dubbio una strategia di backup. Gli attributi di un file (i flags del Finder, le date, il tipo di file e i riferimenti a chi lo ha creato) sono informazioni addizionali che un sistema di backup standard per UNIX non solo non ha modo di leggere, ma anche di registrare. Congiuntamente, questi dati sono riferiti da ora in poi come “attributi estesi”.
Il filesystem HFS+ non usa gli inode allo stesso modo dei filesystem UNIX (infatti gli hard link vengono emulati grazie ad un elaborato sistema che riproduce gli stessi effetti di un tradizionale hard link UNIX). Di conseguenza uan strategia di backup basata sulla scansione degli inode è praticamente impossibile.
Gli alberi binari del filesystem da sole potrebbero offrire una soluzione ma in pratica è meglio ignorare questa implementazione e concentrarsi sulle API; questo approccio offre risultati più consistenti ed è portabile.
A causa delle differenze tra i filesystem HFS + e gli UNIX tradizionali (come ad esempio UFS, il filesystem di Berkeley disponibile in Mac OS X) è necessario l’utilizzo di soluzioni particolari per la creazione e il ripristino delle copie di backup nei sistemi Mac OS X.
Inoltre i sistemi non-Mac non possono essere usati per la copia di file provenienti da un sistema Mac. Se si scompattano i file di un archivio su un’altra macchina e poi li si ricompatta, i datiche non possono essere rappresentati su quella macchina verrebbero irrimediabilmente persi.

Cosa funziona in Mac OS X v10.4 Tiger

Esistono alcune soluzioni commerciali per Mac OS X. Dettagli in merito allo loro compatibilità e funzionalità esulano da questo articolo, ma i relativi rivenditori saranno quasi con ogni probabilità felici di rispondere a tali domande. Assicuratevi di chiedere tutte le informazioni che vi servono secondo le vostre specifiche esisgenze. Non tutti i programmi compatibili con Mac OS X supportano pienamente tutte le sue funzionalità.
Ci sono alcune utilità già incluse in Mac OS X che possono essere utili allo scopo almeno in parte. Il più conosciuto è senz’altro ditto, un’utility specifica per Mac OS X che sin dalla nascita è stata in grado di gestire le resource fork dei file (nelle versioni precedenti la 1.4, il flag -rsrc deve essere passato per permettere a ditto di copiare le resource fork). Ditto può essere usato quasi in ogni tipo di situazione dal momento che può copiare interi file, archiviarli e ripristinarli. L’archivio crreato da ditto può essere sia nel formato PkZip che cpio. Siccome ditto può essere eseguito dalla linea di comando, è molto semplice programmare i backup e gestire eventuali problemi senza la necessità di una supervisione costante.
Un’altra opzione è tar che, a partire da Mac OS X 10.4, riconoscee gestisce le resource fork e gli attributi. Per contro non è in grado di gestire path molto lunghi e potrebbe non salvare i nomi dei file in maniera corretta (tale anomalia viene seganalata con un messaggio di errore). Tar può comunque archiviare e ripristinare le resource fork e gli attributi dei file. Nelle versioni più obsolete di Mac OS X tar non gestiva niente che non fosse solo il data fork e i permessi del file.
L’utilità pax è un’alternativa più flessibile rispetto a tar supportando le intestazioni di formati multipli. Preserva inoltre gli attributi estesi. Grazie a queste funzionalità pax è in grado di gestire path più lunghe.
L’utilità rsync offre performance migliori quando si eseguono copie di file particolarmente grossi. Per copiare gli attributi estesi occorre specificare il flag -E. rsync può essere usato in rete per centralizzare i backup.
In termini di affidabilità e velocità l’Apple Software Restore (ASR) è difficile da battere. Questo programma viene usato per la creazione di CD di ripristino in volumi HFS+. Per usare ASR, occorre creare un’immagine del disco  usando Disk Utility (usare il comando Crea immagine da directory, no Crea immagine da dispositivo). Un backup creato in questo modo può essere ripristinato in altri dischi come nello stesso. ASR può ripristinare i dati sostiuendoli oppure ridormattando il disco e poi copiarli in esso. In ogni caso, il largo impiego è dovuto essenzialmente per la velocità but of course it does remove any existing files.
Le immagini disco usate da ASR sono immagini disco standard Mac e possono essere montate nel desktop per copiare file specifici.
Vi è anche un’utlità a riga di comando denominata asr che può essere usata allo stesso modo. Inoltre è possibile specificare un volume esistente come sorgente piuttosto che un un’immagine compressa. Se asr viene richiamato senza il flag -erase, il programma semplicemente estrae i dati nella posizione corrente. Da tenere presente che asr non è in grado di operare in sorgenti o destinazioni che non siano volumi, ovvero non è possibile copiare i file in una subdirectory.
Per effettuare il restore di macchine di cui si conosce perfettamente la configurazione. è possibile usare asr in modelità serve, in cui fornirà una stream da una immagine sorgente. I sistemi client non possono usare questo sistema per un ripristino in locale  senza prima aver riformattato il volume di destinazione.Questo è un ottimo modo per effettuare il backup della configurazione del sistema, ma sarà necessario usare qualcos’altro per i file personali.

Avvertimenti

Ci sono alcune cose da tenere bene a mente quando si sviluppa una strategia di backup. Una delle cose più importanti è quella di testare il proprio sistema di backup in più circostanze differenti. Una delle cose più ovvie da testare è se è effettivamente possibile ripristinare i file. Un programmatore che ha sviluppato un’utilità per l’archiviazione a scopo ricreativo ha osservato che la gente rimane si è sempre impressionata per la qualità dei suoi backup senza chiedersi mai se era possibile effettuarne poi il ripristino. Prima di iniziare a fidarsi del proprio ssitema, è necessario effettuare il ripristino dei dati per testarlo! Ripristinare una gran varietà di file per testare tutte le possibilità: file con resource fork, file con l’ACL (se lo si utilizza), ecc.
I backup su sistemi attivi possono perdere dati significativi. Qualunque strategiadi backup che si adotta per questo tipo di sistemi devono tenere presente questo; se non si prevede questo rischio.

Localizzazione delle cartelle

Uno dei punti di forza di Mac OS X, dal punto di vista di un programmatore, è senza dubbio il sistema di localizzazione integrato in esso. Il Sistema Operativo offre allo sviluppatore una serie di strumenti che facilitano l’integrazione delle proprie applicazioni nella lingua usata dall’utente. Questi strumenti possono essere estesi non solo alle applicazioni, ma anche alle cartelle del filesystem. Se con il Finder apriamo la nostra Home, troviamo al suo interno le cartelle Documenti, Filmati e Musica. Ma se andiamo ad esplorarla attraverso il Terminale, ci accorgeremo che tali cartelle corrispondono alle directory Documents, Movies e Music.
Attraverso questo sistema, è possibile semplificare le operazioni sulle cartelle rendendole più user-friendly all’utente, senza complicare troppo la vita al programmatore, dal momento che egli, potrà sempre e comunque, fare riferimento alle path di queste cartelle attraverso il nome reale, senza preoccuparsi di come queste vengono chiamate dall’utente nella sua lingua.
Vediamo come possiamo personalizzare i nomi di queste cartelle, o meglio ancora, aggiungerne di altre.

Metodo 1

Questo metodo prevede la modifica della configurazione del Finder e, affichè la nostra cartella venga localizzata, occorre ripetere l’operazione sotto descritta in ogni singola installazione di Mac OS X. Questo approccio viene usato per le cartelle di sistema predefinite.
Andiamo nella nostra Home e creiamo la cartella Projects.
Quindi da terminale, attraverso il nostro editor di testo preferito (io uso vi) editiamo il file contenente le stringhe di localizzazione per l’italiano (ovviamente la regola vale per qualunque lingua, basta modificare il file corretto!):

$ sudo vi /System/Library/CoreServices/SystemFolderLocalizations/it.lproj/SystemFolderLocalizations.strings

e andiamo ad aggiungere la seguente riga:

"Projects" = "Progetti";

Salviamo il file e poi digitiamo il seguente comando:

$ touch Projects/.localized

Quest’ultimo crea un file all’interno della nostra cartella che indica al Finder di localizzarla usando la stringa che abbiamo impostato.
Per rendere effettive le modifiche dobbiamo disconnetterci e effettuare di nuovo il login, oppure riavviare il sistema.

Metodo 2

Questo metodo segue invece un approccio leggermente diverso in quanto le stringhe di localizzazione risiedono all’interno della cartella stessa. Per fare ciò dobbiamo innanzitutto aggiungere l’estensione .localized al nome della cartella. Questa volta creeremo la relativa directory direttamente da Terminale:

$ mkdir Projects.localized

Noterete fin da subito che il Finder mostrerà solo la prima parte del nome, nascondendone l’estensione.
Adesso creiamo la subdirectory .localized:

$ mkdir Projects.localized/.localized

Quindi creiamo al suo interno il file per la localizzazione in italiano:

$ vi Projects.localized/.localized/it.strings

e inseriamo la traduzione:

"Projects" = "Progetti";

Salvate le modifiche; dopodiché rifate il login oppure riavviate il sistema, al termine del quale troverete il nome della vostra cartella localizzata.

I metodi descritti in questo articolo sono validi purché nelle preferenze del Finder non sia stata spuntata l’opzione Mostra tutte le estensioni dei documenti (Menù Finder > Preferenze > Avanzate).
La localizzazione delle applicazioni invece, benché si basi sullo stesso principio, merita senza dubbio un articolo a parte, vista la maggior complessità.