[C++] Player di File System

[misterx]

ciao,
l'idea mi è venuta per risolvere un problema su un disco il cui file system è VxFS di Veritas. Cercando in rete ho trovato l'header che credo rappresenti la struttura di tale file system però, prima di tentare qualcosa magari troppo oneroso in termini di tempo, vi chiedo se qualcuno ha già sperimentato programmazione del genere e magari, sgambiarci due idee costruttive.

Preciso che non ho intenzione di scrivere codice che accede al drive in quanto, attraverso una utility (g4l), mi sono procurato un file raw che rappresenta di fatto il contenuto dell'intero HD; ora si tratta di capire come è strutturato per leggere file e directory.

Grazie

[misterx]

Originariamente inviato da Bellaz89

Non ne so molto, ma il file che hai postato fa parte del driver di linux di Vxfs

Se vuoi divertirti o scrivere un reader/writer per fare altre cose puoi guardare gli altri sorgenti presenti nella directory del header.

Se vuoi leggere il contenuto di quel filesystem non puoi provare a montarlo con una distro linux?

si, è il driver di linux ed è l'unico che ho trovato disponibile. La strada delle distro l'ho già tentata senza successo, quindi mi sono detto che scrivere un player senza avere la pretesa di scriverlo, una volta che si conosce la struttura del file system e non credo serva conoscerla tutta nei minimi dettagli, il gioco dovrebbe essere fatto: dovrebbe, uso il condizionale.

[pabloski]

Originariamente inviato da misterx

si, è il driver di linux ed è l'unico che ho trovato disponibile. La strada delle distro l'ho già tentata senza successo

Come mai non va? Linux implementa FreeVxFS e dovrebbe montare un volume del genere senza problemi. Magari e' corrotto? Ha bisogno di un fsck?

Riguardo l'implementazione di un lettore per quel filesystem, come hai gia' detto, le informazioni sono qui https://github.com/torvalds/linux/tr...er/fs/freevxfs

Alla fin fine si tratta di interpretare strutture dati, estrarre gli offset dei file interessanti, spostarsi in quella posizione sul drive fisico o sul file immagine che hai creato e prelevare i dati di quei file.

Implementa pure le extent, per cui puo' essere necessario leggere all'interno dei blocchi le info sugli offset di ulteriori blocchi. Cioe' non tutte le informazioni utili per reperire tutti i blocchi le trovi nella "FAT"/inode.

[misterx]

Originariamente inviato da pabloski

Come mai non va? Linux implementa FreeVxFS e dovrebbe montare un volume del genere senza problemi. Magari e' corrotto? Ha bisogno di un fsck?

Riguardo l'implementazione di un lettore per quel filesystem, come hai gia' detto, le informazioni sono qui https://github.com/torvalds/linux/tr...er/fs/freevxfs

Alla fin fine si tratta di interpretare strutture dati, estrarre gli offset dei file interessanti, spostarsi in quella posizione sul drive fisico o sul file immagine che hai creato e prelevare i dati di quei file.

Implementa pure le extent, per cui puo' essere necessario leggere all'interno dei blocchi le info sugli offset di ulteriori blocchi. Cioe' non tutte le informazioni utili per reperire tutti i blocchi le trovi nella "FAT"/inode.

infatti è corrotto e le varie distro provate da me vxfs non lo vedono nella maniera più assoluta. Ho installato anche opensolaris e niente.
L'unica via è studiarsi la struttura vxfs e provare a leggere.

Unico dubbio è l'offset del file raw da 9 GB: da che byte si inizia a leggere?
Osservando la struct vxfs_sb { } sembra dall'inizio e poi attraverso i vari campi ci si sposta nelle directory e nei vari file e qui, ci sarà un qualche campo, a modi albero binario, che dice dove si trovano i vari blocchi che costituiscono il file di interesse in quanto, potrebbe essere sparpagliato nei vari cluster.

[pabloski]

Originariamente inviato da misterx

Unico dubbio è l'offset del file raw da 9 GB: da che byte si inizia a leggere?

Identifica il superblocco. Dovrebbe trovarsi all'offset 8192. Se non vuoi usare un valore hardcoded, cerca il magic VXFS_SUPER_MAGIC che e' 0xa501FCF5.

Li' dentro ci sono i valori vs_emap e vs_imap che indicano gli offset della mappa delle extent e degli inode. La struct del superblocco e' definita nel file vxfs.h.

Se non ti trovi a tuo agio a spulciare il codice, procurati il libro Unix Filesystems di Pate, ex dipendente Veritas, proprio gli ideatori di VxFS. Li' c'e' un capitolo molto dettagliato proprio su questo filesystem.

[misterx]

grazie ad entrambi, mi viene un dubbio: l'hd era collegato ad un PC HP con cpu risc e se non ricordo male, dovrebbe entrare in gioco l'ordine dei bit bigendian e littlendian o non è così?

[misterx]

a partire dal byte 8192 non trovo nulla, quindi ho effettuato una ricerca ed il risultato è il seguente:

