[onlit4regs]

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

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

[jaclaz]

onlit4regs, on 14 September 2012 - 08:51 AM, said:

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 .

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

[onlit4regs]

hi Jaclaz,

I was so busy the last days that I completly forgot my hard drive issue !
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

[jaclaz]

onlit4regs, on 07 October 2012 - 11:29 AM, said:

I was so busy the last days that I completly forgot my hard drive issue !
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.
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.cgsecurit...sk_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...tchatvmback/vdk
optionally using my pseudo-GUI for it:
http://jaclaz.alterv...ts/VDM/vdm.html
BUT better if creating a .pln file for it, by hand or using the little batch here:
http://www.forensicf...r=asc/start=42/

Can you confirm that the first sector of the "my500GB.img" is identical to the MBR sector you initially posted?
(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

This post has been edited by jaclaz: 07 October 2012 - 12:10 PM

[onlit4regs]

jaclaz, on 07 October 2012 - 12:09 PM, said:

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 !

jaclaz said:

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

TESTDISK <path>\my500GB.img

http://www.cgsecurit...sk_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 ....

jaclaz said:

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

jaclaz said:

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?

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

yes MBR is the same
thanks for your help

[jaclaz]

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.
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*:

Quote

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" 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

[onlit4regs]

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

[jaclaz]

onlit4regs, on 04 November 2012 - 08:27 AM, said:

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?

onlit4regs, on 04 November 2012 - 08:27 AM, said:

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).

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:

Quote

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.

jaclaz

[onlit4regs]

jaclaz said:

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 (but not interesting for me !)
the values I've given yesterday were from this file.

jaclaz said:

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)

jaclaz said:

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:

Quote

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.

yes it's the same values on first line
thanks for your help

[jaclaz]

onlit4regs, on 05 November 2012 - 01:16 PM, said:

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.

The total sectors in the structure is

Quote

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" ):

Quote

- 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

This post has been edited by jaclaz: 05 November 2012 - 02:03 PM

[onlit4regs]

size of image is 500 105 217 024 bytes

[jaclaz]

onlit4regs, on 05 November 2012 - 02:54 PM, said:

size of image is 500 105 217 024 bytes

HOW can this have happened?
You posted:

onlit4regs, on 07 October 2012 - 11:29 AM, said:

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

re-do, this time make sure that the resulting sparse image is actually 500105281536 or slightly more than that.

jaclaz

This post has been edited by jaclaz: 06 November 2012 - 04:39 AM

[onlit4regs]

don't know why the size was wrong.
I've redone it, it's now clearly 500 105 281 536 bytes
I've passed again testdisk on it, with same results as before: can see only one directory, and content is empty.
I've tried to mount with IMDisk this new made image my500GB.img, and still same result:

onlit4regs, on 14 September 2012 - 05:16 AM, said:

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 ...)
so, can't get fileextents to work on it too.

??
thanks

[jaclaz]

onlit4regs, on 07 November 2012 - 12:34 AM, said:

don't know why the size was wrong.
I've redone it, it's now clearly 500 105 281 536 bytes
I've passed again testdisk on it, with same results as before: can see only one directory, and content is empty.
I've tried to mount with IMDisk this new made image my500GB.img, and still same result:

But you can still open it in DMDE , this time being NOT propmpted with:

Quote

