Newly-installed Truecrypt hidden os can't boot after decoy os installation

I am using Truecrypt 7.1a and Windows 7 Ultimate SP1 x64 (both as decoy os and hidden os).

I have 1 harddisk with 3 partitions: 35 GB NTFS + 80 GB FAT (with 35 GB hidden os partition) + 350 GB unformatted
The original 100 MB 'system reserved partition' created by Windows Setup was expanded to 35 GB and reformatted, so there is no hidden 100 MB partition creating problems.

After cloning the os to the hidden partition and thereafter installing the decoy os, I can now only boot into the decoy os. If I enter the hidden os password, I get the following message:

find --set-root --ignore-floppies --ignore-cd /bootmgr
Error 15: File not found
Press any key to continue...

...whereafter a red boot menu (GRUB4DOS 0.4.4 2009-09-03) is shown. Trying to boot from the menu has the same result.

However, if I start the decoy os, the hidden os partition can be mounted just fine using the hidden os password. But this password now doesn't load the hidden os via the bootloader.

It is my understanding that the Truecrypt bootloader should load either the decoy os or the hidden os according to the entered password - without any GRUB4DOS or other boot menu ever entering the picture. Am I wrong about this?

*********

I have tried creating a decoy/hidden os system 2 times now from scratch (after wiping the whole disk). Same result.

I have tried using the Truecrypt repair disk to restore the Truecrypt bootloader (worked) and the hidden volume header (did not work, "wrong password"). Trying to restore the hidden volume header from the embedded copy using the decoy os worked. But I still can't boot the hidden os.

I have not tried to restore the system loader because this would require me to decrypt the hidden os. If I do that, repair it and then re-encrypt the hidden os, I assume that I am back to where I am now.

Is it perhaps my version of Truecrypt that has a bug in it? Or are there problems connected to using a Truecrypt hidden os with my version of Windows?

Can it have anything to do with the hidden volume being a clone of a NTFS partition but residing within a FAT partition?

Am I supposed to create a rescue disk before exiting the hidden os after its installation (= before installing the decoy os)? The Truecrypt installer doesn't do this. My current rescue disk was created before encrypting the decoy os.

 

You have so much going on you will probably have to do most of it over, but FOR SURE you will need to blow away the decoy and get a clean one. When you open the hidden OS in any fashion (from within the decoy) you are creating tracks that lead directly to the door and "marking" your drive beyond forensic repair from within the decoy system. There is no sense in redoing the decoy at this point until you/I can determine why you are having these issues.

You can forget about the fact that the second partition is formatted as Fat32, its not a problem. When TC clones the hidden OS into the partition the hidden volume/OS will be NTFS and the outer volume will remain Fat32 if that is how it started. Without question I have done it over a hundred times and its not an issue. Next, TC works flawlessly with Win 7 so that is not an issue, with the exception being on hardware attempting to boot using UEFI. TC will under no circumstances mount on UEFI hardware. I'll assume that is not an issue here but I am simply asking to make sure we cover that square.

Lets SLOW down and get YOUR answers to a few basic questions:

1. After you clone the hidden OS to your drive but BEFORE you remove the donor decoy OS, can you at that point mount the hidden OS? TC will allow you to continue using the hidden OS without removing the original donor decoy (super bad idea long term, but its valuable for this thread). I suspect you are going to answer this question with a YES and if so we are almost sure to know what is causing your issues! Please respond for further help here.

2. Once you blow away (now you need to do at least a one pass wipe for forensic integrity) the decoy, how are you re-installing the decoy OS on the original system disk? If you are using a Windows install disk that creates another nightmare to deal with. Please advise on your method of installing the decoy AFTER the hidden is created. The method before the hidden is created doesn't matter at all. This is an IMPORTANT question I need answered if you want me to help resolve your issues.

Repeating, if the answer to 1 is yes you are so close you should be able to taste success. LOL!!

 

Thank you for your response.

Yes, I realize that I most certainly am giving away the hidden os by accessing its partition using the decoy os, but I only did it to see if the password worked and if the partition could be found at all. When/if I find a solution to my "dual boot" problem I will of course reinstall everything after a good wiping.

Concerning UEFI: My laptop actually does have a UEFI BIOS. I've been fooling around a bit in there, so I'm not really sure how the settings were at the time of installation. The current settings are:
UEFI/Legacy Boot: Legacy Only
- CSM Support Yes
UEFI Secure Boot: Disabled
Is having a UEFI BIOS completely out of the question? Or is it still possible to use Truecrypt if I disable the UEFI boot as I assume that I've done above?

1. Not sure if you mean (a) if I can mount the hidden os partition from within the still-not-removed decoy os, or (b) if I can boot the newly-installed hidden os from the bootloader before installing the decoy os?

If it's (b), then I believe that I successfully tried to boot the hidden os from the bootloader the first time I tried installing, but perhaps that's just something I've dreamt. I'll have to recreate a hidden os again and try this out to be completely sure. I assume that I can just clone the existing decoy os after wiping the current hidden os partition?


2. After creating the hidden os, I let Truecrypt wipe the first partition, whereafter I press 'Exit' and install the decoy os with a USB-key containing an image of the Windows install disk. After installing Windows as decoy os, I install Truecrypt and choose 'Normal System Encryption' and 'Single boot'.

You write that using the Windows install disk creates a nightmare, and this is also a point in the process where I personally have felt that things go wrong. I've read here and there about the Windows installer messing with volume headers and other things without asking.

I'm only used to installing Windows in this way, so if you have a better way that doesn't mess things up, please do advise.


Btw, does it make any difference at all if I create a rescue disk before exiting the newly-installed hidden os compared to creating it in the decoy os afterwards? As I understand it, the bootloader is algorithm-specific and will automatically look for a hidden os password near the end of partition 2 whether a hidden os exists or not. And therefore the bootloaders created by the hidden/decoy oss will be exactly the same.

 

I'll jump on a few of your basic questions: ( I am not addressing the internal TC coding questions here in this thread)

1. The fact that your machine OFFERS UEFI is not a problem. I have several laptops that came with UEFI, but that offer a legacy bios option. I use the legacy option and TC works fine in that configuration. However; you CANNOT run TC with an actual UEFI boot configuration in play, except of course for non-system disk encryption.

2. YES we need to confirm that you can mount the hidden OS BEFORE you blow away the decoy OS. The manner you are using to create the decoy OS after the original is deleted is where you are having problems. The windows installer is a disaster waiting to happen.

First ----- even if only for your own sake ---- confirm my suspicion that you can in fact open the hidden OS as I described in the posts above! BEFORE deleting the decoy OS!

