Jump to content











Photo
- - - - -

[RELEASE] mbrview.g4b a BAT! tool for grub4dos


  • Please log in to reply
69 replies to this topic

#51 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 31 October 2013 - 08:09 AM

Very good. :)

Can you post it as and attachment (inside a .zip file)?

There are known issue with copy/paste through different browsers :w00t: and there is always the risk of yet another big CODE box corruption at the next board software update.   :ph34r:

 

:cheers:

Wonko



#52 nando4

nando4

    Frequent Member

  • Advanced user
  • 112 posts
  •  
    Australia

Posted 31 October 2013 - 02:38 PM

Very good. :)

Can you post it as and attachment (inside a .zip file)?

There are known issue with copy/paste through different browsers :w00t: and there is always the risk of yet another big CODE box corruption at the next board software update.   :ph34r:

 

:cheers:

Wonko

 

You are welcome to post it on the first post, replacing or supplementing the version there. I just removed the wenv calls and replaced them with grub4dos native calls. The body of work is primarily of your creation.

 

You can see there was plenty of discussion about wenv and it's performance. Given the grub4dos improvements since this script was released,  I felt wenv just added an extra layer of complication that was no longer necessary.



#53 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 31 October 2013 - 07:46 PM

You are welcome to post it on the first post, replacing or supplementing the version there. I just removed the wenv calls and replaced them with grub4dos native calls. The body of work is primarily of your creation.

 

You can see there was plenty of discussion about wenv and it's performance. Given the grub4dos improvements since this script was released,  I felt wenv just added an extra layer of complication that was no longer necessary.

I will gladly do, but if you could post it in the form of a .zip archive, I would be sure that it is the actual version that you tested, and not a copy/paste of the code.

Believe me when I tell you that anything (and the contrary of everything can happen), JFYI:

http://reboot.pro/to...st-and-ddlistw/

Please note how the original misadventures described happened long before (and caused by browsers like Internet Explorer/firefox/whatever ) the good IPB board guys decided to botch each and every codebox on any board in the world through one of their updates, and please note how that particular thread's code boxes were affected by two subsequent "botching updates" by them, the first one failing to interpret parse a number of characters and the second one removing newline/linefeeds).

 

:cheers:

Wonko



#54 nando4

nando4

    Frequent Member

  • Advanced user
  • 112 posts
  •  
    Australia

Posted 01 November 2013 - 03:23 AM

Wonko, find the modified mbrview.g4b in attached ZIP file.

Attached Files



#55 Gerolf

Gerolf

    Member

  • Members
  • 75 posts
  •  
    Germany

Posted 28 April 2018 - 04:19 PM

Since the result is going to be displayed as a hex number I think the four bytes of the MBR's disk signature

cat --hex --skip=440 --length=4 %target% | set disksig=
set disksig=%disksig:~10,2%%%disksig:~13,2%%%disksig:~16,2%%%disksig:~19,2%
echo Drive=%target:~0,5%, Signature=%disksig%

should be interpreted as little endian and thus be concatenated in reversed order like this:

set disksig=%disksig:~19,2%%%disksig:~16,2%%%disksig:~13,2%%%disksig:~10,2%

Compare the following construction:

dd if=%target% of=(md)0x300+1 > nul ;; :: 0x300 x 512 = 0x60000
set /A disksig=*0x601b8&0xffffffff > nul ;; :: +0x1b8 = +440: disk signature in MBR
echo Drive=%target:~0,5%, Signature=%disksig:~2,8% ;; :: remove leading "0x"

Then you get the same result that e.g. Minitool Partition Wizard shows for the corresponding device.

https://en.wikipedia...d#Sector_layout



#56 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 28 April 2018 - 05:08 PM

Since the result is going to be displayed as a hex number I think the four bytes of the MBR's disk signature

cat --hex --skip=440 --length=4 %target% | set disksig=set disksig=%disksig:~10,2%%%disksig:~13,2%%%disksig:~16,2%%%disksig:~19,2%echo Drive=%target:~0,5%, Signature=%disksig%
should be interpreted as little endian and thus be concatenated in reversed order like this:
set disksig=%disksig:~19,2%%%disksig:~16,2%%%disksig:~13,2%%%disksig:~10,2%
Compare the following construction:
dd if=%target% of=(md)0x300+1 > nul ;; :: 0x300 x 512 = 0x60000set /A disksig=*0x601b8&0xffffffff > nul ;; :: +0x1b8 = +440: disk signature in MBRecho Drive=%target:~0,5%, Signature=%disksig:~2,8% ;; :: remove leading "0x"
Then you get the same result that e.g. Minitool Partition Wizard shows for the corresponding device.
https://en.wikipedia...d#Sector_layout
Yes and No. :dubbio:

