[jaclaz]

mattiasnyc, on 22 August 2012 - 09:34 AM, said:

So right now it's at 9%, which means I have another week to go. I really wish there was another way...

To reiterate: Trying to recover the data on the source drive (that failed and was unbricked) is playing with fire, right? So that's why I should prefer to use a clone...?

and

What type of risk are we talking if I start working on the source instead? Is it dependent on the operation I perform on it or is it something else at play?

Let's open a few scenarios:

• the unbricked drive is 100% (or 99.99%) functional (percentage of "good" data) and the only issue is a single sector that was corrupted/wiped/whatever
  
• the unbricked drive is (say) 55.32% functional and the remaining 44.68% cannot be recovered in any way
  
• the unbricked drive is (say) 55.32% functional BUT the remaining 44.68% can be read/imaged BUT NOT fixed (made accessible) while still on the same drive
  
• in any of the above, the recovering procedure introduces some "fixes", and either by mistake or by "wrong suggestion/approach" (or by bad luck/Murphy's Law) these "fixes" may cause a chain reaction that deletes (or anyway makes not anymore recoverable) more data
  
• in any of the above cases, since the drive has "bricked" itself at least once before, AND we don't know the exact reason why this happened there are MORE probabilities that it will re-brick itself soon, AND, since the unbricking wasn't actually really entirely successful - which could BTW mean that the cure for a "specific" illness by pure luck temporarily and partially cured the actual different unknown illsness the drive suffers from - we have NO idea if a further UNbricking will be possible at all .

Obviously if you are in case 1. or 2. having an image is only a precaution and not really *needed* (whilst anyway advised).
If you are in case 3. making an image/clone starts to make more sense.
BUT since cases 4. and 5. apply to ALL the previous ones the idea of making an image/clone starts to look like a really *needed* step....

Mind you Murphy's Law could well apply to the actual cloning procedure or to the "target" drive that while you are imaginfg to it - for any reason - decides to brick itself (or right after you have concluded the imaging)....
...and it is also possible that the drive has only a total of (say) three hours of life left which could be used more usefully in attempting to recover selected key data instead of "wasting" them cloning an area of the disk that contains unneeded data.....

The imaging/cloning procedure is the "standard" one as it has been the one (normally) being the less risky, but there aren't guarantees on any kind that it will work "better" than a "direct recovery" attempt or that it will work at all, if the cloning works, at least you have a "second chance", nothing more.

Decisions, decisions always decisions.....

While the disk cloning is running you should be able to start getting a few "key" sectors from both the source and the target drive, not knowing the specific software you are now running I cannot swear it will be possible but it should (i.e. the disks should not be "locked").
If you could get by using HDhacker:
http://dimio.altervista.org/eng/
the MBR (first sector of the \\.\PhysicalDrive)
or alternatively use the rawcopy as mentioned earlier:
http://www.msfn.org/...ost__p__1007536
Actually if you could get with the rawcopy the first 100 sectors of the disks (both source and target disk) by using:

Quote

rawcopy 51200 \\.\PhysicalDriven C:\driven.bin

(twice once for the target and once for the source) we could have already have some data to look at and also have a way to verify that the cloning is working (at least for the initial 100 sectors)
But again it is difficult to say , though UNprobable, it is possible that performing this action may somehow "disturb" the ongoing cloning....

jaclaz

[mattiasnyc]

I have now cloned my unbricked drive.

What would my next move be?

[jaclaz]

mattiasnyc, on 03 September 2012 - 08:03 PM, said:

I have now cloned my unbricked drive.

What would my next move be?

See what is the issue (on the clone).
Make a copy of the basic sectors the MBR and the PBR.
The MBR is "easy", it is the first sector of the disk, CHS 0/0/1 or LBA 0.
A suitable tool to make a copy of it is HDhacker:
http://dimio.altervista.org/eng/
you want the first sector of the \\PhysicalDriven
or you can use the mentioned rawcopy:

rawcopy 512 \\.\PhysicalDrive1 C:\drive1.bin

To get the right n try having a look at the disk in "disk management". If you have only a disk in your PC, it will be PhysicalDrive0 and the "clone" you attach to it will be PhysicalDrive1.
While you are at it, can you see the Partitions(s)/Volume(s) in it? (LogicalDrive(s)).
If yes, you need a copy also of the first sector of it (them), but since you are running 7, that sector may be locked.
If this is the case, you might want to try this other software CLONEDISK:
http://reboot.pro/8480/
http://labalec.fr/erwan/?page_id=42
or a tool to dismount the drive(s)/Partition(s)/Volume(s):
http://reboot.pro/12413/
and then use direct disk access (rawcopy, etc.) to copy the PBR(s).

Once you have the MBR and the PBR(s) copies compress them in a .zip file and attach them to your next post.
If you have difficulties in getting the PBR's attach just the MBR and I will give you more detailed instructions on how to get the PBR(s).

AFTER having got these copies, you can start TESTDIDK following this guide:
http://www.cgsecurit...sk_Step_By_Step
You WANT a log file.
If the disk was parittioned under VIsta or 7 you want to answer "Y" to the questions if irt should look for Partitions created under Vista.
If you are lucky, the procedure might fix the issue.

Report.

jaclaz

[mattiasnyc]

Hi,

here's the latest update of what I've done;

The clone was "Disk 2" and shows up as one contiguous block in "Disk Management" and reads "Unallocated".

HDHacker read teh first sector and gives the following readable "text" message:

"Invalid partition table. Error loading operating system. Missing operating system", plus a bunch of other stuff.




mbr attached...

Attached File(s)

•  MBR_HardDisk2.7z (500bytes)
  Number of downloads: 3

This post has been edited by mattiasnyc: 30 October 2012 - 04:02 PM

[mattiasnyc]

For the record, I'm not sure I fully comprehend the procedure in getting the PBR (unless it stands for Pabst Blue Ribbon, in which case I know how to but just don't want to).

