Windows 3.1 In My BIOS? It’s More Likely Than You Think

April 10, 2019 by Tom Nardi 64 Comments

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 zip and 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.]

Jaromir Sukuba: The Supercon 2018 Badge Firmware

March 7, 2019 by Elliot Williams 3 Comments

If you missed it, the Hackaday Supercon 2018 badge was a complete retro-minicomputer with a screen, keyboard, memory, speaker, and expansion ports that would make a TRS-80 blush. Only instead of taking up half of your desk, everyone at the conference had one around their neck, when they weren’t soldering to it, that is.

The killer feature of the badge was its accessibility and hackability — and a large part of that was due to the onboard BASIC interpreter. And that’s where Jaromir comes in. Once Voja Antonic had finalized the design of the badge hardware for our conference in Belgrade in the spring of 2018, as Jaromir puts it, “all we needed was a little bit of programming”. That would of course take three months. The badge was battle-tested in Belgrade, and various feature requests, speed ups, and bugfixes were implemented (during the con!) by Jaromir and others.

Firmware work proceeded over the summer. Ziggurat29 helped out greatly by finding ways to speed up the badge’s BASIC interpreter (that story is told on his UBASIC and the Need for Speed project page) and rolled into the code base by Jaromir. More bugs were fixed, keywords were added, and the three-month project grew to more like nine. The result: the badge was in great shape for the Supercon in the fall.

Jaromir’s talk about the badge is supremely short, so if you’re interested in hacking a retrocomputer into a PIC, or if you’ve got a badge and you still want to dig deeper into it, you should really give it a look. We don’t think that anyone fully exploited the CP/M machine emulator that lies inside — there’s tons of software written for that machine that is just begging to be run after all these years — but we’re pretty sure nearly everyone got at least into the basement in Zork. Dive in!

Continue reading “Jaromir Sukuba: The Supercon 2018 Badge Firmware” →

Live Hacking And A MIDI Keytar

March 2, 2019 by Brian Benchoff 7 Comments

We can’t think of where you’d buy a new, cheap, MIDI keytar that’s just a keyboard and a handle with some pitch and mod wheels or ribbon controllers. This is a format that died in the 90s or thereabouts. Yes, the Rock Band controller exists, but my point stands. In fact, the closest you can get to a cheap, simple MIDI keytar is the Alesis Vortex Wireless 2 Keytar, but the buttons on the handle don’t make any sense. [marcan] of Wii and Kinect hacking fame took note. (YouTube, embedded below.)

Reverse engineering is a research project, and all research projects begin with looking at the docs. When it comes to consumer electronics, the best resource is the documents a company is required to submit to the FCC (shout out to FCC.io), which gave [marcan] the user manual, and photos of the guts of the keytar. The ‘system update download’ files are living on the Alesis servers, and that’s really all you need to reverse engineer a keytar.

The first step is extracting the actual device firmware from whatever software package appears on the desktop when you download the software update. This is a simple job for 7zip, and after looking at a binary dump of the firmware, [marcan] discovered this was for an STM chip. With the datasheet of the chip, [marcan] got the entry point for the firmware, some values, and the real hardware hacking began. All of this was done with IDA.

This is a five-hour hacking session of cross-referencing the MIDI spec and a microcontroller built thirty years after this spec was developed. It’s an amazing bit of work just to find the bit of code than handled the buttons on the keytar grip, and it gets even better when the patched firmware is uploaded. If you want to ‘learn hacking’, as so many submitters on our tip line want to do, this is what you need to watch. Thanks [hmn] for the tip.

Continue reading “Live Hacking And A MIDI Keytar” →

Supercon: Ruth Grace Wong And Firmware From The Firehose

February 22, 2019 by Elliot Williams 13 Comments

Firmware and software are both just code, right? How different could the code that runs Internet-scale distributed web stuff be from the code that runs a tiny microcontroller brain inside a personal hydroponics device? Night and day!

