Jump to content











Photo
- - - - -

Chainload BestCrypt Volume Encryption MBR with GRUB4DOS?


  • Please log in to reply
15 replies to this topic

#1 AnonVendetta

AnonVendetta

    Silver Member

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

Posted 11 September 2018 - 01:42 PM

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
  • 14323 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 11 September 2018 - 02:01 PM

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
  • 655 posts
  • Location:A new beginning.....
  • Interests:Self-development, computing

Posted 11 September 2018 - 03:07 PM

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
  • 14323 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 11 September 2018 - 05:32 PM

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
  • 655 posts
  • Location:A new beginning.....
  • Interests:Self-development, computing

Posted 11 September 2018 - 06:12 PM

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
  • 655 posts
  • Location:A new beginning.....
  • Interests:Self-development, computing

Posted 15 September 2018 - 02:55 PM

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
  • 14323 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 15 September 2018 - 04:41 PM

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
  • 655 posts
  • Location:A new beginning.....
  • Interests:Self-development, computing

Posted 16 September 2018 - 07:30 AM

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
  • 14323 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 16 September 2018 - 04:09 PM

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



#10 AnonVendetta

AnonVendetta

    Silver Member

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

Posted 20 September 2018 - 07:36 AM

I checked in GParted (Parted Magic) and it says the 1st partition starts on sector 2048. So GParted must have aligned the partitions to 2048 sectors when I partitioned (I didnt let the setup installer do automatic partitioning). I made a backup of the first 2047 sectors with BootIce. Do you think it will be more effective to just chainload the 512 bytes MBR (since BCVE apparently doesn't use a PBR), or should I try to chainload the 2047 sectors image instead? I am thinking that maybe BCVE stores data beyond 512 bytes, but doesnt extend any boot code into the first partition.



#11 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 20 September 2018 - 09:41 AM

At least in the given thread ONLY the MBR (512 bytes) was chainloaded, and there is no reason why this might have changed in the meantime. :dubbio:

 

In any case on a normal disk, sectors LBA 1-2047 would be blank, or in the case of a grub4dos was installed,  sectors 1-15 contents would be the same as the grldr.mbr used, of course sector 1 may contain the data of the "previous" (previous at the time grub4dos was installed) MBR.

 

If you prefer, you can normally copy the first sector of the disk to a file, append 2047 blank sectors and re-deploy  it to the disk, thus keeping the relevant partition table data.

 

Whether the disk will still be bootable or not will depend on the kind of MBR code, if single sector (like most MBR codes) or multi-sector (like grub4dos grldr.mbr), but you will be able to reinstall any MBR code.

 

:duff:

Wonko   



#12 AnonVendetta

AnonVendetta

    Silver Member

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

Posted 22 September 2018 - 01:05 PM

I am going to try zeroing out sectors 513 to 2047 in a hex editor, just to see if BCVE places any code beyond the first sector. If it doesn't boot then I can just restore the snapshot. Then I will know exactly how much needs to be chainloaded.

 

But the partition table is also within the MBR, and I'm not sure that part needs to be chainloaded too (or maybe it does?). If I'm not mistaken the boot code ends at 446, partition table starts at 447 to 510, and the last 2 bytes are the so-called "magic #" bytes. Correct? So if I zero everything from 447 to 2047, then that might be a better test?

 

Quick question, I know primary partition entries are in the MBR, but what about for logical partitions? Are those accounted for in the MBR? And for extended partition (which is really just a primary acting as a container for logicals)?. I think I read somewhere on Wikipedia that logical/extended entries are located in the actual partition, not in the MBR.

 

Thanks!



#13 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 22 September 2018 - 02:41 PM

I am going to try zeroing out sectors 513 to 2047 in a hex editor, just to see if BCVE places any code beyond the first sector. If it doesn't boot then I can just restore the snapshot. Then I will know exactly how much needs to be chainloaded.

 

But the partition table is also within the MBR, and I'm not sure that part needs to be chainloaded too (or maybe it does?). If I'm not mistaken the boot code ends at 446, partition table starts at 447 to 510, and the last 2 bytes are the so-called "magic #" bytes. Correct? So if I zero everything from 447 to 2047, then that might be a better test?

 

Quick question, I know primary partition entries are in the MBR, but what about for logical partitions? Are those accounted for in the MBR? And for extended partition (which is really just a primary acting as a container for logicals)?. I think I read somewhere on Wikipedia that logical/extended entries are located in the actual partition, not in the MBR.

 

Thanks!

 

You are confusing bytes with sectors (and possibly also offsets).

 

A sector is made of 512 bytes.

The MBR is one (first absolute) sector, conventionally indexed as sector LBA 0.

Inside it, also indexed with start offset 0, there are 512 bytes,  first byte is offset 0, last byte (the 512th one) is offset 511.

In the MBR:

From offset 0 to 439 there are 440 bytes that are code.

From offset 440 to 443 there are 4 bytes that are the Disk Signature.

From offset 444 to 445 there are 2 bytes that are normally unused.

From offset 446 to offset 509 there are 64 bytes that are the partition tables (4 entries, each 16 bytes).

From offset 510 to offset 511 there are two bytes that are the "Magic Bytes" 55AA.

 

You have the first partition starting at sector LBA 2048, i.e. you have 2048 sectors before it, conventionally addressed as LBA 0 to LBA 2047, in bytes, you have

2048 * 512 = 1,048,576 bytes before.

 

When using disk addresses for bytes,  LBA:Offset is used, i.e. the address of the "Magic Bytes" in the MBR is:

0:510

whilst the address of the first byte in the PBR is:

2048:0

 and Magic Bytes in the PBR is:

2048:510

 

Normally you leave the first sector (the MBR) or the first 512 bytes if you prefer, alone.

 

If you want to write 00's from sector LBA 1 up to sector LBA 2047 that is fine, you will simply makes sure that the "hidden sectors" or "sectors before" are filled with 00's (which normally already are).

 

The moment you overwrite the Magic Bytes in the MBR, the disk will become "not initialized" in Windows.

 

About partitions, think at them like this.

 

A volume (or - if you prefer - the *whatever* eventually gets a drive letter is windows) is ALWAYS "inside" a partition.

A Primary partition contains only one volume and this volume extends from the first sector of the partition to the last sector of the partition [1]. 

An Extended partition contains one or more volumes.

You can have ONLY one Extended partition in the MBR, i.e. you can have at the most four Primary partitions or three Primary + 1 Extended.

The mechanism by which more than one volume is indexed inside Extended is a "chain".

The first sector of the Extended Partition is a sort of MBR (sometimes called EMBR) in that it has a partition table, where the first entry is the first volume and the second entry is the address to the "next" EMBR, which has as first entry the second volume and as second entry the "next" EMBR .... and so on.

 

You will need to read the (by now historical) page on Goodell's site to better understand:

https://www.goodells...artitions.shtml

https://www.goodells...ot/ptable.shtml

 

:duff:

Wonko

 

[1] Not exactly-exactly, this applies to most filesystems BUT on hard disks or however partitioned media NTFS behaves differently the actual volume is one or more (up to 15) sector(s) smaller than the partition, see:

 

http://reboot.pro/to...ated-with-dsfo/

on the other hand (again for NTFS) what is called "Logical volume inside Extended" is actually given an extent that is one or more sectors more than the volume size, for the same reasons, so it can be called also "Logical partition inside Extended".

And if you think it is confusing it is mainly because it is.



#14 AnonVendetta

AnonVendetta

    Silver Member

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

Posted 22 September 2018 - 10:50 PM

I just examined my 2047 sectors backup file in a hex editor, the first sector (512 bytes) ends with 55AA. After that it is just zeros all the way to the end of the file. I just had a chimp at my zoo job scroll my mouse wheel and visually check for zeros. As a reward he received bananas.

 

So now I know that BCVE uses compact boot code that is entirely located in the MBR.



#15 BlackDragon

BlackDragon
  • Members
  • 3 posts
  • Interests:Gentoo Linux, Debian Arch and Kali.And Constantly Fixing Winblows, (yes I Said Winblows No Typo.)
  •  
    United States

Posted 22 September 2018 - 11:55 PM

I have a question, I was reading a post on this form and saw something about a program called PowerQuest's Partition Table Editor and was wondering where to download it. and I saw it was produced by Symantics which produce of all things Norton so my question is this is this worth downloading and if so will it be a useful tool 



#16 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 23 September 2018 - 12:04 PM

I have a question, I was reading a post on this form and saw something about a program called PowerQuest's Partition Table Editor and was wondering where to download it. and I saw it was produced by Symantics which produce of all things Norton so my question is this is this worth downloading and if so will it be a useful tool 

The issue is that it is not (anymore) available.

 

It used to be on the Symantec/Powerquest ftp site, but it has since been removed, and since its licensing status is unclear (most probably it is proprietary) it cannot be redistributed.

It was here:

ftp://ftp.symantec.com/public/english_us_canada/tools/pq/utilities/PTEDIT32.zip

you may be lucky googling for PTEDIT32.ZIP

 

 

It is an useful tool as long as you need to manually change something in partition tables (and also bootsectors).

Depending on what you need to do and the OS you are running there are alternatives.

 

First one that comes to mind (historically) is Beeblebrox (which was written by a programmer that also wrote part of the Powequest tool) in a good, working version (that however has some issues on some Windows versions):

https://web.archive....byu.edu/~codyb/

 

and in a more modern Java :w00t: version that never worked for me:

https://sourceforge....-windows/0.0.2/

 

but at the time there were not that many alternatives, now there are plenty, including some developed here on reboot.pro by erwan.l and others.

 

So it all depends on what you want/need to do, remembering that you can make big damages using a partition table editor improperly, particularly since a few things changed since the time those tools were developed.

 

:duff:

Wonko






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users