Jump to content

Seagate 7200.11 malediction


Recommended Posts

Hello guys,

I have a seagate HDD 1To (ST31000333AS).

I have no more access to the disk. This means that I can see the disk in an file explorer but when I click on it, I can't get into the drive and see the files.

Under Linux, the drive has the right name while under windows, I just see a drive but in both, the data are not accessible.

No wired sound comes from the drive which makes me think that it is not a hardware problem.

When I boot in the Bios, the drive is seen with the correct serial number and the right size. So it seems that it is neither a BSY nor a 0 LBA error...

Using SeaTools, I did the short test but It failed while the SMART test succeeded.

The report of the test says that I should use Seagate for DOS but I don't know what to do....

So if any of you can help me, it would be fantastic!

KiD

NB: ofc, I do this to retrieve the data. The possible solution that allows me to use the drive again but with the loss of my data does not interess me ...

Edited by joyvalle
Link to comment
Share on other sites


In windows (7) open disk manager.

Can you see the disk?

If it prompts you to initialize the disk, DO NOT click on yes.

There is the (don't worry, it's very common :)) confusion between disk and drive.

The disk drive is the actual piece of hardware (from Seagate in this case).

The disk (or Physicaldrive in Windows) is the WHOLE extent of the device as seen by an OS.

The drive (or LogicalDrive in Windows) is the partition or volume or drive, i.e. the thing to which Windows assigns a drive letter (i.e. what you can try accessing in Explorer or other FileManager).

Under linux you see the disk in, say fdisk -l as /dev/sda, and a drive as /dev/sda1, /dev/sda2, etc.

