0

I found a project on GitHub that emulates a Windows XP operating system, and I have a problem with an iso.

I want to extract it, change things and recreate the iso.

The problem is that it doesn't extract the bootloader, so when I boot the new one with Qemu, it doesn't start the system.

So, it occurred to me that the bootloader could be extracted using dd, but it seems impossible.

isoinfo -d -i /mnt/sda2/windows/vxp/VirtualXP.iso Setting input-charset to 'UTF-8' from locale. CD-ROM is in ISO 9660 format System id: Volume id: VirtualXP Volume set id: 20210310_1500 Publisher id: MagicISO v5.2 COPYRIGHT (C) 2001-2006 MagicISO, Inc. Data preparer id: MagicISO v5.2 COPYRIGHT (C) 2001-2006 MagicISO, Inc. Application id: Copyright File id: Abstract File id: Bibliographic File id: Volume set size is: 0 Volume set sequence number is: 1 Logical block size is: 2048 Volume size is: 22250 El Torito VD version 1 found, boot catalog is in sector 22248 Joliet with UCS level 3 found. No SUSP/Rock Ridge present Eltorito validation header: Hid 1 Arch 0 (x86) ID 'MagicISO Boot Record' Cksum 16 E7 OK Key 55 AA Eltorito defaultboot header: Bootid 88 (bootable) Boot media 0 (No Emulation Boot) Load segment 0 Sys type 6 Nsect 4 Bootoff 56E9 22249

And when I create it again it looks like this, without it working in the emulator:

isoinfo -d -i /mnt/sda2/windows/vxp/vxp0.iso Setting input-charset to 'UTF-8' from locale. CD-ROM is in ISO 9660 format System id: LINUX Volume id: VXP0 Volume set id: Publisher id: Data preparer id: Application id: MKISOFS ISO9660/HFS/UDF FILESYSTEM BUILDER & CDRECORD CD/DVD/BluRay CREATOR (C) 1993 E.YOUNGDALE (C) 1997 J.PEARSON/J.SCHILLING Copyright File id: Abstract File id: Bibliographic File id: Volume set size is: 1 Volume set sequence number is: 1 Logical block size is: 2048 Volume size is: 22935 El Torito VD version 1 found, boot catalog is in sector 79 CD-ROM uses ISO 9660:1999 relaxed format Joliet with UCS level 3 found. SUSP signatures version 1 found Rock Ridge signatures version 1 found Rock Ridge id 'RRIP_1991A' Eltorito validation header: Hid 1 Arch 0 (x86) ID '' Cksum AA 55 OK Key 55 AA Eltorito defaultboot header: Bootid 88 (bootable) Boot media 0 (No Emulation Boot) Load segment 0 Sys type 0 Nsect 4 Bootoff 50 80

I tried with sector number 22249, and it didn't work:

dd if="$1" of=bootloader.bin bs=1024 skip=$sector count=1024

I changed the name of the bootloader to grldr (I imagine that by doing this I am just changing the name), currently the command to generate the iso, I am using the following:

mkisofs -V VXP0 -J -joliet-long -iso-level 4 -D -R -o vxp0.iso -b grldr -c boot/boot.catalog -no-emul-boot -boot-load-size 4 -boot-info-table vxp0
Improve this question

3 Answers 3

Reset to default
3
+50

You can extract the bootloader from an ISO file through geteltorito included in genisoimage:

geteltorito -o bootloader VirtualXP.iso

In the manpage description:

 geteltorito is a Perl script which extracts the initial/default El Torito boot image from a CD if one exists. It will not extract any of other boot images that are allowed by the El Torito standard.
