Jump to content











Photo
- - - - -

Boot windows ISO without bootfix.bin 'press any key' prompt


  • Please log in to reply
79 replies to this topic

#1 steve6375

steve6375

    Platinum Member

  • Developer
  • 6598 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars
  •  
    United Kingdom

Posted 25 August 2014 - 11:50 AM

I wanted to suppress the 'Press any key to boot from CD or DVD' prompt when booting directly from an unmodified Windows Installer ISO.

 

If I boot from a Windows Installer ISO and the use chainloader /bootmgr  I don't see the 'Press any key to boot from CD or DVD' prompt.

 

However, if the ISO is of the Joliet specification, grub4dos 0.4.5c does not understand it (only \README.TXT is listed) and so it has to be booted using chainloader (0xff) - then I do get the 'Press any key to boot from CD or DVD' prompt.

 

It occurred to me that I could patch the initial boot code so that it did not load the bootfix.bin file.

 

 

chainloader (0xff)

causes the text

Load RBA: 0x5B4  Boot Type: 0 = No Emulation

 

to appear.  and 0x5b4 x 4 is 0x16d0  x 512 = 0x2DA000

 

cat --hex --skip=0x2da700 --length=0x100 (0xff)+0x2000

 

shows a string 

SETUPLDR.BINBOOTMGRBOOTFIX.BINBOOTI386AMD64

 

 

Therefore, if we can change the BOOTFIX.BIN string, we can cause it not to be loaded and thus suppress the prompt.

 

The solution turned out to be simple

map /win8.iso (0xff)
map --hook
chainloader (0xff)
cat --locate=BOOTFIX.BIN --number=1 --replace=XXX (0xff)+0x3000
boot

This suppresses the 'Press any key to boot from CD or DVD' prompt.

[Edit] The ISO file is permanently changed which is why this works.

I am not to sure why this works - presumably (0xff) points to memory for at least some of the ISO and not to the actual ISO file???

 



#2 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 25 August 2014 - 12:09 PM

 

This suppresses the 'Press any key to boot from CD or DVD' prompt. The ISO file is not permanently changed.

I am not to sure why this works - presumably (0xff) points to memory for at least some of the ISO and not to the actual ISO file???

In theory (AFAICU) the "chainloader" command when used with a loader file (such as NTLDR or BOOTMGR) loads the file in memory. :unsure:

 

It is possible that when the "target" of the chainloader command is a .iso (mapped to a drive) it loads into memory the "loader" (which in this case is the "no emulation" bootsector). :dubbio:

 

Unrelated :w00t: :ph34r: but something that I would find useful in some cases (and that AFAIK grub4dos does not implement) is the possibility to "stack" some keypresses in a way that the "target" once loaded receives them.

As an example the good ol' XOSL could "manage" BOOT.INI's choices by stacking [arrow down] and [arrow up] and [ENTER] key presses.

 

:duff:

Wonko



#3 steve6375

steve6375

    Platinum Member

  • Developer
  • 6598 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars
  •  
    United Kingdom

Posted 25 August 2014 - 12:18 PM

re. inserting key presses  - I tried this with windows ISO by adding keyboard characters to the BIOS keyboard buffer - it didn't work.

 

Any decently-written code would use an algorithm of

 

1. flush keyboard buffer to absorb all previous key presses

2. wait 

3. check for keypress

4. if no keypress goto 2

5. if key press get scan code and interpret and act on it



#4 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 25 August 2014 - 12:52 PM

Cannot say how it is implemented, however XOSL is open source:

http://sourceforge.net/projects/xosl/

http://sourceforge.n...sl/xosl 1.1.5/

 

The feature is documented here:

http://www2.arnes.si...user/5.html#5_5

 

:duff:

Wonko



#5 steve6375

steve6375

    Platinum Member

  • Developer
  • 6598 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars
  •  
    United Kingdom

Posted 25 August 2014 - 01:04 PM

You could try the bios grub4dos utility and use the BIOS int 16h call

http://webpages.char...chhelp/0233.HTM

 

e.g.

/bios int=0x16 eax=0x500 ecx=0x55

writes U into the keyboard buffer



#6 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 25 August 2014 - 01:22 PM

 

writes U into the keyboard buffer

then,  since the BOOTFIX.BIN asks for "any" key, it should work also in your case to suppress that message. :unsure:

I will try with a NTLDR/BOOT.INI, but if it didn't work for you with bootfix.bin, I doubt it can work for anything else.

 

:duff:

Wonko



#7 steve6375