Now, you are going to want to create a CLEAN copy of your Windows OS system disk to use as your decoy. You can define clean to the level you need to feel comfortable. Mainly, for the purpose of this thread CLEAN means ZERO traces of any hidden OS use or creation. Beyond that its up to you to make that determination.

Do you have any experience creating a copy/image of your system disk (C drive)? I am going to assume you can install a clean win 7 OS and from there we will create a backup from which you can re-install the system. Several FREE programs are available and frankly for your purposes the resident free windows backup will do the trick. Regardless of which you choose here is what you need: A bootable rescue media, which is usually a usb but can also be a CDR/DVR to boot the machine in RAM. Windows will create one for you. Next you need to run the backup program and copy the decoy out to say an external drive. That part is easy too and windows is pretty straight forward. I don't use windows backup because I have high end programs but relax it is enough for what you need at this point.

Restore Process: insert bootable media (USB) and connect the external drive. From there you simply tell the backup program to write the copy back to the system disk (usually C drive). Once you do that you'll simply use TC and encrypt the C drive and you are done. Its easy when you know how to do all this.

Frankly, I only use linux for system disks now but I have done what I am describing to you so many times over the years. My guides are all over the net so I assure you this is routine.

Hopefully you will see this before you spend too much time doing something you'll just have to redo. You MUST have a clean Win 7 OS available to make this work properly.

Let me know how this goes and feel free to ask questions. By the way, we have an imaging forum here and there is tons of help down there. This is where you need to start because things break and being able to fix them requires backups, encryption or not!

 

I'm having some real trouble getting this to work.

Here's what I've done:
1) I decrypted the decoy os and cloned it to the hidden partition.
2) When the Truecrypt-installer was ready to wipe the original os, I clicked Defer and restarted the computer.
3) At the Truecrypt bootloader I entered the hidden os password and without incident the new hidden os loaded. The original os was also able to load by pressing Esc.

So, that part checks out.

4) Thereafter I wiped all 3 partitions and installed a fresh copy of Windows on C:.
5) I created a bootable Windows Rescue CD and an external hdd system image of C:.
6) I cloned Windows to the hidden partition and let Truecrypt wipe the original os partition C:.
7) Then I exited the Truecrypt-installer and restarted the computer. I was now asked for the HIDDEN password (not just A password), which then resulted in the exact same problem as at the beginning of this thread.

I have no idea how this can be possible, since the Windows-installer hasn't been used after the creation of the hidden os.

Hoping that a system image restore somehow would correct this, I continued:
8 ) I restarted and booted the Windows Rescue CD.
9) I tried to copy the system image to C: from the USB-hdd backup. Windows found the backup and started the copy process, but soon gave the message:
The system image restore failed.
Error details: The system cannot find the file specified. (0x80070002)
And when I tried it again:
Windows cannot find a system image on this computer
10) After a restart it did find the image again, but returned with the same error as above.

When Windows Rescue asks if it should format and repartition the drive, I answered no because it shows the whole drive as one unit. There is no option to format only the C: drive.

Now the Truecrypt bootloader keeps saying "Enter password for hidden system", but this results in the original Error 15 and the GRUB4DOS menu. And pressing Esc at the bootloader of course results in "Error: No bootable partition found"

I have no idea what to do now besides wiping the whole disk and try to restore the disk image (while allowing Windows Rescue to format and repartition the disk) and thereafter create the hidden os once again. But somehow this seems futile.

Is it possible that my wiping of the 3 partitions neglected small areas of code at their beginnings and ends, and that this is what is giving me trouble now? Should I perhaps choose 'complete disk wipe' instead of each partition on the disk by itself? Does that really matter?

 

I will give you credit for sticking with this. You are CLOSE and it comes down to restoring the decoy process.


Starting in step 7, I see what is going on but now I am trying to figure out how to instruct you. It would be seconds on this end. Hang in here while I ramble. After deleting/wiping the decoy there should be no evidence of any hidden OS. The TC manual warns that the hidden OS will NOT be available after you blow away the decoy and that is because the TC bootloader should no longer be on the MBR. If you are seeing hidden OS flags there is dirt on your MBR, which is probably there because of how the decoy was written/prepared, or the MBR was not rebuilt. Continue hanging: basic disk geometry of an mbr is 512 bytes. 446 bytes are used by programs (TC in this case) to store loading instructions, followed by 64 bytes (4-16 bytes each-partition slot entries), followed by a 2 byte ID entry = 512. For your purposes the magic happens for TC in the 446 bytes. That is where the TC loader calls everything out, so lets fix this thing and make the problem go away!

I am suspect of your Windows backup, not because of anything you said but because of the symptoms you report. I don't know what tool you are using for wiping partitions, if anything other than TC itself. I am asking for another reason. Free partitioning/wiping/formatting tools have a simple feature to "rebuild the MBR". One example I cite often is partition wizard (FREE). On a normal Windows MBR aligned system disk, you can rebuild the MBR as many times as you want and it won't bother anything. This will restore a Clean/normal mbr aligned 512 bytes, which is what you want and need to start with.

When you make a copy of a Windows system disk a GOOD program/configuration will also backup the MBR so that when you do a system disk restore the MBR is also restored. In this thread that means that the TC bootloader would have been overwritten by a normal MBR. It appears that did not happen here for some reason. Either you did not overwrite the TC bootloader because you didn't save the MBR as part of your system disk backup, or your backup was created with a dirty MBR in place to start with.

You can grab partition wizard and it will boot in RAM from CDR/USB. Once up, you can select rebuild MBR. Its fast, safe, easy! If you do that you will no longer see the hidden OS flags you mentioned. Now you have a clean normal MBR and can proceed with that part of the equation back on track.

Your backup must have something messed up if it can't write back successfully without an error. Did you spend any time down in our imaging forum? There are many good free programs discussed there. This is the piece of the process that is "crushing your head" and once you learn the process its child's play ---- it really is.

BTW --- if you have a former TC rescue disk/cdr from this computer you should still be able to mount the hidden OS in the short term. Just boot from the CD and it'll mount. The rescue disk is decoy system specific so the hidden should still mount with it. I don't want to explain all the internal coding, but trust me it'll work for you, just so you have a system to use while fixing stuff.

HINT --- never blow away the decoy until/unless you confirm you can start the hidden OS on reboot first! This eliminates the hidden OS as the problem if anything goes wrong in the next steps.

 

Allright, I've created a Partition Wizard boot disk and run it.

