Electric Dump Truck Tricycle Is No Toy

There are some utility bicycles on the market, some with electric motors to help carry a good bit of cargo. If you really need to haul more weight than a typical grocery-getter like this, you’ll want to look into a tricycle for higher capacity loads. Nothing you’ll find will match this monstrous electric tricycle hand-built by [AtomicZombie] out of junkyard parts, though. It’s a mule.

Since [AtomicZombie] sourced most of the underpinnings of this build from the junkyard, it’s based on an old motorcycle frame combined with the differential from a pickup truck, with a self-welded frame. He’s using an electric motor and a fleet of lead acid batteries for the build (since weight is no concern) and is using a gear reduction large enough to allow him to haul logs and dirt with ease (and dump them with the built in dump-truck bed), and even pull tree stumps from the ground, all without taxing the motor.

[AtomicZombie] documented every step of the build along the way, and it’s worth checking out. He uses it as a farm tractor on his homestead, and it is even equipped with a tow hitch to move various pieces of equipment around. Unlike a similar three-wheeled electric contraption from a while back, though, this one almost certainly isn’t street legal, but it’s still a blast!

Continue reading “Electric Dump Truck Tricycle Is No Toy”

Don’t Toss That Bulb, It Knows Your Password

Whether it was here on Hackaday or elsewhere on the Internet, you’ve surely heard more than a few cautionary tales about the “Internet of Things” by now. As it turns out, giving every gadget you own access to your personal information and Internet connection can lead to unintended consequences. Who knew, right? But if you need yet another example of why trusting your home appliances with your secrets is potentially a bad idea, [Limited Results] is here to make sure you spend the next few hours doubting your recent tech purchases.

In a series of posts on the [Limited Results] blog, low-cost “smart” bulbs are cracked open and investigated to see what kind of knowledge they’ve managed to collect about their owners. Not only was it discovered that bulbs manufactured by Xiaomi, LIFX, and Tuya stored the WiFi SSID and encryption key in plain-text, but that recovering said information from the bulbs was actually quite simple. So next time one of those cheapo smart bulb starts flickering, you might want to take a hammer to it before tossing it in the trash can; you never know where it, and the knowledge it has of your network, might end up.

Regardless of the manufacturer of the bulb, the process to get one of these devices on your network is more or less the same. An application on your smartphone connects to the bulb and provides it with the network SSID and encryption key. The bulb then disconnects from the phone and reconnects to your home network with the new information. It’s a process that at this point we’re all probably familiar with, and there’s nothing inherently wrong with it.

The trouble comes when the bulb needs to store the connection information it was provided. Rather than obfuscating it in some way, the SSID and encryption key are simply stored in plain-text on the bulb’s WiFi module. Recovering that information is just a process of finding the correct traces on the bulb’s PCB (often there are test points which make this very easy), and dumping the chip’s contents to the computer for analysis.

It’s not uncommon for smart bulbs like these to use the ESP8266 or ESP32, and [Limited Results] found that to be the case here. With the wealth of information and software available for these very popular WiFi modules, dumping the firmware binary was no problem. Once the binary was in hand, a little snooping around with a hex editor was all it took to identify the network login information. The firmware dumps also contained information such as the unique hardware IDs used by the “cloud” platforms the bulbs connect to, and in at least one case, the root certificate and RSA private key were found.

On the plus side, being able to buy cheap smart devices that are running easily hackable modules like the ESP makes it easier for us to create custom firmware for them. Hopefully the community can come up with slightly less suspect software, but really just keeping the things from connecting to anything outside the local network would be a step in the right direction.

(Some days later…)

[Limited Results] had hinted to us that he had previously disclosed some vulnerabilities to the bulb’s maker, but that until they fixed them, he didn’t want to make them public. They’re fixed now, and it appears that the bulbs were sending everything over the network unencrypted — your data, OTA firmware upgrades, everything.  They’re using TLS now, so good job [Limited Results]! If you’re running an old version of their lightbulbs, you might have a look.

On WiFi credentials, we were told: “In the case where sensitive information in the flash memory wasn’t encrypted, the new version will include encrypted storage processing, and the customer will be able to select this version of the security chips, which can effectively avoid future security problems.” Argue about what that actually means in the comments.

Core Memory Upgrade For Arduino

Linux programs, when they misbehave, produce core dumps. The reason they have that name is that magnetic core memory was the primary storage for computers back in the old days and many of us still refer to a computer’s main memory as “core.” If you ever wanted to have a computer with real core memory you can get a board that plugs into an Arduino and provides it with a 32-bit core storage. Of course, the Arduino can’t directly run programs out of the memory and as designer [Jussi Kilpeläinen] mentions, it is “hilariously impractical.” The board has been around a little while, but a recent video shined a spotlight on this retro design.

Impractical or not, there’s something charming about having real magnetic core memory on a modern CPU. The core plane isn’t as dense as the old commercial offerings that could fit 32 kilobits (not bytes) into only a cubic foot. We’ll leave the math about how much your 8-gigabyte laptop would have to grow to use core memory to you.

Continue reading “Core Memory Upgrade For Arduino”

