jaclaz

Use an USB adapter, to be plugged AFTER the OS has booted. jaclaz

WHAT is the "pk"? jaclaz

What is the difficult part? http://web.archive.org/web/*/http://unattended.solta.ru/exectools.7z http://web.archive.org/web/20070223045218/http://unattended.solta.ru/exectools.7z jaclaz

Good , another happy bunny in the basket : http://www.msfn.org/board/index.php?showtopic=128727&st=10 Yep, that's the idea. It's optional, but it won't do any harm. jaclaz

Yep, another slip of the finger , 1023 is of course right, the only things to be changed are the red numbers with the bolded italics ones. You may need to re-boot to see the effect. Anyway re-check the MBR with Tiny Hexer and PTview (just in case). jaclaz

Yep slip of the fingers. The good news are that "1221" and "1,465,145,343" do match (as well as "0" and "1,465,144,064") In the bootsectors: "Sectors before" are 20,484,096 "Total Sectors" are 1,444,661,247 (+1 outside the actual filesystem: the backup bootsector) 20,484,096+1,444,661,247=1,465,145,343 Now all that it should be needed is to use a partition editor, like PTEDIT32 or beeblebrox, or maybe this one (just found): http://www.dtidata.com/ntfs_partition_repair.htm and change the values: 07-80-1023-254-63-1024-254-63-20482875-1444661190 to 07-80-1023-254-63-1024-254-63-20484096-1444661248 Please note that the current first sectors of the "current broken" partition will remain untouched but will be in a "no-man's-land" between first and second partition, and that the sector 1,465,144,064 will remain - unindexed - inside the partition. Maybe, once hopefully everything has gone back to normality, it would be a good idea to fill them with 00's, just to avoid confusion should there be any future occasions of attempting recovery. Obviously, crossing fingers, holding a rabbit foot and the like when editing the MBR is advised... jaclaz