The hdd is shown as Basic MBR 465.76 GB.
First partition (NTFS) is shown as Unformatted.
Second partition (FAT + hidden NTFS) is shown as Other. (Why is this? Why not FAT?)
Third partition as Unformatted.

I originally used Paragon Hard Disk Manager to wipe the partitions one at a time. I didn't notice any possibility to rebuild the MBR, but I was also using the express interface. But I can see that this feature is available in Partition Wizard when I select the whole disk.

I had decided to use Windows itself to create the system image after I read an online manual I found, so I haven't had much of a look in the imaging forum, as I was amazed at how easy the process was (yes, it really is child's play). So it's quite annoying that something still went wrong. I don't believe the MBR was mentioned anywhere in the process of creating the image with Windows.

I of course don't have a Truecrypt rescue disk now because I for some reason decided to wipe the old ones yesterday, and my most recent hidden os creation didn't make one as I chose to abort the normal process in order to create the decoy os from the image instead.

So, should my very next steps be something along these lines?:
1) Rebuild MBR.
2) Wipe complete disk. (Should I first Clean it in Diskpart?)
3) Re-partition.

I am assuming that I am going to have to make yet another (this time, squeeky-clean) install of Windows, create a new (clean) Windows Rescue CD, a new clean system image, clone the os, reboot and confirm hidden os startup, restore system image to C: ?

It's a lot of work, but I don't mind, as I really want to see this setup working.

 

Maybe we can save you a bunch of work. I think you are starting to get the hang of it. LOL!

1. Don't get hung up on the notion of "CLEAN". As a forensic examiner that has looked under the hood on Windows - a bunch; a remarkably squeaky clean OS can stand out as beyond normal too. You are expected to use your OS afterall. Just ask yourself if there is anything on the system disk (traces) that if discovered would leave you in a bad place? Generally the "kill switch" must be pushed if there is ANY trace of hidden OS access/use/creation. There can be NO doubt about this or start over - no exceptions! Beyond that obvious fact just relax.

2. The second partition you asked about will NOT show up as FAT because it isn't a normal filesystem at all. Its actually an encrypted #$#%$%^$^% bunch of ones and zeros. Now when you open the volume using TC, the outer volume is formatted to FAT32 according to your instructions during creation. The entire point for using TC is that everything in that second partition is fully encrypted. There is not one sector that isn't written to by the volume creation wizard and all byte entries are not plain text. TrueCrypt will NEVER write one single byte EVER that is not encrypted to your hard drive. That is the whole pupose and why it is "on the fly" encryption. To you the process appears seamless because you "see" the information being presented to you in plain text while you browse, but in reality there is not ONE plain text byte anywhere on your partition two. Therefore any software tool that attempts to read your disk geometry will NOT report a recognized filesystem. Simple!!

3. Re-partition question from you: Why? You have to decide if the size and structure meets your needs. You have tons of unformatted space and I don't know what you are planning to do with it? You don't need to answer me, just this would be a decent time to make a change if that was your intent since you CANNOT resize an encrypted volume with TrueCrypt.

4. If you have a working Win 7 on your system disk (C drive) and it does NOT have hidden OS traces, then just use that. You are correct in that you can employ the "rebuild MBR" feature in Part Wizard and any dirt from TC use will be totally removed from the MBR! This should not bother the Win 7 startup at all. If it does something else is going on.

5. Much of the hard work/frustration you have experienced is because you did this project out of order. By creating a hidden OS without a clean decoy image to restore with, made it a fight for you. But picture this: you have a clean Win 7 image on your external and have tested it thoroughly and KNOW you can restore the system disk any day you want to. THEN, you create the hidden OS and use that restore process. One time and you are done. Would have been simple. No?

6. You are actually learning some valuable skills here. The majority of folks just use their computers and never have backups ready. Encryption points out the need, but its always been there. Backup skills are a smart and definite pre-requisite to software encryption. Just read through this encryption forum. How many I don't have a rescue disk, I didn't make a volume header backup, I screwed up and used a Windows installer, etc.... posts are made and in the end its all lost except for those willing to pursue heroic measures. Learn this stuff and relax with confidence. Its worth your time in the long run. I usually won't participate in the heroic measures threads after doing them for years on a thousand threads elsewhere. Its hours of recovery instead of a few minutes using the tools in advance and being prepared for when disaster strikes. Don't want to appear rude but that is where I stand on those threads now.

I hope I answered most of your questions, but those that remain I will also gladly try to help you with. As long as I sense you are trying and not just wanting to be spoon fed I will be here!

 

Same problem again, I'm afraid...

This time I did the following:
1) I used a Partition Wizard boot CD to rebuild the MBR and wipe the whole disk.
2) Installed Windows from scratch while creating the same partitions as before. The third partition is to hold a hidden partition for use with the hidden os. It remains unformatted.
3) I used an AOMEI Backupper boot CD to create an external system image.
4) I created a hidden os clone.
5) I restarted and entered the hidden os password to check if it worked. It did.
6) I let Truecrypt wipe C:
7) I shutdown and started the AOMEI Backupper boot CD and restored the system image to C:
8 ) I restarted and entered the decoy os password, which worked.
9) I restarted again and entered the hidden os password, which once again gave me the exact same problem as at the beginning of the thread.

This system was created super clean, so haven't the slightest idea what's gone wrong. I am beginning to find it a bit odd that it's the exact same error that's reported throughout this thread, even though I've done things differently. I'm wondering if it could be a hardware-related issue, as I believe that I've done things correctly this time. Or that I perhaps should try to write protect the boot sector (is that even possible?).

This time I do have a Truecrypt rescue disk, but I haven't tried using it as I'm afraid that there might be a certain order to follow (or avoid following) trying to fix things.

Quite a lot of wasted work up until now, but I'm taking it as a learning experience. At the very least I've come to see that I should have learned to take system backups years ago.

 

KEEP YOUR RESCUE DISK to use later; see thoughts below:

Hmmmm? For now I will assume your system disk backup is good, but only you can verify that. Obviously, you have written it back to the drive and encrypted the decoy already. Further; it appears the TC bootloader is accepting your password and thereafter loading Win 7 on the C drive. So now the decoy is good to go. Further assuming there is still no 100 meg boot partition and that the boot files are inside the two system disks (decoy and hidden)?

Oddly, the hidden OS works and mounts perfectly during initial creation - and specifically before you blow away the donor decoy used to create it.

We still have a few more tricks up our sleeves.

1. You have nothing to lose by using the TC rescue disk but its not likely the problem. The TC rescue disk is decoy OS specific, but still it wouldn't hurt to write back the TC bootloader, which is on the disk in the options. You currently have a working decoy so the TC bootloader appears to be working properly already. Its only a few seconds to test it out though!

