lost partition and filesystem problem with Adata SH14 disk

[jaclaz]

Hello Jacklaz,

I left the drive last night to complete the full indexing of the directories but unfortunately the computer applied updates and rebooted. FML right? I am not really in the mood to wait for it for a whole another day so I used the FAT1 and FAT2 tables that it got but unforutnately it found only around 950 Mb of useful data. I guess the full indexing will be required anyway.

Anyway I will run the full indexing process again and I hope it will complete properly this time. After it finishes I will extract the bootsectors and upload it here.

Kind Regards,

Mihail Velikov

System Administrator

Well, JFYI a non-written Rule of data recovery is that when you set a machine to do something like that (imaging, scanning, etc.), you disconnect it form the internet/local lan (and possibly also disable any service not really-really needed).

I am sorry for your misadventure , but that is the essence of Murphy's Law, of which you provided an excellent example .

jaclaz

[nthnl]

Hello Jacklaz,

I have attached the file that you requested. In the mean time I will try and repair the disk with TestDisk and see how it goes.

Note1: I used the DMDE tool to index the files and directories and it found a lot of usefull files (the programs know about cyrilic symbols). The problem is that I have like 150 Gb of text files and I can't really save them 1 by 1. The bigger problem I think is that I did not find a way to save the index of the disk, so even if I want to buy the software I will still need to wait for it for whole another day to do the indexing again.

Note2: I run the TestDisk and it reported that both my primary and backup boot sectors are bad and only had the option to Rebuid BS. I quit the menu and went back to do a deeper search.

Kind Regards,

Mihail Velikov
System Administrator

100sec.tar

Edited November 15, 2013 by nthnl

[jaclaz]

The good news are that the data you posted is not that bad.

At first sight it seems like there are remainders of the FAT table (at a more "normal" sector 95 - i.e. 63+32).

More exactly it seems like sector 96 is actually the 2nd sector of the FAT table (and 97 the 3rd, etc.)

The exceptionally good news are that from what I can see the first entry in the FAT was (hopefully) a single file, contiguous, around 13 Mb in size.

It is possible that there is a "way out" rebuilding the first sector of the FAT.

I need to understand however if there was just 1 FAT (which is improbable) or 2 (which would be "normal"), and have to check a few values/make a few calculations/experiments.

Give me some time and I may come out with a possible solution.

jaclaz

[jaclaz]

OK, the whole thing seems to make sense.

I am attaching a file 100 sector in size with a rebuilt bootsector (not bootable, just the BPB) and a rebuilt first sector of the FAT.

You should apply it to the image and then run again TESTDISK on the image.

Please run TESTDISK with the LOG option, so that if needed you can post the log I can possibly understand what is happening.

The file is made in the hypothesis that 2 copies of the FAT were there AND that I assumed/calculated the correct number of FAT dedicated sectors

But you could verify if the assumption is correct, before even doing the test.

You do have a disk editor/viewer, and know how to use it?

(DMDE would do as well, but it is not very "friendly" as "pure" hex editor/viewer)

If you check the image sector 96, you will see how it starts with:

81 00 00 00 82 00 00 00 83 00 00 00 84 00 00 00 

and sector 97 starts with:

01 01 00 00 02 01 00 00 03 01 00 00 04 01 00 00 

etc.

The data in the bootsector I re-built uses:

63 "sectors before" <- these come from the MBR and are surely correct

32 "reserved" sectors <- these are more or less a "standard"

238409 sectors per FAT <- these are "calculated" and they may be incorrect

In theory, you should have on sector 96+238409=238505 the same data as sector 96, on sector 97+238409=238506 the same data as sector 97, etc.

It is possible that this won't happen, if the 238409 is wrong or if the second copy of the FAT has "larger" damages than first copy.

You could try going a few tens sectors back or forward and visually check if you see a similar pattern.

A contiguous file larger than a cluster is represented in a FAT32 table as a set of numbers (4 byte values) that are each the one before +1.

I hope I was clear.

jaclaz

100sect2FAT.zip

[nthnl]

Hello Jacklaz,

Yes I know how to use a Hex tool. I downloaded one and I am currently viewing the disk.

So basically here is what I found:

1. From Sector 238504 to sector 238895 - completely empty.

2. Sector 238503 is like 60% written.

3. I went from Sector 238400 till 238505 no match for the 96 or 97 sectors.

So basically between sector 238400 to sector 238895 there are no copies of the 96/97 sectors

Could you please explain how are the sectores per FAT calculated?

Kind Regards,

Mihail Velikov

System Administrator

[jaclaz]

Basically.
A FAT32 table is nothing but a "sequence of groups of 4 bytes, each pointing to the next group in a chain, and each representing a cluster".
Each sector of 512 bytes contains thus 128 of such "groups"
A valid bootsector contains (related strictly to the filesystem) 6 pieces of info:

