Introducing UBRX - an Universal BIOS Recovery Console for x86 PCs

Following up on the previous BIOS generation endeavour, as well as wanting to demonstrate to any naysayer that a universal recovery console (or panic room) in the BIOS bootblock of an x86 system is not something from the realm of fantasy, it is my pleasure to introduce UBRX, the Universal Bootblock Recovery console for X86 systems.

In its current version (0.1), it is mostly a Proof of Concept aimed at the coreboot team, since the crafting of a 'panic room' type bootblock has been on their mind for some time, and my understanding is that their approach would be to make such a bootblock platform specific (the motherboard would first need to be supported by coreboot), whereas I believe that there is a way to be a lot more generic to produce a 'panic room' feature that works on all platforms, even the ones that coreboot doesn't support yet. The current bootblock is less than 2 KB, which ought to leave plenty of room for a Y-modem, CAR, and a full console implementation.

If your aim is to develop a real BIOS from scratch, and you have a PC that is more recent than the year 2000 (most PCs from the late nineties should work too) UBRX might also be of interest to you, since it should provide you with a serial console. In short, UBRX can also be used as a base for BIOS development, regardless of the machine you have.

What UBRX implements then is a safe method for the detection of a PnP Super I/O chip, as well as the detection and initialisation of a 16550 compatible UART there, to then provide on-demand access to a serial console. The emphasis here has to be with the safety of the detection being performed, as it is intended to be executed at every boot, without resulting in advert consequences for non PnP Super I/O hardware residing in the same hardware space as the one we check, or any non UART function residing in the Super I/O. To find more about how we achieve detection safety, I suggest you check the "Detection Primer" section of the UBRX README.

Now, of course, as with "unlimited" broadband, the "universal" applicability of UBRX comes with some understanding that fairness needs to be applied to the claim. As such, non PnP Super I/Os, PnP Super I/Os that require uncommon initialization (I'm looking at you ITE), and platforms using CPUs other than Intel or AMD are not currently supported. Also, due to the lack of datasheets from nVidia, it is very likely that UBRX may not work with motherboards sporting an nVidia chipset. However, if you have an Intel motherboard with an ICH# chipset, or an AMD motherboard with an SB##0 SouthBridge (which probably covers more than 90% of PCs from the last few years), UBRX is expected to work.

Finally, as UBRX is only a Proof of Concept for now, the console is limited to a serial repeater, so there's not much you can do with it. Especially it it missing CAR (Cache As RAM) initialization and Y-modem functionality, to be able to transfer and run bare metal executables to do interesting things, such as flashing the remainder of the BIOS, initializing the full range of RAM according to the hardware, or loading a debugger. Therefore, if you choose to test and flash UBRX, remember that you must have means to reflash your BIOS using an external program, as your PC will become unusable.

Please head to the github project for more info. A source tar archive of the source can also be downloaded here.

com0com signed drivers

If you are using VMware to play with virtual serial consoles on Windows, and especially if you want to have access to that console right from the start, a very nice tool to have is com0com, which is a null-modem emulator that creates a pair of connected virtual COM ports.
VMware does of course offer the possibility to use a named pipe, but you can only connect to it after the image has started running, which may result in bootup messages being truncated. And if you use the VMware option of directing serial to a file, then you can no longer interact.

Com0com solves this problem nicely by creating a pair of virtual COM ports, that are always available, and that you can use with VMware on one end, and putty or HyperTerminal on the other.

The only problem however is that, as of version 2.2.2.0, the current com0com drivers are unsigned. However, since I had a driver signing certificate begging to be used (before it expired), I have now made a signed version of the drivers available, so that you can easily install com0com without having to change the boot properties of your Vista or Windows 7 installation.

The signed 2.2.2.0 com0com drivers can be obtained here. They are compatible with any Windows 10, Windows 8.x, Windows Vista or Windows XP system.


Important Note: It is not because the signing certificate for the com0com driver above is now expired that this driver is invalid and/or should not be used. Timestamping was used at the time of the signature, therefore the driver package above is exactly as good as one using a non expired certificate. If signed driver packages ceased to be valid after the certificate expired, this would close the door for developers using a code signing certificate that they renew on a yearly basis, as it would require their users to upgrade their driver of applications every single year, which is of course nonsense. In short, regardless of what the expiration date on the certificate is, this driver package is no less usable or less safe that one with a non expired certificate.

Note that I stripped the GUI installer, so only the commandline one is available. Even with commandline, the installation is very easy however. All that you need to do is:

1. Download and extract the files (using 7-zip if needed)
2. Open an elevated command prompt in the i386\ (32 bit) or x64\ (64 bit) directory
3. Run the command:
   setupc
4. Enter the install command:
   install - -
5. Accept the prompts.

Once the driver is installed, two connected COM ports will be created: CNCA0 and CNCB0, which you can use, one with VMware, and the other with putty.

Now you don't have to miss any bootup messages and you can use an interactive COM port that persists regardless of the power status of the virtual machine. Enjoy!

Preventing USB devices with different serials to be seen as separate devices

Once again, I have to give props to Xiaofan:

The following is quoted from a USB-IF forum post (the link is now invalid)
http://www.usb.org/phpbb/viewtopic.php?p=33850

"Win2000/XP has a way to ignore the serial number.
This is copied form an AppNote I wrote:
-------------------------------------------------------
Ignore serial number in Win2000 / XP In Windows 2000 and XP,
there is a way to ignore the serial number for a certain device.
This is not recommended in general, but there are reasons to do so.

This is the registry key
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\UsbFlags]
The global way: The entry below does enable the serial numbers despite
its name! It is already there after a fresh installation.
GlobalDisableSerNumGen = 1
We recommend keeping the above setting unchanged.

Now here is the individual way. Create an entry under the
above ...\UsbFlags key. The name must start with "IgnoreHWSerNum"
followed by the vendor and product ID of the device. The value for the
entry is 1 for disable.
Example:
IgnoreHWSerNum0536016A= 1
Our vendor ID (VID) is 0536 (hex), the product ID (PID) depends
on the interface you choose.