2. Hang in on these ideas and they are nothing personal: what you keep describing "feels like" during the time you write back the decoy OS somehow the second partition is being messed with. That should not be happening and I am not saying it is, but the symptoms make me doubt that I am wrong. Rather than relying upon your backup being "sound" I am going to suggest doing an end run around what I think may be going on here. Even though the second partition should not be touched, what would an end run around be, just in case it is being messed with? Two ideas, second almost certainly will work since I do it all the time for another reason.

One: TC creates a normally configured volume header during the creation of the hidden OS. If you think about it, there could be no plausible deniability unless the outer volume (containing your hidden OS) appeared normal. It is configured exactly as any volume header would be. During volume header creation the space used is exactly the same whether or not there is a hidden volume inside the space. Lets not get bogged down with the coding, which I have lived and breathed for a decade now. Your hidden OS is "called out" in the same manner as any hidden volume would be. What that means is that you have the ability to create a normal volume header backup for partition 2 using the TC control panel. You should always have volume header backups of any encrypted volume, and they are small around 130 k. What does this mean? Using a backup volume header you can easily restore the exact header as when the "snapshot" was taken. In YOUR specific case here, it means that you can restore the partition 2 header if that is getting corrupted when you write back your decoy. That alone may get you past your hurdle, but if the corruption is beyond simply the header addresses than we go to option 2 for a complete run around.

Two: Let me preface this suggestion by telling you that I do it all the time (many dozens at least) because my disk configuration is so out of normal I don't even want to fully discuss it here. Briefly; I recently worked on a project with someone where I developed multiple hidden OS's with none in slot 2 to avoid even the hint of a hidden OS. With coding it was doable, but the point is to show you this will work for your much more simple application. After you create your hidden OS again and its up and working fine (before blowing away the donor decoy) I would consider this end around. You can do a sector image (take an exact image of all 80 GB) where the backup exactly copies/images the second partition. The backup will be 80 GB (the size you mentioned above) because each and every sector/byte on partition two is imaged. Its working right now so when you image it back it will also work. On my usb3 hardware and using my backup tools such a backup in either direction would be very well under an hour for 80GB. If you only have usb2, it might be 90 minutes or so with a backup verification step included. I used to tutor alot on this software and sector based images for hidden OS's is a great scheme. You cannot use TC and recreate a hidden OS unless you start from scratch every time, and for me thats a no thanks. I can re-hit my hidden OS's in under a half hour and they are back and as clean as when I created them in the first place. Please consider trying this. In reality its just another backup method that allows you to do something most will never even consider.

Now after restoring that sector backup to your slot 2, you should be able to mount the hidden OS using the TC rescue disk I asked you to keep.

Two things then: try the volume header backup, and you can bank on the sector based image!

ps ---- since your system works so well until you destroy the donor decoy, I don't think its a hardware issue. My .02

 

Thanks, I will look into your suggestions over the weekend.

On the face of it the sector imaging method does sound almost certain to work, and I did notice that method as an option. I remember thinking that such a method could turn out to be very useful in certain situations, but didn't really think about taking a backup of partition 2, as I was feeling confident that I was very close to success.

Unless my Windows-installer flash drive has been 'infected' by something, I do believe that I have made a clean install of Windows. The only possibilities I can see are that either Windows Update or a separate driver updater (Driver Booster 2) has messed with something. But still, after cloning the os, it loads just fine until the decoy is in place.

The 100 MB partition for boot files/Bitlocker IS non-existent, as I intentionally extended its size and reformatted it to make it a normal partition (C: ), both because I hate having to look at it in Disk Management and because I, before installing Truecrypt the first time, had read about people having trouble with Truecrypt apparently because of that 100 MB 'hidden partition'. And Windows installs just fine and with no complaints without it.

I do keep having a feeling that things are being messed with by something (ie. Windows itself) since I keep on getting the same error even though I follow the instructions in the Truecrypt-installer, in online manuals, and from you. My main reason (which I know is very subjective) is that I over the years have seen Windows do many unpleasant things to files and disks - and of course without asking for permission. I don't trust Windows a lot, and can easily imagine it doing something well-intentioned but bad to my partitions in this whole process. Other than it being closed-source, this is reason enough for me to never even consider Bitlocker as an option. Windows is merely an os for me. I don't even trust it to copy files, let alone wipe or defragment them - I choose other options for such tasks. Computer-related stuff (and especially Windows) has given me countless hours of pain over the years. But almost no matter what the problems have been (the current one included, hopefully), the pain usually turns to great pleasure when the problem gets solved, and I myself have become wiser (usually in several other things besides the actual solution). This is learning at its best.

Btw - when wiping a hdd - is what is actually physically being done to the drive the same whichever program is used to wipe (eg. Truecrypt itself)? What i mean is, do some programs only wipe sectors which are 'user data' and leave other parts alone (eg. boot sector)? Or is a 'wipe' truly a wipe whichever program does it?

And could you perhaps also enlighten me about how in the world GRUB4DOS comes into the picture in all of this? Is it part of the Truecrypt-installer? Or of my BIOS? I've only heard about GRUB in connection with Linux, but the closest I've ever come to using Linux was a flash drive with Parted Magic about a year ago when I was doing some data recovery on a USB-hdd. On the current system I've used this flash drive to load some drivers from, but I assume that the probability of this flash drive 'infecting' my new system with GRUB4DOS is very slim to none?

In other words, are there any of the symptoms in this thread that suggest that I should find a different copy of the Truecrypt-installer than the one I am using now?

 

Only time for a few thoughts to fire at you. The TrueCrypt installer: hopefully you know how to verify a file for integrity, but if not here is some basic guidance. Always make sure the file/program you downloaded is verified against established checksums ------- > ALWAYS! If you have any questions read around on how to do a sha512 or no less than a sha256 on the TC file you downloaded. Someone else here can confirm the checksum is correct if you post your checksum here. There is NO security risk in posting a checksum on a public binary. I actually prefer to verify my downloads against pgp keys but the TC guys didn't post a signed file via pgp so the best is sha512 at this point.

GRUB4DOS has nothing to do with TC or your bios. There is an actual forum for grub4dos if you want to learn another skill set. Its powerful and can do amazing things. You don't need to know grub4dos at anything but the basic level to use it for mounting TC on a flash drive. There are several guides on Wilder's and I have some all over the place. Just google grub4dos to mount TC from a flash. Easy stuff and works very very slick. Much better and faster than using an optical disk. By using the simple guides its almost automatic, but then I've done a hundred of them. LOL!

