Jump to content











Photo
- - - - -

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


  • Please log in to reply
79 replies to this topic

#26 steve6375

steve6375

    Platinum Member

  • Developer
  • 7107 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars, www.easy2boot.com
  •  
    United Kingdom

Posted 26 August 2014 - 03:15 PM

OK - something is weird - the Win8 ISO that was showing a 'Press any key to boot to CD or DVD'  no longer shows the prompt!

 

If I compare the two files (the original on my Windows HDD and the one on the test USB drive that I tested with grub4dos) -

 

WinHex shows the ISO has been modified!

 

 

Attached Thumbnails

  • Capture_Win8A.JPG
  • Capture_Win8B.JPG
  • Capture_WIn8C.JPG


#27 tinybit

tinybit

    Gold Member

  • Developer
  • 1158 posts
  •  
    China

Posted 26 August 2014 - 03:33 PM

OK - something is weird - the Win8 ISO that was showing a 'Press any key to boot to CD or DVD'  no longer shows the prompt!

 

If I compare the two files (the original on my Windows HDD and the one on the test USB drive that I tested with grub4dos) -

 

WinHex shows the ISO has been modified!

 

And it means no BIOS bug found. And it could mean no more problems and end of discussion, couldn't it?



#28 tinybit

tinybit

    Gold Member

  • Developer
  • 1158 posts
  •  
    China

Posted 26 August 2014 - 03:50 PM

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:

 

In this example, you have never directly/explicitly used the buffer. It is the grub4dos kernel who uses the buffer, not you.

 

You only saw/got what you should see/get. No abnormal things ever occurred. Your disk sector data should have been modified as it should.

 

 

 

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?

 

I will try to answer them with another post. Wait some time.



#29 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 26 August 2014 - 03:58 PM

And it means no BIOS bug found. And it could mean no more problems and end of discussion, couldn't it?

It may also mean that one should use

map --read-only /myiso.iso (0xff)

as the mapped device appears then Read/Write, even if it is a .iso mapped to a CD/DVD like device. :dubbio:

 

I will try to answer them with another post. Wait some time.

Thank you. :)

 

:duff:

Wonko



#30 steve6375

steve6375

    Platinum Member

  • Developer
  • 7107 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars, www.easy2boot.com
  •  
    United Kingdom

Posted 26 August 2014 - 04:02 PM

I guess so. So .ISO files are writeable under grub4dos - I just assumed the CDFS file system did not support writes in grub4dos???



#31 steve6375

steve6375

    Platinum Member

  • Developer
  • 7107 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars, www.easy2boot.com
  •  
    United Kingdom

Posted 26 August 2014 - 04:07 PM

title WINTEST DIR PATCH
debug 2
map /_ISO/WINDOWS/WIN8/Win8.1_32.ISO (0xff)
map --hook
cat --locate=f\x00i\x00x\x00.\x00b\x00i\x00 --number=5 (0xff)+0x3000 && echo Found fix.bi
cat --locate=q\x00i\x00x\x00.\x00b\x00i\x00 --number=5 (0xff)+0x3000 && echo Found qix.bi
cat --locate=f\x00i\x00x\x00.\x00b\x00i\x00 --number=1 --replace=q\x00i\x00x\x00.\x00b\x00i\x00 (0xff)+0x3000
cat --locate=q\x00i\x00x\x00.\x00b\x00i\x00 --number=1 (0xff)+0x3000 && echo (0xff) has been patched!
pause
chainloader (0xff)

This actually permanently changes the directory entry for \boot\bootfix.bin  in the ISO file to  \boot\booqix.bin !!!

 

I think it also corrupts the ISO because  7Zip can no longer read it as a Joilet ISO, but UltraISO does read it and shows the  bootqix.bin file.

P.S. It still boots though.



#32 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 26 August 2014 - 04:22 PM

I guess so. So .ISO files are writeable under grub4dos - I just assumed the CDFS file system did not support writes in grub4dos???

But this has nothing connected to CDFS, i.e. not with the filesystem, but a lot of things connected to the "nature" of a CD-ROM like device.

 

I mean, of course .iso files are writable under grub4dos, since you access them as sectors on the hard disk like device hosting the .iso file, the point is when you map them to a CD-like device and access them through that  mapping, that should be IMHO "inherently read only". :dubbio:

 

BTW, not really an issue, one should make sure to use the --read-only parameter when mapping and the "issue" is solved.

 