Meaning that not necessarily Minitool Partition Wizard has *any* authority on how to display or interpret 4 bytes, a Disk Signature is either a Signature or a number, compare with the known issue about "Magic Bytes":
http://starman.vertc.../mbr/AA55H.html

Try running WMIC as follows:
wmic diskdrive get name, signature

very likely you will find decimal negative numbers as a result. :w00t:

On the other hand in MountedDevices in the Registry you will find the 4 byte sequence EXACTLY as it is written in the MBR at offset 440 as you can check with a hex editor. (i.e. as MBRview shows it)

And if you run Diskpart (Select disk #, detail disk) you will get as Disk ID: again the 4 bytes sequence "inverted". (i.e. as you propose)

So, three different ways (the WMI/WMIC clearly completely wrong) to display a 4 byte sequence.

If you want to mimic the hypothetically "right" way (Minitool and Diskpart) you are welcome, but if you want to look for a drive letter in the Registry to understand to which disk it belongs, the "plain" way is more handy.

Exception made for the stupid conversion to signed decimal that WMIC performs, it is just a matter of preferences IMHO.

Not so casually (shameless plug ;)) in my MBRview script/structure viewer for Tiny Hexer:

http://reboot.pro/to...-hexer-scripts/

I provide both the "inverted" and "plain" Disk Signature, marking the first one as 0x (as it should be IF it is a hex number) and without the 0x the latter (as it should be being a plain sequence of bytes).

:duff:
Wonko

#57 Gerolf

Gerolf

    Member

  • Members
  • 75 posts
  •  
    Germany

Posted 28 April 2018 - 06:35 PM

Thank you! Now, if both ways do make sense, I simply suggest to separate the consecutive bytes with spaces

set disksig=%disksig:~10,2% %disksig:~13,2% %disksig:~16,2% %disksig:~19,2%

to make it more intuitive that this is not one single hex number.



#58 Gerolf

Gerolf

    Member

  • Members
  • 75 posts
  •  
    Germany

Posted 28 April 2018 - 08:26 PM

 Shorter, leaving intact the hex editor's formatting:

set disksig=%disksig:~10,11%


#59 Gerolf

Gerolf

    Member

  • Members
  • 75 posts
  •  
    Germany

Posted 28 April 2018 - 10:55 PM

Your linked document says in its headline that "55AAH is the Wrong Way to represent the Byte Sequence 55h followed by AAh on a PC". Marked as "Bytes", the "wrong" expression "0x55AA" can be found in this code fragment:

cat --hex --skip=510 --length=2 %target% | set magic=
set magic=0x%magic:~10,2%%%magic:~13,2%
if "%magic%"=="0x55AA" goto :mbOK
echo No valid Magic Bytes: %magic% instead of 0x55AA
:mbOK
:: echo Valid Magic Bytes %magic%

The following equivalent uses the "correct" hex Word "0xAA55" as proposed by The Starman:

cat --hex --skip=510 --length=2 %target% | set magic=
set magic=0x%magic:~13,2%%%magic:~10,2%
if "%magic%"=="0xAA55" goto :mbOK
echo No valid Magic Word: %magic% instead of 0xAA55
:mbOK
:: echo Valid Magic Word %magic%


#60 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 29 April 2018 - 01:28 PM

 

Your linked document says in its headline that "55AAH is the Wrong Way to represent the Byte Sequence 55h followed by AAh on a PC". Marked as "Bytes", the "wrong" expression "0x55AA" can be found in this code fragment:



cat --hex --skip=510 --length=2 %target% | set magic=
set magic=0x%magic:~10,2%%%magic:~13,2%
if "%magic%"=="0x55AA" goto :mbOK
echo No valid Magic Bytes: %magic% instead of 0x55AA
:mbOK
:: echo Valid Magic Bytes %magic%

The following equivalent uses the "correct" hex Word "0xAA55" as proposed by The Starman:



cat --hex --skip=510 --length=2 %target% | set magic=
set magic=0x%magic:~13,2%%%magic:~10,2%
if "%magic%"=="0xAA55" goto :mbOK
echo No valid Magic Word: %magic% instead of 0xAA55
:mbOK
:: echo Valid Magic Word %magic%

I know :smiling9: , I pointed you to it.

 

But I really don't get your point.

 

You want to sue me or Nando4 for the way the check is scripted? :w00t:

Do you believe that to be a bug? :unsure:

Is it really so important to need to be corrected? :dubbio:

 

