Lost Techniques: Bond-out CPUs And In Circuit Emulation

These days, we take it for granted that you can connect a cheap piece of hardware to a microcontroller and have an amazing debugging experience. Stop the program. Examine memory and registers. You can see and usually change anything. There are only a handful of ways this is done on modern CPUs, and they all vary only by detail. But this wasn’t always the case. Getting that kind of view to an actual running system was an expensive proposition.

Today, you typically have some serial interface, often JTAG, and enough hardware in the IC to communicate with a host computer to reveal and change internal state, set breakpoints, and the rest. But that wasn’t always easy. In the bad old days, transistors were large and die were small. You couldn’t afford to add little debugging pins to each processor you produced.

This led to some very interesting workarounds. Of course, you could always run simulators on a larger computer. But that might not work in real time, and almost certainly didn’t have all the external things you wanted to connect to, unless you also simulated them. Continue reading “Lost Techniques: Bond-out CPUs And In Circuit Emulation”

Building An Open Source Point Of Sale System

[Mukesh Sankhla] has been tinkering in the world of Point of Sale systems of late. His latest creation is a simple, straightforward kiosk system, and he’s open sourced the design.

The Latte Panda MU single-board computer is at the heart of the build, handling primary duties and communicating with the outside world. It’s hooked up to a touchscreen display which shows the various items available for purchase. As an x86 system, the Latte Panda runs Windows 11, along with a simple kiosk software package written in Python. The software uses Google Firebase as a database backend. There’s also an Xiao ESP32 S3 microcontroller in the mix, serving as an interface between the Latte Panda and the thermal printer which is charged with printing receipts.

It’s worth noting that this is just a point-of-sale system; it executes orders, but doesn’t directly deliver or vend anything. With that said, since it’s all open-source, there’s nothing stopping you from upgrading this project further.

We’ve featured other interesting point-of-sale systems before; particularly interesting was the San Francisco restaurant that was completely automated with no human interaction involved Continue reading “Building An Open Source Point Of Sale System”

The Hottest Spark Plugs Were Actually Radioactive

In the middle of the 20th century, the atom was all the rage. Radiation was the shiny new solution to everything while being similarly poorly understood by the general public and a great deal of those working with it.

Against this backdrop, Firestone Tire and Rubber Company decided to sprinkle some radioactive magic into spark plugs. There was some science behind the silliness, but it turns out there are a number of good reasons we’re not using nuke plugs under the hood of cars to this day.

Continue reading “The Hottest Spark Plugs Were Actually Radioactive”

An FPGA-Based Mechanical Keyboard

You can buy all kinds of keyboards these days, from basic big-brand stuff to obscure mechanical delicacies from small-time builders. Or, you can go the maker route, and build your own. That’s precisely what [Lambert Sartory] did with their Clavier build.

This build goes a bit of a different route to many other DIY keyboards out there, in that [Lambert] was keen to build it around an FPGA instead of an off-the-shelf microcontroller. To that end, the entire USB HID stack was implemented in VHDL on a Lattice ECP5 chip. It was a heavy-duty way to go, but it makes the keyboard quite unique compared to those that just rely on existing HID libraries to do the job. This onboard hardware also allowed [Lambert] to include JTAG, SPI, I2C, and UART interfaces right on the keyboard, as well as a USB hub for good measure.

As for the mechanical design, it’s a full-size 105-key ISO keyboard with one bonus key for good measure. That’s the coffee key, which either locks the attached computer when you’re going for a break, or resets the FPGA with a long press just in case it’s necessary. It’s built with Cherry MX compatible switches, has N-key rollover capability, and a mighty 1000 Hz polling rate. If you can exceed that by hand, you’re some sort of superhuman.

The great thing about building your own keyboard is you can put in whatever features you desire. If you’re whipping up your own neat interface devices, don’t hesitate to let us know!

Porting A Fortran Flight Simulator To Unity3D

