Unbricking A $2,000 Exercise Bike With A Raspberry Pi Zero And Bluetooth Hacks

August 4, 2020 by Dan Maloney 17 Comments

Really, how did we get the point in this world where an exercise bike can be bricked? Such was the pickle that [ptx2] was in when their $2,000 bike by Flywheel Home Sports was left without the essential feature of participating in virtual rides after Peloton bought the company. The solution? Reverse engineer the bike to get it working with another online cycling simulator.

Sniffing Flywheel Bluetotooth packets with Bluetility

We have to admit we weren’t aware of the array of choices that the virtual biking markets offers. [ptx2] went with Zwift, which like most of these platforms, lets you pilot a smart bike through virtual landscapes along with the avatars of hundreds of other virtual riders. A little Bluetooth snooping with Bluetility let [ptx2] identify the bytes in the Flywheel bike’s packets encoding both the rider’s cadence and the power exerted, which Zwift would need, along with the current resistance setting of the magnetic brake.

Integration into Zwift was a matter of emulating one of the smart bikes already supported by the program. This required some hacking on the Cycling Power Service, a Bluetooth service that Zwift uses to talk to the bike. The final configuration has a Raspberry Pi Zero W between the Flywheel bike and the Zwift app, and has logged about 2,000 miles of daily use. It still needs a motor to control the resistance along the virtual hills and valleys, but that’s a job for another day.

Hats off to [ptx2] for salvaging a $2,000 bike for the price of a Pi and some quality hacking time, and for sticking it to The Man a bit. We have to say that most bike hacks we see around here have to do with making less work for the rider, not more. This project was a refreshing change.

[Featured images: Zwift, Flywheel Sports]

[via r/gadgets]

Die Photos Reveal Logic From Commodore 128 PLA Chip

July 29, 2020 by Dan Maloney 27 Comments

The 8721 PLA, or programmable logic array, was one of the chips that had to be invented to make the Commodore 128, the last of the 8-bit computers that formed the leading edge of the early PC revolution, a reality. [Johan Grip] got a hold of one of these chips and decided to reverse engineer it, to see what the C-128 designers had in mind back in mid-1980s.

PLAs were the FPGAs of the day, with arrays of AND gates and OR gates that could be connected into complex logic circuits. [Johan]’s investigation started with liberating the 8721 die from its package, for which he used the quick and easy method favored by [CuriousMarc]. The next step was tooling up, as the microscope he was using proved insufficient to the task. Even with a better microscope in hand, [Johan] still found the need to tweak it, adding one of the new high-quality Raspberry Pi cameras and motorizing the stage with some stepper motors and a CNC controller board.

With optics sorted out, he was able to identify all the pads on the die and to find the main gate array areas. Zooming in a little further, he was able to see the connections between the matrices of the AND and OR gates, which makes decoding the logic a relative snap, although the presence of what appears to be an output block with latching functions confounds this somewhat.

The end result is a full Verilog HDL file that reflects the original 8721 logic, which we think is a pretty neat trick. And we’d love it if our own [Bil Herd] could chime in on this; after all, he literally designed the C-128.

Reverse Engineering Teaches An Old Scope New Tricks

July 18, 2020 by Adil Malik 8 Comments

[PMercier] clearly loves his old Tektronix TDS3014 scope, which did however lack essentially modern connectivity such as an Ethernet port for control and a USB port for a convenient way to capture screenshots. So he decided to do some in-depth reverse engineering and design his own expansion card for it. The scope already has an expansion port and an expansion card, but given this model was first released in 1998, purchasing an OEM part was not going to be an option.

They don’t make ’em like they used to. Test equipment is today is built to last a decade — but usually lives on much longer. This is certainly true for the previous generations of kit. It’s no surprise that for most of us, hand-me-downs from universities, shrewd eBay purchasing, and even fruitful dumpster dives are a very viable way to attain useful and relevant test equipment. Now, while these acquisitions are more than adequate for the needs of a hobbyist lab, they are admittedly outdated and more to the point, inaccessible from a connectivity and communication standpoint. A modern lab has a very high degree of automated data acquisition and control over ethernet. Capturing screen dumps on a USB is a standard feature. These modern luxuries don’t exist on aging equipment conceived in the age of floppy disks and GPIB.

Continue reading “Reverse Engineering Teaches An Old Scope New Tricks” →

High-End Ham Radio Gives Up Its Firmware Secrets

July 14, 2020 by Dan Maloney 46 Comments

Amateur radio operators have always been at the top of their game when they’ve been hacking radios. A ham license gives you permission to open up a radio and modify it, or even to build a radio from scratch. True, as technology has advanced the opportunities for old school radio hacking have diminished, but that doesn’t mean that the new computerized radios aren’t vulnerable to the diligent ham’s tender ministrations.

A case in point: the Kenwood TH-D74A’s firmware has been dumped and partially decoded. A somewhat informal collaboration between [Hash (AG5OW)] and [Travis Goodspeed (KK4VCZ)], the process that started with [Hash]’s teardown of his radio, seen in the video below. The radio, a tri-band handy talkie with capabilities miles beyond even the most complex of the cheap imports and with a price tag to match, had a serial port and JTAG connector. A JTAGulator allowed him to probe some of the secrets, but a full exploration required spending $140 on a spare PCB for the radio and some deft work removing the BGA-packaged Flash ROM and dumping its image to disk.