IF it is, then the correction is (should be):

cat --hex --skip=510 --length=2 %target% | set magic=
set magic=%magic:~10,2%%%magic:~13,2%
if "%magic%"=="55AA" goto :mbOK
echo No valid Magic Bytes: %magic% instead of 55AA
:mbOK
:: echo Valid Magic Bytes %magic%

With all the affection and respect I have for Daniel B.Sedory (the Starman) :worship: I pointed you to that page only to show you how opinions may be different on the way a sequence of bytes is interpreted, and while all in all I believe he is actually right::

http://starman.vertc.../mbr/AA55H.html

 

Therefore, we'd advise any authors who need to describe a signature (apart from books on assembly language), to list each byte as it's found on some media or in memory, rather than attempting to use a hexadecimal number comprised of more than a single byte.

 

(this is the way I used for the Disk Signature), you got me :ph34r: on the 0x prepended to the "Magic Bytes", though I have to disagree with the notion of a sequence of two bytes (a signature or "Magic Bytes") constituting a "Word".

 

:duff:

Wonko



#61 Gerolf

Gerolf

    Member

  • Members
  • 75 posts
  •  
    Germany

Posted 29 April 2018 - 01:51 PM

Not suing, Wonko! I think your mbrview.g4b is such an instructive little piece of code that it's worth to be discussed in detail even for "educational" purposes.



#62 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 29 April 2018 - 03:24 PM

Not suing, Wonko! I think your mbrview.g4b is such an instructive little piece of code that it's worth to be discussed in detail even for "educational" purposes.

Is it?  :blush: Thanks for the compliment. :)

 

