Dear Andrea,
Welcome to coreboot. Please do not send messages over 500 kB (definitely not more than 1 MB) to mailing lists.
Am 16.02.25 um 18:30 schrieb Andrea Battelli:
I have an embedded system that I want to reuse but the bios is locked up and when I press the f12 key, it shows only a boot option (payload). How can I disassemble the bios or rebuild another one?
Attached is the dump of the rom and the screenshot of the boot menu
It’d be great if you just copied the text output from the payload.
SeaBIOS (version SageBIOS-20161017_085144-ttyree-dev-gtk-gtech-com) Select boot device:
1. Payload [igt_secure]
Sage Engineering [1] *was* a company offering coreboot development a long time ago. No idea, if they upstreamed this board, or how to get the source code. What board is it exactly?
Anyway, your attached dump has a coreboot image (CBFS – coreboot file system), you can dump with `cbfstool`:
``` $ ~/src/coreboot/util/cbfstool/cbfstool bios_igt_orig.bin print FMAP REGION: COREBOOT bios_igt_orig.bin: 16384 kB, bootblocksize 1024, romsize 16777216, offset 0xc00000 alignment: 64 bytes, architecture: x86
Name Offset Type Size Comp roothashes 0xc00000 (unknown) 192 none fallback/romstage 0xc00100 stage 60241 none fallback/ramstage 0xc0ecc0 stage 94548 none fallback/payload 0xc25e80 simple elf 49158 none bootsplash.jpg 0xc31ec0 bootsplash 48411 none etc/boot-menu-wait 0xc3dc40 raw 8 none (empty) 0xc3dc80 null 4888 none keyupdate 0xc3efc0 mma 8192 none (empty) 0xc41000 null 3992 none keystore 0xc41fc0 mrc 131072 none img/igt_secure 0xc62000 simple elf 83362 none vgaroms/videobios.rom 0xc76600 optionrom 65536 none (empty) 0xc86640 null 51544 none bootorder 0xc92fc0 raw 4096 none (empty) 0xc94000 null 2604952 none cpu_microcode_blob.bin 0xf0ffc0 microcode 38912 none (empty) 0xf19800 null 157592 none mrc.cache 0xf3ffc0 mrc_cache 65536 none (empty) 0xf50000 null 65432 none fsp.bin 0xf5ffc0 spd 524288 none (empty) 0xfe0000 null 12248 none bootorder_sata 0xfe3000 raw 4096 none bootorder_usb 0xfe4040 raw 4096 none bootorder_sec 0xfe5080 raw 4096 none (empty) 0xfe60c0 null 24 none rootpub 0xfe6100 fsp 2064 none (empty) 0xfe6940 null 103000 none ```
It does not seem to contain the build configuration, but you might be able to boot from a USB device. From there you should be able to read the logs with `cbmem` and find out the coreboot version and board name. Maybe that brings you further.
I have never heard of `igt_secure`. As you can access the dump, you can at least build the payload yourself, and replace `fallback/payload` or add it under `img/`. Maybe that works. No idea if the keys/hashes verify anything from this.
Anyway, the above should get you going.
Kind regards,
Paul
[1]: https://se-eng.com/ [2]:
Hi Andrea,
Is this actually a PC? A little Googling makes me think it's a gaming machine which may explain the "igt_secure" payload, in which case it may be designed to phone home or do some validation before booting the OS.
I think Paul has the right idea - see if it will boot from USB or whatever other media is available. If you can flash the firmware image then you can try swapping the payload with something else; the 16MB ROM should even be big enough to fit a minimal Linux kernel if you don't have ports for USB, SATA, etc. in that device.
The CPU is a Haswell which is still fairly popular in coreboot. If you have detailed hardware information then you might try to add a new mainboard target for your system. There are several examples in the src/mainboard directory and on review.coreboot.org (search for HASWELL).
I have never heard of `igt_secure`. As you can access the dump, you can
at least build the payload yourself, and replace `fallback/payload` or add it under `img/`. Maybe that works. No idea if the keys/hashes verify anything from this.
Hi Andrea,
I developed that BIOS for IGT although their payload was proprietary, i.e. I only gave them the technology to add to it. Their payload is designed to authenticate their OS (also proprietary), on an internal USB drive IIRC, prior to loading and running. And the hash for the system's root key is programmed into an OTP region of the system's SPI flash.
I can't recall anything to suggest the system could be easily repurposed by anyone outside of IGT. The system was specifically designed to be inflexible, in that regard, in order to address problems they'd experienced in older systems. It wouldn't surprise me if the internal drive was removed as part of decommissioning the system.
The payload may potentially contain an unadvertised hotkey to allow a password and which may present an option to configure a different boot path. Of course I have no knowledge of what password IGT would have chosen nor whether it would've been updated since its initial deployment. Assuming they built in that capability, the password wouldn't be discernable since only its signed hash would be detectable in the flash image.
Also, my memory is a little fuzzy on how early, in POST, the system's security actually begins. So it may be theoretically possible to design and build a new payload to remove/replace into the image. However, in my experience, there can be some real compatibility challenges between the version of libpayload used and the coreboot (SageBIOS) source.
Sorry that I don't have better news for you.
Marshall
On Fri, Feb 28, 2025 at 11:59 AM David Hendricks david.hendricks@gmail.com wrote:
Hi Andrea,
Is this actually a PC? A little Googling makes me think it's a gaming machine which may explain the "igt_secure" payload, in which case it may be designed to phone home or do some validation before booting the OS.
I think Paul has the right idea - see if it will boot from USB or whatever other media is available. If you can flash the firmware image then you can try swapping the payload with something else; the 16MB ROM should even be big enough to fit a minimal Linux kernel if you don't have ports for USB, SATA, etc. in that device.
The CPU is a Haswell which is still fairly popular in coreboot. If you have detailed hardware information then you might try to add a new mainboard target for your system. There are several examples in the src/mainboard directory and on review.coreboot.org (search for HASWELL).
I have never heard of `igt_secure`. As you can access the dump, you can
at least build the payload yourself, and replace `fallback/payload` or add it under `img/`. Maybe that works. No idea if the keys/hashes verify anything from this.
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
-
David Hendricks -
Marshall Dawson -
Paul Menzel