offset=103485792 A501FCF5
offset=119226720 A501FCF5
offset=148194816 A501FCF5
offset=366755852 A501FCF5
offset=367833092 A501FCF5
offset=368476932 A501FCF5
offset=368478084 A501FCF5
offset=472752132 A501FCF5
offset=476155908 A501FCF5
offset=2725093380 A501FCF5
offset=2726662148 A501FCF5

ci sono più superblocchi, forse una sorta di backup?

la stranezza è che facendo un fseek con 368478084 diminuendo il risultato di 4 byte fseek( fp, 368478080, SEEK_SET ); ottengo:

magic number = F5FC01A5 (ordine inverso)
block size = 56

[pabloski]

Originariamente inviato da misterx

ci sono più superblocchi, forse una sorta di backup?

Si, i superblocchi hanno parecchi backup. Il primo e' quello normalmente usato.

Originariamente inviato da misterx

la stranezza è che facendo un fseek con 368478084 diminuendo il risultato di 4 byte fseek( fp, 368478080, SEEK_SET ); ottengo:

magic number = F5FC01A5 (ordine inverso)
block size = 56

Tieni conto dell'endianness. x86 e' little endian dopo tutto e a te serve per forza usare tipi word o quad word per estrarre gli offset.

[misterx]

Originariamente inviato da Bellaz89

Domanda: non e' che ci sono piu' partizioni?

In ogni caso a questo punto la cosa migliore e' mappare la struttura vxfs_sb in corrispondenza dei magic number e vedere cosa ne viene fuori

ahi, le partizioni non le ho verificate.

è il magic number non mi convince.
Cercando con ultraedit nel raw file per sincerarmene, ne trovo n, e li trovo anche nella medesima posizione con un semplice programma in C dove ho implementato un semplice buffer LIFO questo in quanto, il magic number non si trova ad una distanza partendo da zero divisibile per 4, si devono costruire parole da 4 byte scorrendo i byte uno ad uno e scartando ogni volta il primo entrato nel buffer: sistema arcaico ma funziona.

Però, ottenuti gli offset, il primo a 8192 ci può stare che sia andato perduto forse dopo una esecuzione maldestra del comando fsck -F vxfs -a full ...... ma, non mi è chiaro come mai riesco a trovari i magic number nell'ordine 0xa501FCF5 ma quando poi effettuo il salto con la fseek e riempio la struttura struct vxfs_s e visualizzo il campo vs_magic, questo è reversato

[misterx]

Originariamente inviato da Bellaz89

Perche' e' strano che trovi il reverse? come hai detto anche tu questo accade a causa dell'endianess.

è strano ne lsenso che, se visualizzi il file raw con ultredit vedi il magic number little endian, se fai una lettura dal C con la fread hai big endian, magari mi sfugge qualcosa.

[misterx]

Originariamente inviato da Bellaz89

Si ok.. ma come visualizzi la memoria letta con fread ? se fai printf("%x", magic_number); il numero dovrebbe essere visualizzato rigirato.

esatto!
Ma come mai ho queste differenze tra ultraedit e la printf?

[misterx]

Originariamente inviato da Bellaz89

UltraEdit ti dovrebbe far vedere la memoria 'plain' ovvero byte per byte.
Quando leggi la memoria pero' a causa dell'endianness di x86 la cifra meno significativa e' la piu' a sinistra. di conseguen, visto che la visualizzazione avviene sempre in big endian, la printf ti rigira i byte. Non so se sono stato chiaro za la printf di "%x" che dovrebbe mostrare le cifre in formato big endian, rigira le cifre.

In parole povere: se hai un'area di memoria del genere su x86_64

.. AA BB CC DD ..

assegni questa memoria ad esempio ad un unsigned int e fai printf("%x");

Il risultato sara'

DDCCBBAA

sei stato chiaro, è una cosa che non sapevo.


printf("%x", c & 0xff);
fread(&c, sizeof(c), 1, fp);
printf("%x", c & 0xff);
fread(&c, sizeof(c), 1, fp);
printf("%x", c & 0xff);
fread(&c, sizeof(c), 1, fp);
printf("%x\n", c & 0xff);

ottengo quello che dici

Quindi tutto quello che leggo dal file raw va reversato in ambiente intel, è così?

[misterx]

Originariamente inviato da Bellaz89

Yess, pero' solo a livello di tipo. la cosa che devi fare e' scrivere delle routine di conversione per i tipi del filesystem (solo gli int e eventualmente i tipi float).

quindi, per capire, va reversato tutto ciò che descrive i file, i vari offset, ma non i byte che rappresentano i file?

per la conversione little<->big uso questa già fatta da altri:

swapped = ((num>>24)&0xff) | // move byte 3 to byte 0
                    ((num<<8)&0xff0000) | // move byte 1 to byte 2
                    ((num>>8)&0xff00) | // move byte 2 to byte 1
                    ((num<<24)&0xff000000); // byte 0 to byte 3

[misterx]

ci sto lavorando,
sto leggendo il libro di Pate ma lo trovo troppo superficiale, non esiste qualcosa di più approfondito che spieghi meglio le varie strutture come sono connesse tra loro?

p.s.
come non detto http://h20565.www2.hpe.com/hpsc/doc/...r_na-c05189468