[Travis] picked up the analysis from there. He found three programs within the image, including the radio’s firmware and a bunch of strings used in the radio’s UI, in both English and Japanese. The work is far from complete, but the foundation is there for further exploration and potential future firmware patches to give the radio a different feature set.

This is a great case study in reverse engineering, and it’s really worth a trip down the rabbit hole to learn more. If you’re looking for a more formal exploration of reverse engineering, you could do a lot worse than HackadayU’s “Reverse Engineering with Ghidra” course, which just wrapping up. Watch for the class videos soon. Continue reading “High-End Ham Radio Gives Up Its Firmware Secrets” →

Learn The Secrets Of Matching Bottle Cap Threads To One Another

July 12, 2020 by Donald Papp 25 Comments

Do you want to design something to match existing threads on a bottle, or a cap? It turns out there’s an easier way than reaching tiredly for the calipers and channeling one’s inner reverse-engineer. Bottle cap threads — whose industry term is the neck finish — aren’t arbitrary things; they are highly standardized, and [Noupoi] researched it all so that you don’t have to! The Bottle Cap Thread Calculator takes a few key measurements and spits out everything needed to model exact matches. Need some guidance on how exactly to use the information the calculator spits out? There is a handy link to a Fusion360 tutorial on creating bottle threads (YouTube video) to demonstrate.

This all came from [Noupoi] wanting to model an adapter to transfer the contents of one bottle to another, smaller bottle. By identifying which thread was used on each bottle, the job of modeling a matching adapter was much easier. It turns out that the bottle necks were an SP 28-415 (larger) and a 24-415 (smaller), and with that information the adapter was far simpler to design. If you want to check the adapter out, it’s available on Thingiverse.

If truly reverse-engineering bottle threads is needed, here’s a method we covered that involves making a simple cast and working from that.

[via Reddit]

Looking For Pi In The 8087 Math Coprocessor Chip

May 20, 2020 by Dan Maloney 14 Comments

Even with ten fingers to work with, math can be hard. Microprocessors, with the silicon equivalent of just two fingers, can have an even harder time with calculations, often taking multiple machine cycles to figure out something as simple as pi. And so 40 years ago, Intel decided to give its fledgling microprocessors a break by introducing the 8087 floating-point coprocessor.

If you’ve ever wondered what was going on inside the 8087, wonder no more. [Ken Shirriff] has decapped an 8087 to reveal its inner structure, which turns out to be closely related to its function. After a quick tour of the general layout of the die, including locating the microcode engine and ROM, and a quick review of the NMOS architecture of the four-decade-old technology, [Ken] dug into the meat of the coprocessor and the reason it could speed up certain floating-point calculations by up to 100-fold. A generous portion of the complex die is devoted to a ROM that does nothing but store constants needed for its calculation algorithms. By carefully examining the pattern of NMOS transistors in the ROM area and making some educated guesses, he was able to see the binary representation of constants such as pi and the square root of two. There’s also an extensive series of arctangent and log₂ constants, used for the CORDIC algorithm, which reduces otherwise complex transcendental calculations to a few quick and easy bitwise shifts and adds.

[Ken] has popped the hood on a lot of chips before, finding butterflies in an op-amp and reverse-engineering a Sinclair scientific calculator. But there’s something about seeing constants hard-coded in silicon that really fascinates us.

Poking Around Inside Of A Linux Security Camera

May 20, 2020 by Tom Nardi 21 Comments

This deep dive into the Linux-powered Reolink B800 IP camera started because of a broken promise from its manufacturer. When [George Hilliard] purchased a kit that included six of the cameras and a video recorder, the website said they were capable of outputting standard RTSP video. But once he took delivery of the goods, and naturally after his return window had closed, the site was updated to say that the cameras can only function with the included recorder.

Taking that as something of challenge, [George] got to work. His first big break came when he desoldered the camera’s SPI flash chip and replaced it with a socket. That allowed him to easily take the chip out of the device for reading and flashing as he tinkered with modifying the firmware. After adding cross-compiled versions of busybox, gdb, and strace to the extracted firmware, he bundled it back up and flashed it back to the hardware.

If you think that’s the end of the story, it isn’t. In fact, it’s just the beginning. While getting root-level access to the camera’s OS would have potentially allowed for [George] to dump all the proprietary software it was running and replace it with open alternatives, he decided to take a different approach.

Instead of replacing the camera’s original software, he used his newly granted root powers to analyze it and figure out how it worked. This allowed for to sniff out some very suspect “encryption” routines built into the software, and eventually write his own server side in Rust that finally allowed him to use the cameras with his own server…albeit with a bit more work than he bargained for.

Projects like these are a fantastic look at real world reverse engineering, and a reminder that sometimes achieving your ultimate goal means taking the long way around. Even if you’re not in the market for a hacked security camera, there’s no doubt that reading the thorough write-up [George] has prepared will teach you a few things. But of course, we’d expect no less from a guy who runs Linux on his business card.