It might be difficult for modern audiences to believe, but at one point Microsoft Windows fit on floppy disks. This was a simpler time, with smaller hard drives, lower resolution displays, and no hacker blogs for you to leave pessimistic comments on. A nearly unrecognizable era, to be sure. But if you’re one of the people who looks back on these days fondly, you might wonder why we don’t see this tiny graphical operating system smashed into modern hardware. After all, SkiFree sure ain’t gonna play itself.
Well, wonder no more. A hacker by the name of [redsPL] thought that Microsoft’s latest and greatest circa 1992 might do well crammed into the free space remaining on a ThinkPad X200’s firmware EEPROM. It would take a little fiddling, plus the small matter of convincing the BIOS to see the EEPROM as a virtual floppy drive, but clearly those are all minor inconveniences for anyone mad enough to boot their hardware into a nearly 30 year old copy of Visual Basic for a laugh.
The adventure starts when [redsPL] helped a friend install libreboot and coreboot on a stack of old ThinkPads by using the Raspberry Pi as an SPI flasher, a pastime we’re no strangers to ourselves. Once the somewhat finicky software and hardware environment was up and running, it seemed a waste not to utilize it further. Especially given the fact most firmware replacements only fill a fraction of the X200’s 8 MB chip.
Of course, Windows 3.1 was not designed for modern hardware and no proper drivers exist for much of it. Just getting the display resolution up to 1024×768 (and still with only 256 colors) required patching the original video drivers with ones designed for VMWare. [redsPL] wasn’t able to get the sound hardware working, but at least the PC speaker makes the occasional buzz. The last piece of the puzzle was messing around the
xz commands until the disk image was small enough to sneak onto the chip.
Believe it or not, this isn’t the first time we’ve seen Windows from this era running on a (relatively) modern ThinkPad. For whatever reason, these two legends of the computing world seem destined to keep running into each other.
[Thanks to Renard for the tip.]
Recently I was given a somewhat crusty looking ThinkPad T400 that seemed like it would make a good knock around machine to have on the bench, if it wasn’t for the fact the person who gave it to me had forgotten (or perhaps never knew) the BIOS password. Cleaning the machine up, putting more RAM in it, and swapping the wheezing hard drive for an SSD would be a relatively cheap way to wring a few more years of life from the machine, but not if I couldn’t change the boot order in BIOS.
Alright, that’s not entirely true. I could have installed an OS on the SSD from my desktop and then put it into the T400, but there was something else at play. The locked BIOS gave me the perfect excuse to install LibreBoot on it, which is one of those projects I’ve had in the back of my mind for years now. Replacing the BIOS with something entirely different would solve the password issue, but there was only one problem: the instructions for flashing LibreBoot onto the T400 are intimidating to say the least.
You’re supposed to take the entire machine apart, down to pulling the CPU cooler off and removing the display. All so you can flip the motherboard over to access a flash chip between the CPU and RAM that’s normally covered by a piece of the laptop’s frame. Oh how I hated that diabolical chunk of magnesium which kept me from my silicon quarry. Flashing the chip would take a few minutes, but YouTube videos and first hand accounts from forums told me it could take hours to disassemble the computer and then put it back together after the fact.
Deep into that darkness I peered, long I stood there, wondering, fearing, doubting. Then a thought came to me: maybe I could just cut the thing. If it was a success, it would save me hours of work. If it failed, well, at least the computer didn’t cost me anything. Time to roll the dice.
Continue reading “Installing LibreBoot the (Very) Lazy Way”
If you want to not take for granted how easy and seamless computers have become, take up vintage computing as a hobby. If you venture down the retro path, you’ll quickly question how anyone ever got any useful work done with computers, and the farther back you go in computer history, the more difficult everything seems to become.
Case in point: how do you easily transfer files between a home-brew PC/XT and your modern desktop? Back in the day we did it with null modem cables or by sneaker-netting stacks of floppies, but [Scott M. Baker] found another way — putting a Raspberry Pi on the ISA bus as a virtual floppy drive. The heart of the ISA card is an IDT7130, a 1-kb RAM chip that allows simultaneous asynchronous access over dual ports. One port talks to the ISA bus and the other talks to the GPIO of the Pi, after level-shifting to make everything voltage compatible, of course. [Scott] wrote a driver for the card, plugged a Pi Zero W into the header pins, and threw a Python server together that makes local images available to the shared memory on the card. The upshot of this is that the retro machine thinks it has a floppy in it, but it’s actually a server. The video below has tons of detail and shows the card in action. Pretty slick.
[Scott]’s projects are always fun to check out, and he really seems to have the retro life dialed in. Whether it’s old jukebox hacks or a Unix-ish OS for Z80s, there’s plenty to learn. Although we’d like to see more about that PC/XT in the video; are those Nixies we spy along the front panel?
Continue reading “Making Vintage Computing Easy, The Hard Way”
At this year’s BlackHat Asia security conference, researchers from Cylance disclosed two potentially fatal flaws in the UEFI firmware of Gigabyte BRIX small computers which allow a would-be attacker unfettered low-level access to the computer.
Gigabyte has been working on a fix since the start of 2017. Gigabyte are preparing to release firmware updates as a matter of urgency to only one of the affected models — GB-BSi7H-6500 (firmware vF6), while leaving the — GB-BXi7-5775 (firmware vF2) unpatched as it has reached it’s end of life. We understand that support can’t last forever, but if you sell products with such a big fault from the factory, it might be worth it to fix the problem and keep your reputation.
The two vulnerabilities that have been discovered seem like a massive oversight from Gigabyte, They didn’t enable write protection for their UEFI (CVE-2017-3197), and seem to have thrown cryptography out of the window when it comes to signing their UEFI files (CVE-2017-3198). The latter vulnerability is partly due to not verifying a checksum or using HTTPS in the firmware update process, instead using its insecure sibling HTTP. CERT has issued an official vulnerability note (VU#507496) for both flaws.
Attackers may exploit the vulnerabilities to execute unsigned code in System Management Mode (SMM), planting whatever malware they like into the low level workings of the computer. Cylance explain a possible scenario as follows:
The attacker gains user-mode execution through an application vulnerability such as a browser exploit or a malicious Word document with an embedded script. From there, the attacker elevates his privileges by exploiting the kernel or a kernel module such as Capcom.sys to execute code in ring 0. A vulnerable SMI handler allows the attacker to execute code in SMM mode (ring -2) where he finally can bypass any write protection mechanisms and install a backdoor into the system’s firmware.
With all this said, it does raise some interesting opportunities for the hacker community. We wonder if anyone will come up with a custom UEFI for the Brix since Gigabyte left the keys in the door.
Something is rotten in the state of Intel. Over the last decade or so, Intel has dedicated enormous efforts to the security of their microcontrollers. For Intel, this is the only logical thing to do; you really, really want to know if the firmware running on a device is the firmware you want to run on a device. Anything else, and the device is wide open to balaclava-wearing hackers.
Intel’s first efforts toward cryptographically signed firmware began in the early 2000s with embedded security subsystems using Trusted Platform Modules (TPM). These small crypto chips, along with the BIOS, form the root of trust for modern computers. If the TPM is secure, the rest of the computer can be secure, or so the theory goes.
The TPM model has been shown to be vulnerable to attack, though. Intel’s solution was to add another layer of security: the (Intel) Management Engine (ME). Extremely little is known about the ME, except for some of its capabilities. The ME has complete access to all of a computer’s memory, its network connections, and every peripheral connected to a computer. It runs when the computer is hibernating, and can intercept TCP/IP traffic. Own the ME and you own the computer.
There are no known vulnerabilities in the ME to exploit right now: we’re all locked out of the ME. But that is security through obscurity. Once the ME falls, everything with an Intel chip will fall. It is, by far, the scariest security threat today, and it’s one that’s made even worse by our own ignorance of how the ME works.
Continue reading “The Trouble With Intel’s Management Engine”
[Moogle] wrote in to see if anyone can figure out why his unused electrolytic capacitors are popping. This is the behavior you see in populated caps whose electrolyte dries out. But these are still in his parts bin. Anyone know why they would pop when going unused?
We see a lot of BIOS flashing hacks; but it’s always a handy thing to know about when you get in a bind. Here [Adan] shows us how to reflash a corrupt BIOS using a Tiva C Launchpad board.
Wanting to hack together her own blow gun [Carlyn] scrapped a handheld vacuum cleaner. When she discovered the pump could not easily be converted from suck to blow she made a handheld suction manipulator which picks up paper plates and a few slightly heavier objects.
Unfortunately a drill press is not one of the tools we have in our lair right now. If we did, this tip about using it to help tap threads in a hole would come in really hand.
Retro computing fans will appreciate this Z80 computer build (translated). It’s a fairly large mainboard with plenty of chips, resistors, buttons, and seven segment displays. Excellent. [Thanks Daniel]
We start to drool a little bit when we see a teardown post that shows off a piece of equipment really well. We’ve already reached for a bib to catch the slobber from pawing our way through [David’s] teardown of an HP 6010A bench supply.
We’ve seen the Arduino used to flash BIOS chips several times now. But these hacks are almost always the result of a bad flash. This time around [GNUtoo] is interested in putting a tool in your hands which can be used to flash Coreboot to your motherboard. His offering uses the Arduino Uno, but there are several other hardware options covered as well.
The firmware makes use of the serprog-duino library which was crafted at writing to flash memory chips. On the computer side of things the flashrom package pushes the BIOS image to the Arduino. The nice thing is the flashrom is a common packge in Linux repositories so it’s probably just an apt-get away.
The process isn’t fast, taking about ten minutes to program a 1 Mb chip. But if you’re just interested in loading an open source BIOS alternative this is easy to set up.