Installing LibreBoot The (Very) Lazy Way

August 20, 2018 by Tom Nardi 47 Comments

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” →

Making Vintage Computing Easy, The Hard Way

May 4, 2018 by Dan Maloney 35 Comments

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” →

Gigabytes The Dust With UEFI Vulnerabilities

April 4, 2017 by Jack Laidlaw 46 Comments

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.

The Trouble With Intel’s Management Engine

January 22, 2016 by Brian Benchoff 93 Comments

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” →

Hackaday Links: February 16, 2014

February 16, 2014 by Mike Szczys 17 Comments

[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.

Arduino Uno BIOS Flasher

May 4, 2012 by Mike Szczys 39 Comments

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.

Brute Force BIOS Hacking Using The Arduino

November 16, 2011 by Jeremy Cook 37 Comments

This clever hack uses an Arduino to do a brute force attack on a computer’s BIOS. In theory, this technique could be used for other programs, but it’s use would be limited since there’s no way to account for too many wrong passwords.

The Arduino generates and outputs the possible password emulating a USB keyboard. When this is done, the pixel in the middle of the screen is read. This is done by reading the analog red signal synced up with the corresponding horizontal and vertical pulses. As with any hack, there were some programming issues that had to be overcome (including one that locked up the keyboard emulator), but this was resolved, and the code is available if you wan to build your own.

Hardware for this build is simple, involving a LCD output, a button to stop everything, and a couple diodes to get the USB keyboard working correctly. This hack turned out quite nicely, and the code and schematics are included!