7 marzo 2011

Recupero di una pendrive USB

E' capitato ancora una volta. Qualcuno ha una pendrive che all'improvviso risulta vuota e Windows chiede se sia il caso di formattarla.

No! Alt! Stop!
Niente panico, proviamo a recuperare il contenuto
Se il danno hardware non è esteso (e spesso non lo è, anzi, mi è sempre capitato il caso che ad essere "persa" è stata la parte di disco relativa al boot sector/partition table/FAT) è possibile recuperare se non tutto almeno buona parte dei files presenti.
Ma procediamo con ordine.
  1. Scopriamo su quale device è presente la pendrive (che ovviamente non viene montata, non potendo trovare alcun filesystem valido al suo interno).
    Per prima cosa inseriamo il pendrive in una porta USB e poi da terminale diamo:
    [tuxmal@work ~]# dmesg
    ottenendo:
    usb 1-6: new high speed USB device using ehci_hcd and address 7
    usb 1-6: New USB device found, idVendor=0457, idProduct=0151
    usb 1-6: New USB device strings: Mfr=0, Product=2, SerialNumber=3
    usb 1-6: Product: USB Mass Storage Device
    usb 1-6: SerialNumber: 73971bc79344b6
    usb-storage 1-6:1.0: Quirks match for vid 0457 pid 0151: 80
    scsi5 : usb-storage 1-6:1.0
    scsi 5:0:0:0: Direct-Access                               1.0  PQ: 0 ANSI: 2
    sd 5:0:0:0: Attached scsi generic sg3 type 0
    sd 5:0:0:0: [sdc] 983808 512-byte logical blocks: (503 MB/480 MiB)
    sd 5:0:0:0: [sdc] Write Protect is off
    sd 5:0:0:0: [sdc] Mode Sense: 00 00 00 00
    sd 5:0:0:0: [sdc] Assuming drive cache: write through
    sd 5:0:0:0: [sdc] Assuming drive cache: write through
     sdc: unknown partition table
    sd 5:0:0:0: [sdc] Assuming drive cache: write through
    sd 5:0:0:0: [sdc] Attached SCSI removable disk
    quindi il device è sdc. Alternativamente avremmo potuto leggere queste info con:
    [tuxmal@work ~]# tail /var/log/messages
  2. Creiamo un file contenente i dati del pendrive, per le varie prove di recupero (pendrv è il nome del file utilizzato per i test), l'opzione bs specifica la grandezza dell'intero pendrive (in questo caso 512MB):
    [tuxmal@work ~]# dd bs=512M if=/dev/sdc of=./pendrv
  3. Copiamo il file appena creato (per sicurezza, potremo ritornare sui nostri passi senza più toccare il pendrive, che anzi, rimuoviamo dalla porta USB):
    [tuxmal@work ~]# cp pendrv pendrv.bkup
  4. Adesso, passiamo all'azione, controlliamo se si riesce a leggere qualcosa all'interno del pendrive:
    [tuxmal@work ~]# parted ./pendrv
    Nel caso in esame non risulta presente alcuna partizione. Possiamo provare ancora così:
    [tuxmal@work ~]# fdisk ./pendrv
    e, poiché non otteniamo alcun risultato interessante, ancora:
    [tuxmal@work ~]# fdisk -u -l ./pendrv
    oppure
    [tuxmal@work ~]# fdisk -l ./pendrv
  5. Se ancora non si hanno riscontri positivi, come nel mio caso, proviamo con:
    [tuxmal@work ~]# gpart -g -i ./pendrv
    che continua a visualizzare partizioni errate:
          Begin scan...
        Possible partition(DOS FAT), size(486mb), offset(0mb)
        End scan.

        Checking partitions...

        * Warning: partition(Primary 'big' DOS (> 32MB)) starts beyond disk end.
        Partition(Primary 'big' DOS (> 32MB)): invalid primary
        Ok.

        Guessed primary partition table:
        Primary partition(1)
          type: 000(0x00)(unused)
          size: 0mb #s(0) s(0-0)
          chs:  (0/0/0)-(0/0/0)d (0/0/0)-(0/0/0)r

        Primary partition(2)
          type: 000(0x00)(unused)
          size: 0mb #s(0) s(0-0)
          chs:  (0/0/0)-(0/0/0)d (0/0/0)-(0/0/0)r

        Primary partition(3)
          type: 000(0x00)(unused)
          size: 0mb #s(0) s(0-0)
          chs:  (0/0/0)-(0/0/0)d (0/0/0)-(0/0/0)r

        Primary partition(4)
          type: 000(0x00)(unused)
          size: 0mb #s(0) s(0-0)
          chs:  (0/0/0)-(0/0/0)d (0/0/0)-(0/0/0)r

  6. Proviamo comunque   a montare il nostro pendrive:
    [tuxmal@work ~]# mount -t vfat -o loop ./pendrive /mnt/usbdrv/
    Se nulla si è risolto, otterremo ancora errori del genere:
      mount: tipo fs errato, opzione non valida, superblocco su /dev/loop0 danneggiato,
             codepage o programma ausiliario mancante, o altro errore
             In alcuni casi si possono trovare informazioni utili in syslog. Provare
             ad esempio 'dmesg | tail'
    # dmesg | tail
      FAT: invalid media value (0x01)
      VFS: Can't find a valid FAT filesystem on dev loop0.
      FAT: invalid media value (0x01)
      VFS: Can't find a valid FAT filesystem on dev loop0.
      FAT: invalid media value (0xa5)
      VFS: Can't find a valid FAT filesystem on dev loop0.
      FAT: invalid media value (0xa5)
      VFS: Can't find a valid FAT filesystem on dev loop0.
      FAT: invalid media value (0xa5)
      VFS: Can't find a valid FAT filesystem on dev loop0.
  7. Proviamo ad utilizzare, allora,
    [tuxmal@work ~]# testdisk ./pendrive
    seguendo i menù riusciremo a correggere boot sector e partition table ed a visualizzare i file (menù [Advanced]). Proprio da quest'ultimo menù, tramite [Image Creation], creo una nuova immagine del pendrive (dal nome di default image.dd).
  8. Adesso proviamo a vedere dentro il pendrive recuperato:
    [tuxmal@work ~]#mount -t vfat -o loop ./image.dd /mnt/usbdrv/ -o codepage=850,iocharset=utf8
    montando l'immagine ottenuta, questa volta riuscimo a leggere tutti i file presenti. Per una corretta visualizzazione dei nomi dei file è stato necessario specificare le opzioni
      codepage=850,iocharset=utf8
    poiché le operazioni sono state svolte su di una linuxbox che usa UNICODE come charset di default.
