Jump to content











Photo
- - - - -

How to write Syslinux gptmbr.bin (440 bytes) into MBR sector of GPT disk using dd.exe ?

gptmbr.bin dd.exe syslinux

  • Please log in to reply
14 replies to this topic

#1 devdevadev

devdevadev

    Frequent Member

  • Advanced user
  • 477 posts
  •  
    India

Posted 03 December 2018 - 04:26 PM

in linux, we use

https://wiki.gentoo....iki/Syslinux/en

dd bs=440 conv=notrunc count=1 if=/usr/share/syslinux/gptmbr.bin of=/dev/sda

http://www.lightofda...cgi/BIOSBootGPT

dd if=/usr/share/syslinux/gptmbr.bin of=/dev/sda bs=440 count=1

in Windows, I tried following equivalent dd.exe commands to write gptmbr.bin to mbr sector of GPT Disk .

dd.exe if="D:\gptmbr.bin" of=\\.\PhysicalDrive3 bs=440 count=1
dd.exe if="D:\gptmbr.bin" of=\\.\PhysicalDrive3 bs=440 count=1 conv=notrunc

But both gives following errors ??

C:\Users\DEv\Desktop\AIO>dd.exe if="D:\gptmbr.bin" of=\\.\PhysicalDrive3 bs=440 count=1
rawwrite dd for windows version 0.6beta3.
Written by John Newbigin <jn@it.swin.edu.au>
This program is covered by terms of the GPL Version 2.

Error writing file: 87 The parameter is incorrect
1+0 records in
0+0 records out

and 

C:\Users\DEv\Desktop\AIO>dd.exe if="D:\gptmbr.bin" of=\\.\PhysicalDrive3 bs=440 count=1 conv=notrunc
rawwrite dd for windows version 0.6beta3.
Written by John Newbigin <jn@it.swin.edu.au>
This program is covered by terms of the GPL Version 2.

notrunc
Error writing file: 87 The parameter is incorrect
1+0 records in
0+0 records out

Where I am doing mistake ? Does dd.exe not support bs=440 ?

Should I first convert 440 bytes gptmbr.bin to 512 bytes gptmbr.bin if possible ?

Does dsfi.exe and dsfo.exe support writing of 440 bytes gptmbr.bin to mbr sector of GPT disk ?

 

http://reboot.pro/to...e-9#entry193659

 

How Wonko [mkhidGPT001.zip]/GPTMBR.mbr is different from syslinux gptmbr.bin ?

 

Please help.... 



#2 misty

misty

    Gold Member

  • Developer
  • 1033 posts
  •  
    United Kingdom

Posted 03 December 2018 - 04:46 PM

Do you need to include a blocksize in your command? Wouldn't just writing the file result in it being written to the first 440 bytes of the first sector of disk 3 anyway?

Maybe try -
dd.exe if="D:\gptmbr.bin" of=\\.\PhysicalDrive3


#3 misty

misty

    Gold Member

  • Developer
  • 1033 posts
  •  
    United Kingdom

Posted 03 December 2018 - 04:54 PM

BTW, writing to the first 440 bytes of sector 0 will leave the partition table (and if memory serves also any disk signature) intact.

:cheers:

Misty

#4 devdevadev

devdevadev

    Frequent Member

  • Advanced user
  • 477 posts
  •  
    India

Posted 03 December 2018 - 05:07 PM

Maybe try -

dd.exe if="D:\gptmbr.bin" of=\\.\PhysicalDrive3
C:\Users\DEv\Desktop\AIO>dd.exe if="D:\gptmbr.bin" of=\\.\PhysicalDrive3
rawwrite dd for windows version 0.6beta3.
Written by John Newbigin <jn@it.swin.edu.au>
This program is covered by terms of the GPL Version 2.

Error reading file: 87 The parameter is incorrect
0+1 records in
0+1 records out


#5 misty

misty

    Gold Member

  • Developer
  • 1033 posts
  •  
    United Kingdom

Posted 03 December 2018 - 05:35 PM

@devdevadev
Does \\.\PhysicalDrive3 exist?

Also try removing the quotes from "D:\gptmbr.bin" - I haven't used dd for windows in a while and can't remember if they are supported. They are not required in your case anyway, as the path does not have any spaces.

Misty

#6 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 03 December 2018 - 05:52 PM

It depends on a number of things. basically if you write to a block device you cannot write less than the block size of the target device with a number of programs AFAICR, cannot say about dd for windows, surel dsfo/dsfi behave like that.
 
BUT writing to the MBR (first sector of hard disk) may be also a different issue (access denied) on some OS/systems.
 
There is NO GPTMBR.mbr in mkhidGPT001.zip, there is a  is a HidGPT63.mbr, obviously different from the Syslinux gptmbr.bin (besides the different name, it is a half-@§§edly modified MBR code, though it is originlly by the same Author, Peter Anvin).
 
