Hackaday Podcast Episode 256: 0, 256, 400, 0x100, And 10000000

For this week’s episode, we did something super special — we all convened to answer your burning questions about your hosts, both as hackers and as humans. We kick things off with a segment featuring a hearty round-table discussion between Elliot, Al, Dan, Kristina, and Tom. What’s on our benches? What do we type on? Go find out!

None of us figured out What’s That Sound though a few of us had some creative guesses. Can you guess the sound? There could be a t-shirt in it for ya.

Kristina and Elliot went on to have a normal podcast too, but since the round table section went so long, we’ll process up that section and put it out early next week.

Check out the links below if you want to follow along, and as always, tell us what you think about this episode in the comments!

Download this epic monument of podcasting and savor it for the next 256 weeks.

This Week In Security: Broken Shims, LassPass, And Toothbrushes?

Linux has a shim problem. Which naturally leads to a reasonable question: What’s a shim, and why do we need it? The answer: Making Linux work wit Secure Boot, and an unintended quirk of the GPLv3.

Secure Boot is the verification scheme in modern machines that guarantees that only a trusted OS can boot. When Secure Boot was first introduced, many Linux fans suggested it was little more than an attempt to keep Linux distros off of consumer’s machines. That fear seems to have been unwarranted, as Microsoft has dutifully kept the Linux Shim signed, so we can all run Linux distros on our Secure Boot machines.

So the shim. It’s essentially a first-stage bootloader, that can boot a signed GRUB2 or other target. You might ask, why can’t we just ask Microsoft to sign GRUB2 directly? And that’s where the GPLv3 comes in. That license has an “anti-tivoization” section, which specifies “Installation Information” as part of what must be provided as part of GPLv3 compliance. And Microsoft’s legal team understands that requirement to apply to even this signing process. And it would totally defeat the point of Secure Boot to release the keys, so no GPLv3 code gets signed. Instead, we get the shim.

Now that we understand the shim, let’s cover how it’s broken. The most serious vulnerability is a buffer overflow in the HTTP file transfer code. The buffer is allocated based on the size in the HTTP header, but a malicious HTTP server can set that value incorrectly, and the shim code would happily write the real HTTP contents past the end of that buffer, leading to arbitrary code execution. You might ask, why in the world does the shim have HTTP code in it at all? The simple answer is to support UEFI HTTP Boot, a replacement for PXE boot.

The good news is that this vulnerability can only be triggered when using HTTP boot, and only by connecting to a malicious server or via a man-in-the-middle attack. With this in mind, it’s odd that this vulnerability is rated a 9.8. Specifically, it seems incorrect that this bug is rated low complexity, or a general network attack vector. In Red Hat’s own write-up of the vulnerability, they argue that the exploitation is high complexity, and is only possible from an adjacent network. There were a handful of lesser vulnerabilities found, and these were all fixed with shim 15.8. Continue reading “This Week In Security: Broken Shims, LassPass, And Toothbrushes?”

The End Of Landlines?

Imagine if, somehow, telephones of all kinds had not been invented. Then, this morning, someone entered a big corporation board room and said, “We’d like to string copper wire to every home and business in the country. We’ll get easements and put the wires on poles mostly. But some of them will go underground where we will dig tunnels. Oh, and we will do it in other countries, too, and connect them with giant undersea cables!” We imagine that executive would be looking for a job by lunchtime. Yet, we built that exact system and with far less tech than we have today. But cell phones have replaced the need for copper wire to go everywhere, and now AT&T is petitioning California to let them off the hook — no pun intended — for servicing landlines.

The use of cell phones has dramatically decreased the demand for the POTS or plain old telephone service. Even if you have wired service now, it is more likely fiber optic or, at least, an IP-based network connection that can handle VOIP.

Continue reading “The End Of Landlines?”

FLOSS Weekly Episode 769: OpenCost — We Spent How Much?

This week Jonathan Bennett and Katherine Druckman talk with Matt Ray about OpenCost. What exactly is Cloud Native? Why do we need a project just for tracking expenses? Doesn’t the cloud make everything cheaper? Is there a use case for the hobbyist?

The cloud is just a fancy way to talk about someone else’s servers — and what may surprise you is that they charge you money for the privilege of using those computers. But how much? And when you have multiple projects, which ones cost how much? That’s where OpenCost comes in. Not only does it help you track down costs in your cloud usage, it can also catch problems like compromised infrastructure sooner. Mining bitcoin in your Kubernetes Cluster makes a really noticeable spike in processor usage after all.
Continue reading “FLOSS Weekly Episode 769: OpenCost — We Spent How Much?”

Friendly Flexible Circuits: The Cables