1. how many sectors are before the beginning of the volume <-this is the same info that you can get from the MBR, i.e. 63
2. how many sectors are reserved <- this are the very beginning of the volume and correspond to the bootsector itself, plus "auxiliary sectors", like the backup of the bootsector, code (in the case of a bootable volume) exceeding the bootsector, etc.
3. the cluster size <- number of sectors that are indexed "together" i.e. 64
4. how many FAT tables there are <- normally 2, in some rare cases 1
5. how many sectors are "dedicated" to the FAT table <-these need to be "enough" to index the whole amount of clusters in the volume
6. how many sectors are in the whole volume <- i.e. "size of the volume", this is the same info that you can get from the MBR, i.e. 1953520002

#1 and #6 are not a problem (as we got them from the MBR)

#2 is a guess, but a - allow me - very educated one, as when a volume is "large enough", 32 reserved sectors are common AND we found what has the aspect of a second sector of a FAT on sector 96.

#3 is also a guess, but also a very educated one

#4 is one of the problems, as a "normal" Windows Format won't allow to create a FAT32 volume larger than a relatively small size and while almost all third party programs also use 2 FATs, it is possible that a "custom" programs creates just one

#5 is the biggest problem

You have a volume that has a sector size of 1953520002, of these 32 are reserved, so you have left 1953519970 sectors.

Of these we know that a (second) part is addressed in clusters of 64 sectors, and that before them there are a number of sectors, each addressing 128 clusters, times 2, and that these sectors must be enough to address each of the clusters in the second part.

So you have an equation *like*:

2x+y=1953519970

Where y should be in theory a multiple of 64 and x=y/128

The problem is with the "rounding".

I resolved (actually simulated your disk using a tool I have) the equation as:

2*238409+1953043152=1953519970

the 238409 sectors are enough to index 238409*128=30516352 clusters and 30516352*64=1953046528 (more than the 1953043152 remaining), BUT 1953043152 is not exactly divisible by 64.

On the other hand, with 238048 sectors I would have not enough "space" i.e.:

2*238408+1953043154=1953519970 238408*128*64=1953038336 (LESS than the remaining 1953043154 sectors).

BUT there is no actual "law" preventing me from allocating a slightly larger amount of sectors for the FATs, and use not *all* of them.

In other words, I could decide to solve the equation as:

2*238417+ 1953043136=1953519970

and in this case I would have 1953043136 that is perfectly divisible by 64 (and I would simply have a few sectors of the FAT tables that will be never used)

Different formatting programs may use one or the other "strategy" or use a different "rounding" algorithm.

I hope that the above is clear enough, it's a bit complex, and it is not easy to "compact" this kind of info in a forum post.

Please try posting:

1. the sector 238503
2. some 100 sectors starting from 238895 (or from the first sector after 238895 which is NOT empty)
3. some 100 sectors starting from 238895-238409=486 (or from the first sector after 238895 which is NOT empty - 238409)

Maybe I can detect the "increasing number" pattern I was early referring to and be sure about the "sync" of the 2 tables.

I am still believing that there were originally 2 FAT tables, it is possible that just like the area from the bootsector to the first sector of the first FAT was wiped (or defective) a number of sectors from the second table were also in the same condition.

If there was only 1 FAT, the sectors that you scanned and found 00's, around 238505 and up to 238895 would belong to the first file or directory on the volume,

There is another possibility, which is that is possible that the cluster size was, instead of 64 sectors, 128 (and thus the FAT size would be halved) but it would be "non-standard", compare with:

http://support.microsoft.com/kb/140365/en-us

jaclaz

[nthnl]

Hello Jacklaz,

First - thank you very much for the detailed explanation - as of now I have read it twice and it still doesn't make full sense but I will get the hang of it.

Second - I have attached the information that you required.

Thank you very much for your help and please excuse me for taking so much of your valuable time.

Kind Regards,

Mihail Velikov

System Administrator

sectors.zip

Edited November 18, 2013 by nthnl

[jaclaz]

Well, it is really "queer".

