38C3: Lawsuits Are Temporary; Glory Is Forever

December 29, 2024 by 35 Comments

One of the blockbuster talks at last year’s Chaos Communications Congress covered how a group of hackers discovered code that allegedly bricked public trains in Poland when they went into service at a competitor’s workshop. This year, the same group is back with tales of success, lawsuits, and appearances in the Polish Parliament. You’re not going to believe this, but it’s hilarious.

The short version of the story is that [Mr. Tick], [q3k], and [Redford] became minor stars in Poland, have caused criminal investigations to begin against the train company, and even made the front page of the New York Times. Newag, the train manufacturer in question has opened several lawsuits against them. The lawsuit alleges the team is infringing on a Newag copyright — by publishing the code that locked the trains, no less! If that’s not enough, Newag goes on to claim that the white hat hackers are defaming the company.

What we found fantastically refreshing was how the three take all of this in stride, as the ridiculous but incredibly inconvenient consequences of daring to tell the truth. Along the way they’ve used their platform to speak out for open-sourcing publicly funded code, and the right to repair — not just for consumers but also for large rail companies. They are truly fighting the good fight here, and it’s inspirational to see that they’re doing so with humor and dignity.

If you missed their initial, more technical, talk last year, go check it out. And if you ever find yourself in their shoes, don’t be afraid to do the right thing. Just get a good lawyer.

Bokeh photo of red light particles in the dark

Beam Me Up: Simple Free-Space Optical Communication

December 29, 2024 by 26 Comments

Let’s think of the last time you sent data without wires. We’re not talking WiFi here, but plain optical signals. Free-space optical communication, or FSO, is an interesting and easy way to transmit signals through light beams. Forget expensive lasers or commercial-grade equipment; this video by [W1VLF] offers a simple and cheap entry point for anyone with a curiosity for DIY tech. Inspired by a video on weak signal sources for optical experiments, this project uses everyday components like a TV remote-control infrared LED and a photo diode. The goal is simply to establish optical communication across distances for under $10. Continue reading “Beam Me Up: Simple Free-Space Optical Communication” →

38C3: Xobs On Hardware Debuggers

December 29, 2024 by 3 Comments

If you just want to use a debugger for your microcontroller project, you buy some hardware device, download the relevant driver software, and fire up GDB. But if you want to make a hardware debugger yourself, you need to understand the various target chips’ debugging protocols, and then you’re deep in the weeds. But never fear, Sean [Xobs] Cross has been working on a hardware debugger and is here to share his learnings about the ARM, RISC-V, and JTAG debugging protocols with us.

He starts off with a list of everything you need the debugger hardware to be able to do: peek and poke memory, read and write to the CPU registers, and control the CPU’s execution state. With that simple list of goals, he then goes through how to do it for each of the target chip families. We especially liked [Xobs]’s treatment of the JTAG state machine, which looks pretty complicated on paper, but in the end, you only need to get it in and out of the shift-dr and shift-ir states.

Continue reading “38C3: Xobs On Hardware Debuggers” →

Wire Rope: Never Saddle A Dead Horse

December 29, 2024 by 26 Comments

If you’re into building large projects, you’ll eventually find yourself looking at wire rope. Multistrand steel wire used as antenna guy wires, bridge supports, and plenty of other uses.  The [HowNot2] team tested an old rule of thumb for wire rope. “Never saddle a dead horse”.

Click through the break for more:

Continue reading “Wire Rope: Never Saddle A Dead Horse” →

A Die-Level Look At The Pentium FDIV Bug

December 29, 2024 by 10 Comments

The early 1990s were an interesting time in the PC world, mainly because PCs were entering the zeitgeist for the first time. This was fueled in part by companies like Intel and AMD going head-to-head in the marketplace with massive ad campaigns to build brand recognition; remember “Intel Inside”?

In 1993, Intel was making some headway in that regard. The splashy launch of their new Pentium chip in 1993 was a huge event. Unfortunately an esoteric bug in the floating-point division module came to the public’s attention. [Ken Shirriff]’s excellent account of that kerfuffle goes into great detail about the discovery of the bug. The issue was discovered by [Dr. Thomas R. Nicely] as he searched for prime numbers. It’s a bit of an understatement to say this bug created a mess for Intel. The really interesting stuff is how the so-called FDIV bug, named after the floating-point division instruction affected, was actually executed in silicon.

We won’t presume to explain it better than [Professor Ken] does, but the gist is that floating-point division in the Pentium relied on a lookup table implemented in a programmable logic array on the chip. The bug was caused by five missing table entries, and [Ken] was able to find the corresponding PLA defects on a decapped Pentium. What’s more, his analysis suggests that Intel’s characterization of the bug as a transcription error is a bit misleading; the pattern of the missing entries in the lookup table is more consistent with a mathematical error in the program that generated the table.

The Pentium bug was a big deal at the time, and in some ways a master class on how not to handle a complex technical problem. To be fair, this was the first time something like this had happened on a global scale, so Intel didn’t really have a playbook to go by. [Ken]’s account of the bug and the dustup surrounding it is first-rate, and if you ever wanted to really understand how floating-point math works in silicon, this is one article you won’t want to miss.

A Review That Asks: Do You Need A Thermal Camera?

December 29, 2024 by 45 Comments

[Maker’s Fun Duck] has a recent video review of a cheap thermal camera from a company called Kaiweets, which you can see below. It checked all of his boxes: It was standalone, handheld, cheap, and not too cheap. The question is: does it work well for the kinds of things we would do with such a camera?

That’s a tricky question, of course, because everyone’s uses are different. Considering a soldering iron. A tiny one is great for working on PCBs, but lousy for soldering large coax connectors. A soldering gun works well for that purpose, but is too much for the PCB. The same goes for thermal cameras. Some are great for, for example, finding leaky parts of houses, but might not be so great at locating defective components on a PCB.

Continue reading “A Review That Asks: Do You Need A Thermal Camera?” →

The Business Card Of DOOM

December 28, 2024 by 11 Comments

This account of running DOOM on a PCB business card isn’t really about serving the “Will it DOOM?” meme of getting the classic game to run on improbable hardware. Rather, this project has more to do with getting it done right and leveraging work that’s already been done.

We’ll explain. You may recall [rsheldiii]’s previous DOOM keycap build, which was quite an accomplishment for someone who doesn’t fancy himself a hardware hacker. But he made a fair number of compromises to pull that build off, and rather than letting those mistakes propagate, he decided to build a more general platform to serve as a jumping-off point for the DOOM building community. The card is centered on the RP2040, which keeps things pretty simple. The card has a tiny LCD screen along with USB jacks for power and a keyboard, so you can actually play the game. It also has GPIO lines brought out to pads on the edge of the board, in case you want to do something other than play the game, which is shown in the brief video below.

Pretty standard stuff, right? Perhaps, but where this project stands out for us is that it stresses the importance of relying on reference circuits. We’ve all seen projects that have been derided for pulling the example circuit from the datasheet, but as [rsheldiii] points out, that seems a little wrongheaded. Component manufacturers put a lot of effort into those circuits, and they don’t do it out of the goodness of their hearts. Yes, they want to make it easier for engineers to choose their parts, but in doing so they’ve done a lot of the work for you. Capitalizing on that work wherever possible only makes sense, and in this case the results were perfect for the task at hand.

Continue reading “The Business Card Of DOOM“ →