[INVALID] Booting ISO from TrueCrypt system disk

tigr

Member
Hi,

It seems that booting ISO images doesn't work when the disk containing the BCD and the ISO image is encrypted with TrueCrypt using full system disk encryption. This doesn't work for both "run from disk" and "run from memory" modes. What happens is that the image is loaded into the memory (I can see the loading progress) and an initial message (if any) is shown by the ISO's boot record, but then the computer just freezes. I've tried this on an internal SATA drive and external USB drive using several ISO images, the result is always the same. Booting from unencrypted disk works fine.

My best guess (but only a guess) is that the code reading the ISO contents from disk somehow bypasses int13h interrupt of BIOS where TrueCrypt bootloader hooks to decrypt the data on the fly. This would mean that the ISO is read into memory in an encrypted form. But in that case I can't explain how the ISO boot code showing the message is executed correctly – is the boot code copied somewhere when ISO entry is added to BCD?

Best regards,
tigr
 
This wouldnt be a bug with EasyBCD but a bug to report to Microsoft about their BCD overall. EasyBCD is just a graphical interface for the BCD. All it does is allow you something pretty to look at when you modify the BCD. Other than that everything that happens is what Microsoft has done to it. So if the BCD cant read encrypted boot contents, that is something that they intended or they need to know about to fix.
 
EasyBCD is just a graphical interface for the BCD. All it does is allow you something pretty to look at when you modify the BCD. Other than that everything that happens is what Microsoft has done to it.

Not exactly. As far as I understand, for booting ISO images EasyBCD creates custom (Grub-based?) loaders. Apart from that, booting from WIM images (supported natively by BCD) works fine, so it's rather a problem with this custom EasyBCD ISO loader.
 
To the contrary, NeoGrub/EasyBCD use the int13h interrupt - which I would think is why TrueCrypt isn't working. Are you sure TrueCrypt "intercepts" int13h calls?
 
Interesting. I'll open a bug report, but to be perfectly honest, it's going to be very low priority as it will entail much work and there's a fairly simple workaround.
 
It's less than ideal, but an unencrypted partition on your disk with the images on it should solve the problem, no?
 
It's less than ideal, but an unencrypted partition on your disk with the images on it should solve the problem, no?
Well, first, even if only the system partition is encrypted (in contrast to the whole system disk) and ISO images are on another, unencrypted partition, there's still TrueCrypt bootloader with its int 13h code so it's not certain whether this would work without knowing the exact source of the problem. Second, it's hardly a workaround – it's rather giving up encryption of part of the data while the whole point of using encrypted system disk is to have all the data encrypted.
 
Hey, I'm just telling you the way it is. I could tell you it's high on my priority list, but that would be lying. EasyBCD w/ NeoGrub and ISO boot has been out for many, many years and we have many TrueCrypt users; but this is (apparently) the first time someone has tried to put the two together. I'm acknowledging the issue, but at the end of the day, there's a very real triage system going on; there are other issues and features that take a much higher precedence here.
 
Hey, I'm just telling you the way it is.
And I understand this, your explanation is perfectly valid to me. I'm just trying to describe my situation as clearly as possible, don't read my posts as a resentment of any kind.

Anyway, is the code used by NeoGrub available somewhere so I could try and investigate the issue closer by myself?
 
After more investigation I can only say that the issue seems to be really complex. For instance I tried running the same tests on VirtualBox and, although the images also didn't run properly with encryption, they failed on a much later stage than bootloading. I also found one image that runs flawlessly in each scenario. So it seems that the factors here are not only TrueCrypt and NeoGrub, but also the hardware and the image contents itself. The reason may be indeed that there's something messed up with the interrupts (grub4dos installs yet another layer of handlers over the same interrupts that TrueCrypt does), but that's still nothing sure. I guess I will indeed have to give up encryption... :/
 
Tigr, that's actually been my/our general finding with regards to ISO boot. NeoGrub/grub4dos does it OK and will load things properly via the int13h interrupts, but the software you load almost always inevitably assumes it's actually being run from the CDROM drive and redoes the hard disk identification and search via it's own methods, and usually not via int13h. That's why you can only install a few Linux distros from ISO emulation, you can run Windows repair from the setup CD but not install, and so on and so forth.
 
Back
Top