IoT Air Purifier Makes A Great Case Study In Reverse Engineering

February 6, 2024 by 10 Comments

Here at Hackaday, about the only thing we like more than writing up tales of reverse engineering heroics is writing up tales of reverse engineering heroics that succeed in jailbreaking expensive widgets from their needless IoT dependency. It’s got a real “stick it to the man” vibe that’s hard to resist.

The thing is, we rarely see a reverse engineering write-up as thorough as the one [James Warner] did while integrating an IoT air purifier into Home Assistant, so we just had to make sure we called this one out. Buckle up; it’s a long, detailed post that really gets down into the weeds, but not unnecessarily so. [James] doesn’t cloud-shame the appliance manufacturer, so we can’t be sure who built this, but it’s someone who thought it’d be a swell idea to make the thing completely dependent on their servers for remote control via smartphone. The reverse engineering effort started with a quick look at the phone app, but when that didn’t pay off in any useful way, [James] started snooping on what the device was talking about using Wireshark.

One thing led to another, wires were soldered to the serial pins on the ESP32 on the purifier’s main board, and with the help of a FlipperZero as a UART bridge, the firmware was soon in hand. This gave [James] clues about the filesystem, which led to a whole Ghidra side quest into learning how to flash the firmware. [James] then dug into the meat of the problem: figuring out the packet structure used to talk to the server, and getting the private key used to encrypt the packets. This allowed a classic man-in-the-middle attack to figure out the contents of each packet and eventually, an MQTT bridge to let Home Assistant control the purifier.

If it sounds like we glossed over a lot, we know — this article is like a master class on reverse engineering. [James] pulled a lot of tools out of his kit for this, and the write-up is clear and concise. You may not have the same mystery fan to work with, but this would be a great place to start reverse engineering just about anything.

Thanks to [ThoriumBR] for the tip.

Retrotechtacular: The Master Hands Of The Early Automotive Industry

February 6, 2024 by 15 Comments

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

February 6, 2024 by 4 Comments

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” →

It Wasn’t DOOM That Killed The Amiga

February 6, 2024 by 111 Comments

If you were the type of person who might have read Hackaday had we been around in the late 1980s or early 1990s, it’s a reasonable guess that you would have had a 16-bit home computer on your desk, and furthermore that it might have been a Commodore Amiga. These machines gave the best bang for the buck in those days with their impressive multimedia capabilities, and they gained a fervent following which persists to this day. [Carl Svensson] was one of them, and he’s penned a retrospective on the demise of the platform with the benefit of much hindsight.

The heyday of the Amiga from its 1985 launch until the days of the A1200 in the early-to-mid 1990s saw Moore’s Law show perhaps its fastest effects for the consumer. In that decade the PC world jumped from the 8088 to the Pentium, and from a PC speaker and CGA if you were lucky, to a Sound Blaster 16 and accelerated SVGA. By comparison the Amiga didn’t change much except in model numbers and a few extra graphics modes, and when a faster processor came it was far to little too late.

Defender of the Crown, released in 1986

There’s a well-worn path with some justification of blaming Commodore-s notoriously awful management for the debacle, but the piece goes beyond that into the mid ’90s. His conclusion is that what really killed the Amiga was that the CPU price reductions which defined the x86 world at that time never came to 68k or PowerPC lines, and that along with the architecture zealotry of the fan base meant that there would never be the much-longed-for revival.

He also takes a look at the other home computer platforms of the era, including the “all its killer architecture managed to kill was, sadly, Atari itself” Atari Falcon, and the Acorn Archimedes, which also lives on for enthusiasts and is perhaps the most accessible survivor. From here having also the benefit of hindsight we can’t disagree with him on his assessment, so perhaps it’s best to look at the Amiga not as the platform we should rightfully still be using, but the great stepping stone which provided us a useful computer back in t he day without breaking the bank.

They Want To Put A Telescope In A Crater On The Moon

February 6, 2024 by 30 Comments

When we first developed telescopes, we started using them on the ground. Humanity was yet to master powered flight, you see, to say nothing of going beyond into space. As technology developed, we realized that putting a telescope up on a satellite might be useful, since it would get rid of all that horrible distortion from that pesky old atmosphere. We also developed radio telescopes, when we realized there were electromagnetic signals beyond visible light that were of great interest to us.

Now, NASA’s dreaming even bigger. What if it could build a big radio telescope up on the Moon?

Continue reading “They Want To Put A Telescope In A Crater On The Moon” →

Atopile Wants You To Code Schematics

February 6, 2024 by 58 Comments

We’d wager that, if you’re reading Hackaday, you’ve looked at more than a few circuit diagrams in your day. Maybe you’ve even converted a few of them over to a PCB. It’s a workflow that, at this point, is well-understood. But as designs become more complex, the schematics are harder to create and maintain. That’s why Atopile wants to treat hardware design more like writing code.

We can see some real benefits to this but also some possible drawbacks. On the plus side, reusing chunks of PCB description should be easy. On the other hand, detecting certain errors on a schematic or PCB layout is easier than spotting them in code. Of course, there are probably types of errors that are easier to catch in code, too, so maybe that’s not a problem. Certainly, if you can spit out a schematic from your code, you could — potentially — have the best of both worlds.

Continue reading “Atopile Wants You To Code Schematics” →

Sailing (Directly) Into The Wind

February 6, 2024 by 22 Comments

Humans have been sailing various seas and oceans for thousands of years, and using boats for potentially even longer than that. But as a species we wouldn’t have made it very far if it was only possible to sail in the same direction the wind is blowing. There are a number of methods for sailing upwind, but generally only up to a certain angle. [rctestflight] wondered if there was some way of sailing straight upwind instead and built this rotary sail craft to test the idea.

Normally a boat sailing upwind will sail approximately 45° into it, then “tack” 90° across the wind until they’re at another 45° angle from the wind, this time facing the opposite direction. This back-and-forth nature is not the most efficient path, so this vessel uses a few propellers to bypass the traditional sail. The first iteration, built on a sleek catamaran hull, uses a large propeller to catch the wind’s energy, then transfers it mechanically through a set of shafts to an underwater prop.

It took a few tries to get the size and pitch of both propellers narrowed down to where the boat would move forward into the wind, but move it does. A second major iteration of the build uses a single shaft with no gears, with the trade-off that neither propeller is facing an ideal direction, but this has the added benefit of the boat naturally pointing itself upwind.

While none of the designs are speed demons, the concept is sound enough. It’s just that, in most cases, performing multiple tacks to get upwind is acceptable compared to the extreme efficiency losses and drag from propeller-driven sailing crafts like these. A more effective way of propelling a boat upwind, at least using modern technology, might be to trade sails for solar panels.

Continue reading “Sailing (Directly) Into The Wind” →