steve6375

    Platinum Member

  • Developer
  • 6598 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars
  •  
    United Kingdom

Posted 25 August 2014 - 01:23 PM

It sounds like it might work for XOSL as they must deliberately NOT clear the keyboard buffer.



#8 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 25 August 2014 - 01:25 PM

It sounds like it might work for XOSL as they must deliberately NOT clear the keyboard buffer.

Well, then we might ask chenall/tinybit if it is possible (advisable/whatever) for them to have also gruib4dos not clear the keyboard buiffer. :unsure:

 

:duff:

Wonko



#9 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 25 August 2014 - 01:39 PM

Back to topic, about the nice :) .iso trick, the reason must be *something* else. :unsure:

 

I tried mapping a (cd) device to (0xff) and seemingly it doesn't work, (whilst it works fine if I map a .iso to (0xff) :thumbsup:)

 

:duff:

Wonko



#10 sixcentgeorge

sixcentgeorge

    Frequent Member

  • Advanced user
  • 190 posts
  •  
    France

Posted 25 August 2014 - 02:06 PM

i think i saw that with Bartpe live cdrom [or xplite]
 
BBIE - Bart's Boot Image Extractor
 
Bart's way to create bootable CD-Roms


#11 steve6375

steve6375

    Platinum Member

  • Developer
  • 6598 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars
  •  
    United Kingdom

Posted 25 August 2014 - 02:49 PM

Well, then we might ask chenall/tinybit if it is possible (advisable/whatever) for them to have also gruib4dos not clear the keyboard buiffer. :unsure:

 

:duff:

Wonko

 

I don't think that is the problem, bootfix.bin actually contains code to clear the buffer (soaks all keys) before it looks for a key press from the user.



#12 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 25 August 2014 - 02:51 PM

I don't think that is the problem, bootfix.bin actually contains code to clear the buffer (soaks all keys) before it looks for a key press from the user.

i see. :)

 

:duff:

Wonko



#13 steve6375

steve6375

    Platinum Member

  • Developer
  • 6598 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars
  •  
    United Kingdom

Posted 25 August 2014 - 05:29 PM

map /win8.iso (0xff)
map --hook
cat --locate=BOOTFIX.BIN --number=1 --replace=XXX (0xff)+0x3000
chainloader (0xff)
boot

This also works - so it is just map that seems to 'buffer' the iso sectors somehow...



#14 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 25 August 2014 - 06:03 PM

This also works - so it is just map that seems to 'buffer' the iso sectors somehow...

 

Yep, but seemingly it works only if the source of the map command is a file (and not if it is already a device).

