Jump to content

Is there any way to recover a partition after writing zeros with WD DL


Recommended Posts

Hmmm.

Very strange.

The $MFT is by default at sector (786432*8+sectorsbefore)=min 6,291,456 + "x"

If you are at 18,805,000 it's no good, as it would mean that "x " is 18,805,000-6,291,456=12,513,544 which should mean roughly a 6 Gb hidden partition ( that you don't recall).

Are you sure you are looking for the right string?

In HEX it should be:

46494C4530

Try another thing.

Get dmde:

http://softdm.com/

Try scanning the image for NTFS volumes with it.

jaclaz

Ya thats strange it was just 1 big partition (all 298 GiB). how can that be.

Tiny hexer now at sector 20107300 after 23 Hours (cancel it man and try with 46494C4530 in hex value? ).

Yes was looking for sector 6291400 in Decimal and start the search to the word FILE0 (with search for text & dos 8 bits options).

Here are the sector 6291400:

tiny hexer at 6291400

Il try dmde now (that is matter that this soft is shareware for our purposes?)

Update - dmde now on 30% and found 5 entries

Edited by energydream2007
Link to comment
Share on other sites


Ya thats strange it was just 1 big partition (all 298 GiB). how can that be.

Tiny hexer now at sector 20107300 after 23 Hours (cancel it man and try with 46494C4530 in hex value? ).

Yep, at this point it seems like it's not going to find anything or anything of value.

Il try dmde now (that is matter that this soft is shareware for our purposes?)

No prob, the "Free" version is allright for our scope, the Commercial adds features to recover files in batches/groups and "whole" directories:

Free Edition: all disk editor and data recovery features except for folder and group recovery (file recovery only);

Full Edition features also file group and folder recovery (recovers directory tree);

But for us it is at the moment just an alternative to search for the $MFT.

jaclaz

Link to comment
Share on other sites

DMDE Results:

VERY good. :thumbup

Select/highlight in top section "NTFS 0" and click on "Open Volume".

It seems that the $MFT has been foind (though size seems "wrong")

You should have a view similar to the one attached.

Post a screenshot of it.

In the view I posted you can see that the $MFT starts on sector 6291519, which is allright for me as I have 63 sectors before.

From the other view, (the one you already posted) you can see that the probable start sector is 2048 (which makes sense if it was partitioned under Vista).

