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

Sure , point being how many of the programs you run are fully 64 bit, and how many are 32 bit? Or if you prefer, are you not running (say) between 80% and 95% of the time non-native 64 bit programs on that machine? Yep, but this only proves that the good MS guys like to re-use previous code/settings/approaches, not necessarily that it is "smart". As always I might be largely wrong , but IMHO this whole 64 bit stuff has simply been "pushed" onto users a tadbit earlier than actually needed, and does not always make sense in practice. You have a 64 bit OS because with it you can access more memory that allows for larger programs that need more RAM, which since it is available allows for having larger programs that need more RAM that need 64 bit OS which needs more RAM, which ..... A non-entirely-new concept : http://en.wikipedia.org/wiki/Ouroboros jaclaz

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

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

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 586on 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: "sector from 487 to 587" begins with 01 (good) "sector238503" begins with 01 (good) "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

Good. jaclaz

I guess you are asking a bit too much. Particularly the "solid", but in any case it doesn't work really-really like this. I mean, there are several stages that do not allow IMHO to draw a line. A "vector" may be (in my personal experience the "best" vector is the user clicking on random things AND Outlook Express ) Flash or Java, but 1/3 to 4/5 of *any* program nowadays access the Internet, at the very least to check for it's own updates, so it is difficult to say. But the "vector" is only HOW the malware enters a machine, then the "payload" may make use of *any* vulnerability present on the system. Loosely I would say that the patches on "Patch Tuesday" (those that tend to lead to "Exploit Wednesday" ) - with the singular exception of Internet Explorer (and Outlook/Outlook Express) patches - are largely preventing the "payload" from doing damages/work, and very little about the "vectors", but it is difficult - as said - to draw a line between the two. jaclaz

Which you DID NOT report initially. jaclaz

At first sight you are missing the ENABLEDELAYEDEXPANSION, variables inside a FOR loop are not updated unless you use it: http://www.robvanderwoude.com/variableexpansion.php Try changing to !Errorlevel!, and in any case when experimenting you shouldn't redirect the output to NUL, as this way you cannot actually see what is happening, as a matter of fact I would add some more "troubleshooting useful" commands (that you can later remove, once satisfied with result), *like*: SETLOCAL ENABLEDELAYEDEXPANSION....ECHO "%SC%\ixhplayerg.%%a"PAUSEREG QUERY "%SC%\ixhplayerg.%%a" IF "!ERRORLEVEL!"=="0" do (ECHO Errorlevel is 0....jaclaz

Well, that is your fault. Windows 7 booted from a VHD is in no way different from a Windows 7 booted from a "real" partition. It will attempt to take possession of your PC (all your base are belong to us ), it is your duty - and you should know that by know - to keep it busy/entertained in such a way that it doesn't get bored and starts doing random maintenance tasks. jaclaz

See: http://www.msfn.org/board/topic/107504-integration-of-intels-sata-ahci-and-raid-drivers/ 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: 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 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. the cluster size <- number of sectors that are indexed "together" i.e. 64 how many FAT tables there are <- normally 2, in some rare cases 1 how many sectors are "dedicated" to the FAT table <-these need to be "enough" to index the whole amount of clusters in the volume 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: the sector 238503 some 100 sectors starting from 238895 (or from the first sector after 238895 which is NOT empty) 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

Is there a particular *need* for having the XP in the VM "fully updated"? If not, it would be simpler to get a pre-made .vhd from MS, there are the "testing IE" ones that are normally "good enough": http://www.microsoft.com/en-us/download/details.aspx?id=11575&ppud=4 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

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

Only for the record: 07 means NTFS (or HPFS or exFAT)17 means the same HIDDEN27 means Windows "RE partition" (or PQService one)http://www.win.tue.nl/~aeb/partitions/partition_types-1.html Whilst also a type 27 is not assigned a drive letter, it may be interpreted "strangely" by setup , and I would personally use type 17 for hiding a partition. jaclaz

For no apparent reason this thread is interesting : http://windowssecrets.com/forums/showthread.php/157657-Skype-password-reset-token seemingly if you sign in Windows 8.1 with MS account, you can't log off Skype anymore, the "solution" provided by the good MS support is: http://windowssecrets.com/forums/showthread.php/157657-Skype-password-reset-token?p=928741&viewfull=1#post928741 And it is actually the "official" stance, see: https://support.skype.com/en/faq/FA12199/can-i-sign-out-of-skype-windows-8-or-above ... and to be fair, is not even "news" (Windows Phone 8 doees the same): http://forums.wpcentral.com/windows-phone-apps/203679-dear-skype-please-let-me-log-out-skype-windows-phone-8-a.html jaclaz