It would be interesting to see if it can work also on other mapped images (RAW hard disk images, superfloppy images, .vhd's) or if it is limited to .iso images. :unsure:

Or maybe (never experimented with it) one can use the --unsafe-boot option? :dubbio:

 

 

:duff:

Wonko



#15 tinybit

tinybit

    Gold Member

  • Developer
  • 1051 posts
  •  
    China

Posted 26 August 2014 - 06:47 AM

Let me imagine and describe why the strange case could happen.

 

chainloader (0xff) ----- it only tells the boot command to load the "boot" sectors(if total size of the boot sectors is greater than 512), and it has not yet loaded the boot sectors. The boot command will actually load the boot sectors at last.

 

The cat command modified the content of the (oxff) device. But, the (0xff) is virtual. Its content is just on the hard disk. When grub4dos kernel tries to write something to harddrive, (I suppose) it encountered a BIOS bug which caused the data to be discarded(that is, not actually written to disk).

 

On the other hand, grub4dos will buffer the device on read/write access. For real or virtual cdrom device, the buffer size is 64K. Thus, although the actual write failed, the contents of 64K buffer is in memory. Next, if we try to read device data that has buffered, we will get the data from the buffer, effectively avoiding a read access from the (real or virtual cdrom) device.

 

So, when the boot command finally run, it would read and load the (possibly) already buffered boot sectors in memory(with the sector contents modified), and transfer control to the boot sectors, which will continue to boot up the system on the virtual cdrom device.



#16 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 26 August 2014 - 07:43 AM

@Tinybit

I may be wrong, but IF it is possible to have this happen "by design" (as opposed to "due to BIOS bug") it would be IMHO an useful feature.

A switch like --in-cache maybe to access the cache instead of the "real" file or device?

 

:duff:

Wonko



#17 steve6375

steve6375

    Platinum Member

  • Developer
  • 6598 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars
  •  
    United Kingdom

Posted 26 August 2014 - 08:32 AM

Let me imagine and describe why the strange case could happen.

 

On the other hand, grub4dos will buffer the device on read/write access. For real or virtual cdrom device, the buffer size is 64K. Thus, although the actual write failed, the contents of 64K buffer is in memory. Next, if we try to read device data that has buffered, we will get the data from the buffer, effectively avoiding a read access from the (real or virtual cdrom) device.

 

So, when the boot command finally run, it would read and load the (possibly) already buffered boot sectors in memory(with the sector contents modified), and transfer control to the boot sectors, which will continue to boot up the system on the virtual cdrom device.

 

If that is true then where would this buffer be? I should be able to find XXXTFIX.BIN in memory somewhere???



#18 tinybit

tinybit

    Gold Member

  • Developer
  • 1051 posts
  •  
    China

Posted 26 August 2014 - 09:01 AM

steve6375, on 26 Aug 2014 - 4:32 PM, said:

If that is true then where would this buffer be? I should be able to find XXXTFIX.BIN in memory somewhere???

If I remember correctly, the buffer begins at 0x20000 and ends at 0x2FFFF. The buffer size is 64K. EDIT: at 0x30000, not 0x20000

It is considered a virtual "track" of data on the device. grub4dos kernel almost always read data track by track(where track means virtual track). Each time it reads a track, it will buffer it at 0x20000 EDIT:0x30000. For CDROMs and virtual CDROMs, the virtual track size is 64K(i.e., it covers the whole buffer). For CHS-only disks, the virtual track size is the same as the real track size. For LBA-enabled disks, the virtual track size is 127 sectors(=63.5K). Only one virtual track is buffered, and the rest of the buffer (if there is any) is unused.

Note that the buffer is for all disks. That means, the buffer only holds the virtual track data of the last accessed int13 disk. (ud) and (pd) are not an int13 device, so they will not buffer.



#19 steve6375

steve6375

    Platinum Member

  • Developer
  • 6598 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars
  •  
    United Kingdom

Posted 26 August 2014 - 09:18 AM

title WINTEST
set s=0x50
debug 2
map /_ISO/WINDOWS/WIN8/Win8.1_32.ISO (0xff)
map --hook
cat --locate=BOOTFIX.BIN --number=1 (0xff)+0x3000
cat --locate=BOOTFIX.BIN --number=1 --replace=XXX (0xff)+0x3000
cat --locate=\x58\x58\x58TFIX.BIN --number=1 (0xff)+0x3000 && echo (0xff) has been patched!
echo Searching...
cat --locate=\x58\x58\x58TFIX.BIN (md)%s%+0x600
set /A x=%?% - 0x10
echo %x%
if not "%x%"=="0xFFFFFFFFFFFFFFF0" cat --hex --length=0x20 --skip=%x% (md)%s%+0x600
pause
reboot

I tried this and it doesn't work. It says  2DB7BF for the location in (0xff) and then 'has been patched' but can't find the string in memory.

I looked for the string in memory using cat and couldn't find it....



#20 tinybit

tinybit

    Gold Member

  • Developer
  • 1051 posts
  •  
    China

Posted 26 August 2014 - 09:46 AM

I am afraid the use of (md) caused problems. The (md) might be buffered and overwrite the buffer.

EDIT:

Buffer is not at 0x20000, but at 0x30000 and end at 0x3FFFF.



#21 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 26 August 2014 - 11:08 AM

I don't understand. :w00t: :(

 

The string BOOTFIX.BIN (on a .iso I have handy) is on sector 33 (where I believe it should be).

cat --locate=BOOTFIX.BIN (0xff)0+3000

returns

10FBF 3B7FBF

 

0x10FBF->69567 and 69567/2048=33,96826171875, i.e. the end of sector 33

 

And, as a matter of fact, if I use:

 

cat --locate=BOOTFIX.BIN (0xff)33+1

it returns

7BF

 

If the buffer is 64 Kb , i.e. the area between 0x30000 and 0x3FFFF, i.e. FFFF in size ->65535 bytes, the offset should be outside of the buffer. :dubbio:

 

Maybe in the case of the .iso some initial empty sectors are "skipped"? :unsure:

 

 

Would Fn.42 be able to access it? :unsure:

 

:duff:

Wonko



#22 tinybit

tinybit

    Gold Member

  • Developer
  • 1051 posts
  •  
    China

Posted 26 August 2014 - 12:07 PM

Emm...

 

The device is divided into virtual tracks. It is

 

The 1st virtual track, i.e., track 0

The 2nd virtual track, i.e., track 1

The 3rd virtual track, i.e., track 2

and so on

 

If you are to read the first sector of the device, then grub4dos kernel is likely to read the first virtual track and place it at buffer 0x30000. if you continue to read sectors inside the first track, grub4dos kernel will get the data from the buffer.

 

Consider you are to read a sector, say, it is on the 4th virtual track. Then grub4dos kernel will read the whole virtual track(remember it is the 4th virtual track) into the buffer at 0x30000.

 

At any moment, the buffer only holds one virtual track.

 

If you switch to another (new) disk and read from it, then the buffer will holds a virtual track for the new disk.



#23 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 26 August 2014 - 12:51 PM

I do understand that an Italian communicating with a Chinese writing in English and viceversa may incur in *something* lost in translation :), but in this case *everything* is seemingly lost. :w00t: :ph34r:

 