Now, why Wonko in mkhidGPT.cmd would extract the MBR (to a file 512 bytes in size), patch its first 432 bytes and then write the patched file to the MBR (as opposed to more simply and directly patch the MBR on disk)?
ECHO Writing the special MBR ...
IF NOT EXIST HidGPT63.mbr CALL :Missing HidGPT63.mbr&GOTO :EOF
IF EXIST GPTMBR.mbr DEL GPTMBR.mbr
dsfo \\.\Physicaldrive%PhysDN% 0 512 GPTMBR.mbr
dsfi GPTMBR.mbr 0 432 HidGPT63.mbr
dsfi \\.\Physicaldrive%PhysDN% 0 512 GPTMBR.mbr
GOTO :EOF

:duff:
Wonko
  • devdevadev likes this

#7 devdevadev

devdevadev

    Frequent Member

  • Advanced user
  • 477 posts
  •  
    India

Posted 03 December 2018 - 06:04 PM

@devdevadev
Does \\.\PhysicalDrive3 exist?

Attached File  Screenshot (93).png   30.78KB   0 downloads

C:\Users\DEv\Desktop\AIO>dd.exe if=D:\gptmbr.bin of=\\.\PhysicalDrive3
rawwrite dd for windows version 0.6beta3.
Written by John Newbigin <jn@it.swin.edu.au>
This program is covered by terms of the GPL Version 2.

Error reading file: 87 The parameter is incorrect
0+1 records in
0+1 records out


#8 devdevadev

devdevadev

    Frequent Member

  • Advanced user
  • 477 posts
  •  
    India

Posted 03 December 2018 - 06:24 PM

dsfo \\.\Physicaldrive3 0 512 GPTMBR.mbr
dsfi GPTMBR.mbr 0 440 gptmbr.bin
dsfi \\.\Physicaldrive3 0 512 GPTMBR.mbr

Will it do exactly the same process linux dd command do here



#9 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 03 December 2018 - 06:41 PM

Will it do exactly the same process linux dd command do here ?

No, but it will give exactly the same result :)  ( through doing a different process).

 

GIven that the dsfi won't write to a block device any number of bytes that is not a multiple of the block size, the temporary file "GPTMBR.mbr" 512 bytes in size, combining the data from (a copy of) the current MBR with the code from the Syslinux gptmbr.bin is needed, in order to be able to write a "whole" sector.

 

:duff:

Wonko


  • devdevadev likes this

#10 devdevadev

devdevadev

    Frequent Member

  • Advanced user
  • 477 posts
  •  
    India

Posted 03 December 2018 - 07:47 PM

http://reboot.pro/to...pe/#entry204816

http://reboot.pro/to...pe/#entry204831
 

Can we not use similar approach for syslinux gptmbr.bin as you described for grldr.mbr using dd.exe ?

dd.exe if=\\.\PhysicalDrive3 of=\GPTMBR.mbr count=1 --localwrt
dd.exe if=\gptmbr.bin of=\GPTMBR.mbr bs=440 count=1 --localwrt
dd.exe if=\GPTMBR.mbr of=\\.\PhysicalDrive3 count=1 --localwrt
dd.exe if=\\.\PhysicalDrive3 of=\GPTMBR.mbr bs=512 count=1
dd.exe if=\gptmbr.bin of=\gptmbr512.bin bs=512 count=1
dd.exe if=\GPTMBR.mbr of=\gptmbr512.bin bs=1 count=72 skip=440 seek=440
dd.exe if=\gptmbr512.bin of=\\.\PhysicalDrive3 bs=512 count=1


#11 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 03 December 2018 - 08:54 PM

That (with --localwrt ) is a DIFFERENT program. it is the dd of the FAU , not the "dd for Windows" by John Newbigin you were using/mentioned earlier.

 

But of course the "interemediate file" approach can work as well :) , though I lost you with the "bs=512 count=16" :dubbio: if you are referencing this post:

http://reboot.pro/to...pe/#entry204831

it is about copying (and "installing") the whole "normal" grldr.mbr (which is actually 16 sectors) and BTW there is also a reference to yet another dd version, the Cygwin one where (at least with the 32 bit and on XP) the bs=440 count=1 worked just fine.

 

 

:duff:

Wonko



#12 devdevadev

devdevadev

    Frequent Member

  • Advanced user
  • 477 posts
  •  
    India

Posted 21 December 2018 - 05:34 AM

@echo off
cd /d "%~dp0"
    if "%PROCESSOR_ARCHITECTURE%"=="x86" (
        set gdisk=gdisk32.exe
        ) else (
        set gdisk=gdisk64.exe
    )
echo.
echo.  gdisk32.exe \\.\physicaldriveN
echo.  x
echo.  a
echo.  1
echo.  2
echo.  w
echo. & pause

%gdisk% \\.\physicaldrive1
pause

echo.Installing Syslinux...
syslinux.exe -f --mbr --active --directory /boot/syslinux/ --install E:
pause

echo. Writing the special MBR ...
IF EXIST GPTMBR.mbr DEL GPTMBR.mbr