There’s an old saying (paraphrasing a quote attributed to Hoare): “I don’t know what language scientists will use in the future, but I know it will be called Fortran.” The truth is, there is a ton of very sophisticated code in Fortran, and if you want to do something more modern, it is often easier to borrow it than to reinvent the wheel. When [Valgriz] picked up a textbook on aircraft simulation, he noted that it had an F-16 simulation in it. In Fortran. The challenge? Port it to Unity3D.

If you have a gamepad, you can try the result. However, the real payoff is the blog posts describing what he did. They go back to 2021, although the most recent was a few months ago, and they cover the entire process in great detail. You can also find the code on GitHub. If you are interested in flight simulation, flying, Fortran, or Unity3D, you’ll want to settle in and read all four posts. That will take some time.

Continue reading “Porting A Fortran Flight Simulator To Unity3D”

Toy Train Joins The Internet Of Things

[Zoltan] was developing a workshop on Matter for DEF CON, and wanted to whip up a fun IoT project to go with it. His idea was simple—take a simple toy train, and put it on the Internet of Things.

Speed and low cost were the goals here, with a budget of around $40 and a timeline of one week. The train set sourced for the build was a 43 piece set with a locomotive, one carriage, and a simple oval track, retailing for $25. The toy train got a new brain in the form of an ESP32-C3 DevKitM-1, with the goal of commanding the device over Wi-Fi for ease of use. The microcontroller was set up to control the train’s brushed DC motor with an IRL540 MOSFET. A USB battery bank was initially employed to power the rig, which sat neatly on the train’s solitary carriage. This was later swapped out for a CR123A battery, which did the job for the train’s short duration in service.

Code for the project was simple enough. The ESP32 simply listens for commands via Matter protocol, and turns the train on and off as instructed. [Zoltan] demos the simple interoperability of the Matter protocol by switching the train on and off with Google Home voice commands, and it works perfectly well.

Toy trains aren’t something we typically see included in smart homes, but maybe they should be. If you’re cooking up your own oddball IoT hacks, be sure to let us know on the tipsline!

Unitree Humanoid Robot Exploit Looks Like A Bad One

Unitree have a number of robotic offerings, and are one of the first manufacturers offering humanoid robotic platforms. It seems they are also the subject of UniPwn, one of the first public exploits of a vulnerability across an entire robotic product line. In this case, the vulnerability allows an attacker not only to utterly compromise a device from within the affected product lines, but infected robots can also infect others within wireless range. This is done via a remote command-injection exploit that involves a robot’s Bluetooth Low Energy (BLE) Wi-Fi configuration service.

Unitree’s flagship G1 humanoid robot platform (one of the many models affected)

While this may be the first public humanoid robot exploit we have seen (it also affects their quadruped models), the lead-up to announcing the details in a post on X is a familiar one. Researchers discover a security vulnerability and attempt responsible disclosure by privately notifying the affected party. Ideally the manufacturer responds, communicates, and fixes the vulnerability so devices are no longer vulnerable by the time details come out. That’s not always how things go. If efforts at responsible disclosure fail and action isn’t taken, a public release can help inform people of a serious issue, and point out workarounds and mitigations to a vulnerability that the manufacturer isn’t addressing.

The biggest security issues involved in this vulnerability (summed up in a total of four CVEs) include:

  • Hardcoded cryptographic keys for encrypting and decrypting BLE control packets (allowing anyone with a key to send valid packets.)
  • Trivial handshake security (consists simply of checking for the string “unitree” as the secret.)
  • Unsanitized user data that gets concatenated into shell commands and passed to system().

The complete attack sequence is a chain of events that leverages the above in order to ultimately send commands which run with root privileges.

We’ve seen a Unitree security glitch before, but it was used to provide an unofficial SDK that opened up expensive features of the Go1 “robot dog” model for free. This one is rather more serious and reportedly affects not just the humanoid models, but also newer quadrupeds such as the Go2 and B2. The whole exploit is comprehensively documented, so get a fresh cup of whatever you’re drinking before sitting down to read through it.