General BIOS editing capabilities

[Curious.George]

[Inspired by "edit BIOS" post...]

Pointers to a tutorial on what sorts of things can be done to an existing BIOS? I.e., how far I can "bend" it from what it originally aspired to be?

And, how to determine which BIOSes/machines are most suitable for modification (particularly mainstream laptops)?

[stj]

Re: General BIOS editing capabilities

most non-EFI bioses are a stack of nested menu's with bits set and cleared to decide if you will see them and what options you can choose.

EFI bioses use modules for everything and have a filesystem - they are a huge security risk!

there are a lot of programs around to edit them in various ways - but it's down to luck if your bios will work with the software.

go look on bios-mods.com for more info
and look at stuff like these:
https://github.com/corna/me_cleaner
https://github.com/platomav/MEAnalyzer
https://github.com/skochinsky/me-tools
https://github.com/theopolis/uefi-firmware-parser

or better yet, get shot of the old bios
https://www.coreboot.org

[Curious.George]

Re: General BIOS editing capabilities

most non-EFI bioses are a stack of nested menu's with bits set and cleared to decide if you will see them and what options you can choose.

But, is the "basic structure" of the code cast in concrete? E.g., I'm imagining a table of entry points for various services (IRQs). Could I scramble (rearrange) such a table and prevent the machine from being used as a COTS PC? (e.g., move the handler for the display to a different IRQ so it doesn't know how to display stuff)

EFI bioses use modules for everything and have a filesystem - they are a huge security risk!

there are a lot of programs around to edit them in various ways - but it's down to luck if your bios will work with the software.

OK, so it would be a crap shoot to acquire a particular machine with the intent of making such changes. Instead, I'd have to TRY particular machines until I found one that tolerated the abuses I was going to inflict on it.

go look on bios-mods.com for more info
and look at stuff like these:
https://github.com/corna/me_cleaner
https://github.com/platomav/MEAnalyzer
https://github.com/skochinsky/me-tools
https://github.com/theopolis/uefi-firmware-parser

or better yet, get shot of the old bios
https://www.coreboot.org

Thanks!

[ChaosLegionnaire]

Re: General BIOS editing capabilities

thats interesting. i have a board with a shitty programmed bios. if i install the full 4gb of ram, it constantly complains of a usb overcurrent and shuts down.

one workaround i found was to use a video card that reserves 512mb of pci address space and then set the agp aperture size to 256mb reserving a total of 768mb of pci address space and having 3.25gb of ram useable. as long as 3.25gb or less of ram is useable, it wont complain of this usb overcurrent shutdown bug.

obviously, the person doing the bios programming focked themselves with buggy pci address table code and gart code that overwrote some bits in another part of the memory address space triggering a fake usb overcurrent warning in memory. i wonder if i can mod the bios to fix this bug.

[stj]

Re: General BIOS editing capabilities

there was a period where the bios had errors intentionally inserted at micro$ofts request so Linux wouldnt install properly.

it may have been the acpi table.

[stj]

Re: General BIOS editing capabilities

But, is the "basic structure" of the code cast in concrete? E.g., I'm imagining a table of entry points for various services (IRQs). Could I scramble (rearrange) such a table and prevent the machine from being used as a COTS PC?

no, the editors only let you mess with config menu's on old bios or modules on UEFI.

you could do if if you compiled a new bios with coreboot.
they already have configured builds for a number of motherboards - i would start with that and edit it.

keep in mind that some drivers / o.s.'s wont use the bios once running.
you may be better just editing the magic-bytes used to identify different filesystems so it wont boot from another device.

[Curious.George]

Re: General BIOS editing capabilities

no, the editors only let you mess with config menu's on old bios or modules on UEFI.

So, I can just show/hide the settings that are presented to the user (in "SETUP")? I.e., I could hide the "boot Device" selection and HOPE that it doesn't reset itself from whatever device I elect as THE boot device -- but, can't actually FORCE a particular selection to remain in effect?

E.g., I could disable PXE, CD/DVD, USB, etc. boot devices to force the machine to boot from internal disk. Then, remove these "settings" from the SETUP menu to prevent them from being explicitly changed. But, that doesn't guarantee that the "default" might not be restored (e.g., by pulling the CMOS battery or by the BIST determining something is corrupt in the settings and FORCING them to their defaults).

