Sign in to follow this  
Followers 0
onlit4regs

still no partition on Seagate after successful unbrick

63 posts in this topic

so, I have tried DMDE on the original hard drive, It couldn't display the directory/file structure , it was so long on "reading MFT", more than 4 days to complete only 3% !! so I aborted

I am confused by your reports:

softdm shows me all the files and directories of my hard drive, but trying to recover a dozen of files results with unreadable files. :angry:

Were you previously using dmde to look at the $MFT of the "image" you made?

If yes, that image - even if partial - actually holds a seemingly valid $MFT.

You can try the following:

  1. open the (partial) image with dmde
  2. check in it's directory structure the names of the fiiles you most value
  3. try using this tool getFileExtents
    http://www.wd-3.com/archive/luserland.htm
    to understand the location of the files (one by one) and/or of the various fragments of them
  4. try imaging just the relevant sectors found above with ddrescue from the original disk to new files
  5. re-assemble the new files into the "original" ones

If this strategy works, you will be able to get just the "strictly needed" files in a smaller time.

jaclaz

0

Share this post


Link to post
Share on other sites

I can't get "getfileextents" to work

should I use it on my hard drive or on my image ?

how to tell it to search on the drive or image ? parameter seems to be only the filename

thanks

0

Share this post


Link to post
Share on other sites

I can't get "getfileextents" to work

should I use it on my hard drive or on my image ?

how to tell it to search on the drive or image ? parameter seems to be only the filename

thanks

On the image (I mean if the dmde can access the $MFT entries of the image, as I seem to understand, asked you but had no specific answer about).

The image must be mounted to a drive letter (using a virtual disk driver) in order to let getfilextents work. <- Sorry :blushing: I omitted this piece of info.

Possibly the most easy to use one (and "good enough" for the task) could be IMDISK:

http://www.ltr-data.se/opencode.html/

http://reboot.pro/forum/59/

See if it can mount the image to a drive letter.

jaclaz

0

Share this post


Link to post
Share on other sites

yes dmde has no problem seeing the directory/file structure on the image file, I see all my favorite files.

I've mounted it with IMDisk, with default parameters of size of virtual disk, etc. It showed a new letter, but impossible to browse this letter ! (no filesystem type indicated in IMDisk, and windows can't see the size of partition, file or directory unreable or corrupted ...) :realmad:

so, can't get fileextents to work on it too.

??

thanks

0

Share this post


Link to post
Share on other sites

yes dmde has no problem seeing the directory/file structure on the image file, I see all my favorite files.

Good. :)

I've mounted it with IMDisk, with default parameters of size of virtual disk, etc. It showed a new letter, but impossible to browse this letter ! (no filesystem type indicated in IMDisk, and windows can't see the size of partition, file or directory unreable or corrupted ...) :realmad:

so, can't get fileextents to work on it too.

Wait a minute, are you still using the "resulting" image as ddrescue created it, or did you "grow" it to it's full size (creating a new file with mksparse and dd-ing to it the image)?

jaclaz

0

Share this post


Link to post
Share on other sites

I'm working with the "grown" image (mkparse + dd-ing) - 500go

I should test dmde or IMDisk with the small image made by Drdd ?

0

Share this post


Link to post
Share on other sites

I'm working with the "grown" image (mkparse + dd-ing) - 500go

I should test dmde or IMDisk with the small image made by Drdd ?

The grown image, the NTFS filesystem driver is likely to throw errors on a "less-than-declared-size" one.

The "grown" image should mount, the only issue being (hopefully) the backup of the bootsector, which shouldn't be checked by the NTFS filesystem driver when mounting :unsure:.

It is very possible that - for any reason - the partial image that you have is not an image of the first 134 or so Gb of the original hard disk (and consequently the "grown" image is "invalid") or that somehow the $MFT is "misplaced" in the "grown" image or that - again for *any* reason the making of the sparse file or the dd-ing to it of the partial image produced an invalid image.

How EXACTLY did you create the "grown" image?

