15 replies to this topic

[Wonko the Sane]

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

 

Wonko

[Wonko the Sane]

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".


Wonko

[Wonko the Sane]

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

 

Wonko

[Wonko the Sane]

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).

 

Wonko

[Wonko the Sane]

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.

 

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.

 

Wonko   

[Wonko the Sane]

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

 

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.

[BlackDragon]

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 

[Wonko the Sane]

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 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.

 

Wonko