You can also try clicking (on the new view you created by "Open Volume" to click on the + near $Root and see if you can recognize some files/directories.

jaclaz

post-25215-0-73241900-1293369898_thumb.j

Link to comment
Share on other sites

DMDE Results:

VERY good. :thumbup

Select/highlight in top section "NTFS 0" and click on "Open Volume".

It seems that the $MFT has been foind (though size seems "wrong")

You should have a view similar to the one attached.

Post a screenshot of it.

In the view I posted you can see that the $MFT starts on sector 6291519, which is allright for me as I have 63 sectors before.

From the other view, (the one you already posted) you can see that the probable start sector is 2048 (which makes sense if it was partitioned under Vista).

You can also try clicking (on the new view you created by "Open Volume" to click on the + near $Root and see if you can recognize some files/directories.

jaclaz

Here:

DMDE NTFS0

The $Root contains nothing (as the $MetaData). all the files are in $MFT dir and i do recognize them.

how to proceed man?

Link to comment
Share on other sites

The $Root contains nothing (as the $MetaData). all the files are in $MFT dir and i do recognize them.

how to proceed man?

Problem is that from the view you posted the $MFT seems corrupted. :unsure:

Try clicking on $MFT on the left, then on any folder and inside the folder try recovering a single (smallish) file. (BE CAREFUL as to use a folder on ANOTHER drive as target for the recovered file).

I am wondering what the heck can have hapened. :unsure:

Can you right click on the actual image you made and choose Properties (and post screenshot)?

I have some doubts about the TinyHexer screenshots you posted. :unsure:

How big is the image you have (in bytes)?

jaclaz

Edited by jaclaz
Link to comment
Share on other sites

The $Root contains nothing (as the $MetaData). all the files are in $MFT dir and i do recognize them.

how to proceed man?

Problem is that from the view you posted the $MFT seems corrupted. :unsure:

Try clicking on $MFT on the left, then on any folder and inside the folder try recovering a single (smallish) file. (BE CAREFUL as to use a folder on ANOTHER drive as target for the recovered file).

I am wondering what the heck can have hapened. :unsure:

Can you right click on the actual image you made and choose Properties (and post screenshot)?

I have some doubts about the TinyHexer screenshots you posted. :unsure:

How big is the image you have (in bytes)?

jaclaz

Well the recover of the file (mp3) was ok and the file is ok.

I did suspected the image iv created (using getdataback) and already deleted it before saw this post :rolleyes:

But created a new one with DrDD and scan for NTFS using DMDE:

New DMDE serch results using new Image by DrDD

and the new open volume results:

New open volume

And here is the properties of the new image of DrDD:

Properties (don mind the language)

In bytes the size is: 320,070,320,640 / 320,070,324,224 (as presented in the window posted).

About tiny hexer - tell me if to scan the new image and how proceed in our process tnx man

Edited by energydream2007
Link to comment
Share on other sites

I really don't know. :unsure:

What you posted says:

  • that the partition started at 2048 <- which as said makes a lot of sense if the Volume was partitioned under Vista
  • that the $MFT should be at sector 6293504 <-which matches default values and the 2048 start
  • BUT the $MFT view is different from a "good" $MFT <- which also justifies why Tiny Hexer cannot see the initial "FILE0" of the $MFT
  • AND anyway *somehow* dmde can "see" your old files.

If you can make a copy of the image, I can prepare a "fake" pre-formatted image and we can try replacing (on the COPY, NOT on the "original" image) the first and last million sectors from the "fake image".

This way you should be able to analize the modified COPY of the image in TESTDISK and/or mount it in a Virtual disk and attempt running chkdsk on it.

Another option may be (it depends on how much data you need to recover) to continue using dmde "manually" - one file at the time - or consider buying a license for it, for non-commercial uses it is 16 Euros.

jaclaz

Link to comment
Share on other sites

I really don't know. :unsure:

What you posted says:

  • that the partition started at 2048 <- which as said makes a lot of sense if the Volume was partitioned under Vista
  • that the $MFT should be at sector 6293504 <-which matches default values and the 2048 start
  • BUT the $MFT view is different from a "good" $MFT <- which also justifies why Tiny Hexer cannot see the initial "FILE0" of the $MFT
  • AND anyway *somehow* dmde can "see" your old files.

If you can make a copy of the image, I can prepare a "fake" pre-formatted image and we can try replacing (on the COPY, NOT on the "original" image) the first and last million sectors from the "fake image".

This way you should be able to analize the modified COPY of the image in TESTDISK and/or mount it in a Virtual disk and attempt running chkdsk on it.

Another option may be (it depends on how much data you need to recover) to continue using dmde "manually" - one file at the time - or consider buying a license for it, for non-commercial uses it is 16 Euros.

jaclaz

Weird. about DMDE - i dont have a problem to buy it but the files he showing to me is almost exactly as any recovery soft showing me to recover (witch is always between 11 to 27GB) - and offcourse its nowhere near the capacity iv used - (almost all the drive)

about "fake" pre-formatted image plan - yes im now making a copy of the image (witch will take some time casue its on caviar green slow drive).

p.s. - TestDisk see just physical disks no?.

p.s - can i mount the DrDD image with DaemonTools and such?

What to do now? (or just wait for the copy image to created and then proceed) :rolleyes:

Link to comment
Share on other sites

p.s. - TestDisk see just physical disks no?.

p.s - can i mount the DrDD image with DaemonTools and such?

No, testdisk can operate on images allright, only your current image has no meaningful data for testdisk (no MBR, no PBR, no PBR mirror)

Of course NOT with Daemon tools.

But there are virtual disk drivers, even for x64, only cannot say how complex would it be to install them on Windows 7 64 bit.

There are 64 bit builds of VDK.EXE (recommended) and of IMDISK (not recommended right now as it only mounts the volume and NOT the \\.\PhysicalDrive)

Best place to get the known to be working VDK 64 bit driver is within this package (evolution of mbrbatch for XP x64 - won't probably work as is on 7 - the driver should):

http://reboot.pro/5000/

http://reboot.pro/5000/page__st__5

just the driver:

http://oss.netfarm.it/win32/

What to do now? (or just wait for the copy image to created and then proceed) :rolleyes:

See if you get the hang of the VDK and of the thread in the meantime.

jaclaz

P.S.: Here are the two chunks of the "fake" image.

WARNING you will need 7-zip to uncompress the archives inside the .zip and they will uncompress to 512 Mb each.

The image has been partitioned/formatted under XP, but it shouldn't make any difference, for TESTDISK or other similar apps.

You can use dsfi/dsfo (part of the dsfok toolkit) - it should work allright under Windows 7 64, download from:

http://members.ozemail.com.au/~nulifetv/freezip/freeware/

syntax is quite straight:

dsfi <your path>\image[0-512000000].dd 0 0 <your COPY of the image>
dsfi <your path>\image[319558320640-320070320640].dd 319558320640 0 <your COPY of the image>

fake_image_chunks.zip

Edited by jaclaz
Link to comment
Share on other sites

OK iv downloaded and extracted the fake images and the dsfok. (man 6kb to 976MB thats some super compression :thumbup )

I guess that after im altering the copy image with the new sectors through dsfi commands i need to mount it with VDK? (well il take step by step and then will talk about vdk :rolleyes: ).

1st i need to wait 7 minutes to the copy of the image to be complete. (tnx for all the help man :yes: )

Update - the 1st dsfi command is at 175000MB and keep going

that was the command:

dsfi w:\New\fake_image_chunks\image[0-512000000]\image[0-512000000].dd 0 0 w:\DDimage\3200AAKS_Copy.dd

Update - 1st dsfi command completed:

post-302585-0-94026200-1293422334_thumb.

Now starting the 2nd dsfi command witch is:

dsfi w:\New\fake_image_chunks\image[319558320640-320070320640]\image[319558320640-320070320640].dd 319558320640 0 w:\DDimage\3200AAKS_Copy.dd

2nd command as completed:

post-302585-0-39451000-1293436873_thumb.

P.S - i can see that the fake images as been expanded as the result of those commands (0-512000000 to 298GB & 319558320640-320070320640 to 595.7GB)

Waiting for VDK instructions (or the proper next step) :thumbup

Edited by energydream2007
Link to comment
Share on other sites

No :(, my bad, I posted WRONG dsfi command (mixed source with destination) :blushing:

image[0-512000000].dd should be exactly 512,000,000 bytes.

as well

image[319558320640-320070320640].dd should be exactly 512,000,000 bytes.

Your image w:\DDimage\3200AAKS_Copy.dd should be 320,070,320,640 bytes in size.

The RIGHT commands are:

dsfi <destination> <offset> <size> <source>

Thus:

dsfi w:\DDimage\3200AAKS_Copy.dd 0 0  w:\New\fake_image_chunks\image[0-512000000]\image[0-512000000].dd 

dsfi  w:\DDimage\3200AAKS_Copy.dd 319558320640 0  w:\New\fake_image_chunks\image[319558320640-320070320640]\image[319558320640-320070320640].dd

Due to the mistake, the first one made w:\New\fake_image_chunks\image[0-512000000]\image[0-512000000].dd a copy of w:\DDimage\3200AAKS_Copy.dd , and the second one appended your image at the end of a BIG file (the fake image + a lot of blank sectors).

Sorry for the mishap.

The good news are that w:\DDimage\3200AAKS_Copy.dd was left "untouched".

Delete both the HUGE, modified w:\New\fake_image_chunks\image[0-512000000]\image[0-512000000].dd and w:\New\fake_image_chunks\image[319558320640-320070320640]\image[319558320640-320070320640].dd.

And re-do (with the corrected commands) starting again from the files inside the .zip/.7z.

The result of the two commands should be the w:\DDimage\3200AAKS_Copy.dd still remaining the same 320,070,320,640 bytes in size, but with the first and last 1,000,000 sectors (512,000,000 bytes) replaced by the contents of the "fake image chunks".

I would wait for a moment with VDK, try first what happens with TESTDISK.

to open the image with testdisk open a command prompt in the testdisk directory and in it type:

testdisk_win /log w:\DDimage\3200AAKS_Copy.dd 

jaclaz

Link to comment
Share on other sites

No :(, my bad, I posted WRONG dsfi command (mixed source with destination) :blushing:

image[0-512000000].dd should be exactly 512,000,000 bytes.

as well

image[319558320640-320070320640].dd should be exactly 512,000,000 bytes.

Your image w:\DDimage\3200AAKS_Copy.dd should be 320,070,320,640 bytes in size.

The RIGHT commands are:

dsfi <destination> <offset> <size> <source>

Thus:

dsfi w:\DDimage\3200AAKS_Copy.dd 0 0  w:\New\fake_image_chunks\image[0-512000000]\image[0-512000000].dd 

dsfi  w:\DDimage\3200AAKS_Copy.dd 319558320640 0  w:\New\fake_image_chunks\image[319558320640-320070320640]\image[319558320640-320070320640].dd

Due to the mistake, the first one made w:\New\fake_image_chunks\image[0-512000000]\image[0-512000000].dd a copy of w:\DDimage\3200AAKS_Copy.dd , and the second one appended your image at the end of a BIG file (the fake image + a lot of blank sectors).

Sorry for the mishap.

The good news are that w:\DDimage\3200AAKS_Copy.dd was left "untouched".

Delete both the HUGE, modified w:\New\fake_image_chunks\image[0-512000000]\image[0-512000000].dd and w:\New\fake_image_chunks\image[319558320640-320070320640]\image[319558320640-320070320640].dd.

And re-do (with the corrected commands) starting again from the files inside the .zip/.7z.

The result of the two commands should be the w:\DDimage\3200AAKS_Copy.dd still remaining the same 320,070,320,640 bytes in size, but with the first and last 1,000,000 sectors (512,000,000 bytes) replaced by the contents of the "fake image chunks".

I would wait for a moment with VDK, try first what happens with TESTDISK.

to open the image with testdisk open a command prompt in the testdisk directory and in it type:

testdisk_win /log w:\DDimage\3200AAKS_Copy.dd 

jaclaz

OK Il delete the modified ones and run the new fixed commands + try with testdisk command

Il update soon :hello:

Update - i ran the fixed commands and now run the testdisk command witch seems to find lost partiton man:

post-302585-0-52032200-1293478579_thumb.

iv chosen the backup to a log file option witch gives me the next window that im not sure what is the proper step:

post-302585-0-49681200-1293478959_thumb.

Waiting for your instructions :hello:

Edited by energydream2007
Link to comment
Share on other sites

Just press "P" on the last screenshot, as in:

P: list files

But I don't think you will get anything meaningful. :(

I thought a bit over the matter and it seems to me like two things are possible:

  1. the partition was NTFS formatted using a "strange" program that puts the $MFT in the first (or last) million sectors (and that have then been wiped by the WD tool) :unsure:
  2. the WD tool does something "more" than just wiping the first and last million sectors :ph34r:

If the "P" doesn't let you see any file (or no more file than dmde did), the next logical step would be to attempt a file-based recovery (please read as PhotoRec):

http://www.cgsecurity.org/wiki/PhotoRec

The "quality and amount" of recovered files can vary greatly with very low percentages for heavily fragmented volumes and high ones for not fragmented ones - but you will have anyway to open each recovered file and re-name it.

jaclaz

Link to comment
Share on other sites

Just press "P" on the last screenshot, as in:

P: list files

But I don't think you will get anything meaningful. :(

I thought a bit over the matter and it seems to me like two things are possible:

  1. the partition was NTFS formatted using a "strange" program that puts the $MFT in the first (or last) million sectors (and that have then been wiped by the WD tool) :unsure:
  2. the WD tool does something "more" than just wiping the first and last million sectors :ph34r:

If the "P" doesn't let you see any file (or no more file than dmde did), the next logical step would be to attempt a file-based recovery (please read as PhotoRec):

http://www.cgsecurity.org/wiki/PhotoRec

The "quality and amount" of recovered files can vary greatly with very low percentages for heavily fragmented volumes and high ones for not fragmented ones - but you will have anyway to open each recovered file and re-name it.

jaclaz

Ya man i cant see any files when pressing P. i thought that PhotoRec is just for pics but im running it now and it see alot more extensions.

man i really wanted to recover the whole partition - file based just not going to do the job.

what more options do i have? il do anything to recover just tell me what do you think. :rolleyes:

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...