Would it be unwise to move along to the next step with only a copy of the MBR and NOT the PBR?

[jaclaz]

mattiasnyc, on 30 October 2012 - 04:07 PM, said:

For the record, I'm not sure I fully comprehend the procedure in getting the PBR (unless it stands for Pabst Blue Ribbon, in which case I know how to but just don't want to).

Would it be unwise to move along to the next step with only a copy of the MBR and NOT the PBR?

Well, in your particular case you simply "cannot" (in the sense of "easily") get the PBR.

The MBR you just posted is partially corrupted, hence the disk manager cannot find any LogicalDrive (the PBR is first sector of the LogicalDrive) on the disk/image and HDhacker simply doesnt know which sector to get.

For whatever reasons, the Partition Tables in the MBR you posted are completely 00ed out.

At first sight the MBR CODE is seemingly that of 2K/XP.

You can try running Testdisk (remember to use the /log) since the original disk seems like having being partitioned under XP, reply N (No) to the question if the disk was partitioned under Vista.
Report BEFORE telling Testdisk to write anythng.

jaclaz

[mattiasnyc]

Thanks jaclaz,

I will try Testdisk today. Does it take hours to do its thing or is it a matter of minutes? (I have to work from home today because of the hurricane)

[jaclaz]

mattiasnyc, on 31 October 2012 - 05:59 AM, said:

Thanks jaclaz,

I will try Testdisk today. Does it take hours to do its thing or is it a matter of minutes? (I have to work from home today because of the hurricane)

The initial detection (if any is found ) of the PBR/bootsector should take a few seconds.

If no bootsector is found where it normally is (sector 63 on XP - if I recall correctly it was just a single "huge" partiton) it may take much longer as it will have to scan the whole disk, on a perfectly functional SATA II 500 Gb disk I would say less than one hour, though, for the whole scan.

jaclaz

[mattiasnyc]

jaclaz, on 31 October 2012 - 06:08 AM, said:

The initial detection (if any is found ) of the PBR/bootsector should take a few seconds.

If no bootsector is found where it normally is (sector 63 on XP - if I recall correctly it was just a single "huge" partiton) it may take much longer as it will have to scan the whole disk, on a perfectly functional SATA II 500 Gb disk I would say less than one hour, though, for the whole scan.

jaclaz

I will try this and NOT write anything until I've posted results here. One more thing:

jaclaz, on 31 October 2012 - 04:25 AM, said:

You can try running Testdisk (remember to use the /log) since the original disk seems like having being partitioned under XP,

What do you refer to when you say "use the /log"? That particular sign/word ("/log") doesn't appear on the "testdisk step by step" guide page.

[jaclaz]

mattiasnyc, on 31 October 2012 - 06:48 AM, said:

What do you refer to when you say "use the /log"? That particular sign/word ("/log") doesn't appear on the "testdisk step by step" guide page.

I am more used to work on command line, it is simply faster, open a command prompt, navigate to the directory where TESTDISK is, type on command line

testdisk_win.exe /log

press [ENTER]

If you double click on testdisk_win.exe you will anyway be prompted to do that:
http://www.cgsecurit...ep#Log_creation
you want to Create a log.

jaclaz

[mattiasnyc]

I've now run test disk through the "Quick Search" function and it has found no partitions at all. My options at the bottom of the screen are:

"Keys A: add partition, L: load backup, Enter: to continue"

please advise, and thanks for all your time and help!

[jaclaz]

mattiasnyc, on 01 November 2012 - 09:44 AM, said:

I've now run test disk through the "Quick Search" function and it has found no partitions at all. My options at the bottom of the screen are:

"Keys A: add partition, L: load backup, Enter: to continue"

please advise, and thanks for all your time and help!

"Keys A: add partition, L: load backup, Enter: to continue"

You are between:
http://www.cgsecurit..._for_partitions
and:
http://www.cgsecurit...e_partitions.3F
i.e. since "Quick Search" failed, you want to do a "Deep Search".

jaclaz

[mattiasnyc]

Thanks. Can you tell I'm a noob at this?

It's at 12%. I will report back.

[mattiasnyc]

Done. Still nothing. Same options; add partition, load backup or enter to continue...

[jaclaz]

