Jump to content











Photo
- - - - -

Chainload BestCrypt Volume Encryption MBR with GRUB4DOS?


  • Please log in to reply
8 replies to this topic

#1 AnonVendetta

AnonVendetta

    Silver Member

  • Advanced user
  • 643 posts
  • Location:A new beginning.....
  • Interests:Self-development, computing

Posted A week ago

OK, so I'm doing some tests in a VMware Workstation VM, and I would like to chainload BCVE's bootloader with G4D. I had tried encrypting Windows 10 with BCVE in VirtualBox, but 10 kept complaining that it couldn't find the boot volume. My setup is legacy BIOS on MBR. I had tried with a single NTFS partition as the C drive, containing Windows as well as boot files. And with a System Reserved volume containing boot files, and a separate partition for Windows. With VMware there is no issue booting while encrypted with BCVE.

 

Getting on with it, I've been toying around with G4D a bit lately, and it is a bit daunting because I am not familiar with maintaining its' menu.lst config file. I have already been successful in creating entries that can boot Debian and Gentoo (not in a VM).

 

My method of installing G4D is:

1. Download http://dl.grub4dos.c...a-2017-12-23.7z, I am going with this because I think I remember the Easy2Boot dev stating that it is most stable version of G4D so far

2. Extract file contents into an unencrypted NTFS partition

3. Install G4D MBR by using the "Restore" MBR feature of BootIce, restored file is grldr.mbr, target disk is the same (only one) disk that 10 is installed to

4. Add a entry to menu.lst that chainloads 10's bootmgr, ensure that it boots

 

But now I would like to throw BCVE into the mix. Chainloading bootmgr directly is no longer an option, since it is located in an encrypted volume. If I first install G4D and then encrypt with BCVE, it appears that BCVE relocates G4D to some area of the disk, probably outside a partition, or embedded somewhere in the C drive. BCVE loads first and then hands off to G4D after the correct password is typed. It may also be relocating it to the 1MB unallocated space at the end of the disk, even though this space isn't shown in GParted when partitioning, I am sure that it is there because the ending sector of the last partition isn't the same as the ending sector of the actual disk. This isn't the desired behavior, I want G4D to be the first bootloader to load, so it needs to be in the MBR.

 

I think the best way to accomplish this is to:

1. Install and encrypt with BCVE, while first only having original Windows 10 boot code in the MBR

2. Make a copy of the BCVE MBR with BootIce.

3. Reinstall original Windows 10 MBR boot code by running the 'bootrec /fixmbr' command from a 10 setup ISO

4. Install G4D by following steps 1-4 above

5. Create a menu.lst entry that chainloads the BCVE MBR file

 

This attempt has failed, every time I try to chainload this MBR nothing happens, G4D goes to boot the entry and then hangs on a "_" cursor, no error is given.

 

I also know that BCVE has an option to move the encrypted volume's key to either external storage or an ISO, but this seems overly complex in contrast to just chainloading an MBR image.

 

Thanks for any help!



#2 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 14257 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted A week ago

5. Create a menu.lst entry that chainloads the BCVE MBR file

 

This attempt has failed, every time I try to chainload this MBR nothing happens, G4D goes to boot the entry and then hangs on a "_" cursor, no error is given.

 

the 5. should be:

issue a set of commands (insert here the EXACT commands given AND the whatever grub4dos provides as feedback after each command) on grub4dos command line.

 

The method worked just fine, see around here:

http://reboot.pro/to...record/?p=40910

 

but of course it depends on the commands used.

 

It is also possible that in the ten years since the above mentioned reports by ktp *something* has changed in either BestCrypt or grub4dos, but it is unlikely :unsure:

 

:duff:

Wonko



#3 AnonVendetta

AnonVendetta

    Silver Member

  • Advanced user
  • 643 posts
  • Location:A new beginning.....
  • Interests:Self-development, computing

Posted A week ago

Am I correct in assuming that the G4D bootloader is little more than a command interpreter, that just reads the menu.lst and executes the commands line by line? If so, then wouldn't it be sufficient to write out the contents of menu.lst instead? I am not familiar with doing the commands manually.



#4 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 14257 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 6 days ago

Am I correct in assuming that the G4D bootloader is little more than a command interpreter, that just reads the menu.lst and executes the commands line by line? If so, then wouldn't it be sufficient to write out the contents of menu.lst instead? I am not familiar with doing the commands manually.

The point is that each single command may (or may not) give feedback in the form of:
1) actual feedback from the command interpreter (such as an error or a diagnostic message)
2) a "hang"
3) something else