@NoelC No, I was saying that what the good MS guys call "features" are the things that you (nicely ) removed, while the only "real feature" (the mounting of the .iso) that you listed is not really-really "news", as it was available (via third-party tools/drivers, and JFYI also through MS's own VSS driver) since a long time. As dencorso suggested - it would be very nice if you could provide a list of the add-ons/third party tools that you "adopted" in your setup and I am sure that a lot of people would be interested in more details on the exact procedure you followed to have the install result as a "better" Windows 7 or Windows 7.01. : jaclaz

Well, for the record third party tools (that you seemingly use for removing "features" of Windows 8.1) and BTW more thatn one Freeware, exist to mount/access .iso since the dawn of time and suitable to all recent NT based systems, surely including XP and - if I remember correctly - even 2K. jaclaz

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

You are very welcome, I am sure . Just to clear the matter re: Clonezilla, one must understand that each tool has it's own little "quirks" (and a designed scope) and every situation is a bit different. In your particular case you had not a "failed/corrupted" filesystem, but rather you had a perfectly sound FAT32 filesystem (and you had it on an perfectly working disk). Clonezilla, is designed for cloning of valid filesystems, and among it's features is to copy only used (meaning filled with data AND properly indexed by the filesystem) sectors, this is among it's "features" as it speeds sensibly the copy. the "mistake" or the "misleading" is to call this procedure a "clone" (as it is not, or better it is a clone at filesystem level, but not at physical disk one). But Clonezilla does contain also dd and ddrescue, so you can use it as well to make such a copy, only you won't be "guided" by the scripted interface. Still for the record, what you found was the actual $MFT (not the $MFTMirr), the $MFTMirr is a copy of the first four sectors of the $MFT and it's location is - in my experience - "variable", as such it is not easy to find without having a valid bootsector. The location of the $MFT is on the other hand "almost always" (i.e. for any partition/filesystem) bigger than around 5-6 Gb in a given location on cluster 786432. The bootsector on NTFS is actually a file, called $boot, 16 sectors in size that is at the very beginning of the filesystem. The only part really needed to access a filesystem is it's first sector which is mirrored in a bootsector mirror. This mirror of the bootsector was once (NT3.5 and 4.0) placed in the middle of the filesystem, on "modern" NTFS it is on the last section of the partition space (first sector outside the filesystem/volume) and as such normally easily found. Using a disk editor (personally I use the good ol'Tiny Hexer on windows) or a "low level" tool like DMDE is of course not the easiest thing to do and a background on the innards of the filesystem that you want to recover are needed. Free tools (like the mentioned TESTDISK, which is an exceptionally good/useful program) or Commercial tools like the one you used (which does have a "good reputation") are obviously much easier (though in some occasions more seemingly easy that what they actually are) but, on the other hand, they tend more or less to be targeted to "more common" situations. TESTDISK was probably tricked by the fact that you had a perfectly good MBR and FAT32 filesystem (or possibly you were tricked by it's seemingly "easy" way of use), as it is most peculiar that there was a valid $MFT and TESTDISK was not capable of detecting it . In any case it is obvious that if it was "so easy" to recover data with manual, free tools, Commercial "advanced" tools would have no reason to exist, the choice of using the simpler free tools comes at the price of needing to know what exactly to do with them, and such knowledge does have a cost (but is also, in my perverted mind, "fun" ), on the other hand Commercial tools are often a quicker way, the essence is however that of first thing making the clone/image, this way if one tool fails, you can always restore the image and try with another tool, (and if you fail anyway, this gives you anyway an option to have an untouched copy to give to a professional data recovery service). Some time ago I jolted down my personal "rules" : http://www.msfn.org/board/topic/84345-data-recovery-tool/#entry572375 jaclaz

Not really-really AFAIK. But it seemingly does write to the "hidden sectors" (that are AFTER the MBR and BEFORE the "bootsector"). The good linux guys call this area "embedding area" (for no apparent reason if not for using some even more confusing terminology) http://www.chiark.greenend.org.uk/ucgi/~cjwatson/blosxom/debian/2010-08-28-windows-applications-making-grub2-unbootable.html http://ubuntuforums.org/showthread.php?t=1661254 The technology used by some Adobe products (but not only) is called "flexnet", it is made by these guys here (just to know who is the actual responsible for messing with your hidden sectors): http://www.flexerasoftware.com/ jaclaz .

Anyway, should you not be able to recover the data this way, we can still try assuming that your previous DMDE scan for FAT was accurate and recreate a new bootsector with the relevant BPB data on it. You can also use DMDE (or any disk editor) to look manually in the disk to check for the FAT start. Typically it is a few sectors after the bootsector (8 according to your previous DMDE scan) and basically it is the first sector that starts with the F8 FF FF 0F FF FF sequence. The previous scan of DMDE says that the FAT size is 122065408, the "sectors before" from your initial posts are 63 and the partition size is (still from there) 1953520002 sectors. The only thing that is not clear or "queer" is the number of FAT's, from the DMDE scan you reported it may be that there is only one table (and DMDE assumes that a part of the FAT1 is actually the FAT2) but this is "uncommon" as normally there are two copies of the FAT table. If you want, you can dd the first 100 sectors of the disk, compress them in a .zip file and either attach them to your post or upload to any file hosting service and post the link. From Linux, that would be: dd if=/dev/sdb of=100sects.bin bs=512 count=100(of course the command must be run from RW mounted filesystem or anyway the of= file must be on such a filesystem, i.e. include a path to it) It would be easy if the data is confirmed to prepare a couple bootsectors, one with just one FAT and the other with two FATs. jaclaz

Yep. If the DMDE found FAT table has not errors, as it seemed, now that you have the data on a surely working device, you can try also re-running TESTDISK, if it now can write to the bootsector, most probably it can fix the filesystem enough to acess the data "normally". But can you post the actual recovery log? BY checking the location of the chunks that errored out it is possible to see if they beloong to filesystem data or to the actual data, as this makes a big difference (between being unable to access some 16,000 entries or being unable to access - or get corrupted - 1 or two files) In any case usually the idea is to re-run the tool a couple more times with the "-C" option to see if it can recover the "errored" areas, possibly by using a smaller block size: and/or using the "reverse" approach: jaclaz

Maybe Microsoft sold the patent rights for that system to Yahoo... --JorgeA Good one! Just for the record, bell (or Gauss) curves are a good instrument when production or constance of quality are the scopes, and never a good one where research and innovation are. They tend to heighten the relevance of average, and while they may be useful to "cut" the bad out, they also cut the "exceptionals" or the "geniuses" out. By re-sampling data over and over, the result is always tending to be "average". jacla