• Announcements

    • xper

      MSFN Sponsorship and AdBlockers!   07/10/2016

      Dear members, MSFN is made available via subscriptions, donations and advertising revenue. The use of ad-blocking software hurts the site. Please disable ad-blocking software or set an exception for MSFN. Alternatively, become a site sponsor and ads will be disabled automatically and by subscribing you get other sponsor benefits.
Sign in to follow this  
Followers 0
onlit4regs

still no partition on Seagate after successful unbrick

63 posts in this topic

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

size of image is 500 105 217 024 bytes

HOW can this have happened?

You posted:

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

Edited by jaclaz
0

Share this post


Link to post
Share on other sites

:blink:

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:

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

:blink:

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:

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:

  1. do a log of the session
  2. check/verify/fix the $MFT Mirror
  3. post the actual log

jaclaz

0

Share this post


Link to post
Share on other sites

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

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

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

  1. do a log of the session
  2. check/verify/fix the $MFT Mirror
  3. 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

testdisk.log.txt

0

Share this post


Link to post
Share on other sites

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:

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.cgsecurity.org/wiki/Advanced_NTFS_Boot_and_MFT_Repair

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

0

Share this post


Link to post
Share on other sites

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

0

Share this post


Link to post
Share on other sites

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

jaclaz

0

Share this post


Link to post
Share on other sites

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 !! :thumbup

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

0

Share this post


Link to post
Share on other sites

Then, I can see the directory and files under windows !! :thumbup

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 :thumbup:

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

gfe.zip

gfedec.zip

Edited by jaclaz
0

Share this post


Link to post
Share on other sites

sorry, but how to use your batch ?

gfe.cmd driverletter: ??

thanks

0

Share this post


Link to post
Share on other sites

sorry, but how to use your batch ?

gfe.cmd driverletter: ??

thanks

No, you need to provide the full path to the target file.

If you want to know the extents of file (say) F:\my_path\my_file.ext, you would normally run:

GetFileExtents.exe F:\my_path\my_file.ext

hence:

gfe.cmd F:\my_path\my_file.ext

or

gfedec.cmd F:\my_path\my_file.ext

jaclaz

0

Share this post


Link to post
Share on other sites

GetFileExtents always returns me this error:

initFileTranslation: invalid descriptor

(even when I try on the file that was recoverable)

:huh:

0

Share this post


Link to post
Share on other sites

GetFileExtents always returns me this error:

initFileTranslation: invalid descriptor

(even when I try on the file that was recoverable)

:huh:

Hmmm. :unsure:

Try it on a file on another volume (a "good" one, with a working filesystem).

For very small files it won't work as they are stored directly in the $MFT, but it should otherwise work (I don't think that there are issues with the "sparse" nature of the underlying file, as it is mounted in IMDISK, you could try using a different mounting tool/driver, but it shouldn't actually matter).

Try another tool.

Get myfragmenter:

http://www.mydefrag.com/SeeAlso-MyFragmenter.html

(part of mydefrag):

http://www.mydefrag.com/Manual-DownloadAndInstall.html

make SURE to use it with the -i switch, i.e.

myfragmenter.exe -i F:\my_path\my_file.ext

What happens?

Also please, when posting the result of a command, post also the EXACT way you invoked it (command line), you did not specify how you invoked GetFileExtents, it could be that you invoked it wrongly (in the sense of having given it a non existing path or whatever)...

jaclaz

0

Share this post


Link to post
Share on other sites

so, the command I used was:

getfileextents F:\myfile.txt

and always get the same error: initFileTranslation: invalid descriptor

on a "good" partition, it worked ! no problem. It's only with the mounted image that cause problems.

with myfragmenter, I have more results:

MyFragmenter.exe -i f:\montage\2011-tmp.pds

MyFragmenter v1.2, 2008 J.C. Kessels

Commandline argument '-i' accepted.

Processing: f:\montage\2011-tmp.pds

Fragment list:

Extent 1: Lcn=495625, Vcn=0, NextVcn=2

Extent 2: Lcn=28135076, Vcn=2, NextVcn=4

Extent 3: Lcn=48751063, Vcn=4, NextVcn=8

Extent 4: Lcn=48797290, Vcn=8, NextVcn=16

Extent 5: Lcn=50038742, Vcn=16, NextVcn=32

Extent 6: Lcn=26068714, Vcn=32, NextVcn=48

Extent 7: Lcn=94098378, Vcn=48, NextVcn=65

Extent 8: Lcn=74619826, Vcn=65, NextVcn=80

Extent 9: Lcn=95440487, Vcn=80, NextVcn=99

Extent 10: Lcn=106615323, Vcn=99, NextVcn=112

Extent 11: Lcn=95441871, Vcn=112, NextVcn=131

Extent 12: Lcn=48579698, Vcn=131, NextVcn=134

134 clusters, 12 fragments.