Ruth Grace Wong works in the former world, but moonlights as a manufacturing engineer with some friends. Their product had pre-existing firmware that contained (at least) one bug, and Ruth’s job was to find it. The code in question was written by the Chinese PCB engineer, who knew the electronics intimately but who had no software background, providing Ruth an opportunity to jump head-first into the rawest of raw embedded programming. Spoiler alert: she found the bug and learned a lot about firmware along the way. This talk follows her along the adventure.

“The code is very well documented, in Chinese” but the variable names are insanely non-descriptive. Similarly, while the PCB engineer knows full well what a 24C02 is, if you’re a software geek that might as well be Chinese. As you’d expect, web searches came to the rescue on both fronts.

The bug ended up hiding in a logical flaw in the PWM-setting code inside an interrupt service routine, and it kept the fan from ever coming full on. Once found, it was easily fixed. But getting to the point where you understand the codebase deeply enough to know where to look is four-fifths of the battle. Heck, setting up the toolchain alone can take a day or two.

If you’re a fellow software type, Ruth’s talk (embedded below) will give you a quick glimpse into the outer few layers of the onion that is embedded firmware development, from a familiar viewpoint. Give her quick and value-packed talk a watch! Grizzled hardware veterans will nod along, and maybe even gain a little insight into how our code looks to “them”.

Continue reading “Supercon: Ruth Grace Wong And Firmware From The Firehose” →

Don’t Toss That Bulb, It Knows Your Password

January 29, 2019 by Tom Nardi 70 Comments

Whether it was here on Hackaday or elsewhere on the Internet, you’ve surely heard more than a few cautionary tales about the “Internet of Things” by now. As it turns out, giving every gadget you own access to your personal information and Internet connection can lead to unintended consequences. Who knew, right? But if you need yet another example of why trusting your home appliances with your secrets is potentially a bad idea, [Limited Results] is here to make sure you spend the next few hours doubting your recent tech purchases.

In a series of posts on the [Limited Results] blog, low-cost “smart” bulbs are cracked open and investigated to see what kind of knowledge they’ve managed to collect about their owners. Not only was it discovered that bulbs manufactured by Xiaomi, LIFX, and Tuya stored the WiFi SSID and encryption key in plain-text, but that recovering said information from the bulbs was actually quite simple. So next time one of those cheapo smart bulb starts flickering, you might want to take a hammer to it before tossing it in the trash can; you never know where it, and the knowledge it has of your network, might end up.

Regardless of the manufacturer of the bulb, the process to get one of these devices on your network is more or less the same. An application on your smartphone connects to the bulb and provides it with the network SSID and encryption key. The bulb then disconnects from the phone and reconnects to your home network with the new information. It’s a process that at this point we’re all probably familiar with, and there’s nothing inherently wrong with it.

The trouble comes when the bulb needs to store the connection information it was provided. Rather than obfuscating it in some way, the SSID and encryption key are simply stored in plain-text on the bulb’s WiFi module. Recovering that information is just a process of finding the correct traces on the bulb’s PCB (often there are test points which make this very easy), and dumping the chip’s contents to the computer for analysis.

It’s not uncommon for smart bulbs like these to use the ESP8266 or ESP32, and [Limited Results] found that to be the case here. With the wealth of information and software available for these very popular WiFi modules, dumping the firmware binary was no problem. Once the binary was in hand, a little snooping around with a hex editor was all it took to identify the network login information. The firmware dumps also contained information such as the unique hardware IDs used by the “cloud” platforms the bulbs connect to, and in at least one case, the root certificate and RSA private key were found.

On the plus side, being able to buy cheap smart devices that are running easily hackable modules like the ESP makes it easier for us to create custom firmware for them. Hopefully the community can come up with slightly less suspect software, but really just keeping the things from connecting to anything outside the local network would be a step in the right direction.

(Some days later…)

