The end of the year is often a time for people to exchange presents and — of course — the rich want to buy each other the best presents. The Neiman Marcus company was famous for having a catalog of gift ideas. Many were what you’d consider normal gifts, but there were usually extreme ones, like a tank trunk filled with 100,000 gallons of cologne. One year, the strange gift was an authentic Chinese junk complete with sails and teak decks. They apparently sold three at $11,500 (in 1962 money, no less). Over the top? In 1969, they featured a kitchen computer.
Wait a minute! In 1969, computers were the purview of big companies, universities, and NASA, right? Well, not really. By that time, some industrial minicomputers were not millions of dollars but were still many thousands of dollars. The price in the catalog for the kitchen computer was $10,600. That’s about $86,000 in today’s money. The actual machine was a Honeywell 316, based on one of the computers that helped run the early Internet.
Aspiring polyglots can be stymied by differing keyboard layouts and character sets when switching between languages. [Thomas Pollak]’s Poly Keyboard circumvents this problem by putting a screen in every key of the keyboard.
In his extensive build logs, [Pollak] details the different challenges he’s faced while bringing this amazing keyboard to life. For example, the OLED screens need glyph rendering to handle the legends on the keys. Since the goal is true universal language support, he used the Adafruit-GFX Library as a beginning and was able to extend support to Japanese, Korean, and Arabic so far in his custom fork of QMK.
The attention to detail on this build is really impressive. Beside the dedication to full glyph support, [Pollak] has measured the amount of extra force the flex cables from the OLEDs add to the actuation of the keyswitches. For the Gateron yellow switch he tested, the difference was about 62.2 g versus the initial 49.7 g.
In case you’re thinking you’ve seen other screen keyboard projects, [Pollak] includes a roundup of similar projects in his logs as well. This isn’t the first keyboard we’ve seen here at Hackaday with an OLED on top of a keyswitch, although [Voidstar Lab]’s MiRage only has three screen keys that were removed in a later iteration. If you’d like a more conventional fixed display in your keyboard, check out [Peng Zhihui]’s modular board with an e-ink display and haptic feedback knob.
In a perfect world, all of our electronic devices would come with complete documentation, and there’d be open source libraries available for interfacing them with whatever we wanted. There’d never be arbitrary lockouts preventing us from using a piece of hardware in a way the manufacturer didn’t approve of, and the “cloud” wouldn’t be a black-box server in some data center on the other side of the planet, but a transparent and flexible infrastructure for securely storing and sharing information.
Unfortunately, that’s not the world we live in. What’s worse, rather than moving towards that electronic utopia, the industry appears to be heading in the opposite direction. It seems like every month we hear about another service shutting down and leaving viable hardware to twist in the wind. Just yesterday Google announced they’d be retiring their Stadia game streaming service early next year — leaving users with unique Internet-connected controllers that will no longer have a back-end to communicate with.
Matthew Alt
Luckily for us, there’s folks like Matthew [wrongbaud] Alt out there. This prolific hacker specializes in reverse engineering, and has a knack not just for figuring out how things work, but in communicating those findings with others. His conquests have graced these pages many times, and we were fortunate enough to have him helm the Introduction to Reverse Engineering with Ghidra class for HackadayU back in 2020. This week, he stopped by the Hack Chat to talk about the past, present, and future of reverse engineering.
Matthew got his start in reverse engineering during college, when he was working in a shop that specialized in tuning engine control units (ECUs). He was responsible for figuring out how the ECUs functioned, which ultimately would allow them to be modified to improve engine performance beyond the vehicle’s stock configuration. Sometimes that involved uploading modified calibration data, or disabling functions that were detrimental to engine performance. These software changes could potentially increase engine output by as much as 50 HP, though he says that sometimes the goal was to simply increase throttle response so the vehicle would feel more aggressive on the road.
Moving on to the tools of the trade, Matthew explained why he prefers using Ghidra for embedded targets over classic reverse engineering tools like IDA Pro. As an example he points to a recent project where he used Ghidra’s API and intermediary language PCode to crack passwords in Game Boy Advance games. Though he does mention that IDA still has its place if you’re looking to peek into some Windows C++ software.
Matthew also pointed to new techniques and tools for working with fault injection which have opened up a lot of exciting possibilities over the last few years. In fact, he says tools like ChipWhisperer will become invaluable as newer devices adopt advanced security features. When gadgets are using secure boot and encrypted firmware, gaining access is going to take a bit more than just finding an unleaded serial port on the board. Glitching attacks will become more commonplace, so you might as well get up to speed now.
Colin O’Flynn’s ChipWhisperer makes side-channel power analysis and glitching attacks far more accessible.
We’d like to thank Matthew Alt for not just stopping by the Hack Chat, but for being such a good friend to the Hackaday community. His work has been inspirational for all of us here, and it’s always exciting when he’s penned a new blog post detailing another challenge bested. The next time your favorite MegaCorp releases some anti-consumer gadget, you can take some comfort in knowing he’s still out there bending hardware to his will.
The Hack Chat is a weekly online chat session hosted by leading experts from all corners of the hardware hacking universe. It’s a great way for hackers connect in a fun and informal way, but if you can’t make it live, these overview posts as well as the transcripts posted to Hackaday.io make sure you don’t miss out.
Attentive readers will recall that we’ve featured [Matthew Alt]’s reverse engineering exploits before, like the time he got root on a Linux-based arcade cabinet. For something a bit more challenging, he chose a Trezor One crypto wallet this time. We briefly covered a high-stakes hack (third item) on one of these wallets by [Joe Grand] a while back, but [Matthew] offers much, much more detail.
After introducing the theory of glitching attacks, which seek to force a processor into an undefined state using various methods, [Matthew] discusses the specifics of the Trezor wallet and how the attack was planned.
His target — the internal voltage regulator of the wallet’s STM32 microcontroller — required desoldering a few caps before the attack could begin, which was performed with a ChipWhisperer. After resolving a few initial timing issues, he was able to glitch the chip into dropping to the lowest level of readout protection, which gave access to the dongle’s SRAM through an ST-Link debugger.
While this summary may make the whole thing sound trivial, it’s obvious that the attack was anything but, nor was the effort that went into writing it all up. The whole thing reads a little like a techno-thriller, and there’s plenty of detail there if you’re looking for a tutorial on chip glitching. We’re looking forward to part 2, which will concentrate on electromagnetic fault-injection using a PicoEMP and what looks like a modified 3D printer.
Very few retrocomputing projects are anything other than a labor of love. There’s really no practical reason to build a computer that is woefully inadequate for just about any task compared to even an entry-level PC today. But the lack of a practical reason to do something rarely stops a hacker, as with this nifty modular Z80-based rack computer.
Actually, there’s at least one area where retrocomputers excel compared to their modern multi-core gigahertz counterparts — and that’s nostalgia. That’s what [Ricardo Kaltchuk] was going for with his build, which started by finding a Z80 and an Intel 8251 USART in his parts bin. Those formed the core of what would become the “Proton” computer, a modular beauty built around 7 cm by 10 cm PCBs that plug into a backplane inside a rack made from aluminum angle. Aside from the power supply and the Z80 CPU, other modules include a RAM card with a zero insertion force socket for an EPROM, a mass-storage module sporting a 128 MB Compact Flash card, plus modules for standard serial and I2C comms.
The fit and finish are excellent, and the performance is impressive. The Proton runs CP/M and boasts a ton of old applications that will bring back some memories, like SuperCalc and dBase. We’d venture a bet that WordStar is in there someplace, or easily could be. The video below is a little rough, but shows everything off really well.
In some ways, the Proton reminds us of the RC2014, but its fit and finish are what bring this build home. That’s not to take away from the work [Ricardo] obviously put into documentation, though. The 62-page manual has every detail of every module, plus instructions for building one of your own.
It is no secret that I have a few things permanently burned into my neurons: the 1802 instruction set, the commands for WordStar, and the commands for emacs. There was a time when emacs was almost my operating system. With no X11, emacs gave you a way to have a shell in one window, check your mail, and keep your work open.
I still use emacs a lot (although I’ve been getting more and more pleased with vscode with an emacs keybinding extension). But I also spend a lot of time — like right now — writing in a Web browser. Especially if I’m writing about code, it gets hard to remember which set of keys you have to use and I’ve wanted to do something about it for a long time. The answer is a very cool program called Autokey. (You can download my files for it, but you probably want to read more first.) It probably doesn’t work if you have switched to Wayland, but it can do a lot for you ranging from saving you some typing to reprogramming your favorite program to have different keystrokes. However, it isn’t without its problems, and I’ll tell you what I know about it.
The Value Proposition
Autokey sits in your system tray and it watches what you type. In its most simple usage, you can set up different phrases to substitute what you type.
For example, I might reprogram HaD to show up as Hackaday to save myself some typing. I usually use some odd character at the start or end so I don’t accidentally trigger things. So maybe I’m tired of typing or mistyping http://www.hackaday.com. I could set up ~had to automatically type the correct URL for me.
An Analogue to Digital Converter (ADC) is at its core a straight-forward device: by measuring an analog voltage within a set range and converting the measured level to a digital value we can use this measurement value in our code. Through the use of embedded ADCs in microcontrollers we can address many essential use cases, ranging from measuring the setting on a potentiometer, to reading an analog output line on sensors, including the MCU’s internal temperature and voltage sensors.
The ADCs found in STM32 MCUs have a resolution between 12 to 16 bits, with the former being the most common type. An ADC can be configured to reduce this resolution, set a specific sampling speed, and set up a multi-mode configuration depending on the exact ADC peripheral. STM32 MCUs feature at least a single ADC peripheral, while some have multiple. In this article we will take a look at how to configure and use the basic features of the ADCs in STM32 MCUs, specifically the ADCs found in F0 and the ADC5_V1_1 type as found in most F3-family MCUs.