Your disk wiping question: comes down to opinions, which vary widely. Its a relic at this point but I am fond of Eraser. For FAT32 and NTFS its really slick and you can custom configure the wipe routine to employ on your disk. It is free and installs on 7 without a hitch.

As one more sidenote: you mentioned that you have never used Linux as your operating system. I would encourage anyone reading along here to consider it for many reasons. I will not get "windows ugly" over this, but I only use linux now for my private/secure needs. As I type this post I am on a linux vm, which is using TOR, and is connected to a linux host that is VPN'd, that is connected to a router using another VPN. Get the picture (5 hops)? LOL!!

 

I don't know if you will come back here before re-doing your drive but I wanted to stress how the simple volume header backup may work. Many times the windows installers only hit the part of a partition structure where the TC volume header resides. If you use your decoy and TC to create a volume header backup you might get lucky and a simple restore of the header will put you back in business. I've seen it on many occasions, and a header restore is seconds at most.

 

I'm finding it difficult to understand what's been going on with my system the last several days.

Since my last post i did this:
1) Wrote back the Truecrypt bootloader (no effect).
2) Restored the volume header of partition 2 (no effect).
3) Restored my previous system image of the donor os to C: and created a new hidden os.
4) Entered the hidden os password (worked, hidden os booted). Did this a few times "just to be sure".
5) Created a sector image of partition 2.
6) Let Truecrypt wipe C:
7) Restored from the system image once again to create a decoy os, booted it and encrypted it. Restarted.
8 ) Entered the hidden os password (worked!?!). Tried the decoy password (worked). Tried them both several times (both worked).
9) Encrypted partition 3 and created a hidden partition within it.
10) Tried both passwords several times again (both still worked).

As you can see, I did not have to restore the sector image of partition 2, or use the Truecrypt rescue disk. I even used the same system image as last time. For some reason it simply worked after I created the decoy os and encrypted it.

The only thing I can think of that I've done differently from the previous attempt (besides the multiple uses of both passwords) is specifically telling AOMEI Backupper to use partition 1 for the system restore, instead of letting the program figure out for itself which partition it should use. Could this really be what went wrong at the previous attempt? It did restore to partition 1, but perhaps it can mess with things unless one is specific about which partition to use?

However, this does of course not explain what went wrong on the earlier attempts. I am unsure about whether Windows was overwriting the volume header of partition 2 and/or doing something else that would result in the hidden os not booting.

So, even though things do appear to be working now, I'm honestly not completely comfortable moving important data to the hidden volumes on partition 2 and 3. Because of all the trouble up until now, I'm still not really convinced that the hidden os will boot every single time from now on - because I still don't know what the problem was. But maybe I'll just have to live with that.

If I do lose contact with the hidden os, I assume that restoring my sector image of partition 2 will solve that. But what about data in the hidden volume of partition 3? Apart from forgetting to protect the hidden volume when using its outer volume, should I be relatively safe from trouble by backing up partition 3's volume header? Or will I need to keep an encrypted backup of the partition?

 

First off, Congratulations on having a working system. You have confirmed exactly what I was thinking all along, and indirectly stated several times above in this thread.

Candidly, I was trying to say in "nice terms" that you were restoring the decoy system disk incorrectly - almost for sure. Many backup programs require you to instruct them as to WHERE to write the image you are using. While I am not familiar with the one you are using I have tested and "driven" numerous software concerning the issue of imaging/backups. After reading your "account" of your now working system it should be obvious to you that not telling the program to specifically write to C was the cause of the mistake! This is a BIG and common mistake to assume the software will just "magically" know it belongs on C only. You have learned a bunch through your trials here, and I might add you prevailed so "hat's off to you".

The end arounds that I mentioned earlier in this thread were actually some ways to help your recover from a "bad restore" and I was using those to help you and even point out the why after the fact. The sector imaging (assuming its done correctly) works flawlessly with TC and encrypted partitions. Now you will be able to restore your hidden OS by simply connecting the external drive with the backup and running the restore program. I did that type restore often over the years.

Regarding your partition 3: that is an archive volume so you can backup only the data inside the volumes if the size requirements are not too high. Obviously all users should have volume header backups of any volume that contains information that you don't want lost.

Backups are very important regardless of encryption. A hard drive can and will fail. NEVER trust the hard drive with data that is important and is not backed up on another media. Its not an IF but a WHEN on the subject of physical drive failure.

Mostly ---- I am proud of you for sticking through this thread with me and showing some tough resolve. Good job!!

note and thoughts: when you created the partition 3 if you used the decoy to do so there is NO way to be certain it will really remain hidden due to OS tracks created when you made the volume. If you created the hidden part 3 volume from within the hidden OS you are good to go. A good rule of thumb is never open a hidden volume from inside the decoy.

 

Well, thank you very, very much for your help! You have been patient and your input has been very informative and enlightening. This would have taken much, much longer without it. I would eventually have gotten to imaging at some point, but not as an early choice.

Yes, the lastest attempt does seem to have to do with manually directing the backup program to the correct partition. I just assumed that when the program reads the image and detects that it is a system image, and then asks me if I want to do a *system restore*, that this of course magically would be done on the correct partition. Silly me.

However, the earlier attempts (before creating an image) are still a mystery to me. Because, in the Truecrypt-installer one is actually instructed to *install* Windows to create a decoy system - which I assume means by the normal method with a DVD or ISO. I can't possibly be the only person who's run into this problem after following the official instructions, so I find it strange that nothing is mentioned in the installer about the possibility of creating the decoy os from an image. It almost seems to me that the only workable method (at least on my hardware) actually is 'manually' restoring a system image to avoid Windows or the backup program sabotaging things. Perhaps Truecrypt's original website mentioned something about this, don't know.

The outer volume of partition 3 was created in the decoy os, and afterwards the hidden volume in the hidden os. That was how i believe Truecrypt instructed me. It couldn't create the outer volume from within the hidden os due to the forced read-only setting of the 'fresh' partition. I assume that my hidden volume within is safe by doing it this way (the only way, as I understood it).

A really great bonus that I've gotten out of all this is a resolve to take system and sector images. Why haven't I done this before? I should have started 20 years ago! I've installed Windows from scratch too many times, and we all know how good a use of time this is. Several crippling attacks by malicious code over the years didn't give me enough incentive to create a clean system backup with which quickly to solve my problems. For some reason it was this minor encryption ordeal that was what it took to convince me.

Now I can't wait to spend hours and hours creating super clean system images for each of my computers, seriously!

