mboost-dp1

Recovery af data fra formateret disk


Gå til bund
Gravatar #1 - inckie
28. maj 2014 02:32
Jeg har noget data på en harddisk (disk image) som er blevet quick formattet fra NTFS til ext4

Pt. har jeg dog kun adgang til et image oprettet med TestDisk af harddisken.

Dataen jeg forsøger at genskabe lå oprindeligt op en NTFS partition på harddisken, herefter er der så oprettet et ext4 filsystem oven på ved en fejltagelse efter skift fra Windows til Linux.

Personen der har gjort det, mener at han kun har fortaget en "quick format", samt at han ikke har gemt data på disken efterfølgende.

Er der nogle der har erfaringer med recover af data i sådanne tilfælde?

De programmer jeg har prøvet ser ud til at være lidt forvirret over ntfs/ext4 "problem stillingen" eller også er det bare mig der bruger dem forkert.
Gravatar #2 - kinaholm
28. maj 2014 05:47
GetDataBack for NTFS burde kunne gøre det.
Jeg har i al fald, med succes, brugt det flere gange på NTFS partitioner.

Ellers kan KasperD sikkert komme med et godt bud, hvis det ikke virker ;)
Gravatar #3 - IT-ekspert Kejser
28. maj 2014 08:22
#1 som #2 skriver så kan du bruge GetDataBack for NTFS - har selv prøvet den da jeg kom til at lave en disk jeg havde liggende klar til en synology NAS mens jeg stadig havde data på.

Den går ind og kigger på indholdet af disken og finder f.eks. NTFS partitioner selvom de ikke er i MBR.

Og ellers så hør kasperd
Gravatar #4 - inckie
28. maj 2014 16:13
GetDataBack finder heller ikke noget

Så har jeg prøvet med:

R-Studio (finder kun ext4)
TestDisk/Photorec (Finder slet ikke ikke noget)

Det er ikke mig der har lavet det image af disken.

men det er lavet ved hjælp af TestDisk, som vidst nok bare bruger dd

hvis man blot dd'er partitionen altså i dette tilfælde /dev/sdb1 fremfor /dev/sdb vil man så få data med der har ligget på NTFS partition der er blevet fjernet?

Gravatar #5 - Hubert
28. maj 2014 17:51
#4

Hvis du dd'er en disk vil du få alt data med der er på disken. Du laver en 1:1 kopi af disken med dd. Noget tyder på at man har lavet lidt mere end en quick format
Gravatar #6 - kasperd
28. maj 2014 21:22
kinaholm (2) skrev:
Ellers kan KasperD sikkert komme med et godt bud, hvis det ikke virker
IT-ekspert Kejser (3) skrev:
Og ellers så hør kasperd
Jeg ved ikke ret meget om NTFS. Men lidt viden om partitionering, ext4 og data recovery kan jeg nok bidrage med.

inckie (4) skrev:
hvis man blot dd'er partitionen altså i dette tilfælde /dev/sdb1 fremfor /dev/sdb vil man så få data med der har ligget på NTFS partition der er blevet fjernet?
Det kommer an på hvordan partitionstabellen har set ud. Jeg gætter på at partitionstabellen er blevet lavet om før der blev formatteret som ext4.

Hubert (5) skrev:
Noget tyder på at man har lavet lidt mere end en quick format
En ændring af paritionstabellen lyder sandsynligt. Men det vil jo ikke skrive ret mange sektorer til disken.

Jeg kan sige så meget at mkfs.ext3 som default ikke skriver til samtlige sektorer på disken, men kun til dem der nu engang skal indeholde metadata på et ext3 filsystem. Og det har næppe ændret sig med ext4. De fleste af de sektorer der bliver skrevet til med mkfs.ext3 bliver faktisk blot fyldt med nuller (om det så er en brugbar oplysning i den her sammenhæng skal jeg ikke kunne sige).

Jeg har et par bud på, hvad man kan gøre for at give recovery programmerne en bedre chance for at genskabe NTFS filsystemet. Man skal for det første finde ud af præcist hvor på disken NTFS partitionen har startet. For selv hvis samtlige data er intakt er det ikke nemt at læse et filsystem som ikke ligger på det offset man tror det gør. For det andet kan man lave et image af disken, hvori man så skriver nuller til alle de sektorer, der indeholder ext4 metadata. Så sikrer man i hvert fald at recovery programmerne ikke bliver forvirret af ext4 dataene.