dsfo \\.\Physicaldrive1 0 512 GPTMBR.mbr
dsfi GPTMBR.mbr 0 440 gptmbr.bin
hexalter GPTMBR.mbr 0x1BE=0x80
dsfi \\.\Physicaldrive1 0 512 GPTMBR.mbr
pause

I have tried above approach for installing Syslinux (so that Grub4dos will be chainloaded from Syslinux.cfg ) in 4TB GPT USB-HDD but does not seems to works. I got totally BLANK screen when booted in Sony VAIO....But works in QEMU...?

 

Should I also try 4096 bytes instead of 512 bytes similarly as suggested in Misty Approach ?

dsfo \\.\Physicaldrive1 0 4096 GPTMBR.mbr

dsfi GPTMBR.mbr 0 440 gptmbr.bin
hexalter GPTMBR.mbr 0x1BE=0x80
dsfi \\.\Physicaldrive1 0 4096 GPTMBR.mbr


#13 misty

misty

    Gold Member

  • Developer
  • 1033 posts
  •  
    United Kingdom

Posted 21 December 2018 - 06:40 AM

Please do not try my suggestion. The follow up posts to my suggestion confirm that I was wrong. If you use a 4k sector size to overwrite the protective mbr on a 512 byte sector disk (or emulated 512 sector in your case) then you could end up overwritting the gpt header and partition table if you are not careful.

Sorry for my brief response. I'm on my phone.

#14 ady

ady

    Frequent Member

  • Advanced user
  • 165 posts

Posted 22 December 2018 - 09:09 AM

Probably the generic method of:

1_ copy/extract the first 512 bytes from the device/image to a temporal file;

2_ replace the first 440 bytes of the temporal file with the same amount of bytes from gptmbr.bin;

3_ copy the resulting (new) temporal file, back to the first 512 bytes of the device/image;

... should be expected to work (at least on "512-bytes_per_sector" devices/images).


Each user might choose different tool(s) for the same generic procedure (according to needs / skills / preferences...).


Having said that (by now, an obvious statement), someone might want to attempt a different potential "hack": hex-editing "syslinux.exe".

Please note that I have not actually attempted this procedure myself, so the usual "don't blame me", "at your own risk" and "back up before..." (etc.) are relevant for these comments.

So, FWIW...

The Windows-based SYSLINUX installer, "syslinux.exe" (and "syslinux64.exe") include within it (embedded) several items:

* the bootloader code/file ("ldlinux.sys")
* the core module (since version 5.00) ("ldlinux.c32")
* the "mbr.bin" file, used with the "-m" option of the SYSLINUX installer.

Let's imagine the following generic procedure (please forgive me for the following non-elegant / crude / raw description):

_ open "mbr.bin" in some hex editor, select the whole 440 hex values, "[ctrl+c]" the selection;
_ open "syslinux.exe" in the hex editor, "search" (or "find") the same hex values;
_ open "gptmbr.bin" in the hex editor, select the whole 440 hex values, "[ctrl+c]" the selection;
_ in the hex editor, go back to the already-opened "syslinux.exe", and replace -- probably with "[ctrl+v]", but please check your own hex editor's shortcuts before proceeding -- the selected hex values (which were/are the equivalent 440 bytes of "mbr.bin") with the 440 bytes of "gptmbr.bin";
_ save and close all files and the hex editor.

Now the "-m" option of the "hacked" installer would use the "gptmbr.bin" code for the first 440-bytes of your destination device/image. OTOH, now the "-a" option of this hacked installer should probably not be used?

Since I have not attempted this procedure myself, I don't know whether the "syslinux.exe" command would run correctly, or instead perhaps it would fail in some way (even silently?).

Of course, the procedure could be accomplished by means of other / different tools, instead of using an hex editor as described above.

To be clear, I am not saying this is the best alternative (especially considering that I have not attempted to use such hacked syslinux[64].exe myself). I am just posting this comments in case it might be interesting / helpful as an alternative in some potential situation for someone.

BTW, the procedure _might_ work with the DOS-based SYSLINUX installer ("syslinux.com") for versions 4.05-4.07 too (with their corresponding mbr files of the same respective versions).

Regards,
Ady.



#15 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 22 December 2018 - 11:19 AM

@ady

The procedure works just fine, no need to hack anything, if you read attentively the report by devdevadev:

I have tried above approach for installing Syslinux (so that Grub4dos will be chainloaded from Syslinux.cfg ) in 4TB GPT USB-HDD but does not seems to works. I got totally BLANK screen when booted in Sony VAIO....But works in QEMU...?

the issue is only on this particular Sony laptop, and to have it working - besides the procedure to "install" it, there will be the need to change something in the actual CODE.

 

Besides (JFYI), usually when modifying a "PE" binary, you need to correct the checksum, see:

https://www.codeproj...cksum-Algorithm

 

There are a few toiols around capable of fixing the checksum, besides the one in the above article, this one:

https://ryanvm.net/f...opic.php?t=5381

 

Or this one:

http://www.coderforl...ies/#PEChecksum

 

:duff:

Wonko







Also tagged with one or more of these keywords: gptmbr.bin, dd.exe, syslinux

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users