As "implied" by PhysicalDrive vs. LogicalDrive, the first is accessed (and accessible) as "RAW" independently from it having a "logical" structure (i.e. a Master Boot Record with it's partition table, one or more partitions or volumes, with their Volume Boot Records).

Are you more familiar with Windows or Linux?

I will need to have you copy a few sectors with dd or a similar program to have a look at them, normally if the disk is still (at least partially) functional the issue is in the "logical" part, i.e. a corruption in either the partitioning or in the filesystem(s) and can often be repaired/fixed.

As well, you should run TESTDISK making a LOG and post the log:

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

(for the moment just run the TESTDISK with the LOG option and don't write anything to the disk)

Ideally BEFORE doing anything to that disk it would be advisable to make a "dd-like" or "forensic sound" image of the disk "as is", to do this you should have available, besides some patience, a "same size" (to make a "clone") or a "larger size" disk drive available.

You might also need (but this is to be seen if partition/filesystem recovery works or not) some available space on another drive to store recovered files if file based recovery will be needed.

jaclaz

Edited by jaclaz
Link to comment
Share on other sites

Hello Jaclaz,

I'm more familiar with linux command than windows. I use linux for work while windows is more for gaming...

So here is the result of fdisk -l :

Disk /dev/sdb: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders, total 1953525168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xcbce2081

Device Boot Start End Blocks Id System
/dev/sdb1 63 1953520064 976760001 7 HPFS/NTFS/exFAT

(To be complete, there is a sda but I didn't paste the result)

This means that the partition is seen. I knew that because in the linux file explorer (thunar), the partition name is correct.

Here is the log from testdisk

Fri Jan 24 14:03:11 2014
Command line: TestDisk

TestDisk 6.14, Data Recovery Utility, July 2013
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org
OS: Linux, kernel 3.2.0-40-generic (#64-Ubuntu SMP Mon Mar 25 21:22:10 UTC 2013) x86_64
Compiler: GCC 4.4
Compilation date: 2013-07-30T14:13:28
ext2fs lib: 1.41.12, ntfs lib: libntfs-3g, reiserfs lib: 0.3.1-rc8, ewf lib: 20120504
/dev/sda: LBA, HPA, LBA48, DCO support
/dev/sda: size 976773168 sectors
/dev/sda: user_max 976773168 sectors
/dev/sda: native_max 976773168 sectors
/dev/sdb: LBA, HPA, LBA48, DCO support
/dev/sdb: size 1953525168 sectors
/dev/sdb: user_max 1953525168 sectors
/dev/sdb: native_max 1953525168 sectors
Warning: can't get size for Disk /dev/mapper/control - 0 B - 1 sectors, sector size=512
Hard disk list
Disk /dev/sda - 500 GB / 465 GiB - CHS 60801 255 63, sector size=512 - WDC WD5000AAKX-08ERMA0, S/N:WD-WCC2EV882038, FW:19.01H19
Disk /dev/sdb - 1000 GB / 931 GiB - CHS 121601 255 63, sector size=512 - ST31000333AS, S/N:9TE1Y4G0, FW:CC4H


TestDisk exited normally.

I'll do the copy of the drive asap.

KiD

Link to comment
Share on other sites

Good. :)

The disk drive seems like working fine:

Disk /dev/sdb - 1000 GB / 931 GiB - CHS 121601 255 63, sector size=512 - ST31000333AS, S/N:9TE1Y4G0, FW:CC4H

The:

Device Boot Start End Blocks Id System
/dev/sdb1 63 1953520064 976760001 7 HPFS/NTFS/exFAT

is good, it means that you have a single partition on it, I would presume NTFS, created under XP or earlier.

Can you confirm this is the case?

So I need a dd copy of:

  1. sector LBA 0 (MBR)
  2. sector LBA 63 (VBR)

Compress the two tresulting sectors into a .zip file and attach it or upload it somewhere and provide a link to it.

In TESTDISK (still making a log) can you try "going forward" and see if it finds a partition/filesystem?

Follow this:

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

and do a "Quick Search".

jaclaz

Link to comment
Share on other sites

Yes it is a NTFS partition.

I tried to backup the disk in an image with Clonezilla but it failed....

For future reader, the command on linux to read the MBR is:

sudo dd if=/dev/sdc of=/tmp/backup-sdc.mbr bs=512 count=1

For the vbr, I used this command:

sudo dd if=/dev/sdc of=/tmp/back-sdc.vbr bs=512 count=1 skip=62

but I am not sure if it is correct.

(As I used cloneZilla with a external disk to backup, the external disk was recognized as sdb and the mounted disk was sdc. Then, even if I removed the external disk, the disk is no more sdb but sdc ... weird)

The log for the "Quick Search" is in the .zip file attached.

thks,

KiD

mbr_vbr_log.zip

Edited by joyvalle
Link to comment
Share on other sites

For the vbr, I used this command:

sudo dd if=/dev/sdc of=/tmp/back-sdc.vbr bs=512 count=1 skip=62

but I am not sure if it is correct.

Yep, it is correct :), but you will need to skip 63 sectors.

LBA starts with 0, so it equates to say "sectors before", i.e. sector LBA 0 will have 0 sectors before, and you skip 0 sectors, LBA 63 means that it has 63 sectors before and you skip 63 sectors.

The issue is that the result of sector 62 is "terrible" :ph34r:

The sector is filled :w00t: with 0x54's (which is BTW a "queer" hex value), normally it is filled with 00's.

Let's seee if sector 63 actual contains the valid data.

A "normal" NTFS filesystem created under XP and earlier will have the $MFT starting at LCN 786432 and have an 8 sectors (4096 bytes) Cluster size.

Hence sector 786432*8+63=6291456+63=6291519

should be the beginning of the $MFT.

Use *any* hex/disk editor to inspect sector LBA 6291519 and see if it starts (first few bytes) with "FILE0" or "FILE*".

Maybe better, get DMDE from here (though there is also a command line Linux Version, do use the Windows one with which I am more familiar):

http://dmde.com/

(get the 2.6.0 for the moment)

You can use it to make the dd-like or "forensic sound" disk copy too, if you did not manage to make one through Clonezilla:

http://www.msfn.org/board/topic/170392-how-to-recover-accidentaly-deleted-partitionfiles/page-2#entry1061689

Then follow this set of instructions:

http://www.msfn.org/board/topic/170392-how-to-recover-accidentaly-deleted-partitionfiles/?p=1061113

and see if it can find the $MFT.

jaclaz

Edited by jaclaz
Link to comment
Share on other sites

hey, I'm back. (sorry for the late answer)

A little question: Do you know why there is an error message written in the MBR?

"Invalid partition table... Error Loading Operating System ... Missing Operating System"

So the block 63 (VBR) is in attachment. I watched the content and there is something more than weird...

It contains a message in french (here in english): "Error reading disk .... BOOTMGR absent ....BOOTMGR compress .... CTRL+ALT+DEL to restart .... restart"

Ctrl alt del to restart ???

It looks like the message was written in sdb instead of stdout (I am not an expert. This is just a guess from a C programmer :D).

Actually, the block 6291519 starts with FILE0 and there is a $MFT further in the block....

I'll try DMDE.

Thanks again for the support!!

KiD

vbr_block6291519.zip

Edited by joyvalle
Link to comment
Share on other sites

Sector 63 is seemingly fine (that text you see is the "normal" - though "French" ;) - set of error messages that may be displayed when attempting to boot), nothing "weird" :).