32C3: Dieselgate — Inside The VW’s ECU

[Daniel Lange] and [Felix Domke] gave a great talk about the Volkswagen emissions scandal at this year’s Chaos Communication Congress (32C3). [Lange] previously worked as Chief architect of process chain electronics for BMW, so he certainly knows the car industry, and [Domke] did a superb job reverse-engineering his own VW car. Combining these two in one talk definitely helps clear some of the smog around the VW affair.

[Lange]’s portion of the talk basically concerns the competitive and regulatory environments that could have influenced the decisions behind the folks at VW who made the wrong choices. [Lange] demonstrates how “cheating” Europe’s lax testing regime is fairly widespread, mostly because the tests don’t mimic real driving conditions. But we’re not sure who’s to blame here. If the tests better reflected reality, gaming the tests would be the same as improving emissions in the real world.

As interesting as the politics is, we’re here for the technical details, and the reverse-engineering portion of the talk begins around 40 minutes in but you’ll definitely want to hear [Lange]’s summary of the engine control unit (ECU) starting around the 38 minute mark.

[Domke] starts off with a recurring theme in our lives, and the 32C3 talks: when you want to reverse-engineer some hardware, you don’t just pull the ECU out of your own car — you go buy another one for cheap online! [Domke] then plugged the ECU up to a 12V power supply on his bench, hooked it up, presumably to JTAG, and found a bug in the firmware that enabled him to dump the entire 2MB of flash ROM into a disassembler. Respect! His discussion of how the ECU works is a must. (Did you know that the ECU reports a constant 780 RPM on the tacho when the engine’s idling, regardless of the actual engine speed? [Domke] has proof in the reverse-engineered code!)

The ECU basically takes in data from all of the car’s sensors, and based on a number of fixed data parameters that physically model the engine, decides on outputs for all of the car’s controls. Different car manufacturers don’t have to re-write the ECU code, but simply change the engine model. So [Domke] took off digging through the engine model’s data.

Long story short, the driving parameters that trigger an emissions reduction exactly match those that result from the EU’s standardized driving schedule that they use during testing — they’re gaming the emissions tests something fierce. You’ve really got to watch the presentation, though. It’s great, and we just scratched the surface.

And if you’re interested in our other coverage of the Congress, we have quite a collection going already.

Tamagotchi ROM Dump And Reverse Engineering

tamagotchi-rom-dump-and-reverse engineering

Often the true key to success is persistence and that holds true for this project which dumped the ROM from the current generation of Tamagotchi toys. If you’re a fan of learning the secrets built into consumer electronics — and you know we are — you’ll want to go back and watch the 24-minute lecture on Tamagotchi hacking which [Natalie Silvanovich] gave a 29C3 last year. She had made quite a bit of headway hacking the playable pods, but wasn’t able to get her hands on a full ROM dump from the General Plus chip on board processor. This update heralds her success and shares the details of how it was done.

As we learned form the video lecture it was a huge chore just to figure out what processor this uses. It turned out to be a 6502 core with a few other things built in. After prowling the manufacturer’s website she found example code for writing to Port A. She was then able to execute her own code which was designed to dump one byte of ROM at a time using the SPI protocol.

[Natalie] posted her code dump if you’re interested in digging through it. But as usual we think the journey is the most interesting part.

[Thanks Itay]

A Better Way To Hack IClass RFID Readers

iClass is an RFID standard that is aimed at better security through encryption and authentication. While it is more secure than some other RFID implementations, it is still possible to hack the system. But initial iClass exploits were quite invasive. [Brad Antoniewicz] published a post which talks about early attacks on the system, and then demonstrates a better way to exploit iClass readers.

We remember seeing the talk on iClass from 27C3 about a year and a half ago. While the technique was interesting, it was incredibly invasive. An attacker needed multiple iClass readers at his disposal as the method involved overwriting part of the firmware in order to get a partial dump, then patching those image pieces back together. [Brad] makes the point that this is fine with an off-the-shelf system, but high-security installations will be using custom images. This means you would need to get multiple readers off the wall of the building you’re trying to sneak into.

But his method is different. He managed to get a dump of the EEPROM from a reader using an FTDI cable and external power source. If you wan to see how he’s circumventing the PIC read protection you’ll have to dig into the source code linked in his article.

2708 EPROM Dumper

[Andrea “Mancausoft” Milazzo] has been restoring old equipment which often contain EPROM chips. He thought he was all set with an EPROM reader which easily dumped the data from 2716 chips and a few others. But he found that the hardware was unable to read 2708 and 2704 chips. His solution was to build a PIC-based EPROM dumper.

You may remember from some of our recent features that these chips are something of a ticking clock. They store program code and other information vital to the functioning of old hardware. Since they’re erased with UV light, years of exposure to ambient light can zap some of the data.

The specs needed to read a chip of this type are rather rudimentary. There are ten address pins and eight data pins. [Andrea] also needed a way to get data from the microcontroller to a computer for backup. He uses two more pins for this purpose, bringing the I/O count to 20. He went with  PIC 18F4610 and built the rest of the reader around it.