Maybe I can ask some questions and you can reply to them? :unsure:

 

Preamble:

  • Steve6375's experiments lead to believe that just mapping (or hooking the mapping) allows this strange "write on read only" behaviour.
  • This happens seemingly only if you map a file to a device and not if you map a device to another device.
  • The data that can be modified is at offset 69567 in the "source".
  • If the buffer is 65535 in size, it cannot possibly contain those bytes, unless either the buffer is larger or is starts not from the beginning of the device.
  • Issuing root (0xff) and/or chainloader (0xff) after the map -hook don't seem to change the behaviour.
  • Noone has switched to other disks
  • In the case of a .iso image the meaning of "track" and it's size needs to be clarified. :dubbio: 

 

Questions:

  1. Which command(s) put these bytes into memory?
  2. Is there a way to obtain the EXACT address in memory where the bytes are and where the write with cat --locate --replace actually happens?
  3. If there is, which is the way?
  4. Is it possible to verify/inspect this memory location?
  5. If yes HOW can it be done?

:duff:

Wonko



#24 tinybit

tinybit

    Gold Member

  • Developer
  • 1051 posts
  •  
    China

Posted 26 August 2014 - 02:22 PM

>>> The data that can be modified is at offset 69567 in the "source".

>>> If the buffer is 65535 in size, it cannot possibly contain those bytes, unless either the buffer is larger or is starts not from the beginning of the device.

 

69567 / 65536 = 1.0615081787109375

 

it is on the second track, that is, track #1. When the cat command is to read or write this data, it will place track#1 at buffer(automatically by grub4dos kernel), not track 0, nor any other track.

 

Consider a special case as follows. The data(string) to be modified happen to be at the end of track 0 and extended to the beginning of track 1. grub4dos will modify the first track and update data on the device. Then it will modify the second track and uppdate data on device. At this moment, the buffer only holds track 1(the second track). In this case you cannot see your whole string in the 64K memory buffer.

 

>>> Which command(s) put these bytes into memory?

 

No commands do it. It is done automatically by grub4dos kernel.

 

 

>>> Is there a way to obtain the EXACT address in memory where the bytes are and where the write with cat --locate --replace actually happens?

 

If you keep your work in a track(I mean you do not switch to another track, do not access data that crosses two or more tracks), then you can get the track from the buffer. The buffer address is 0x30000. So the track data begins at 0x30000. The data in the buffer is just a mirror of the track. To get the exact address of your string in the buffer, you have to do a calculation. If you know the offset in the track, you will also know the offset in the buffer(because the two offset values are equal).

 

>>> If there is, which is the way?

 

by calculation, as explained above.

 

>>> Is it possible to verify/inspect this memory location?

>>> If yes HOW can it be done?

 

yes, as explained above.

 



#25 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 26 August 2014 - 03:08 PM

Can you provide the calculation AND the exact specific command (HOW it can be done) if I want to "see" the data in memory?

 

Please, I am trying to learn by practical examples.

 

I issue these commands:

map /myiso.iso (0xff)

map --hook

 

Now, I know that on (0xff), on sector 33, at absolute offset 69567 there is the string BOOTFIX.BIN.

I then issue the command:

cat --locate=BOOTFIX.BIN --replace=XXX (0xff)33+1

 

If I issue the command:

cat --hex --skip=1952 (0xff)33+1

I can see it (modified) alright.

 

BTW if issue the command (say):

cat --hex --skip=1952 (0xff)500+1

and then re-issue the command:

cat --hex --skip=1952 (0xff)33+1

I can still see the string modified :w00t:

so the modification seem to affect not the "current" track buffer. :dubbio:

 

 

WHAT specific command should I issue now to see the modified string in memory?

WHAT is the specific address I  have to give to the command?

 

:duff:

Wonko






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users