And btw, everything is still working, so my feelings of risk concerning moving my data to the encrypted drives will probably vanish soon, and then I'll be fully converted to encryption after all.

 

Sounds good to me!!

When you get some time to do some reading, give a serious look at VeraCrypt. It started as a simple continuation of the TrueCrypt code, but has evolved to much more than that now. We/coders are examining some "difficulties" with the Windows driver assignment system (always Windows just being windows). I have converted all of my TC archive volumes over to VeraCrypt to capitalize on the significant improvements in the code.

Not saying TC is bad for archive volumes, just there is more strength and iterations in the newer coding. You would have to do a full re-work of any system disks, so that is another "time slot" you'll need to consider. MY personal vote is VeraCrypt for archive volumes and Linux for system disks. You have to make up your own mind on that one.

I enjoyed coming alongside you on this thread. Best of luck to you!!


ps - the way you created partition 3 is the proper way. You actually should prefer having tracks in the decoy OS to demonstrate where the partition 3 volume came from. Your comments made me smile because its been a long while since I ran public binaries with that "read only" restriction in the code. Its a reasonable restriction for new users but I quickly outgrew it and made it go away. LOL!!

 

I'm continuing this slightly dated thread, as I was the OP and am now again having the same problem as mentioned previously. After my apparent success 2½ months ago the exact same problem (or something very close to it?) has returned.

In the meantime I was checking out Veracrypt as an alternative but found it much too slow for the CPU and my patience when mounting. So I have chosen to settle for Truecrypt 7.1a in combination with a very long and complex password.

I'm using the same hardware, same software, and same partition setup as before. Here's what I've done since trying out Veracrypt:
1) Wiped everything and installed Windows 7 (3 partitions, no 100MB 'hidden' partition).
2) Created an external image of partition 1.
3) Created an outer volume with hidden OS on partition 2.
4) Checked that the hidden OS password worked when restarting (it did).
5) Created an external copy of the volume header on partition 2.
6) Created an external sector image of partition 2.
7) Restored external image of partition 1, restarted, and started encrypting decoy OS.
8 ) When Truecrypt rebooted for the pretest, I tested the hidden OS password at the bootloader (it worked).
9) Restarted and entered the decoy OS password and let Truecrypt finish encrypting the decoy OS.