Volume does not fit into device:
Use this virtual volume size (this is what I've selected)
or
Use decreased volume size

and see the $MFT contents with it?

Since (the good thing is) that the image is a "copy", we can play a bit with it.
What happens if you mount it in IMDISK , open a command prompt and run in it:

CHKDSK F:

(provided that the drive letter assigned by IMDISK is F:, of course)?

But BEFORE that, can you check it again in TESTDISK, and do three things:

• do a log of the session
  
• check/verify/fix the $MFT Mirror
  
• post the actual log

jaclaz

[onlit4regs]

jaclaz, on 07 November 2012 - 04:15 AM, said:

But you can still open it in DMDE , this time being NOT propmpted with:

Quote

Volume does not fit into device:
Use this virtual volume size (this is what I've selected)
or
Use decreased volume size

and see the $MFT contents with it?

yes, there is no more prompted message
on the lower right pane, I can see "FILE:$MFT" with all information about $FILE_NAME, $DATA,$BITMAP, ....

Quote

But BEFORE that, can you check it again in TESTDISK, and do three things:

• do a log of the session
  
• check/verify/fix the $MFT Mirror
  
• post the actual log

jaclaz

under testdisk, I've just searched for partition, display files (only display one empty directory) and that's all
I've attached the log
did you want other actions in testdisk ? I don't understand which action you mean on checklist #2
thanks

Attached File(s)

•  testdisk.log.txt (2.24K)
  Number of downloads: 3

[jaclaz]

onlit4regs, on 07 November 2012 - 11:54 AM, said:

under testdisk, I've just searched for partition, display files (only display one empty directory) and that's all
I've attached the log
did you want other actions in testdisk ? I don't understand which action you mean on checklist #2
thanks

You see, in the log there is:

Quote

NTFS filesystem need to be repaired.

ntfs_readdir failed

Now we do know (from the PBR/bootsector) that the $MFT mirror is on cluster 61048000, i.e. 61048000*4096=250052608000 (given or taken the few sectors before) i.e. around 250 Gb, i.e. well beyond your "good" 134 Gb, so in practice thre is NO $MFT mirror.

Actually - on a "normal" image it should be there (in the worst case) as all 00's BUT you have a sparse 500Gb image, so the $MFT Mirror actually doesn't exist at all. (I hope I make some sense to you now, a sector in a sparse file does not exist until something actually performs an operation on that sector).

This may be connected (or may be not) with the Windows IFS driver incapable to recognize the NTFS volume (error you have in IMDISK) and with the TESTDISK log (though it may be only PART of the issue).

The idea is to first thing use TESTDISK to create a new $MFTMirror from the actual $MFT, see here:
http://www.cgsecurit..._and_MFT_Repair

Quote

Repair An NTFS MFT

The MFT (Master File Table) is sometimes corrupted. If Microsoft's Checkdisk (chkdsk) failed to repair the MFT, run TestDisk. In the Advanced menu, select your NTFS partition, choose Boot, then Repair MFT. TestDisk will compare the MFT and MFT mirror (its backup). If the MFT is damaged, it will try to repair the MFT using the backup. If the MFT backup is damaged, it will use the main MFT.

before attempting running CHKDSK.

jaclaz

[onlit4regs]

I've done testdisk, Advanced Menu, Boot, and then Org.BS
it wrotes backup sector with the original sector
then I've made "Repair MFT", it wrotes the Mirror MFT with original MFT

I have the same problem mounting with IMDriver, no success under windows explorer

should I run a chkdsk now ?
thanks

[jaclaz]

onlit4regs, on 07 November 2012 - 01:50 PM, said:

should I run a chkdsk now ?

Yes.
Run it at first without parameters, then - again - with /F parameter and then - again - with the /R parameter.
Let's see what happens.

jaclaz

[onlit4regs]

ok, first checkdisk without parameters returns a lot of messages like this one (sorry it's translated from french):
errors corrected in index $I30 of file 42062
....
index verification terminated
errors found. chkdsk can not continue in read only mode

Then, with /F, a lot of messages like this:
errors corrected in index $I30 of file 41863
Sort of index $I30 of file 41863
Restore of orphaned file xxxx.xxx (1198) in file of directory 49
Insert of index entry with ID 311 in index $SDH of file 9
Fix of record segment of security file
...
Errors corrected in miror of MFT
Errors corrected in "capslock" file
errors corrected in bitmap attribute of MFT
errors corrected in volume map

and finally with /F /R:
everything was ok

Then, I can see the directory and files under windows !!
but of course, still unable to read the dozen of files I'm interested in.
should I give a try with the extents now ? (from your procedure in a previous post)
thanks a lot

[jaclaz]

onlit4regs, on 08 November 2012 - 12:46 AM, said:

Then, I can see the directory and files under windows !!
but of course, still unable to read the dozen of files I'm interested in.
should I give a try with the extents now ? (from your procedure in a previous post)
thanks a lot

Yep :

You may want to redirect the output of running getfileextents to a file, so that you have a list of the offsets (it would be a good idea to later use a spreadsheet to make a list of them.
A simple batch may be of use (make a directory C:\GFE\ and save this as GFE.CMD :

@ECHO OFF
SETLOCAL ENABLEDELAYEDEXPANSION
Set File=%~dpnx1
ECHO FOffset: LBA:     Sectors: File	
FOR /F "tokens=3,5,7 delims=: " %%A IN ('getFileExtents.exe "%File%"') DO (
CALL :octify Foffset %%A
CALL :octify LBA %%B
CALL :octify Sectors %%C
ECHO !Foffset! !LBA! !Sectors! %File%
ECHO !Foffset! !LBA! !Sectors! %File%>>gfelog.log
)
ECHO.>>gfelog.log
GOTO :EOF

:octify
SET %1=0000000%2
SET %1=!%1:~-8,8!
GOTO :EOF

depending on the spreadsheet and local settings you use, you can replace the spaces in the line:

ECHO !Foffset! !LBA! !Sectors! %File%>>gfelog.log

with either [TAB] or [COMMA] or [SEMICOLON]

jaclaz

Edit: Typo in the batch. "Good" version attached (just in case)
Edit2: Added as attachment gfedec.zip, that directly outputs decimal data instead of Hex

Attached File(s)

•  gfe.zip (406bytes)
  Number of downloads: 2
•  gfedec.zip (856bytes)
  Number of downloads: 3

This post has been edited by jaclaz: 08 November 2012 - 06:48 AM