[Limited Results] had hinted to us that he had previously disclosed some vulnerabilities to the bulb’s maker, but that until they fixed them, he didn’t want to make them public. They’re fixed now, and it appears that the bulbs were sending everything over the network unencrypted — your data, OTA firmware upgrades, everything. They’re using TLS now, so good job [Limited Results]! If you’re running an old version of their lightbulbs, you might have a look.

On WiFi credentials, we were told: “In the case where sensitive information in the flash memory wasn’t encrypted, the new version will include encrypted storage processing, and the customer will be able to select this version of the security chips, which can effectively avoid future security problems.” Argue about what that actually means in the comments.

Under The Hood Of Leica Camera Firmware

January 29, 2019 by Lewin Day 11 Comments

There’s nothing quite like waiting for something you’ve ordered online to arrive. In [Alex]’s case, he’d ordered a new Leica camera, only to find out there was a six month backlog in shipping. Wanting to whet his thirst regardless, he decided to investigate the Leica website, and reverse engineered a whole heap of camera firmware. As you do.

[Alex] didn’t stop at just one camera, instead spreading his interest across whatever firmware Leica happened to have online at the time. This approach led to improved effectiveness, as there were similarities in the firmware used between different cameras that made it easier to understand what was going on.

There are plenty of surprise quirks – from firmwares using the Doom WAD data format, to compression methods used by iD software in old game releases. [Alex]’s work runs the gamut from plotting out GUI icons on graph paper, to building custom tools to tease apart the operation of the code. Sample components were even sourced from connector manufacturers to reverse engineer various accessories, too.

[Alex]’s methodical approach and perseverance pays off, and it’s always interesting to get a look under the hood of the software underpinning consumer devices. We’ve even seen similar work done to decode the mysteries of Pokemon cries.

[Thanks to JRD for the tip!]

Automatic Soap Dispenser Hides Arduino Board

December 25, 2018 by Tom Nardi 46 Comments

If you’ve been hanging out here at Hackaday for awhile, you’ve certainly seen projects that were based around the concept of putting a miniature computer inside the carcass of some other piece of electronics. In fact at this point it’s something of a running joke, certainly we must have seen an Arduino or Raspberry Pi shoehorned into every type of consumer gadget ever built by this point. But if you thought this would be another example of that common trope by the headline, you might be in for something of a surprise.

[zapta] didn’t put an Arduino inside this GOJO LTX-7 soap dispenser, it was already in there to begin with. That’s right, apparently we’ve hit the point that even cheap soap dispensers are now running on programmable microcontrollers. While we can’t blame those of you who are no doubt groaning and/or rolling their eyes thanks to this particular case of computational gluttony, it does mean we’re able to report with a straight face something which frankly would have passed as an April Fool’s joke in previous years: the development of an open source soap dispensing firmware.

So how does one upload a new Arduino sketch to their GOJO soap dispenser? It’s not like the thing has a USB port on the side for convenient hacking. As explained by [zapta], it involves stripping the dispenser all the way down until the electronics board is free, and then adding in a programming header to make subsequent firmware fiddling a bit easier. Writing a new firmware to the ATTiny48 powered board will require an external ISP (the Atmel AVRISP MKII was used for this hack, though any should work), but it’s otherwise pretty painless.

[zapta] has done an excellent job documenting the different components on the board, and reverse engineered enough of the critical aspects (such as the motor controller and proximity sensor) to write a new open source firmware which can be flashed to the GOJO LTX-7. Beyond allowing you to “Open Source All the Things”, using this new firmware does have some practical advantage in that you can configure how much soap is dispensed per activation. Going further, we’d be exceptionally interested in hearing about anyone who manages to come up with a firmware that enables some hitherto impossible soap dispensing trickery.

We’ve seen hacks involving dispensers of all types, from Halloween games that spit out candy to gadgets which let dogs get their own treats, but a soap dispenser hack is something truly new for us. More proof that there’s still plenty of hardware out there just waiting to be hacked!