you could do if if you compiled a new bios with coreboot.

OK, I will take a closer look at that option.

they already have configured builds for a number of motherboards - i would start with that and edit it.

I'm interested in laptops. I'll need to modify ~1,000 of them and can't expect to have 1,000 of the exact same make/model (though I'd want them to be comparable models in terms of features, capabilities, size, etc.) So, I'd like to find a few similar makes/models that can be "crippled" equivalently.

Am I more likely to find support for "big name" products? Older vs. newer? Etc.

keep in mind that some drivers / o.s.'s wont use the bios once running.

I'll be installing an RTOS that I wrote so I can tweek the hooks to the BIOS to use the services that the RTOS needs. I mainly want to make it so an OTS OS can't be installed. I want to turn the laptops into "dedicated appliances" that have no value other than in their new role (i.e., no value to a potential thief because the thief won't be able to install any other OS on them -- I can guarantee that my RTOS won't support OSX/Windows/Linux/BeOS/etc. applications so you've just stolen a brick!)

you may be better just editing the magic-bytes used to identify different filesystems so it wont boot from another device.

Yes. Or, limit the disk size recognized by the BIOS to something outrageously tiny (e.g., 1MB) with the knowledge that my RTOS can work-around that limitation (but that OTS OSs would be confounded by it). I can't change the structure of the supported filesystem(s) without rewriting lots of BIOS code but my RTOS can rely on its own filesystem code once loaded (so even the disks contents are useless to a thief).

Thanks!

[stj]

Re: General BIOS editing capabilities

the non-efi bios,
is exactly as you said, but you can also set the *default* and *optimised* menu values,
so a battery pull isnt an issue.

with coreboot, if your RTOS is small enough, you could make it the boot-payload or atleast some of it, so it boots from the flash!

[RJARRRPCGP]

Re: General BIOS editing capabilities

thats interesting. i have a board with a shitty programmed bios. if i install the full 4gb of ram, it constantly complains of a usb overcurrent and shuts down.

I thought I heard of a BIOS bug like that with a motherboard in the DDR1 era, possibly the Asus socket 939 motherboards.

[Curious.George]

Re: General BIOS editing capabilities

the non-efi bios, is exactly as you said, but you can also set the *default* and *optimised* menu values, so a battery pull isnt an issue.

Oh, OK. So, my strategy would be to set everything the way I want, force those settings into the default AND optimised "sets", then lockdown the menu options so they can't be changed. Finally, hack the motherboard so the BIOS can't be (easily) reflashed?

with coreboot, if your RTOS is small enough, you could make it the boot-payload or atleast some of it, so it boots from the flash!

It won't fit. In addition to the RTOS, there is a virtual machine that JITs the "programs".

[I'm developing a STEM project/"class" for preteens in the public school system to expose them to "real world" software/engineering by letting them develop autonomous algorithms for various "machines". E.g., "write a program to get this turtle to navigate a maze, unattended" or "write a program to allow this drone to identify and locate a particular target area and land IN that area" or "drive the turtle to navigate a 3D! maze". I bundle a lot of "services" with the RTOS -- e.g., vision subsystem, sensor interfaces, position feedback, etc. -- so the kids can just USE those capabilities (without needing the sophistication of being able to develop that technology). So, all of that has to be in place when the laptop boots -- don't want to complicate the issue by requiring the kids to deal with the normal sort of programming environment (edit/compile/link).]

[piernov]

Re: General BIOS editing capabilities

thats interesting. i have a board with a shitty programmed bios. if i install the full 4gb of ram, it constantly complains of a usb overcurrent and shuts down.

one workaround i found was to use a video card that reserves 512mb of pci address space and then set the agp aperture size to 256mb reserving a total of 768mb of pci address space and having 3.25gb of ram useable. as long as 3.25gb or less of ram is useable, it wont complain of this usb overcurrent shutdown bug.

obviously, the person doing the bios programming focked themselves with buggy pci address table code and gart code that overwrote some bits in another part of the memory address space triggering a fake usb overcurrent warning in memory. i wonder if i can mod the bios to fix this bug.

Yeah seen several BIOS with issues supporting 4GB RAM. Note that the Intel 945 chipset is not supposed to support 4GB anyway (no remapping of peripheral address space above 4GB), but even then BIOS should be written in a way that 4GB is supported but the non-remappable physical address space is marked as hardware reserved.
I think it may be the same for ATI RC410, officially boards support up to 2GB, I have one that works with 3GB but not 4GB.
And I've even seen a laptop with RS690M that works with 4GB, but POST summary will show 5GB instead…

there was a period where the bios had errors intentionally inserted at micro$ofts request so Linux wouldnt install properly.

it may have been the acpi table.

I don't know if it's intentional or not, but back in the days there were lots of issues in ACPI tables.
Linux started reporting more and more of those issues.

Just as an example, I have a Compaq desktop with an MSI MS-6577 board, and for some reason the RSDP structure says that it supports ACPI >= 2.0 in the version field, while in fact it doesnt support it and the extended data of the RSDP structure for ACPI 2.0 is just garbage.
It makes Linux fail parsing RSDP since the checksum for extended data is wrong.
I could extract the ACPI tables (and fix their checksums, some were wrong), but RSDP structure is somewhere else. I was not able to find where it is, so for now I edited the acpica driver (tbxfroot.c file) to ignore the extended checksum, and I set the acpi=rsdt kernel parameter to force it to use RSDT instead of ACPI 2.0's XSDT.

Was not really the topic but I wanted to share that anyway.



Now, to stay more or less on topic, if you are looking at a thousand of device, you should try to reach to a Chinese OEM and see what they can do. If you need to stay with x86, a custom Atom box may be a good idea. Or they could probably do something even cheaper and more customized with a low-end ARM SoC…

[Curious.George]

Re: General BIOS editing capabilities

Now, to stay more or less on topic, if you are looking at a thousand of device, you should try to reach to a Chinese OEM and see what they can do. If you need to stay with x86, a custom Atom box may be a good idea. Or they could probably do something even cheaper and more customized with a low-end ARM SoC…

Talking to a "Chinese OEM" will likely require PAYING for those devices (laptops) -- a foolish/needless expenditure when you can approach businesses to DONATE their USED laptops for the same purpose. As the laptops present a virtualized environment, each student "sees" roughly the same capabilities, regardless of the particulars of his/her laptop -- just needs to be capable enough to support all the overhead of the VM system at a speed that "feels responsive".

[I just don't want to have to deal with kids who use a COTS laptop on-line, install oddball apps, get malware, "pawn" it, etc.. Those folks would, then, need TIMELY "$upport" to bring the laptop back to a usable state. That means staff/labor to address those needs. Again, an avoidable expense if you lock the device down so all it is good for is "developing machine-control algorithms" (esp when those "machines" don't exist anywhere outside of this classroom -- no "resale value", either).]