Please list EXACTLY, in DETAIL, EACH and EVERY step you performed to make that image.

jaclaz

0

Share this post


Link to post
Share on other sites

hi Jaclaz,

I was so busy the last days that I completly forgot my hard drive issue ! :blushing:

so, here is what I've done for this grown image:

- datarescuedd the faulty drive in a single image of all sectors (with a lot of reading errors)

- mksparse <path>\my500GB.img 500105281536

- dsfi <path>\my500GB.img 0 0 <path>\thewhatever136GB.img

thanks a lot

0

Share this post


Link to post
Share on other sites

I was so busy the last days that I completly forgot my hard drive issue ! :blushing:

so, here is what I've done for this grown image:

- datarescuedd the faulty drive in a single image of all sectors (with a lot of reading errors)

- mksparse <path>\my500GB.img 500105281536

- dsfi <path>\my500GB.img 0 0 <path>\thewhatever136GB.img

Good. :thumbup

And if you access this "my500GB.img" with dmde you can actually see the $MFT, but if you try opening/mounting it with IMDISK you have issues (like being prompted to format it and/or in the IMDISK control panel NOT seeing NTFS as "filesystem")?

Do I get this right?

If yes, you can try the following, using TESTDISK on the "my500GB.img" as follows:

TESTDISK <path>\my500GB.img

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

be sure to choose to Create a log, follow the above and post the log and a description of what it says on screen (since the disk was originally partitioned on XP, do reply "No" to the question about it having been partitioned under Vista as it should speed up things).

It is also possible that (for any reason) the IMDISK (which works at a "somewhat higher level" than other virtual drivers) have different kinds of issues with the image, it is possible that *somehow* it fails to detect the offset to the partition (BTW are you prompted to choose an offset when mounting the image?), another thing you may want to try is (on XP, NOT on 7) the VDK driver:

https://sites.google.com/site/chitchatvmback/vdk

optionally using my pseudo-GUI for it:

http://jaclaz.altervista.org/Projects/VDM/vdm.html

BUT better if creating a .pln file for it, by hand :w00t: or using the little batch here:

http://www.forensicfocus.com/Forums/viewtopic/t=1489/postdays=0/postorder=asc/start=42/

Can you confirm that the first sector of the "my500GB.img" is identical to the MBR sector you initially posted? :unsure:

(Would it be possible that you got the MBR and PBR "right" with hdhacker form the "original disk" and that somehow when you made the image either of them is not there/is corrupted?)

jaclaz

Edited by jaclaz
0

Share this post


Link to post
Share on other sites

And if you access this "my500GB.img" with dmde you can actually see the $MFT, but if you try opening/mounting it with IMDISK you have issues (like being prompted to format it and/or in the IMDISK control panel NOT seeing NTFS as "filesystem")?

Do I get this right?

absolutly !

If yes, you can try the following, using TESTDISK on the "my500GB.img" as follows:

TESTDISK <path>\my500GB.img

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

be sure to choose to Create a log, follow the above and post the log and a description of what it says on screen (since the disk was originally partitioned on XP, do reply "No" to the question about it having been partitioned under Vista as it should speed up things).

testdisk have seen the NTFS partition of 500Go, said structure OK.

when pressing "P", there is only one directory displayed, and when entering it, it's empty ....

It is also possible that (for any reason) the IMDISK (which works at a "somewhat higher level" than other virtual drivers) have different kinds of issues with the image, it is possible that *somehow* it fails to detect the offset to the partition (BTW are you prompted to choose an offset when mounting the image?)

offset is automatically set at 63 blocks when I select my500gb.img

another thing you may want to try is (on XP, NOT on 7) the VDK driver:

Can you confirm that the first sector of the "my500GB.img" is identical to the MBR sector you initially posted? :unsure:

vdk driver did the same thing as IMDISK: mount partition, but when trying to access on windows: "this drive must be formatted" :angry:

yes MBR is the same

thanks for your help

0

Share this post