I consider it only one of the several - as usual - half-@ssed batches that I put together just to show both real programmers and common users how simple problems can be solved by simple tools, hoping to spur them into making more and better simple tools (and usually failing miserably :( , though from time to time a young padawan does learn something and actually produces something of use).

 

JFYI, it is only a simplified (and adapted to grub4dos syntax, later amended/simplified by nando4) re-using parts of the MBRbatch here:

http://reboot.pro/to...atch-001-alpha/

 

(that could actually have some "educational" purpose :unsure: )

 

:duff:

Wonko



#63 zammibro

zammibro

    Member

  • Members
  • 59 posts
  •  
    United States

Posted 16 May 2021 - 05:10 PM

Please find attached mbrview.g4b, a simple grub4dos !BAT script to inspect the contents (partition table) of a MBR.

 

Sorry for seemingly stupid question, but how exactly would one run this very thing on a Win 10 64-bit PC? Shouldn't such "explanation" be placed in the 1st post to begin with?  :crazy: In particular given latest chenall's grub4dos installed?

 

Can the OP add a screenshot of the outcome of this batch? What the user is expected to see in it? Can I verify with it and how, if Grub4DOS was installed into my HDD MBR, or its merely running from c: root invoked by Windows Bootmanager?


Edited by zammibro, 16 May 2021 - 05:13 PM.


#64 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 17 May 2021 - 08:37 AM

Naah, it's not a stupid question, it is just an uninformed one.

 

Grub4dos - besides being a bootmanager/bootloader - is a (minimal) Operating System, and has an internal command processor, not entirely unlike DOS command.com or NT cmd.exe, with a number of available commands, besides the ones normally used for booting (usually assembled in entries in the menu.lst.

Among the features of this mini-OS, there is the capability of running batch script files (that have a syntax very similar to DOS or better NT batch files) you can open the .g4b files with - say - notepad and inspect their contents (and modify it if needed)

 

So you boot to grub4dos.

Press "c" to get to the grub> prompt.

From here you invoke the batch filename, using its relative or absolute path and press [ENTER]

 

Examples:

/mbrview.g4b [ENTER] 

(hd0,0)/mbrview.g4b [ENTER]

depending on the version of grub4dos and how the environment is set, also a simpler

mbrview.g4b [ENTER] 

might work.

 

You will be told that you need to pass a parameter (the hard disk device you want to run the command on), so re-run it as (say):

(hd0,0)/mbrview.g4b (hd0) [ENTER]

 

You should get *something like*:

https://rmprepusb.co...elementor-1616/

https://rmprepusb.te...79ecd27e9ef.jpg

 

In case you have renamed the file or you have a non-standard environment setting, you mightl need to use "call" as seen in the screenshot above.

The screenshot is about the older version that needed WENV, but nowadays you should use the no-wenv version, the difference in the output should be only the lines/columns separators in the table.

 

:duff:

Wonko



#65 zammibro

zammibro

    Member

  • Members
  • 59 posts
  •  
    United States

Posted 17 May 2021 - 02:16 PM

The linked Tutorial mentions /boot/grub as default folder for Grub4DOS uitilities. Windows 10 has c:/Boot dir with BCD files, which doesn't look like the best place for grub utils, and its Boot, not boot dir. Does grub4dos pay attention to capital letters in paths?

 

Chenall's current Grub4Dos.7z distributions contain EXT folder with the above utilities, and also quite a few files in the grub4dos folder. I found that simply copying to C:/ the files grldr, grldr.mbr, menu.lst is enough to boot grub4dos from Windows Bootmanager after adding its entry to BCD. So the obvious questions are: a) what the other files in that forlder are used for? and c) where to copy the ext folder?

 

Finally, it remains unclear how to find out if Grub4DOS was already added to the HDD MBR, or it boots merely from c:/ drive, or both? Does your mbrview.g4b tool allow that? Can you explain a bit meaning or interpretation of column titles and entry examples in that sample table?


Edited by zammibro, 17 May 2021 - 02:21 PM.


#66 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 17 May 2021 - 03:40 PM

Normally Windows 7+ has the \boot\BCD on a volume that gets no drive letter, if you have it on C:\ it means that you installed it on an already partiitioned/formatted disk intentionally.

Nothing prevents you from making inside the existing \boot\ directory a new one called "grub", i.e. \boot\grub and put in it all related grub4dos files.

Grub4dos is CaSe SeNsItIvE on some filesystems but not on other ones, on NTFS and FAT it is not, normally use small letters..

If you open grldr with Notepad or - better - Wordpad (or anyway with a text editor) and scroll down to the very end of the file, you will see how "embedded" in grub4dos there is a sort of "menu.lst" which is executed before the commands in any external menu.lst file.
The one in the last grub4dos i have handy is:

 

 

pxe detect
configfile
default 0
timeout 1

title find /menu.lst, /boot/grub/menu.lst, /grub/menu.lst
errorcheck off
configfile /boot/grub/menu.lst
configfile /grub/menu.lst
if "%@root%"=="(ud)" && calc *0x82A0=*0x82b9&0xff
if "%@root:~1,1%"=="f" && find --set-root --devices=f /menu.lst && configfile /menu.lst
find --set-root --ignore-floppies --ignore-cd /menu.lst && configfile /menu.lst
find --set-root --ignore-floppies --ignore-cd /boot/grub/menu.lst && configfile /boot/grub/menu.lst
find --set-root --ignore-floppies --ignore-cd /grub/menu.lst && configfile /grub/menu.lst
configfile http://b.chenall.net/menu.lst
errorcheck on
commandline

title commandline
commandline

title reboot
reboot

title halt
halt

 

which basically attempts to run the menu.lst in a couple predefined directories on current root and if it fails, to find (and set root to) the menu.lst file on other devices/volumes and passes control to it (if found).

Before that (in the "body" of the file) there is a setting for the environment PATH (and for the extension of the batch files).

If you boot to grub4dos and run the command "command" (no pun intended) you will see:
current default path: (bd)/BOOT/GRUB
(bd) means "boot device", i.e. the *whatever* grub4dos was booted from, or if you run "help command" you will see some more options.

Basically "as is", the default path is
(bd)/boot/grub
and the extension for the batch files is undetermined.
You can change these settings to *whatever* you see fit, personally I use (bd)/grub4dos for the PATH, and .g4b for the EXTension..
Run:
command --set-path=(hd0,0)/zammibro
command --set-ext=.g4b
command

You can see how you changed the path and extension environment variables.

So now you can make (assuming that your C:\ drive under windows is (hd0,0) in grub4dos) a C:\zammibro\ directory and put in it mbrview.g4b and from now on you can run it from the grub> prompt simply as "mbrview".

Since your is a "static" install of grub4dos on internal hard disk, you can decide to put those environment variable settings in either the external menu.lst or in the embedded one, so that every time you boot your default directory will always be (hd0,0)/zammibro (or whatever you want to make it) and the batch files extension .g4b.

In your setup:
1) switch on
2) BIOS
3) MBR code invoking bootsector of active partition
4) bootsector code invoking BOOTMGR
5) BOOTMGR reading \boot\BCD settings
6) choice of grub4dos
7) BOOTMGR loading grldr.mbr
8) grldr.mbr loading grldr
9) grldr loading menu.lst
10) grub4dos showing menu.lst choices