Kan vi ikke lige få et hexdump af de første 512 bytes af imaget?
Gravatar #7 - inckie
28. maj 2014 22:06
kimse@kimse-laptop-linux ~ $ dd if=/media/kimse/TOSHIBA\ EXT/Recovered/image_remaining.dd bs=512 count=1 | hexdump -C
1+0 records in
1+0 records out
512 bytes (512 B) copied, 0.000165427 s, 3.1 MB/s
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000200
kimse@kimse-laptop-linux ~ $

Gravatar #8 - Hubert
29. maj 2014 09:49
kasperd (6) skrev:
En ændring af paritionstabellen lyder sandsynligt. Men det vil jo ikke skrive ret mange sektorer til disken.


Med mindre man har valgt at lave en generelt overskrivning af disken that is. Men jeg kender absolut intet til, hvad der sker når man ændrer fil systemet på en disk. Det var ikke et emne, der var dækket i mit forensics kursus.
Gravatar #9 - kasperd
29. maj 2014 12:46
inckie (7) skrev:
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000200
kimse@kimse-laptop-linux ~ $
Det var ikke ret meget vi fik ud af det. Lad os prøve at få lidt mere. Prøv denne kommando i stedet
hexdump < /media/kimse/TOSHIBA\ EXT/Recovered/image_remaining.dd | head -42
Hvis du kan få fat i et image af hele disken og ikke bare den ene partition, så vil det gøre opgaven lettere. Hvor stor er disken, du prøver at rede data fra?
Gravatar #10 - inckie
30. maj 2014 05:48
kasperd skrev:
Hvor stor er disken, du prøver at rede data fra?


Mener det er en 120GB SSD disk.

Hvilket også passer meget godt med størrelsen af imaget

kimse@kimse-laptop-linux ~ $ du -h /media/kimse/TOSHIBA\ EXT/Recovered/image_remaining.dd
120G /media/kimse/TOSHIBA EXT/Recovered/image_remaining.dd


kasperd skrev:
Det var ikke ret meget vi fik ud af det. Lad os prøve at få lidt mere. Prøv denne kommando i stedet


Den gav lidt mere, har gemt outputtet i en fil og krypteret med GPG http://gupl.dk/710860/

nøglen er sendt i et PM
Gravatar #11 - kasperd
30. maj 2014 09:27
inckie (10) skrev:
Den gav lidt mere, har gemt outputtet i en fil og krypteret med GPG http://gupl.dk/710860/
Image filen indeholder et 119GB ext4 filsystem. De første 512 bytes af ext4 filsystemet mangler. Så i første omgang var der ingen af standard værktøjerne, der ville kendes ved den. Men da jeg opdagede at der blot manglede 512 bytes kunne jeg få værktøjer til at håndtere den ved at sætte nuller ind foran.

Hvis opgaven var at rede data fra ext4 filsystemet, så ville det ikke være noget problem at mangle de første 512 bytes, for ext{2,3,4} reserverer de første 1024 bytes til boot sector.

Men hvis vi skal forstå hvad der er gået galt og hvor vi evt. kan finde nogen data at rede fra NTFS filsystemet, så har vi brug for oplysninger om partitionstabellen. Så det vil altså stadigvæk være en fordel at få et image af hele disken.
Gravatar #12 - Hubert
30. maj 2014 09:39
http://www.ntfsrecoverysoftware.com/restore-partit... kunne måske være et bud på et værktøj der kan bruges.
Gravatar #13 - snesman
10. jun. 2014 08:57
kinaholm (2) skrev:

Ellers kan KasperD sikkert komme med et godt bud, hvis det ikke virker ;)


Jeg har hørt at kasperd kan læse sådan en disk med det blotte øje!
Gravatar #14 - kasperd
10. jun. 2014 11:19
snesman (13) skrev:
Jeg har hørt at kasperd kan læse sådan en disk med det blotte øje!
Hvis man gav mig et hexdump af et FAT filsystem kunne jeg nok fortælle hvilke filnavne der fandtes i roden blot ved at kigge på det. Men ligefrem at læse disken uden noget elektronik tror jeg ikke, jeg ville kunne klare.

Men hvis du pinger mig over RFC 1149 kan jeg godt svare uden brug af elektronik. (Dog kun hvis du snakker IPv6, det er IPv4 stads er en tand for besværligt til at gøre uden elektronik.)
Gravatar #15 - snesman
10. jun. 2014 11:58
Sådan går det når man laver en kasperd-joke.
Touché
Gå til top

Opret dig som bruger i dag

Det er gratis, og du binder dig ikke til noget.

Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.

Opret Bruger Login