Fonti
Partition-Rescue HOWTO
Per una occhiata veloce sul problema.
"Invalid or incomplete multibyte or wide character" Issue
Mi ha ispirato per inserire le opzioni di mount relative al set di caratteri.

Powered by ScribeFire

2 commenti:

  1. Certo, i danni constatati sono sostanzialmente di tipo logico, ma mi permetto di parlare di danno hardware in quanto la riscrittura sulle pennette in esame mi è risultata sempre impossibile (anche una successiva formattazione terminava con un fallimento); nondimeno il danno hardware deve essere limitato. Per questo motivo, oltre che per non compromettere ulteriormente il dispositivo, tutte le operazioni sono effettuate su di una copia dei dati trascritti in un file su disco.

    RispondiElimina
  2. Sono d'accordo sul considerare i vari danni hardware come diceva appunto @TuxmAL. Va detto che molto spesso quando c'è un guasto (di tipo elettrico intendo) la pen drive non è più funzionante e quindi non è in grado di comunicare con il PC. Ne consegue che qualsiasi operazione effettuata con metodi software non avrà alcun effetto. Il metodo descritto è certamente validissimo quando c'è un danneggiamento di tipo "logico" quindi la pen drive funziona ancora ma non si può accedere ai dati. Per casi di danneggiamenti invece derivati da urti, shock elettrici o guasti ai componenti non c'è altra soluzione che un approccio diretto sull'hardware. Le ditte specializzate in recupero dati infatti utilizzano strumentazioni che consentono di lavorare direttamente sui chip di memoria . Si può trovare qualche informazione in proposito (in italiano) qui www.sosdati.it

    RispondiElimina