Improve this answer
2
  • I like this script. Does exactly what my FAQ link does in a script... Commented Jan 23, 2024 at 22:31
  • This seems to be the correct solution, however when I recreate the iso it doesn't work. Did you try it in Qemu? I changed bootloader to grldr, I really don't know how to do it. mkisofs -V VXP0 -J -joliet-long -iso-level 4 -D -R -o vxp0.iso -b grldr -c boot/boot.catalog -no-emul-boot -boot-load-size 4 -boot-info-table vxp0. If it works for you, you could create a repository on GitHub with the new iso. Commented Jan 25, 2024 at 1:20
1

I'm posting this as an answer instead of a comment in case it earns me the bonus, but I googled "Extract El Torito" and ended up at the:

Rufus Github Repository - Issue 63.

In case you don't know what RUFUS is see: Rufus - Create Bootable USB Drives the Easy Way. Apparently, issue 63 was a feature request now closed that involves the issue you're trying to resolve. About halfway down the request is this:

RUFUS FAQ Section - I'm trying to work with an ISO, but Rufus says it's unsupported.

I believe if you perform the steps outlined there, you'll end up with your desired results.

Summary of Steps

  1. Create a USB based on FreeDOS in Rufus.
  2. Mount the ISO file you created and look for the Virtual Disk Image that contains the DOS Boot Files
  3. Extract those files Back to the root.
  4. Modify any .bat files if needed.
  5. After modification, dd the entire mounted image back to a USB

The El Torito Boot Standard

See the Phoenix's BIOS Manufacturers published standard on El Torito, specifically page 14 for what is actually happening. Quoting ISOBuster:

It is not simply possible to copy a bootable floppy image onto CD or DVD and then hope the medium is now bootable. The File System really needs to know and needs to provide special structures and volume descriptors (in accordance with the El Torito standard).

Improve this answer
3
  • I appreciate the answer, but I'm on Linux, if it works for you you could create a repository on GitHub with the bootloader and the new iso. Commented Jan 25, 2024 at 1:29
  • @GAD3R and I aren't going to do the work for you. We've given you two correct answer as the script he mentioned does exactly what the FAQ I linked to does. You can accomplish the steps in the FAQ using Linux. 7-Zip is in the package repository, and any iso can be mounted via the loopback device. Commented Jan 25, 2024 at 14:58
  • I would like you to try it and tell if it works, without necessarily uploading the repository. Commented Jan 26, 2024 at 0:08
1 
dd if="$1" of=bootloader.bin bs=1024 skip=$sector count=1024

You used the wrong block size. The CD-ROM operates on 2048-byte blocks, but the boot code size in the El Torito header is specified in 512-byte blocks for some reason. 4 x 512 bytes = 2048, or exactly 1 CD-ROM block. And the isoinfo results indicate the boot block seems to be the very last block in the image.

So:

dd if=VirtualXP.iso of=bootloader.bin bs=2048 skip=22249 count=1

or maybe just

tail -c 2048 VirtualXP.iso > bootloader.bin

Hopefully there are no binary offsets within the bootloader that would need to be changed to match your new ISO structure.

Improve this answer
5
  • I already tried it in Qemu and it didn't work, I updated the question with the command with which I recreate the iso. If you get it working, you can create a GitHub repository with the bootloader and the new iso. Commented Jan 25, 2024 at 1:35
  • Did you use bs=2048 with that dd command? Your original question still says bs=1024. If the wrong block size was used, you'd get the wrong part of the image. And the count=1024 in the command in your question would give you a total of 1024*1024 bytes, while the boot block is just a single 2048-byte block. Commented Jan 25, 2024 at 5:44
  • Yes, I tried that and it didn't work. Apparently what is being extracted is boot.catalog instead of the bootloader. Commented Jan 26, 2024 at 0:04
  • According to the isoinfo output, the boot catalog is the block just before the boot block, so you were very close. You should try bs=2048 skip=22250 count=1 then. Commented Jan 26, 2024 at 5:56
  • I already tried, but doing that copies 0 bytes. 0 bytes copied, 0,000363325 s, 0,0 kB/s Commented Jan 26, 2024 at 7:07

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.