When you use the menu.lst you have no way to know which command did what, all you can see is - maybe - the last feedback by the last command that either succeeded and provided the feedback or hanged, but you have no way to know WHICH was the last command that created the *whatever* you obtained as result of a menu.lst entry.

The contents of menu.lst are good enough (in a request for help/assistance), as an example if one of the commands in the menu.lst is evidently wrong someone may spot the problem, but for actual experimenting and troubleshooting the approach on command line, with commands one at the time and related feedback are the best way to proceed.

Besides, this way you can issue/insert "diagnostic/lookup" commands (such as - only as an example - "map --status" or "set var") to see if the environment is correct, etc.

You could enable debug or even better single-stepping however, see:
https://www.rmprepus...orials/grub4dos
search in the page for "single-step".

:duff:
Wonko



#5 AnonVendetta

AnonVendetta

    Silver Member

  • Advanced user
  • 643 posts
  • Location:A new beginning.....
  • Interests:Self-development, computing

Posted 6 days ago

I'm going to rebuild my VM for a clean start, since I have did other things in it that aren't related to what I want to test. I'll report back later.



#6 AnonVendetta

AnonVendetta

    Silver Member

  • Advanced user
  • 643 posts
  • Location:A new beginning.....
  • Interests:Self-development, computing

Posted 3 days ago

It looks like BCVE doesn't install any PBR code into the C drive. I did a backup of C's PBR with BootIce, before and after encrypting with BCVE, both files have the same checksum. I just mention this because the linked post(s) keep mentioning something about chainloading a PBR, which is different from the MBR. The MBR sector's current length is only 1, but I think G4D uses more (either 8 or 16, can't remember which). But wouldn't that make it go well past the MBR and partition table and maybe into a filesystem in the 1st partition?

My current setup is pretty simple, 2 primary partitions, the first is Windows and boot files and marked as bootable, the 2nd is an unencrypted Data partition where G4D's files will live. G4D's files are in place but with an empty menu.lst, and I have not written it into the MBR yet.

I use BootIce to make a backup of the post-BCVE MBR, and have a snapshot ready to revert to if something doesnt work. That way, I'm not locked out of the VM and forced to rebuild it again.

#7 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 14257 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 2 days ago

Two points of note:

1) it is not like you *need* to install the grub4dos grldr.mbr (anyway it is 16 sectors, so it uses 15 sectors beyond the MBR, and you have either 62 or 2047 normally unused sectors before the first partition), but you can well chainload it from your other boot manager (like Windows BOOTMGR) without needing to "install" it

2) the given thread never mentions chainloading a Bestcrypt or Truecrypt PBR (which as you verified doesn't actually exist), it mentions how mr_ thought to install grub legacy to the PBR (which he never actually did), the actual report is by ktp that successfully chainloaded a copy of the Bestcrypt MBR:

http://reboot.pro/to...record/?p=40928

 

:duff:

Wonko



#8 AnonVendetta

AnonVendetta

    Silver Member

  • Advanced user
  • 643 posts
  • Location:A new beginning.....
  • Interests:Self-development, computing

Posted 2 days ago

Yes, I know there is no need to install it into the MBR, since it can be chainloaded other ways. But I simply don't trust Windows Boot Manager to chainload anything except into itself, especially Windows 10's incarnation. Windows 10 has become such a fuckup OS as of late. I would be more likely to trust GRUB2 or SysLinux to chainload G4D. But that still adds an additional layer, and longer wait times. My goal is to set up G4D as the so-called "master" bootloader which chainloads everything else, including other bootloaders if necessary. And I can even do emulated UEFI with G4D, so even better, I get to have my cake and eat it too. I've done alot of reading and came to the informed conclusion that G4D is the bootloader I would like to have at the top of the food chain, due to its' flexibility, scripting capabilities, ability to boot almost anything including other loaders, etc. So yes, in my case, it does need to be in the MBR, at least as long as I stick with MBR partitioning.



#9 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 14257 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted A day ago

Well, you can still have it NOT in the MBR, and use the UMBR which remains a single sector in length, though that will create some limitations (the grldr file cannot be moved without updating the UMBR).

Anyway, as said, you don't need to worry if you install it, normally the grldr.mbr will not interfere with anything (the 16 sector length is only an issue in rare cases - typically old DOS programs - where the hidden sectors are used either as part of a status log or as authentication/copy protection).

 

:duff:

Wonko






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users