No joy. Try searching the same EB52904E54465320 starting form first sectors of partition. It is very possible that the "shift" is bigger than expected. If you find it, post that sector (and it's position). Good The one on 1,465,144,064 should be the "current" one (backup bootsector of "current" partition). The one on 1,465,145,343 might be the "original" one (backup bootsector of "original" partition), which should mean that (if the actual partition size is exactly the same) that the shift is of 1,465,145,343-1,465,144,064=279 sectors and not of the 128-63=65 sectors I guessed. Post these two sectors. jaclaz

Good. NO, it seems like we've found the actual thing. Date is 11/10/2008. Now we have to find out how to fix the thingy. If everything is like I presume, the actual original bootsector is at LBA 20482940, to check, post first 200 sectors of the partition. From the original bootsector we should be able to understand if not only the start position but also the end position was changed. The other check is to (opening the \\.\PhysicalDrive and NOT the partition) to go near the end of the partition, say sector 1,465,140,000 and from it start searching for the backup bootsector, in search use hex string EB52904E54465320. I need the sector number where you find it. With the new (please read old ) verified addresses it should be just a matter of changing a couple of numbers in the MBR. jaclaz

Yep , keep 'em coming, the ones you just posted seem completely unlike "them". There is a possibility that has just come to my mind. If the drive was originally partitioned by Vista or Windows 7, it might have had a "wrong" (from the old "standard" view-point) sector alignment. I.e. it could have been aligned to the "cluster size" instead of on cylinder border. Just a guess, but if the recovery partition was made with an older OS, it would have had the "normal" 0/1/1 start and n/254/63 end (in this case 1023/254/63 .i.e. "a suffusion of yellow" since recovery partition is bigger than the CHS limit), and your recovery partition does have this values. Then comes into play a "standard" Vista or 7 that aligns partitions differently. A "normal" first partition starts at 0/1/1 and ends at n/254/63. The same if created on an unpatched NT 6/7 will start on different address, aligned with 128 sectors before: http://www.911cd.net/forums//index.php?showtopic=21186 most probably 0/2/3 but normally end on border, like m/254/63, see here for an example: http://www.msfn.org/board/index.php?showtopic=119963&st=17 Cannot say if non-first partitions would be as well aligned like that, but if they are, then it is possible that the "actual partition" starts not at 20482875 LBA, but rather at 20482875-63+128=20482940. Then TESTDISK "thought" that partitions were bounded to cylinder borders and when you told it to create the bootsector, it re-created the bootsector in the "wrong" place, also adjusting the partitioning data. If this is the case, the $MFT should be at sector 6291456-63+128=6291521 This would make sense IF you did not (high probability ) go into "Options" and changed "Cylinder Boundary" from the default "Yes" to "No" and the "Allow partial last cylinder" from the default "No" into "Yes". I do know that the above seems complex and confusing (actually it is complex and confusing ). jaclaz

NO. The guide uses this one: http://alldav.com/index.php?main_page=product_info&cPath=9&products_id=11 the new version of which is this one: http://alldav.com/index.php?main_page=product_info&cPath=0&products_id=28 Please notice how the word "TTL" is used in the description of BOTH the above. Notice also how on the product you linked to there is NO mention of "TTL" but mention of "UART". Cannot say if it means anything , but the FT232R: http://www.ftdichip.com/Products/FT232R.htm can output different levels, depending on how the board is made: http://www.ftdichip.com/Documents/DataSheets/DS_FT232R.pdf If pin 4 of the IC is connected to pin 17 it is configured for 3.3 V (right for this use) If pin 4 of the IC is connected to pin 20 or however to + 5v CC (possibly wrong for this use) You are of course perfectly free to do whatever you want , but this is NOT what is recommended, please check point #7 of the read-me-first: jaclaz

The screenshots are of no practical use, the .zip files may . Actually a $MFT first sector has the "$.M.F.T." (Unicode) string at offset 0xF2, but if for any reason that string has been overwritten, you won't obviously find it, the "FILE0" is a more generic string that occurs on each sector of the $MFT and thus allows to find also "fragments" of a $MFT. The real problems is that I still have not any idea about the WHY/HOW this mix-up occurred, quite frankly, we are "grasping at straws", hoping that somehow: the $MFT was originally in a "non-standard" position, that it is still there that TESTDISK somehow used (wrongly) in the bootsector the "standard" address As you can see quite a lot of assumptions . jaclaz

How big can the bootsector be? I have a bootable cd which is like 200MB, yet it shows "0 Objects" in Windows explorer. So does that mean that all 200MB of files/folders are in the bootsector? If it's a floppy emulation either 1.44 Mb or 2.88 Mb. If it's a "no-emulation" virtually any size (within the limits of the actual media) though normally the no-emulation bootsector is 2.048 bytes, it can be bigger, a typical example is grub4dos' grldr which can be used as bootsector and is around 220 Kb if I recall correctly If it's a hard disk emulation any size (within the limits of the actual media). But this is about "standards", one can make "special" "non-standard" CD's with lots of variants, including that of hiding any file to the "normal" OS, so there is really no way to know "generally", a specific CD may have been built in a specific way, and another one in a different specific one. jaclaz

Yes and no. It is bootable through a setting which is called "no-emulation". For reference: http://www.911cd.net/forums//index.php?showtopic=21212&st=23 http://www.911cd.net/forums//index.php?showtopic=18306 http://www.911cd.net/forums//index.php?showtopic=17278 Run BBIE on the CD/DVD: http://www.nu2.nu/bbie/ jaclaz

No, it simply means that the found $MFT was created on that date, which translates - IF that is the "right" $MFT - to the fact that the volume was formattted on that day (which I am presuming to be unlikely). Knowing the "history" of that system/drive may give hints to understand if this is likely or not. Continue gathering them, it is possible that the one till now found is part of something else, and that we find later the "real" one. jaclaz

Compare with point #1 and #2 of the Read-me-first: Pretty much a non-target! I see that you have then double-posted, so discussion (if any) continues here: http://www.msfn.org/board/index.php?showtopic=145646 jaclaz

Sectors 1081443~1081643 seem like being NOT the real thing/not usable. Sectors 1083487~1083687 seem better, at offset 50176 (sector 98/200 of "1083585" file) there is a "full" $MFT. Only it seems like having been created on 15/02/2005, would it be possible? jaclaz

If the bootable CD is of the "floppy emulation" or of the "hard disk emulation" type, yes, it's normal, the actual files are inside the bootsectors and NOT in the "normal" filesystem. You need one of the available CD/DVD tools or you can make an image of it and use 7-zip. jaclaz

Well, try again. Take power off from everything, connect the HD normally, see if it has changed it's LBA0 state. If yes, try getting your data back, first thing. If no, try the procedure again from start. It is possible that your drive is suffering from another problem.... jaclaz

A possibility is to access the BIOS (SMBIOS) settings and change them programmatically: http://linux.dell.com/libsmbios/main/index.html http://www.dmtf.org/standards/smbios Some vendors provide CMOS Tokens: http://linux.dell.com/libsmbios/main/security.html#what_cmos Or maybe mod this: http://rayer.ic.cz/romos/romose.htm BUT it's a loooong way, as I see it. Maybe you should ask for help in forums dedidacated to BIOS and BIOS modding.... jaclaz

Or maybe you could try using another Ramdisk, there are several freeware ones. A list is here: http://www.boot-land.net/forums/index.php?showtopic=1507 jaclaz

OT but just for the record: HotSwap! http://mt-naka.com/hotswap/index_enu.htm Maybe a Win9x backport of it or writing something similar is possible? jaclaz

Wayback Machine! http://web.archive.org/ Here: http://web.archive.org/web/20080403025159/unattended.solta.ru/unattended.en.htm jaclaz

It's very strange. The sectors you posted do contain some references to $Quota, $ObjId, $Reparse (i.e. typical objects of a $MFT): http://www.ntfs.com/ntfs-system-files.htm Now, with reference to your posted file: $Quota is on sector #16 which translates to Record #8 (should be Record #24) $ObjId is on sector #18 which translates to Record #9 (should be Record #25) $Reparse is on sector #20 which translates to Record #10 (should be Record #26) Which should mean that the actual $MFT beginning is 24-8=16*2=32 sectors before the chunk of sectors you posted, i.e. 1081543-32= 1081511 (which still makes very little sense) To be on the safe side, try saving 200 sectors (100 sectors before first found occurrence and 100 sectors after it). I.e.: Sectors 1081443~1081643 Sectors 1083487~1083687 etc. jaclaz

Sure, a "loop" that is not closed is not a "loop". See here: By now you should know it by heart, however, read again point #8 AND links within it. You shouldn't be "desperate" check point #14 of the said read-me-first. Don't worry, don't panic, . jaclaz

NO. As cdob said, mapping something in a Virtual Machine has NOTHING to do with USB booting, it may give some hints about the general bootability of a device, but NOT "Usb-bootability". Compare with these: http://www.boot-land.net/forums/index.php?showtopic=8042 http://www.boot-land.net/forums/index.php?showtopic=9688 http://www.boot-land.net/forums/index.php?showtopic=8581 jaclaz