After this point (and I've redone the whole process a few times with the same result), when encryption of the decoy OS is complete, the hidden OS password will not boot the hidden OS, but returns the exact same error message as the one at the very beginning of this thread, followed by the GRUB4DOS menu.

I have a Truecrypt Rescue Disk, but writing a new bootloader does nothing. Trying to restore my external volume header of partition 2 from within Truecrypt also does nothing. The same goes for restoring the sector image of partition 2. None of these things makes the hidden OS bootable after completion of the decoy OS encryption.

I can only boot the hidden OS after restoring the external image of partition 1 and having begun (but not completed) the encryption of the decoy OS (ie. when Truecrypt reboots for its pretest).

Something that seems different this time is that when the decoy OS starts after the pretest, I have to start Truecrypt myself for it to continue with the decoy OS encryption. I believe that it started by itself the first time I was having these problems. However, when started it says 'Pretest completed' and continues on with the rest of the encryption process. Doesn't really look suspicious to me, but just not the way I remember it from earlier on.

So, in summary:
Same problem as earlier with the hidden OS password not working. I have a TC Rescue Disk, an external volume header of partition 2, and an external sector image of partition 2, but they do not help. I have confirmed several times that the hidden OS is functioning and that its password actually works with the new decoy OS bootloader until Truecrypt starts to actually encrypt the decoy OS (ie. right after the pretest).

Once I get everything working my plan is to periodically make a sector image of the whole disk, not just partition images etc., so I will have a single image file containing both decoy and hidden OSs and multiple partitions that I know will all work together. I am assuming that such an image file need not be further encrypted and can therefore be safe to have lying around. (?)

However, my situation right now is very deja vu for me, and I think I must be missing something. Any suggestions?

 

Can someone please help me? Since my last post I have searched the forum and elsewhere for a solution to my problem of not being able to boot my hidden OS. Nothing I've found seems to work.

As can be seen earlier in the thread, I actually got things to work 3 months ago. Unfortunately, I chose not to create a whole disk image as I quickly opted to give VeraCrypt a try instead because of its higher level of security. However, VC turned out to be too taxing for the CPU. Several minutes mounting is too much for my patience, so I chose to stick with TrueCrypt.

The error I keep on getting when entering the hidden OS password is this:
find --set-root --ignore-floppies --ignore-cd /bootmgr
Error 15: File not found
Press any key to continue...
..followed by a red GRUB4DOS menu.

At this point I am clueless as to how on Earth I got it to work 3 months ago. My understanding was that it had to do with the way I had been creating the decoy OS; that the process tampered with either the TC bootloader or volume headers.

I have of course reread all the previous help and tried to redo what ended up working the first time. Besides that:

- The hidden OS works just fine, but only boots until i start encrypting the decoy OS after the pretest. So the bootloader created by the decoy OS does actually work with the hidden OS. But after decoy OS encryption the above error message is shown if I try to boot the hidden OS. Why this happens is a mystery to me. I assume that it's still the same bootloader after encryption finishes..?

- I've tried to boot the hidden OS from the TC rescue disk, which results in the same error.

- Volume headers for partitions C and D (outer and hidden) have been rewritten. No change.

- Restored sector image of partition D (with the hidden OS on it). Even tried restoring a sector image of partition C created after encryption. Both did nothing.

- I've even tried to create and restore the partition backups with a different program (Macrium Reflect). I'm not sure if it also backed up the MBR with the system partition, as I couldn't find this anywhere in the program. When I marked partition C for backup, the program at the same time also marked the disk itself (without partition D and E), just like when clicking on drive vs. partitions in Partition Wizard.

- Thinking that there might be "leftovers" interfering with booting, I have tried rebuilding the MBR with Partition Wizard followed by rewriting the TC bootloader with the rescue disk (both done after restoring partition C). Still same error.

Could this be a hardware problem after all? I've examined the BIOS, but don't see anything suspicious. Perhaps I should try creating the same setup on another computer, just to hopefully convince myself that everything really can be done on the first try. However I really want the current computer to be the one that is used.

I'm really running out of ideas, so can anyone please help, or perhaps just point me in a productive direction?

 

Well I see you are back for more torture. You really have a head scratcher here! This is such a long thread that I may ask you something you already answered.

1. Are you able to mount the decoy OS and if so can you then currently mount the outer volume on partition 2? Remember the outer volume is supposed to be read and opened by the decoy so no forensic danger. Don't manipulate the contents just can it be opened cleanly? If you are only opening the outer volume you don't have to enable the protect hidden volume's content feature on TC. This will help us to determine if the second partition header is fully/partially destroyed. You cannot open the outer volume unless the header is there in partition 2.

## YES on question one is needed for question 2 to even matter

2. (Assuming you are going to eventually blow away the current decoy): using the mounted decoy OS and TC - what happens if you attempt to open the hidden volume (same header location as hidden OS - one and the same) on partition 2? i.e. - there could actually be a normal hidden volume there and TC wouldn't distinguish when you enter the correct password.

3. The most baffling thing in your posts above are where you state you wrote back a sector image of D after encrypting everything and it still doesn't work. What makes this confusing is that IF the decoy being encrypted walked on the header in partition 2 the re-write should have completely corrected that. Hmmmmmm. Long shot - by chance have you ever written back the sector image of D BEFORE encrypting the decoy? I am driving at confirming beyond suspicion that your saved sector image of D is fully intact. In this model you would be opening the restored sector image thereby confirming its intact. Logically if its intact, than writing it back after the decoy OS encryption might destroy it, would make all OK. Long way to verify if the sector D image is proven solid?

4. Are you in a position to take the sata drive (hard drive) to another computer with TC on it? If you have a simple usb to sata connector you can attempt to open both volumes on the second partition using TC on a second computer. I have tools to do the same thing in RAM on the same computer but if you lack those tools it might be easier to physically pull the sata and move it over. Very safe and easy if you have a connector sitting around. They are 10 bucks or less at many stores. Worth a shot since I am trying to eliminate the current computer from the mix just for a test of sorts.

5. Have you ever mentioned the EXACT make and model of computer you are using? I remember back on the TC forums where we had threads in place for those freaky machines that for some strange reasons just did not play well with TC. If you are hesitant to state your model than spend some time googling around looking for "net" threads containing complaints about encryption and THAT specific model.

I am starting to suspect hardware but lets see where these few ideas take you. I am fully open to other readers jumping on this thread.

 

Hi again. Yes, this encryption problem is a wee bit tougher than I would ever have expected.

1. Yes, the decoy OS mounts just fine. An so does the outer volume on partition 2.

Question: If one opens an outer volume while telling TC to protect a hidden volume - will that create any traces in the decoy OS of protecting a hidden OS? Because, if so, then one would have to copy all the decoy files that one wants to be on the outer volume at the point right before the hidden voume is created - and then never copy more files to the outer volume (while using the hidden volume protection).

2. Not sure what you mean by a 'normal hidden volume', but the decoy OS can mount the hidden volume just fine and calls its type 'hidden'. Is it supposed to be shown as 'system' just like partition 1? Explorer also opens the volume without any problems, and the contents look just like what's on the decoy OS volume, as I would expect.

Question: If one wants to create a combined outer/hidden volume header file, should this only be done using the hidden OS? Will it leave traces of a hidden OS if done using the decoy OS?

3. That's exactly what I just don't get. Rewriting the sector image of D should correct any such sector tampering. I can't help but feel that my sector images (from either program) don't contain 100.0% of the partition, but perhaps only 'user data sectors'. Both programs call the sector image a 'full image', so I would expect the volume header to be included in that.

I may have misunderstood what you want me to do, but here's what I've done:

I rewrote the sector image of D (made with Macrium) to test if I can boot the hidden OS. On restart there is no TC bootloader, just a blank screen with a blinking cursor and a clicking sound every time I press a key. Hm.. seems to me that something may be wrong with my sector image of D.

So now I decided to experiment a little. I rewrote the TC bootloader and tried the hidden OS password. Same error 15 as all the way through this thread. Then I tried the decoy OS password, which returned the error "No bootable partition found".

After this I tried another sector image of D (made with Aomei a month ago). On restart the TC bootloader was still there, but same result (error 15).

Then I rewrote my sector image of the encrypted C, which made the decoy OS work again, but not the hidden OS (error 15).

Then I once again rewrote my most recent sector image of D, just to check again. This resulted in the blank screen with blinking cursor and clicking sounds when pressing keys.

I tried to rewrite the volume header for C using the TC rescue disk. It said that the drive already contained a valid header, but I rewrote it anyway. This did nothing.

I rewrote the TC bootloader. This made the decoy OS bootable, but not the hidden OS (error 15).

Seems to me that my newest sector image of D (Macrium) not only restores an inadequate D but also a faulty/erased MBR. And the older sector image (Aomei) just restores an inadequate D. The question must then be exactly how much of D they each restore. That's what I meant earlier when I wrote that I wasn't sure that the sector image was a 100.0% true copy - that the very first (and/or last?) sectors or something else might be missing for some reason.

There clearly is a missing link between the TC bootloader and the hidden volume, and this is most probably because of faulty/lacking sector images of D. However, I do believe that I've created my images the way it's meant to be done (at least in Aomei), as the programs are relatively straighforward to use. Aomei even asks concerning C if it should make a 'system image' (which I assume means including the MBR), so it clearly differentiates between the types. And one just has to click on 'make an exact backup' to get a sector-by-sector image. This stuff is not anywhere near rocket science, but I'm apparently missing something when creating my sector images. But what?

4. Connected the drive to another computer via a USB/SATA bridge. Immediately following what I'd done just above, TC said that there were no TC volumes on the drive (in fact no partitions on it). And this is even with the current decoy OS in working condition and reporting 3 partitions on the original computer and being able to mount both the outer and hidden voumes on D. Interesting. I also tried VeraCrypt with and without 'TC mode', and TC on a third computer, same results.

Actually, several weeks ago I tried connecting the drive to another computer, and there were no problems at that time seeing the TC volumes or opening outer/hidden volumes.

5. The computer I'm using is a Lenovo Thinkpad Edge E135. I've tried googling for someone having any encryption/TC problem using it, but haven't found anything interesting.

Question: Are there certain pieces/types of hardware that generally give trouble when using encryption? I've read in the forum that some new computers only offer UEFI and not legacy BIOS, but are there other hardware or software concerns one should be aware of (and that this computer perhaps happens to have)?

 

This is exactly how the software and hardware should work. It also confirms that something has changed, but what?

You are absolutely certain the separate ~100-250 meg bootmgr/hidden partition does NOT exist on this drive? I assume you know how to check for that because it won't reveal itself in Explorer or Disk Mgmt. Not trying to insult you but that issue produces something very similar to what I keep reading here (on some machines). They work and then a systems update, which can change that hidden partition, causes things to "crash" next boot.

Lenovo Thinkpads, absent any hardware fatigue, play very well with TC and VC. I have a thousand hours using/coding TC on various Thinkpads. At one point I had 3 hidden OS's running with TC on one Thinkpad, so it allowed some "unique coding" and stood up to it just fine!

1. Do you happen to have a spare sata sitting around that you could slap two partitions on as a test? Keep them small -- > if your sata drive is large just leave lots of unallocated space at the tail of the geometry, or a blank third partition, doesn't matter. Test only - get it? I am just trying to narrow down where the issue is coming from. That fact that the "other" computers can no longer see the sata geometry (partitions) is very concerning. It could be an issue on the motherboard, or the sata drive, or ? At this point I am not saying to go buy a new sata, but if one is gathering dust it would be worth the time to investigate using it. An idea anyway. Create the outer volume using FAT32 and you'll only have to add 5-10 % to your system disk for space -------- testing only.

2. You appear to be saying that if you create the hidden OS, and then created a TC rescue disk, and then simply installed your vanilla decoy all would run fine. It would be safe to run this way in the short term (knowing that is not your end game). Since you have Ultimate you could use Bitlocker for the normal system disk, and then have a TC USB to mount the hidden OS. You would need to keep the usb concealed but it would work fine. Perhaps a "B" grade idea but its something that offers a possibility short term. Based upon your tenacity here you'll likely keep at this, but if you weary suggestion 2 is an immediate out!

 

Yes, I'm absolutely certain that there is no 100 MB 'hidden' partition. There is none to see in either Disk Management, the backup programs, or in Diskpart. Diskpart shows the offset value of the decoy OS partition as 1024 KB.

I do have a 100 MB 'hidden' partition on another computer, and it can be seen in Disk Management as the first partition ('system reserved') on the system disk, followed by the C partition with Windows on it.

When I originally installed Windows on the drive that's giving me problems, Windows of course created the 100 MB partition automatically before it created the C partition for Windows. I then created partition D and E. Then I deleted the C partition and expanded the 100 MB 'system reserved' partition to fill the void left by C and then reformatted it so it no longer was a 'system reserved' partition, but changed to a normal one. I then let Windows install on C, which it has always done without any complaints.

Perhaps the TC bootloader doesn't like that the hidden volume is a copy of a combined 'system reserved' and normal C drive? Perhaps it expects that the hidden 100 MB partition will always be there? But still, we DID get it to work 3 months ago, without a 100 MB hidden partition, so I don't see a problem with it. Honestly, I'd rather NOT have those unencrypted 100 MB on my disk, plus I've read about such a 'system reserved' partition giving other people problems when using TC.

Besides a faulty disk (it's only 2-3 years old with very light wear), I can only think of some hardware problem or perhaps 'leftover' code in critical areas giving rise to the trouble, but these partitions have been wiped numerous times now, and the MBR has also been rebuilt a few times.

1. Yes, I do have another unused sata drive - thanks for the reminder.

But what exactly is it you want me to do? Create two small partitions with a from-scratch decoy + hidden OS setup? Or something simpler?

2. No, except for that one time 3 months ago when it suddenly worked, I have never had both passwords work at the same time. Every single time it appears to be the finalizing encryption of the decoy OS that breaks the link between the TC bootloader and the hidden OS starting.

The TC rescue disk is first created when encrypting the decoy OS, and you've said a few times that it is decoy OS specific. Does that mean that it won't make any difference to create a TC rescue disk by using the hidden OS before creating the decoy OS?

I'm not sure how my 'user experience' would be with a TC USB, as I don't understand how that setup works, so I have no opinion about that.

 

I've had some surprising (and slightly embarrassing) progress.

I wrote my image of the donor OS to a long forgotten unused sata harddisk and proceeded to make a new decoy + hidden OS setup. When all was done, I tested the passwords which both worked! As I wrote in a previous post, I hoped that trying it out on another computer would show me that it can in fact be done on the first try. So it turns out that something has apparently gone wrong with my laptop's harddisk.

Next, I wanted to test out the 'old' drive, so I started by using Partition Wizard to delete the partitions, wipe it completely and rebuild its MBR. Then I created a sector image of partitions 1 and 2 from the 'new' drive, followed by their writing to the 'old' drive. Lastly, I used the TC rescue disk to write a TC bootloader (as the backup program doesn't recognize the encrypted C partition as a system partition). However, this did not work: 'No bootable partition'. So I restored the volume header. No change. Hmm..

Does this mean that the 'old' harddisk IS in fact somehow faulty, or is there something else that needs to be done to make the two OSs boot? Do I need to 'prepare' the drive in any certain way? Did I perhaps create my backup of C the wrong way? I assume that when it's an encrypted partition, then I can just back it up as a normal 'non-system' partition using the sector-by-sector mode? And then I would assume that all that's then needed is the TC bootloader. Or am I wrong about this?

It would be really nice if I somehow could get the drive to work, as it's a 'slim' type (7mm), which I'm not gonna find in any shop around here before next week. All my other 2,5" drives are 9,5mm, so even though I can manage to slide them into the connector in the laptop, they are too thick to fit in the drive bay.

Any advice or hints for making the drive functional?

 

Glad the swap SATA suggestion worked for you. So now you have a working system. Yeah.

Regarding the original sata drive I have one suggestion, which I would do immediately because its FREE, and because I love to challenge myself with stuff like this. I can tell you that for some reason that I have never figured out this works almost half the time, even when Partition Wizard and other tools don't. Don't ask me to explain why, it just does, but not quite half the time. Got a few hours for a test? I already know your personality is going to answer yes.

You are going to fully delete the disk partitions and then clean the disk. I know you have done this already with Part Wizard but now we are going to let Windows do it using Part Disk via the Admin Panel. Do you know how to use Partition Disk using Windows?

I would suggest reading just a little if you didn't immediately answer yes to my question before proceeding. Its easy though.

Block Diagram (not specific step by step): open command line in ADMIN mode, which looks similar to a linux terminal. open disk part and then select the device in question. Issue the Clean ALL command not just clean. The clean all command will remove all disk partitions and completely strip the device to raw. Windows will then take the partition-less raw space and clean it thoroughly. When finished you will see that its done. NOW --- stay with windows and create the partition simple volume and then format it all using Win 7. Using this method I have turned numerous disks around that were dead in the water using third party software tools. Bear in mind you may be wasting your time but if you are like me the challenge alone makes it worth it. Hardware is hardware --------- if its bad its bad, but if it just "clogged up with ****" this may clean it off for you. Good luck and let us know.