Stll, having a "temporary write" kind of access to a few "key sectors" could be an useful feature (though really cannot say if doable and with which limits.

 

After all, when you do a map --in-situ something *similar* to this should be happening :unsure:

 

 

:duff:

Wonko



#33 tinybit

tinybit

    Gold Member

  • Developer
  • 1158 posts
  •  
    China

Posted 26 August 2014 - 04:24 PM

Seeing that your last command is:

 

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

 

Note that (0xff)33+1 has been read by grub4dos kernel.

 

So the grub4dos kernel placed the second track at buffer address 0x30000. The content is the mirrored (0xff)32+32 with length 64K.

 

Your string should be at address (0x30000 + 2048 + 1983).

 

Your may use a read command to display the hex value of data at the adress, but you can only get 4 bytes for each read command.

 

Now it is time to answer your questions.

 

 

 

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?

 

Unfortunately, by far, I haven't found such a command. Maybe someone can write a command for this purpose. The command name can be "dumpdiskbuffer" and the like.

 

But the address is already known as mentioned above: (0x30000 + 2048 + 1983).


Edited by tinybit, 26 August 2014 - 05:01 PM.


#34 tinybit

tinybit

    Gold Member

  • Developer
  • 1158 posts
  •  
    China

Posted 26 August 2014 - 04:34 PM

I guess so. So .ISO files are writeable under grub4dos - I just assumed the CDFS file system did not support writes in grub4dos???

 

Yes. writable. You can (over)write files on virtual cdroms with dd or similar commands, unless you mapped with --fake-write or --read-only.



#35 steve6375

steve6375

    Platinum Member

  • Developer
  • 7107 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars, www.easy2boot.com
  •  
    United Kingdom

Posted 26 August 2014 - 04:51 PM

when using (0xff)xxx+yyy - it seems that  the 'blocks' are not 512 byte sectors as with a hard disk or floppy, but are 2048 bytes

 

cat --locate=BOOTFIX.BIN (0xff)0+01a9d  >>> 2DB7BF  D4E7BF
cat --locate=BOOTFIX.BIN (0xff)0+01a9c  >>> 2DB7BF

 

1a9c sectors = 3487744 353800 bytes  * 4 = D4E000
1a9d sectors = 3488256 353A00 bytes  * 4 = D4E800

 

 

Also using --read-only gives a disk-write error if you try to replace a string.

 

mysteries solved?



#36 tinybit

tinybit

    Gold Member

  • Developer
  • 1158 posts
  •  
    China

Posted 26 August 2014 - 05:13 PM

virtual cdroms are a cdrom and should have 2048 sector size, just as a real cdrom should.

 

you cannot write onto a read-only disk. Think it as "write-protect". If your usb drive is write-protected, and you tried to write to it, you will get an error, telling you that you cannot write.

 

if you use --fake-write, you can expect it no longer error out. it simply discard the data written.



#37 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 26 August 2014 - 05:27 PM

@Steve6375
Sure, a CD-ROM device has 2048 bytes sector, no mystery there.
As well if with --read-only you get the disk write error, it is "normal", i.e. it is the same thing that happens if you map the (cd) device to (0xff) (as opposed to mappng a .iso file residing on hard disk like device).
All in all the whole "false alarm" revolves around:
 

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

 
 
 
@tinybit
The actual "exact offset" of the string "BOOT" part of the "BOOTFIX.BIN" is 1983, i.e. the 0x7BF I already mentioned.
Hence I should find "BOOT" (4 bytes) at address 0x30000+0x07BF i.e. 0x307BF.
 
map /myiso.iso (0xff)
map --hook
cat --hex --skip=1983 --length=4 (0xff)33+1
00007BF: 42 4F 4F 54                                        ;BOOT
cat --hex --locate=BOOTFIX.BIN (0xff)33+1
7BF
read 0x307BF
Address 0x307bf: Value 0x0
 
:w00t: :dubbio:
 
:duff:
Wonko



#38 tinybit

tinybit

    Gold Member

  • Developer
  • 1158 posts
  •  
    China

Posted 26 August 2014 - 11:02 PM

See my modified post above(post #33). I guess I was modifying my post while you were doing your test.

 

The second track starts at (0xff)32+1 and ends at (0xff)32+31.

 

So the address of the string is (0x30000 + 2048 + 1983) = 0x30FBF.

 

Also, 69567 - 65536 = 4031 = 0xFBF

 

and we can get the same address (0x30000 + 0xFBF).



#39 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 27 August 2014 - 08:30 AM

Very good.

It works. :yahoo:

 

 

map /myiso.iso (0xff)
map --hook
cat --hex --skip=1983 --length=4 (0xff)33+1
00007BF: 42 4F 4F 54 ;BOOT
cat --hex --locate=BOOTFIX.BIN (0xff)33+1
7BF
read 0x30FBF
Address 0x307bf: Value 0x544f4f42

 

but there is still something "queer":

 

 

cat --hex --skip=1983 --length=4 (0xff)33+1
00007BF: 42 4F 4F 54 ;BOOT
cat --hex --locate=BOOTFIX.BIN (0xff)33+1
7BF

 

Now this seems like a bug of some kind :unsure::

 

cat --hex --skip=1983 --length=4 (0xff)33+1
00007BF: 42 4F 4F 54 ;BOOT

 

cat --hex --skip=4031 --length=4 (0xff)32+2

NOTHING

 

cat --hex --skip=6079 --length=4 (0xff)31+3

00007BF: 42 4F 4F 54 ;BOOT

 

cat --hex --skip=8127 --length=4 (0xff)30+4

00007BF: 42 4F 4F 54 ;BOOT

Then:

cat --hex (0xff)32+1 <- outputs 1 512 bytes (and not 2048 bytes) sector additionally missing last 10 bytes :w00t:

same happens for:

cat --hex (0xff)32+2

cat --hex (0xff)32+3

cat --hex (0xff)32+4

and the contents are NOT that of that sector. 

The sector contains  string "CHS_BOOT" and:

cat --hex --locate=CHS_BOOT (0xff)31+2

works fine and returns 865, whilst:

cat --hex --locate=CHS_BOOT (0xff)32+1

fails and returns NOTHING

 

:duff:

Wonko



#40 steve6375

steve6375

    Platinum Member

  • Developer
  • 7107 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars, www.easy2boot.com
  •  
    United Kingdom

Posted 27 August 2014 - 09:37 AM

I can't repro that? are you using latest 22/08/2014 grub4dos (older versions have NTFS bugfix) ?

http://grub4dos.chen...ries/downloads/



#41 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 27 August 2014 - 10:15 AM

I can't repro that? are you using latest 22/08/2014 grub4dos (older versions have NTFS bugfix) ?

http://grub4dos.chen...ries/downloads/

I was actually testing 2014-08-17.

I just re-tried an older version 2012-06-19 and it works.

I will re-try with 2014-08-22 and report.

If it is that bug :unsure: I don't understand the connection with fiddling with the 0xff device. :unsure:

 

Edit: SAME issue with 2014-08-22 :frusty:

 

:duff:

Wonko



#42 steve6375

steve6375

    Platinum Member

  • Developer
  • 7107 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars, www.easy2boot.com
  •  
    United Kingdom

Posted 27 August 2014 - 10:21 AM

I was actually testing 2014-08-17.

I just re-tried an older version 2012-06-19 and it works.

I will re-try with 2014-08-22 and report.

If it is that bug :unsure: I don't understand the connection with fiddling with the 0xff device. :unsure:

 

:duff:

Wonko

Aug 17 version should have the fix too.

Can you retest with 2014-08-17 from fresh boot as well?

Was it 0.4.5c? I have seen bugs in 0.4.6a and ISO handling.



#43 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 27 August 2014 - 10:26 AM

Sure, it is 0.4.5c (I never use 0.4.6a).

I'll try building a small image in such a way that it is reproducible.

 

:duff:

Wonko



#44 tinybit

tinybit

    Gold Member

  • Developer
  • 1158 posts
  •  
    China

Posted 27 August 2014 - 11:24 AM

It is also important to tell the exact date that introduced the bug.



#45 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 27 August 2014 - 02:47 PM

The behaviour seems "consistent" on a .iso image which has on LBA32 a directory entry. :w00t:
 
Find attached a small "dummy" .iso image where you should be able to replicate:
 
 
map /empty.iso (0xff)
map --hook
cat --hex --skip=1983 --length=4 (0xff)33+1
00007BF: 42 4F 4F 54 ;BOOT
cat --hex --locate=BOOTFIX.BIN (0xff)33+1
7BF
read 0x30FBF
Address 0x307bf: Value 0x544f4f42
 
cat --hex --skip=1983 --length=4 (0xff)33+1
00007BF: 42 4F 4F 54 ;BOOT

cat --hex --skip=4031 --length=4 (0xff)32+2
NOTHING  

cat --hex --skip=6079 --length=4 (0xff)31+3
00017BF: 42 4F 4F 54 ;BOOT

cat --hex --skip=8127 --length=4 (0xff)30+4
0001FBF: 42 4F 4F 54 ;BOOT
 

cat --hex (0xff)32+1

only 0x59 bytes (made essentially of 0xE2 value bytes) are displayed. :frusty:

 

Please try and reproduce the above ...

 

 

:duff:
Wonko

Attached Files



#46 steve6375

steve6375

    Platinum Member

  • Developer
  • 7107 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars, www.easy2boot.com
  •  
    United Kingdom

Posted 27 August 2014 - 03:05 PM

mystery solved! You need to read here

 

Note: If using cat --hex, it may not always work if the first few bytes appear to resemble a compressed file header to grub4dos. In this case cat --hex will not output anything at all!!! To always view the exact byte content a memory area or file, turn off the grub4dos decompression translation using:

# turn off decompression
write 0x82a4 1
# always show actual bytes
cat --hex --length=32 (md)0x300+1
# restore decompression
write 0x82a4 0



#47 steve6375

steve6375

    Platinum Member

  • Developer
  • 7107 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars, www.easy2boot.com
  •  
    United Kingdom

Posted 27 August 2014 - 03:15 PM

I reported this as a 'bug' before - see here

 

I don't think that the auto-decompress should be enabled except for certain commands like splashimage, etc. when it could be enabled - the image read - and then disabled by grub4dos before returning back.

 

As you see from the bug report, it also means you cannot guarantee that  cat or write will write to memory either at all or as intended!

 

tinybit was involved in the discussion before. It would be nice to make a list of when the auto-decompress feature is useful in grub4dos  (i.e. under what circumstances is it used?) and then see if we could have a default of 'auto-decompress off' as the default, but grub4dos turn it on temporarily for certain commands only?



#48 steve6375

steve6375

    Platinum Member

  • Developer
  • 7107 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars, www.easy2boot.com
  •  
    United Kingdom

Posted 27 August 2014 - 03:25 PM

P.S. dd also decompresses

 

so you could have two  100MB files    A and B - if A was a compressed file, then

 

dd if=()/A of=()/B

 

would not work correctly. If A had a compressed file header, g4d would decompress it to B and B would not be big enough.



#49 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 27 August 2014 - 03:38 PM

Yes and no.
 
Meaning that that bug report was about memory and memory drives, here we are instead listing with cat the contents of a (mapped) disk sector.
 
Most probably the origin/cause of the bug is the same :), but it seems to me a bit more relevant as it can happen (though rarely) also "in nature", i.e. without having fiddled in any way with memory or memory drives.
 
About this:
http://www.rmprepusb...mented-commands

...
Later versions of grub4dos (2012) have enhanced cat parameters which allow you to replace strings.
...

Note: If using cat --hex, it may not always work if the first few bytes appear to resemble a compressed file header to grub4dos. In this case cat --hex will not output anything at all!!! To always view the exact byte content a memory area or file, turn off the grub4dos decompression translation using:
# turn off decompression
write 0x82a4 1
...
# restore decompression
write 0x82a4 0


Though I can confirm that the above works fine :yahoo: with latest builds, I can also definitely affirm that *something* must have changed *sometimes* as I can confirm that 2012-06-19 can cat --hex (0xff)+32 just fine.

There seems to be a bug introduced in later 2012 or 2013/2014 versions. :unsure:

But I don't really see an issue if a parameter like --hex automatically writes the 1 to 0x82a4 and on exit re-writes the 0, honestly expecting that a "normal" user will know about the issue and remember the "write 0x82a4 1" before and the "write 0x82a4 0" after a cat command is instead IMHO "too much".

Let's see if through this "revamp" tinybit and/or chenall will reconsider the matter. :)
 
:duff:
Wonko

#50 steve6375

steve6375

    Platinum Member

  • Developer
  • 7107 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars, www.easy2boot.com
  •  
    United Kingdom

Posted 27 August 2014 - 04:06 PM

The auto-decompression was introduced at some point - presumably after 2012-06 ??

The bug report mentions cat --hex - see further down in the bug report.

 

commands such as write, cat --hex  and cat --locate should  set 0x82a4 and then restore it back (to whatever it was before) afterwards in my opinion too. -_-






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users