The MBRview outputs the "normal" data that can be found in partition table entries, they are sometimes called slightly differently but they are the same:
1) Status of the partition (active or nto active)
2) Partition ID
3) CHS addresses (start and end)
4) LBA addresses (start and extension)
compare with this (very old) article:
http://jaclaz.alterv...B/USBstick.html
around half of the page there is a comparison table of the different names different programs use for the same data.

 

The tool should have been called "viewer for the partition table and Disk Signature on the MBR" as it doesn't really-really show you the MBR, but only the partition table contents (and the Disk Signature) in a "human readable" conversion/format.

The actual partition table (and Disk Signature) can be seen as RAW with:

cat --hex --skip=440 (hd0)0+1

And the whole MBR (including code) with the simpler:

cat --hex (hd0)0+1

The issue might be that you don't know the meaning of the data, you will need to read/document yourself on MBR and partition tables in it, this is a good intro:
https://thestarman.p.../PartTables.htm

The current "ext" folder contains a number of tools that were once a separate branch/repository, called grubutils, you don't need any of them for the basic usage of grub4dos, you can consider them as "DOS programs" or - even better - as "external commands", again, back to:
https://rmprepusb.co...elementor-1616/

:duff:
Wonko



#67 zammibro

zammibro

    Member

  • Members
  • 59 posts
  •  
    United States

Posted 17 May 2021 - 04:02 PM

I used EasyBCD to add boot options to Windows Bootloader, may be it added /Boot folder to C:/ drive, or whatever. That's why I wanted to check and if possible remove grub4dos entry from MBR, since it starts from C:/ drive. How to check that?

 

Also, chenall's grub4dos folder in 7Z file contains multiple tools in addition to his ext folder. What these tools are used for?


Edited by zammibro, 17 May 2021 - 04:04 PM.


#68 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 17 May 2021 - 05:06 PM

You have NO grub4dos entry in the MBR.

 

Please re-read, slowly this time, my previous post, particularly the part beginning "In your setup:" it explains (according to your reports) your current booting sequence, you "land" to grub4dos via the BOOTMGR and the BCD.

 

EasyBCD (which is NOT a recommended tool, use BootIce instead) is a tool to (easily) edit the BCD, it doesn't (shouldn't) create a new one, let alone on another volume, but of course it depends on how exactly you used it.

 

In your setup you need ONLY:

grldr.mbr

grldr

(and optionally menu.lst)

 

Anything else (that you don't know what is for) you can (and should) ignore.

 

:duff:

Wonko



#69 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 17 May 2021 - 06:03 PM

my dear wonko, pls excuse the question if it is silly - would the following

 

pxe detect
configfile
default 0
timeout 1

title find /menu.lst, /boot/grub/menu.lst, /grub/menu.lst
errorcheck off
configfile /boot/grub/menu.lst
configfile /grub/menu.lst
if "%@root%"=="(ud)" && calc *0x82A0=*0x82b9&0xff
if "%@root:~1,1%"=="f" && find --set-root --devices=f /menu.lst && configfile /menu.lst
find --set-root --ignore-floppies --ignore-cd /menu.lst && configfile /menu.lst
find --set-root --ignore-floppies --ignore-cd /boot/grub/menu.lst && configfile /boot/grub/menu.lst
find --set-root --ignore-floppies --ignore-cd /grub/menu.lst && configfile /grub/menu.lst
configfile http://b.chenall.net/menu.lst
errorcheck on
commandline

title commandline
commandline

title reboot
reboot

title halt
halt

 

also apply to my vhd booting, if adequately adapted? and if it would, would it stand me in good stead relative to the usual wimboot-guided booting?



#70 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 18 May 2021 - 11:32 AM

@antonino

I don't understand the question.

The quoted part is the *whatever* grldr does BEFORE loading the (external) menu.lst.

As said, essentially the idea is to look for menu.lst *everywhere* and if it doesn't find it, goes to the grub> prompt.

In certain cases (static or fixed install) it makes no sense to search for menu.lst (because in such a static setup you already know where the menu.lst is) and in other cases you can put the directivesyou want grub4dos to execute directly embedded in the grldr file itself, replacing the last few bytes.

Up to you to decide if it fits your usage paradigm.

 

Example #1 (you already know where the menu.lst is):

default 0
timeout 1

title menu.lst on (hd0,0)
configfile (hd0,0)/menu.lst

commandline

 

Example #2 (you don't want an external menu.lst at all and you want to chainload th ebootsector of first partition on first disk)

 

default 0

timeout 5

title Chainload (hd0,0) bootsector

root (hd0,0)
chainloader (hd0,0)+1

title commandline
commandline

title reboot
reboot

title halt
halt

 

:duff:

Wonko


  • antonino61 likes this




1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users