Supercon 2023: Reverse Engineering Commercial Coffee Machines

June 12, 2024 by Jenny List 15 Comments

There was a time when a coffee vending machine was a relatively straightforward affair, with a basic microcontroller doing not much more than the mechanical sequencer it replaced. A modern machine by contrast has 21st century computing power, with touch screens, a full-fat operating system, and a touch screen interface. At Hackaday Supercon 2023, [Kuba Tyszko] shared his adventures in the world of coffee, after reverse engineering a couple of high-end dispensing machines. Sadly he doesn’t reveal the manufacturer, but we’re sure readers will be able to fill in the gaps.

Under the hood is a PC running a Linux distro from a CF card. Surprisingly the distros in question were Slax and Lubuntu, and could quite easily be investigated. The coffee machine software was a Java app, which seems to us strangely appropriate, and it communicated to the coffee machine hardware via a serial port. It’s a tale of relatively straightforward PC reverse engineering, during which he found that the machine isn’t a coffee spy as its only communication with its mothership is an XML status report.

In a way what seems almost surprising is how relatively straightforward and ordinary this machine is. We’re used to quirky embedded platforms with everything far more locked down than this. Meanwhile if hacking vending machines is your thing, you can find a few previous stories on the topic.

Continue reading “Supercon 2023: Reverse Engineering Commercial Coffee Machines” →

Fixing Issues With Knockoff Altera USB Blasters

June 9, 2024 by Maya Posch 14 Comments

One exciting feature of hardware development involving MCUs and FPGAs is that you all too often need specific tools to program them, with [Doug Brown] suffering a price tag aneurysm after checking the cost of an official Altera/Intel USB Blaster (yours for $300) to program a MAX 10 FPGA device with. This led him naturally down the path of exploring alternatives, with the $69 Terasic version rejected for ‘being too expensive’ and opting instead for the Waveshare USB Blaster V2, at a regretful $34. The amazing feature of this USB Blaster clone is that while it works perfectly fine under Windows, it works at most intermittently under Linux.

This led [Doug] down the path of reverse-engineering and diagnosing the problem, ultimately throwing in the towel and downclocking the Altera CPLD inside the adapter after finding that it was running a smidge faster than the usual 6 MHz. This was accomplished initially by wiring in an external MCU as a crude (and inaccurate) clock source, but will be replaced with a 12 MHz oscillator later on. Exactly why the problem only exists on Linux and not on Windows will remain a mystery, with Waveshare support also being clueless.

Undeterred, [Doug] then gambled on a $9 USB Blaster clone (pictured above), which turned out to be not only completely non-functional, but also caused an instant BSOD on Windows, presumably due to the faked FTDI USB functionality tripping up the Windows FTDI driver. This got fixed by flashing custom firmware by [Vladimir Duan] to the WCH CH552G-based board after some modifications shared in a project fork. This variety of clone adapters can have a range of MCUs inside, ranging from this WCH one to STM32 and PIC MCUs, with very similar labels on the case. While cracking one open we had lying around, we found a PIC18 inside, but if you end up with a CH552G-based one, this would appear to fully fix it. Which isn’t bad for the merest fraction of the official adapter.

Thanks to [mip] for the tip.

Reverse Engineering Keeps Early Ford EVs Rolling

June 7, 2024 by Dan Maloney 5 Comments

With all the EV hype in the air, you’d be forgiven for thinking electric vehicles are something new. But of course, EVs go way, way back, to the early 19th century by some reckonings. More recently but still pretty old-school were Ford’s Think line of NEVs, or neighborhood electric vehicles. These were commercially available in the early 2000s, and something like 7,200 of the slightly souped-up golf carts made it into retirement communities and gated neighborhoods.

But as Think aficionado [Hagan Walker] relates, the Achille’s heel of these quirky EVs was its instrument cluster, which had a nasty habit of going bad and taking the whole vehicle down with it, sometimes in flames. So he undertook the effort of completely reverse engineering the original cluster, with the goal of building a plug-in replacement.

The reverse engineering effort itself is pretty interesting, and worth a watch. The microcontroller seems to be the primary point of failure on the cluster, probably getting fried by some stray transients. Luckily, the microcontroller is still available, and swapping it out is pretty easy thanks to chunky early-2000s SMD components. Programming the MCU, however, is a little tricky. [Hagan] extracted the code from a working cluster and created a hex file, making it easy to flash the new MCU. He has a bunch of other videos, too, covering everything from basic diagnostics to lithium battery swaps for the original golf cart batteries that powered the vehicle.

True, there weren’t many of these EVs made, and fewer still are on the road today. But they’re not without their charm, and keeping the ones that are still around from becoming lawn ornaments — or worse — seems like a noble effort.

Continue reading “Reverse Engineering Keeps Early Ford EVs Rolling” →

Old Dot-Matrix Displays Give Up Their Serial Secrets

June 4, 2024 by Dan Maloney 11 Comments

If there’s one thing we like better around here than old, obscure displays, it’s old, obscure displays with no documentation that need a healthy dose of reverse engineering before they can be put to use. These Plessey dot-matrix displays are a perfect example of that.