mattiasnyc, on 01 November 2012 - 01:39 PM, said:

Done. Still nothing. Same options; add partition, load backup or enter to continue...

Hmmm.
It sounds like there are no traces that TESTDISK can find, which is unusual.

Get DMDE:
http://softdm.com/

And try opening the disk with it (Drive->Select Drive->choose the PhysicalDrive->NTFS search).
And report (post a screenshot)
If one (or more) NTFS volume(s) are found, you can access them by selecting and "Open Volume".

Another thing, you should try to get (and post in an archive) the first 100 sectors as detailed in
http://www.msfn.org/...dd/page__st__20

so that I can have a look at them.

jaclaz

[mattiasnyc]

Thanks. I've attached HDhacker again, sectors 1 through 16 as that's all it took in one go.

The DMDE result is pretty much zeroes in general and an NTFS search of the first 5GB shows nothing. I didn't really have time for anything else right now, but I'll try to do more in a by this evening.

Attached File(s)

•  Sector_1through16.7z (542bytes)
  Number of downloads: 2

[jaclaz]

Yes, hdhacker gets at the most 16 sectors, you need to use dsfo or a dd of some kind to get the 100 sectors.
A "normal" NTFS volume has it's $MFT starting at cluster 786432, i.e. at 786432*4096=3,221,225,472 or around 3 Gb give or take a few sectors (sectors before) on the first partition.

Of the sectors you posted, only the first is non-zero (this is normal) and it does contain a MBR code but NO MBR data (all 4 partition entries are 00's or wiped"), it is identical (obviously) to the one you already posted.

This is most uncommon , as it seems like NOT the result of a "random" corruption, but rather of an "intentional" wiping of just the partition table .

Additionally you have two bytes at 0X1BC that are normally 0000 (unused) set instead to A025, but this could be *something* related to XP64 or a "flag" placed there for *any* reason by almost *anything*.

Were you - by any chance and at *any* step - prompted to "initialize" the disk (in disk management or explorer)?
(a just "initialized" disk does have the "right" MBR code but NO MBR partition data)

jaclaz

[mattiasnyc]

jaclaz, on 05 November 2012 - 01:09 PM, said:

Yes, hdhacker gets at the most 16 sectors, you need to use dsfo or a dd of some kind to get the 100 sectors.
A "normal" NTFS volume has it's $MFT starting at cluster 786432, i.e. at 786432*4096=3,221,225,472 or around 3 Gb give or take a few sectors (sectors before) on the first partition.

The above are two different things, right? The first addressing the first 16 sectors and the second talking about where the NTFS "lives", right? So I'm looking at re-running one of the tests over the whole drive to cover where NTFS "lives", and re-running the other test with dsfo or dd. Right?

jaclaz, on 05 November 2012 - 01:09 PM, said:

Were you - by any chance and at *any* step - prompted to "initialize" the disk (in disk management or explorer)?
(a just "initialized" disk does have the "right" MBR code but NO MBR partition data)

jaclaz

I'll have to get back to this later this evening, but "no", I was not prompted to "initialize" and I do not recall having changed the source or clone drives in any way (meaning their partitions). One day the darn thing wouldn't spin, that's all. The only thing I can think of is if I some how screwed up the de-bricking of the source (as far as me being the culprit is concerned).

I'll come back later with more info.

[jaclaz]

mattiasnyc, on 05 November 2012 - 01:25 PM, said:

The above are two different things, right? The first addressing the first 16 sectors and the second talking about where the NTFS "lives", right?

Yes.

I do not want 16 sectors (because I already know how in the best cases there is only one meaningful sector in the first 16 sectors - the MBR - which I already have), I want to have a look at the first 100 sectors because they will contain sector 63 and the following 16 sectors (up to 95) that may be non-zero.
If when the disk was originally partitioned the new Vista and later "partitioning paradigm" has taken place, I will need instead first 2100 sectors.

If you prefer by providing 16 sectors instead of the asked for 100 you didn't fulfill my request at a 16% rate, but rather at a 0% rate (or at the most at a 1% one) and I need it anyway fulfilled at 100% (or possibly even at 2100% )

The reference to the normal location of the $MFT it was because you talked of having scanned first 5 Gb, the (bad ) news were that normally the $MFT is at around 3 Gb, so it should have been found (if it is still there).

jaclaz

This post has been edited by jaclaz: 05 November 2012 - 01:49 PM

[mattiasnyc]

Yeah, I know, LoL, still with this issue right?

So, here's the deal: I've been busy with a bunch of stuff and was about to give up on this when I remembered files that I now need so I figured I'd give it a shot and got into my head to plug in the original un-bricked drive just to see if testdisk would find anything on it, as opposed to the clone.

In testdisk after the initial search I now found the following:

>L, FAT16, LBA, 22947, 1 , 1 , 60799 , 254 63 , 600108382

Basically I'm now jumping back in the thread in response to your post #26, reporting back before I do anything else...


...standing by...



PS. The commas in the string above are only there to give distance between numbers, they obviously don't appear in test disk.

This post has been edited by mattiasnyc: 30 November 2012 - 04:52 PM