Finished, 1 files processed.

what do you suggest for next step ? :yes:

thanks a lot

0

Share this post


Link to post
Share on other sites

with myfragmenter, I have more results:

MyFragmenter.exe -i f:\montage\2011-tmp.pds

MyFragmenter v1.2, 2008 J.C. Kessels

Commandline argument '-i' accepted.

Processing: f:\montage\2011-tmp.pds

Fragment list:

Extent 1: Lcn=495625, Vcn=0, NextVcn=2

Extent 2: Lcn=28135076, Vcn=2, NextVcn=4

Extent 3: Lcn=48751063, Vcn=4, NextVcn=8

Extent 4: Lcn=48797290, Vcn=8, NextVcn=16

Extent 5: Lcn=50038742, Vcn=16, NextVcn=32

Extent 6: Lcn=26068714, Vcn=32, NextVcn=48

Extent 7: Lcn=94098378, Vcn=48, NextVcn=65

Extent 8: Lcn=74619826, Vcn=65, NextVcn=80

Extent 9: Lcn=95440487, Vcn=80, NextVcn=99

Extent 10: Lcn=106615323, Vcn=99, NextVcn=112

Extent 11: Lcn=95441871, Vcn=112, NextVcn=131

Extent 12: Lcn=48579698, Vcn=131, NextVcn=134

134 clusters, 12 fragments.

Finished, 1 files processed.

Good. :)

what do you suggest for next step ? :yes:

thanks a lot

Try using the attached batch.

The output of myfragmenter is expressed in Logical Cluster Number (relative to the Volume) and Virtual Cluster numbers (relative to the file).

The batch converts (or attempts to :w00t:) those in "plain" "absolute" (i.e. relative to the disk) LBA addreses and Sectors lengths of the chunks or extents.

The settings:

Set InitialLBA=63

Set clusterSize=8

are already set in the batch for the disk values you have.

jaclaz

myfragi.zip

0

Share this post


Link to post
Share on other sites

here we go with your magic batch ! :thumbup

Ext: Lcn: LBAstart: Sects: File:

1 495625 3965063 16 f:\montage\2011-tmp.pds

2 28135076 225080671 16 f:\montage\2011-tmp.pds

3 48751063 390008567 32 f:\montage\2011-tmp.pds

4 48797290 390378383 64 f:\montage\2011-tmp.pds

5 50038742 400309999 128 f:\montage\2011-tmp.pds

6 26068714 208549775 128 f:\montage\2011-tmp.pds

7 94098378 752787087 136 f:\montage\2011-tmp.pds

8 74619826 596958671 120 f:\montage\2011-tmp.pds

9 95440487 763523959 152 f:\montage\2011-tmp.pds

10 106615323 852922647 104 f:\montage\2011-tmp.pds

11 95441871 763535031 152 f:\montage\2011-tmp.pds

12 48579698 388637647 24 f:\montage\2011-tmp.pds

0

Share this post


Link to post
Share on other sites

here we go with your magic batch ! :thumbup

Ext: Lcn: LBAstart: Sects: File:

1 495625 3965063 16 f:\montage\2011-tmp.pds

2 28135076 225080671 16 f:\montage\2011-tmp.pds

3 48751063 390008567 32 f:\montage\2011-tmp.pds

4 48797290 390378383 64 f:\montage\2011-tmp.pds

5 50038742 400309999 128 f:\montage\2011-tmp.pds

6 26068714 208549775 128 f:\montage\2011-tmp.pds

7 94098378 752787087 136 f:\montage\2011-tmp.pds

8 74619826 596958671 120 f:\montage\2011-tmp.pds

9 95440487 763523959 152 f:\montage\2011-tmp.pds

10 106615323 852922647 104 f:\montage\2011-tmp.pds

11 95441871 763535031 152 f:\montage\2011-tmp.pds

12 48579698 388637647 24 f:\montage\2011-tmp.pds

Good, now you should be able to put (copy and paste or, better import) the contents of the .log into a spreadsheet.

In theory you have a "good" or almost good 134 Gb image, so anything (roughly, you will have to make the math exactly) before:

134 GB=~134*1024*1024*1024=143881404416/512=LBA 2766950084

should be already on your image, so in the spreadsheet you order by LBA address and get the chunks that are missing.

Now there is the usual doubt about which strategy to use to get the missing data.

Basically there are two theories - no way to know which one may give you "better" results, depending on the actual issue one or the oher may work better, or both could work the same, or both could fail:

  1. theory of "little by little" <- you just try to get the chunk that you need
  2. theory of "greater area" <- you try to get an area of the orignal disk larger than the chunk(s) you need, and then you re-parse this to get the exact chunks

Theory #1 is based on the hypothesis that the head going to a given place is more exact" than "passing by", theory #2 is based ont the opposite hypothesys.