The data in it confirms the $MFT starting at LCN 786432 and the "sectors before (63) and the disk geometry (255/63), and cluster size is 8 sectors (all "normal" values).

The "new" info is that the $MFTMirr is at LCN 122095000 (in case of need).

The $MFTMirr is (should be) an Exact copy of the first few records (4 of them) of the $MFT.

If you extract 8 sectors starting on LCN 786432 (i.e. 786432*8+63=LBA 6291519) and 8 sectors starting from LCN 122095000 (i.e. 122095000*8+63=LBA 976760063) the resulting files should be identical.

Since both the MBR and the PBR are OK, once verified that $MFT and $MFTMirr are identical, everything leads to a filesystem (NTFS) specific error.

Testdisk has a provision to compare the $MFT with the $MFTMirr allowing the user to overwrite the $MFT with the $MFTMirr if they are different.

This kind of errors (normally) can be fixed from Windows by running the CHKDSK utility, in any case DMDE can normally recover the files.

Once you have the image made, the fixing procedure to attempt is (assuming that the partition gets drive letter F: in windows, change it to suit your situation), open a command prompt and in it type:

CHKDSK F:

[ENTER]

it will print some data and end saying something like "cannot proceed in Read ONly mode as no /F parameter was specified"

Redo as:

CHKDSK F: /F

[ENTER]

this time you will likely have a number of error reports and correspondent "fixes".

Once it has finished, redo as:

CHKDSK F: /R

[ENTER]

this last run is likely to last a lot more time and report a bigger number of errors and fixes.

If the above is what happens, run a last time the simple:

CHKDSK F:

and this time the run should end with something like "Windows has checked the file system and found no problems".

Of course it is possible (though rare) that CHKDSK cannot repair a NTFS filesystem, in which case the only way to recover the files is to use specific tools (like the mentioned DMDE, which often can rebuild a "faked" filesystem to get the files or PHOTOREC or other "file oriented" file recovery tools), but let's first see if CHKDSK succeeds.

jaclaz

Link to comment
Share on other sites

hello Jaclaz,

I tried to backup the drive but the process did not succeed.

Here is the error:

LBA 6 304 023 (try2): WinError 1117 impossible to satisfy the demand because of an error on the "peripherique E/S" (I guess in english this is I/O)

Do you have any idea what is it?

NB: I tried to explore the data with dmde to see the block but as you can guess, when I arrive to the block 6304023, the same error arises.

KiD

Edited by joyvalle
Link to comment
Share on other sites

hello Jaclaz,

I tried to backup the drive but the process did not succeed.

Here is the error:

LBA 6 304 023 (try2): WinError 1117 impossible to satisfy the demand because of an error on the "peripherique E/S" (I guess in english this is I/O)

Do you have any idea what is it?

NB: I tried to explore the data with dmde to see the block but as you can guess, when I arrive to the block 6304023, the same error arises.

KiD

That is a "complication" :(.

So, there is probably an underlying "physical" error(s) on the disk that caused the filesystem corruption.

Time to go back to Linux and try imaging again using ddrescue.

It is important that you run ddrescue with a LOG, see the manual:

http://www.gnu.org/software/ddrescue/manual/ddrescue_manual.html

The program will attempt to read even normally not readable areas, but first thing it will save all the "plainly readable", logging which areas were not read, and try them "later" (or at next run).

jaclaz

Link to comment
Share on other sites

dubbio.gif

@jaclaz: with all due respect, every time I read the title of this thread I daydream something along the lines of:

"Dwell forevermore on BSY, thy villainous drolling fiend, thou!" icon33.gif

Because, the imaginary quote above represents what I do understand by a "Seagate 7200.11 malediction". :P

So... ...since you are the 1st responder, could you please help creating a clearer title for this thread?

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