Flexible cables and flex PCBs are wonderful. You could choose to carefully make a cable bundle out of ten wires and try to squish them to have a thin footprint – or you could put an FFC connector onto your board and save yourself a world of trouble. If you want to have a lot of components within a cramped non-flat area, you could carefully design a multitude of stuff FR4 boards and connect them together – or you could make an FPC.

Flexible cables in particular can be pretty wonderful for all sorts of moving parts. They transfer power and data to the scanner head in your flat-bed scanner, for instance.  But they’re in fixed parts too.  If you have a laptop or a widescreen TV, chances are, there’s an flexible cable connecting the motherboard with one or multiple daughterboards – or even a custom-made flexible PCB. Remember all the cool keypad and phones we used to have, the ones that would have the keyboard fold out or slide out, or even folding Nokia phones that had two screens and did cool things with those? All thanks to flexible circuits! Let’s learn a little more about what we’re working with here.

FFC and FPC, how are these two different? FFC (Flexible Flat Cable) is a pre-made cable. You’ve typically seen them as white plastic cables with blue pieces on both ends, they’re found in a large number of devices that you could disassemble, and many things use them, like the Raspberry Pi Camera. They are pretty simple to produce – all in all, they’re just flat straight conductors packaged nicely into a very thin cable, and that’s why you can buy them pre-made in tons of different pin pitches and sizes. If you need one board to interface with another board, putting an FFC connector on your board is a pretty good idea.

Continue reading “Friendly Flexible Circuits: The Cables”

Retrotechtacular: The Master Hands Of The Early Automotive Industry

When motion pictures came along as a major medium in the 1920s or so, it didn’t take long for corporations to recognize their power and start producing promotional pieces. A lot of them are of the “march of progress” genre, featuring swarms of workers happy in their labors and creating the future with their bare hands. If we’re being honest, a lot of it is hard to watch, but “Master Hands,” which shows the creation of cars in the 1930s, is somehow more palatable, mostly because it’s mercifully free of the flowery narration that usually accompanies such flicks.

“Master Hands” was produced in 1936 and focuses on the incredibly labor-intensive process of turning out cars, which appear to be the Chevrolet Master Deluxe, likely the 1937 model year thanks to its independent front suspension. The film is set at General Motors’ Flint Assembly plant in Flint, Michigan, and shows the entire manufacturing process from start to finish. And by start, we mean start; the film begins with the meticulous work of master toolmakers creating the dies and molds needed for forging and casting every part of the car. The mold makers and foundrymen come next, lighting their massive furnaces and packing the countless sand molds needed for casting parts. Gigantic presses stamp out everything from wheels to frame rails to body panels, before everything comes together at the end of the line in a delicate ballet of steel and men.

Continue reading “Retrotechtacular: The Master Hands Of The Early Automotive Industry”

Human-Interfacing Devices: Packing For The Descriptor Heist

We started with figuring out HID descriptors a week ago, and I’ve shown you how to send raw HID packets using a MicroPython fork. We do still have the task in front of us – making a touchscreen device. For that, let’s give you the tools to capture an existing descriptor from a touchscreen, then show you how to tweak it and how it turns out in the end.

Packing For The Heist

When it comes to this kind of adventure, we can’t go without tools and weapons – it could be dangerous! Without them, you could even abandon your project halfway! Here’s enough high-precision tools and ammunition to last you through whatever obstacles you might encounter. Except for the web-based tools, these tools are for Linux, but please remember that you can always use a virtual machine or a Raspberry Pi. Nobody would use Windows for a heist anyway, what’s with all the telemetry and such.

The first tool is for reading descriptors – we need one to learn from, it’s just like a keycard you can flash to a security guard and scan at the vault entry. Of course, with RFID, you want to have enough examples, compare bits between a few cards and all. For now, HID descriptors don’t have authenticity checks, but it looks like that might just change in the future. Leave it to Apple and Microsoft to add them, as usual. On Linux, seeing descriptors is simple – as root, go into /sys/bus/usb/devices/, find your device by its lsusb device tree path, then follow the directory with the VID/PID in it. That directory will contain a report_descriptor file – hexdump it. The entire command could look like this:

sudo hexdump -v -e '/1 "%02X "' /sys/bus/usb/devices/3-6.2/3-6.2\:1.1/0003\:0C40\:8000.0022/report_descriptor

Again, you might need root to even find this path, so use sudo -i if you must. The format string in the hexdump command gives you parser-friendly output. Specifically, for parsing, I use this webpage – it’s wonderful, even adding tabs that delineate different sections of the descriptor, making its output all that more readable! You can also save this webpage locally, it’s a very neat tool. Other than that, you can try other local tools like this one!

Continue reading “Human-Interfacing Devices: Packing For The Descriptor Heist”