Of course on a disk that has no issues both would work perfectly, but you never know, additionally datarescuedd has also an option to get sectors in "reverse reading", which sometimes helps.

The BAD news :( are that seemingly, and though fragmented, that particular file seems like being entirely within he first 134 Gb :ph34r: .

Which could mean that your image already contains some corruprted sector :unsure:

Try getting all single chunks from the original disk with datarescueDD.

Once you have extracted (hopefully) all 12 "chunks", you can re-assemble them by using COPY +, but it is usually more convenient using some od the tools in DSFOK toolkit:

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

If you sum the sizes of the chunks in the spreadsheet you get 1072 sectors, i.e. 1072*512=548864 which should also be the size of the file that you see in Explorer or in DIR...

So you do:

fsz C:\mytemp.dat 548864

This will create an empty file of that size in bytes.

Then you use:

dsfi C:\mytemp.dat <offset> 0 <filechunk.dd> 

which means copy to C:\mytemp.dat, starting from offset <offset> for all it's length (0) the <filechunk.dd> where offset is the offset in BYTEs of the filechunk and the <fileschunk> is the name of the file extracted with datarescuedd, the first chunk with your data should be image[2030112256-2030120448].dd (where obviously 2030112256 is made by the LBA offset*512=3965063*512=2030112256 and 2030120448 is the offset+the length, i.e. 3965063*512+16*512=2030120448)

The use of a spreadsheet is advised as it will produce the exact command lines faster and without the risk of typing errors.

jaclaz

0

Share this post


Link to post
Share on other sites
fsz C:\mytemp.dat 548864

This will create an empty file of that size in bytes.

Then you use:

dsfi C:\mytemp.dat <offset> 0 <filechunk.dd> 

which means copy to C:\mytemp.dat, starting from offset <offset> for all it's length (0) the <filechunk.dd> where offset is the offset in BYTEs of the filechunk and the <fileschunk> is the name of the file extracted with datarescuedd, the first chunk with your data should be image[2030112256-2030120448].dd (where obviously 2030112256 is made by the LBA offset*512=3965063*512=2030112256 and 2030120448 is the offset+the length, i.e. 3965063*512+16*512=2030120448)

The use of a spreadsheet is advised as it will produce the exact command lines faster and without the risk of typing errors.

jaclaz

ok, just to be sure I understand the offset in the dsfi command, for the second chunk, I'll have to use:

dsfi c:\mytemp.dat 8192 0 filechunk2.dd

(16*512 = 8192)

is that right ?

thank a lot

0

Share this post


Link to post
Share on other sites

ok, just to be sure I understand the offset in the dsfi command, for the second chunk, I'll have to use:

dsfi c:\mytemp.dat 8192 0 filechunk2.dd

(16*512 = 8192)

is that right ?

thank a lot

Yep :)

The spreadsheet could look something *like*:

By LBA	Ext:	 Lcn:	 	 LBAstart:	 Sects:	File:	 	 	 Limit:	 	 ROffset:  ROffsetB:
#1 1 495.625 3.965.063 16 f:\montage\2011-tmp.pds 2.766.950.084 - -
#3 2 28.135.076 225.080.671 16 f:\montage\2011-tmp.pds 2.766.950.084 16 8.192
#5 3 48.751.063 390.008.567 32 f:\montage\2011-tmp.pds 2.766.950.084 32 16.384
#6 4 48.797.290 390.378.383 64 f:\montage\2011-tmp.pds 2.766.950.084 64 32.768
#7 5 50.038.742 400.309.999 128 f:\montage\2011-tmp.pds 2.766.950.084 128 65.536
#2 6 26.068.714 208.549.775 128 f:\montage\2011-tmp.pds 2.766.950.084 256 131.072
#9 7 94.098.378 752.787.087 136 f:\montage\2011-tmp.pds 2.766.950.084 384 196.608
#8 8 74.619.826 596.958.671 120 f:\montage\2011-tmp.pds 2.766.950.084 520 266.240
#10 9 95.440.487 763.523.959 152 f:\montage\2011-tmp.pds 2.766.950.084 640 327.680
#12 10 106.615.323 852.922.647 104 f:\montage\2011-tmp.pds 2.766.950.084 792 405.504
#11 11 95.441.871 763.535.031 152 f:\montage\2011-tmp.pds 2.766.950.084 896 458.752
#4 12 48.579.698 388.637.647 24 f:\montage\2011-tmp.pds 2.766.950.084 1.048 536.576

where Roffset= Sects+Previous ROffset and ROffsetB=ROffset*512

The "0" means "copy the whole size" of the following "chunk", you could use instead the exact size of the chunk in bytes, but it only makes more complex the command, i.e. it could be:

dsfi c:\mytemp.dat 8192 0 filechunk2.dd
dsfi c:\mytemp.dat 8192 8192 filechunk2.dd

(by coincidence the second chunk is actually 16 sectors i.e. 8192 bytes in size)

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.