Link to post
Share on other sites

The only explanation that I can find is that *somehow* your initial attempt (post #1) with TESTDISK produced a "wrong" MBR and/or PBR.

The standard NT NTFS drivers finds *something* wrong and decides that the volume needs to be formatted.

Dmde more or less "ignores" them, analyzes the filesystem, finds the "real" $MFT and thus lists all your files "as they were". (then some may be there and some may be in the missing part and thus unavailable).

TESTDISK finds the (wrong) values it initially wrote and reads an "empy" $MFT.

Dmde is not very "easy", let's see if I can guide you into checking the data. :unsure:

Once you have loaded the $MFT (open Dmde, choose the image, search for NTFS), you should have on the left pane [All Found], if you expand it clicking on the + sign, it should read the $MFT and show everything that has been found.

Besides each file or directoryyou should have again a + sign.

Double click a directory (where you know one suitable file should be), the contents of the directory should appear on the right top pane.

Choose a (small) file of which you know the beginning of the contents (like a text file or a small program or a zip file), ideally use for the test something that belongs to the original XP install (and that thus it is likely to be in the first 134 Gb).

In the lower pane you should see the hex dump of first sector of the file (if it is there, if it is not, try with another file that you can "recognize the beginning" and that "is there") and, in the first line something *like*:

LBA:89021727 vol.sec:89021664 clus:11127708 sec:0

The LBA value is the absolute address of that sector, the vol.sec is the relative address within the volume.

Do post these values.

How much is LBA-vol.sec?

i.e.: 89021727-89021664=63 in the above example.

This would confirm that he volume starts at offset 63.

How much is vol.sec/clus?

i.e. 89021664/11127708=8

This would confirm that cluster size is 8 sectors.

Then, do something "crazy" :w00t: make a new backup of both the MBR and of the PBR (better have another copy), then open the image in tiny hexer and:

  • access the MBR sector and fill it with 00's
  • access the PBR sector and fill it with 00's

Run again Dmde on the image with the 00ed MBR and PBR and see if the results on the same file are the same as before.

jaclaz

0

Share this post


Link to post
Share on other sites

hi Jaclaz,

here are the values:

LBA : 6292581

vol.sec: 6292518

clus: 786564

so, that's offset 63 as you supposed

about the last operation you asked, I have made new backup of First boot sector of logical drive and first sector of physical drive with HDHACKER (so it saved 2 files) , and then filled them with 0, and then what to do with those 2 files ?

thanks a lot

0

Share this post


Link to post
Share on other sites

hi Jaclaz,

here are the values:

LBA : 6292581

vol.sec: 6292518

clus: 786564

so, that's offset 63 as you supposed

Yep, the begin offset is 63 allright but those data do not make much sense.

They are not the actual data related to a file, those correspond to entry #531 in the $MFT, possibly the $MFT entry for that file, according to the data till now gathered.

In the "upper right" pane right click on the file name, you will have a set of choices, right now you seem like having chosen "Open MFT file (hex Editor)", while you want to choose the bolded "Open (Hex Editor)".

Can you see in the lower right pane the beginning of the file?

If yes, you will also see the LBA, vol.sec, Cluster and sec. of the actual file.

Is this file recoverable?

about the last operation you asked, I have made new backup of First boot sector of logical drive and first sector of physical drive with HDHACKER (so it saved 2 files) , and then filled them with 0, and then what to do with those 2 files ?

Save them somewhere for the moment.

The strange thing is that you seemingly have valid data in both the MBR and the PBR, the $MFT is apparently there allright, as seen by dmde, but the filesystem driver fails to mount the volume (both through Imdisk and VDK). :unsure:

I am confused.

Try another thing before anything else (on the "my500GB.img").

Open it with DMDE, does it show a window titled "Partitions - dmde 2.4.4"?

Can you see two entries in it, the first one being:

Image:<path>\my500GB.img etc.

and the second:

<label> Primary (A) NTFS (07) 500 GB EBCF 63 <some number>

?

If yes, if you select the second the "Open Volume" button should become enabled, press it.

A new popup should appear, titled "Open NTFS volume" with some data (post this data).

Then press "Open" button.

This way DMDE is using the data coming from the MBR and PBR (and not the results of the NTFS search).

In the lower right pane you should see (first line):

LBA:6291519 vol.sec 6291456 Clus:786432 sec.0 (MFT 0)

If you open again the image, and this time you choose instead "NTFS Search" (start it and wait until "NTFS 0" appears, then press "start/stop") and then select the "NTFS0" and click on the "Open volume" you should get the same:

In the lower right pane you should see (first line):

LBA:6291519 vol.sec 6291456 Clus:786432 sec.0 (MFT 0)

If this is what happens, I am wondering what prevents the NTFS mounting with both IMDISK and VDK. :w00t:

jaclaz

0

Share this post


Link to post
Share on other sites

Yep, the begin offset is 63 allright but those data do not make much sense.

They are not the actual data related to a file, those correspond to entry #531 in the $MFT, possibly the $MFT entry for that file, according to the data till now gathered.

In the "upper right" pane right click on the file name, you will have a set of choices, right now you seem like having chosen "Open MFT file (hex Editor)", while you want to choose the bolded "Open (Hex Editor)".

Can you see in the lower right pane the beginning of the file?

If yes, you will also see the LBA, vol.sec, Cluster and sec. of the actual file.

Is this file recoverable?

hi,

I've done the OPEN (Hex Editor) last time, and I've seen the beginning of the file on the lower right pane. This small text file was recovered with success :yes: (but not interesting for me !)

the values I've given yesterday were from this file.

Try another thing before anything else (on the "my500GB.img").

Open it with DMDE, does it show a window titled "Partitions - dmde 2.4.4"?

Can you see two entries in it, the first one being:

Image:<path>\my500GB.img etc.

and the second:

<label> Primary (A) NTFS (07) 500 GB EBCF 63 <some number>

?

If yes, if you select the second the "Open Volume" button should become enabled, press it.

A new popup should appear, titled "Open NTFS volume" with some data (post this data).

values are:

Bytes per sector:512

Bytes per cluster:4096

Bytes per MFT record:1024

Bytes per index record:4096

Total sectors number: 976768002

MFT cluster (or 0): 786432

MFTMirr cluster (or 0): 61048000

Start Offset: 32256

when I click open , I've a choice:

Volume does not fit into device:

Use this virtual volume size (this is what I've selected)

or

Use decreased volume size

the values from first line are, as you've said:

LBA:6291519 vol.sec 6291456 Clus:786432 sec.0 (MFT 0)

If you open again the image, and this time you choose instead "NTFS Search" (start it and wait until "NTFS 0" appears, then press "start/stop") and then select the "NTFS0" and click on the "Open volume" you should get the same:

In the lower right pane you should see (first line):

LBA:6291519 vol.sec 6291456 Clus:786432 sec.0 (MFT 0)

If this is what happens, I am wondering what prevents the NTFS mounting with both IMDISK and VDK. :w00t:

yes it's the same values on first line

thanks for your help

0

Share this post


Link to post
Share on other sites

when I click open , I've a choice:

Volume does not fit into device:

Use this virtual volume size (this is what I've selected)

or

Use decreased volume size

This is the whole point. :yes:

The total sectors in the structure is

Total sectors number: 976768002

hence the filesystem expects to have:

(976768002+1+63)=976768066*512=500105249792

but the image you reported making is LARGER than that (so the volume should "fit" :unsure: ):

- mksparse <path>\my500GB.img 500105281536:

Can you check (right click in explorer and select properties or do a DIR in a command window) the EXACT size of the image ?

Possibly (and for *any* reason) it is actually smaller than the previously stated.

jaclaz

Edited by jaclaz
0

Share this post


Link to post
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
Sign in to follow this  
Followers 0

  • Recently Browsing   0 members

    No registered users viewing this page.