We’re not sure where [Michael] scored these displays, but they look fantastic. Each 8-pin DIP has two 5×7-matrix, high-visibility LED displays. They bear date codes from the late 80s under the part number, GPD340, but sadly, precious little data about them could be dredged up from the Interwebz. With 70 pixels and only six pins after accounting for power and ground, [Michael] figured there would be a serial protocol involved, but which pins?

He decided to brute-force the process of locating them, using a Pico to sequentially drive every combination while monitoring the current used with a current sensor. This paid off after only a few minutes, revealing that each character of the display has its own clock and data pins. The protocol is simple: pull the clock and data pins high then send 35 bits, which the display sorts out and lights the corresponding pixels. The video below shows a 12-character scrolling display in action.

Plessey made a lot of displays for military hardware, and these chunky little modules certainly have a martial air about them. Given that and the date code, these might have come from a Cold War-era bit of military hardware, like this Howitzer data display which sports another Plessey-made display.

Continue reading “Old Dot-Matrix Displays Give Up Their Serial Secrets” →

Generating A Lost Password By Traveling Back In Time

May 31, 2024 by Jenny List 5 Comments

It’s probable that some of you reading this will have been approached in the past by people who’ve lost the password to their crypto wallets. They hear that you’re involved in some kind of “hacking”, and they cling to the forlorn hope that you might just be able to recover their lost wealth. For most of us there’s little chance we can help, but in [Joe Grand]’s case he has made it something of a specialism. He’s given an account of how he and a friend recovered a particularly difficult password.

The password in question had been generated by RoboForm, a long random string that was impossible for its owner to remember. The only chance of finding it lay in discovering a flaw in RoboForm, and that seemed hopeless until the discovery of a changelog reference to improving the random number generation of the software.

The video below details some of the detective work required to find the password, first reverse engineering an old version of RoboForm to find the flaw, and then the discovery that the random seed was derived from the system time. A range of passwords could be created for a given time frame, reducing the odds of finding the password considerably. The story is not without its twists, but it ends with the wallet’s owner rather theatrically being presented with a giant fake Bitcoin check.

Continue reading “Generating A Lost Password By Traveling Back In Time” →

A picture of the camera in question, successfully uploading a pic thanks to the fix found

Fixing A Camera’s WiFi Connectivity With Ghidra

May 30, 2024 by Arya Voronova 4 Comments

If your old camera’s WiFi picture upload feature breaks, what do you do? Begrudgingly get a new one? Well, if you’re like [Ge0rg], you break out Ghidra and find the culprit. He’s been hacking on Samsung’s connected cameras for a fair bit now, and we’ve covered his adventures hacking on Samsung’s Linux-powered camera series throughout the last decade, from getting root on them for fun, to deep dives into the series. Now, it was time to try and fix a problem with one particular camera, Samsung WB850F, which had its picture upload feature break at some point.

[Ge0rg] grabbed a firmware update .zip, and got greeted by a bunch of compile-time debug data as a bonus, making the reverse-engineering journey all that more tempting. After figuring out the update file partition mapping, loading the code into Ghidra, and feeding the debug data into it to get functions to properly parse, he got to the offending segment, and eventually figured out the bug. Turned out, a particularly blunt line of code checking the HTTP server response was confused by s in https, and a simple spoof server running on a device of your choice with a replacement hosts file is enough to have the feature work again, well, paired with a service that spoofs the long-shutdown Samsung’s picture upload server.

Turned out, a bunch more cameras from Samsung had the same check misfire for them, which made this reverse-engineering journey all that more fruitful. Once again, Ghidra skills save the day.

The Long Road Towards Reverse Engineering The ESP32 Wi-Fi Driver

May 27, 2024 by Maya Posch 16 Comments

Although much of the software that runs on the ESP32 microcontroller is open source, the Wi-Fi driver is not. Instead, it uses a proprietary binary blob. This was no problem for [Jasper Devreker]’s reverse-engineering of the ESP32’s Wi-Fi stack so far until he came face to face with reverse-engineering the initialization of the Wi-Fi peripheral. As it turns out, there is a lot of work involved after you call esp_phy_enable in the Espressif binary blob, with the team logging 53,286 peripheral accesses during the initialization phase. In comparison, sending a Wi-Fi packet takes about ten calls.

Currently, the way that the initialization step is handled is by having the initialization routine in the binary blob do its thing by configuring the radio and other elements before killing the FreeRTOS task and replacing it with their own version. The team is actively looking for a clean approach for moving forward that will avoid simply writing everything from scratch. For the Wi-Fi MAC, existing code (e.g., FreeBSD’s stack) could be used, but the radio code is much more of a headache. Clearly, there’s still a lot more work to be done in order to get a fully open-source Wi-Fi MAC and stack for the ESP32, but having the community (that’s you) pitch in might speed things up if there’s demand for an open-source driver.

[Jasper’s] been working on this for a while. He’s even built a Faraday cage to make the task easier.