If you search on your image with an Hex editor for the hex string B9 F5 00 00 BA F5 00 00, you should find it in two places (do NOT search for them from the beginning of the image, start searching from around sector 500 and from, around sector 238900:

• on sector 586
• on sector 238995

(this is where I have them in my "simulated" image, you will have to confirm this on the actual image you have or correct to the exact sector numbers where the strings are found)

As you can see, 238995-586=238409 (i.e. the size of the FAT table I have)

In both cases the string is at half of the sector, BUT it is at the beginning of the file you attached "sectors from 238896 to 238995"

It seems like when you made that file you *somehow* introduced a "shift" .

As I have hinted before, a FAT32 table contains 128 entries, this means (for allocated clusters, with contiguous files), that the very first entry in the very first sector of the table should have value:

01 00 00 00 (but it has not, because the first two entries are "markers or signatures")

and the last entry of the first sector will have value:

80 00 00 00 (as 0x80 = 128)

Second sector begins with:

81 00 00 00

Third sector begins with:

01 01 00 00

Fourth sector with:

81 01 00 00

Fifth sector with:

01 02 00 00

etc., etc.

in other words, normally a sector belonging to a FAT 32 table (representing an allocated cluster) will begin with 01 or with 81.

I hope you are following me.

On the files you posted inside sectors.zip:

1. "sector from 487 to 587" begins with 01 (good)
2. "sector238503" begins with 01 (good)
3. "sectors from 238896 to 238995" starts with B9 and the "01" can be found at offset 288/0x0120 (if you prefer all sectors on that file begin with either 39 or B9)

Can you check/recheck your image and the procedure you used to make that file?

Also (please again follow me) "sector from 487 to 587" begins with:

01 C4 00 00 , since 0xC401=50177 up to sector 486 there are 50176 entries, i.e. 50176/128=392 sectors of the FAT, to which you add the (63+32) = 95 sectors you get back the sector number 392+95=487

"sector238503" begins with:

01 A4 D1 01 , since 0x01D1A401=30516225, up to sector 238502 there are 30516224 entries. i.e. 30516224/128 238408 sectors + 95 = 238503

This means that sector 238503 still belongs to the first FAT table (which is good, or at least coherent with my previous calculations).

Now if you try taking a new copy of a 100 sectors around 238896 (and hopefully this new copy will have as first bytes either 01 or 81) we will be able to verify the calculations.

Explanation:

Setting temporarily aside the "strage "shift", the first value in "sectors from 238896 to 238995" is 39 0B 01 00 , which is 68409, and 68408/128=534.4375, i.e. sector 238896 should correspond to either sector 534+95=629 or to sector 535+95=630 which would give us a size for the FAT of either 238896-629=238267 or 238896-630=238266 which are evidently "wrong" as we have already made sure that sector 238503 belongs to the first FAT.

I cannot really think of anything (short of a strange controller issue of some kind OR a mistake you did when copying the sectors) that could justify the "shift" in that last file.

Maybe it would be easier (if it is possible for you) if you could image first 95+2*238409+(say) 1000=477,913, let's round them to 488,000 sectors.

That will result in a 488,000*512=249,856,000 bytes file which should compress with zip (or with 7-zip with a slightly higher compression ratio) to something less than 100 Mb. (you may need to upload it to a file hosting like zshare or similar and post a link to it)

jaclaz

[bphlpt]

I would also suggest going back to the company you gave the disk to, and see if they might be a little more forthcoming as to what exactly they did to it. (And personally, I would never give them a disk again. )

Cheers and Regards

[nthnl]

Hello Jacklaz,

Indeed you are correct - the file that I uploaded is wrong . No idea actually how that happened as I used the same procedure -> select the block of text -> copy in to new file. I have done this again and now it seems to be correct. Let me know if you still need me to upload the 100mb file.

Note: I did the search on my device for the B9 F5 00 00 BA F5 00 00 and ideed it can be found at 586 and 238995.

Kind Regards,

Mihail Velikov

System Administrator

238896 - 238995.zip

Edited November 18, 2013 by nthnl

[jaclaz]

That's good.

This new file "238896 - 238995" is identical (actually it has one sector less at the end) to the file "sector from 487 to 587", which neatly confirms that the FAT size is 238896-487=238409 :

You can try what posted on post #19:

http://www.msfn.org/board/topic/170288-lost-partition-and-filesystem-problem-with-adata-sh14-disk/?p=1060289

Remember that file, once unzipped are the first 100 sectors of the image, you should apply them using dd or dsfi (rather than selecting in a hex editor, that may easily lead to mistakes ):

dd example:

dd if=/100sect2FAT.bin of=/mynyceimage.bin

or under Windows you can use, besides a dd port, the dsfi from the dsfok toolkit: http://members.ozemail.com.au/~nulifetv/freezip/freeware/

dsfi myniceimage.bin 0 0 100sect2FAT.bin

jaclaz

[nthnl]

Hello Jacklaz,

Thank you very much for your help.

I wrote the file to the disk and now it seems that Windows knows that this is a FAT filesystem and it shows that there are 652Gb free out of 931Gb which is very good. The problem is now that when I open the drive it seems to be empty. Should I run chkdisk on it or is there any other way to recover the files and structure?

Note: Ok, I run the chkdsk toold on the drive and it says:

This disk contains file system errors that Windows cannot fix.

Insufficient disk space to recover lost data.

292081760 KB in 256422 recovered files.

Windows found problems with the file system that could not be corrected.

Kind Regards,

Mihail Velikov
System Administrator

Edited November 18, 2013 by nthnl

[jaclaz]

I wrote the file to the disk and now it seems that Windows knows that this is a FAT filesystem and it shows that there are 652Gb free out of 931Gb which is very good. The problem is now that when I open the drive it seems to be empty. Should I run chkdisk on it or is there any other way to recover the files and structure?

Well the idea was to write the file to the image (and not to the disk) and trying accessing the image (and not the disk) through TESTDISK (or DMDE).

Even if I have recreated *somehow* some bootsector data and a "fake" first sector of the FAT table (which is enough to have the Windows recognize the filesystem) not necessarily my "fake" sector is "good" or "enough" to allow seeing the files "directly".

Right now (unless I am mistaken) we have two non-synchronized FAT tables and how the Windows FAT32 filesystem driver will deal with this is all to be seen.

TESTDISK has an option (ONLY ONCE valid values are in the bootsector) to attempt rebuild the FAT tables:

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

Now, you have to be careful, very careful.

Until you wrote those 100 sectors file to the hard disk, you had two identical copies of the disk, the disk itself and the image you made out of it.

We do not know (for sure) if when the Windows filesystem driver accesses a filesystem, it automagically changes some values (particularly if accessing a failed/not fully "kosher" one).

In theory you should now make an image of the image (to be on the very safe side) and then use the TESTDISK on the second image, to which you will have to copy the 100 or try using TESTDISK on the actual disk (so that the image is left untouched form when it was made initially).

It is very possible that also CHKDSK may be able to recover the files, but as said I would first try the TESTDISK FAT Repair.

In any case, after EITHER of CHKDSK or TESTDISK FAT repair has been run, the (disk or image) on which it has been run will be changed (and if not repaired fully, you will have to restart from the previous "untouched" disk or image).

jaclaz

[nthnl]

Hello Jacklaz,

What I did initially was to make a 1:1 copy of the broken disk on another drive. I didn't make a binary file, but just pure byte by byte copy with DD. The file that you sent me was applied on the secondary disk and not on the original broken one. As I have the original 100 bytes file we can always revert the changes.

I have already run chkdsk yesterday and it failed to repair the file system with the error message in my previous post.

I read about chkdsk and it seems that initially it only tries to find the files and index them before actually trying to repair the filesystem. Then it estimates how much space will be required and if it is enough then the actual repair will start. As the error message that I received says that there is not enough free space for the recovery of the filesystem I do not believe that it changes anything on the drive. Unfortunately I do not have another 1Tb drive laying around and I am really pesimistic that the company will be OK ordering another one as I can't really promise any results. I will try now if TESTDISK can repair the filesystem and see how it goes.

Update: Ok I run TESTDISK and it reports that the bootsector is OK. I tried the Repair FAT option but it didn't do anything and by this I mean that it scanned the system and reported nothing. After that I used the rebuild bootsector and it completed successfully very fast (like 10 seconds). After this I tried the Repair FAT option but to no avail.

The next thing I did was a scan for the partition and then > Write partition structure to disk. Currently it is "Searching root cluster" and prompted me a few times with results but as I am not sure which one is the correct one I pressesed A(bort interactive mode).

Thank you again for the help.

Kind Regards,

Mihail Velikov

Edited November 19, 2013 by nthnl

[jaclaz]

I don't know.

I mean I don't know if running the CHKDSK (or actually merely accessing/mounting the filesystem through the Windows drivers) is actually producing some changes (even if it does not say so), or, if you prefer, if now restoring the "original" 100 sectors to the cloned disk, this latter is still identical to the original disk.

This is the "advantage" of using an image (as opposed to a "real" disk), both TESTDISK and DMDE use their own methods to access the filesystem, independent from the Windows mount manager and filesystem recognizer/drivers.

Even before running the FAT repair, TESTDISK may be able to show the contents of the disk.

Of the 100 sectors file I sent you, besides the first 63 sectors (that I left untouched) and the 32 sectors (on which I wrote just a "basic" BPB only bootsector, I only "invented" or "faked" sector 95 (the ones after are not changed, I just reused the original ones).

Since sector 96 started with the "continuation" of a "contiguous file", I wrote the sector 95 as if it started with that same (only) file.

By manually inspecting the first 128 clusters of the filesystem (hoping that it is intact) it should be possible to make a "better" sector 95.

Those would be 128*64=8,192 sectors x 512=4,194,304 bytes, starting at offset 63+32+2*238409=476,913 let's make this 9,000 sectors starting from LBA 476,500.

Please understand how UNLIKE the sectors you provided till now, these sectors will contain filenames and file contents, so if there is any concern about privacy, trade secrets or similar, it would be NOT a good idea to share these data with a stranger on the Internet.

jaclaz