[stj]

Re: General BIOS editing capabilities

Oh, OK. So, my strategy would be to set everything the way I want, force those settings into the default AND optimised "sets", then lockdown the menu options so they can't be changed. Finally, hack the motherboard so the BIOS can't be (easily) reflashed?

that will work out,
providing you can get the hardware you want with say an award bios on it.
what is your target, 32bit, 64bit?

[Curious.George]

Re: General BIOS editing capabilities

that will work out,
providing you can get the hardware you want with say an award bios on it.
what is your target, 32bit, 64bit?

I saw lots of Lenovo laptops mentioned (as supported) in one of your links...

My RTOS was originally written for ARM v8 (64b). But, I wrote it to be highly portable as the MCU market is forever changing and the design effort was too large to "leave to chance" in terms of future available hardware. I can easily scale it back to a 32b implementation as most of the "programs" needed for this application don't need to access huge objects.

The important thing is for the kids to think the "virtual" turtle/drone/etc. is responding as the REAL one will. I.e., an underperforming virtualization might have the turtle only capable of moving at some slow pace -- or, taking too long to "think" about its next move -- which wouldn't correlate to the performance the student would see when his code was running on the REAL turtle.

[obviously can't provide REAL turtles to each student to take home to use as that adds to expense and can be impractical for many students size), another maintenance issue, etc.!]

[TechGeek]

Re: General BIOS editing capabilities

there was a period where the bios had errors intentionally inserted at micro$ofts request so Linux wouldnt install properly.

it may have been the acpi table.

I dealt with a Horrible Products machine like that. Tried booting TinyXP for the lols and it crashed out with an ACPI error. Linux also complained about it, but was smart enough to work around it and installed successfully. I also had to compile a Broadcom wireless chipset driver for it.