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.
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!
[Jeremy] had an ASUS EEE PC 1000HE netbook on his hands which had succumbed to a corrupted BIOS. In most situations, people replace a motherboard when the BIOS is damaged beyond repair, but considering the price of motherboards, especially those built for portable devices, he simply refused to go that route.
Instead, he took it apart and did a little investigation to find out what SPI flash chip ASUS used in the netbook. With that information in hand, he put together an SPI flash programmer using a breadboard and a DLP-USB1232H USB to UART module. He couldn’t program the flash chip in-circuit, so he had to desolder it and deadbugged it onto his programmer. Using a few Linux-based flashing tools, he was able to reprogram the chip with a functioning BIOS in short order, saving him from a costly motherboard replacement.
While some motherboard manufacturers have built in secondary BIOS chips to prevent the need for this sort of recovery, it’s nice to know that the process is relatively straightforward, provided you have some basic soldering and Linux skills.
This also isn’t the first time we’ve seen someone recover an EEE PC from the brink – if you’re looking for an Arduino-based alternative, be sure to check this out.