This Owner Took Control Of Their Proprietary Alarm System

When a tip comes in and the tipster feels they have to reassure us that despite appearances their subject is not facilitating crime, it certainly gets our attention. [Flam2006] has a Brinks home security system which can only be configured using a special device only available to installers, and though they managed to secure one through an eBay sale they went to the trouble of reverse engineering its protocol and writing a software emulator in Python. When an owner hacks their own security system to gain full control of something they own, that’s right up our street.

The communication is via an RS485 serial line, and follows a packetised structure with binary rather than ASCII data. There is an almost plug-and-play system for identifying devices connected to a controller, though it is restricted to those devices which the controller already knows about. There is a video of the official method of programming the controller, as well as one of the software in action. We’ve posted them below the break for your delectation.

The ability to perform these tasks on your own property is an important right that has at times been placed under threat by legislation such as the DMCA. We’ve touched upon it countless times, but probably the most high-profile example that we and the wider media have covered are those stories concerning the parts lockdown on John Deere tractors.

Continue reading “This Owner Took Control Of Their Proprietary Alarm System”

Rooting Your Ride: Jailbreaking A Subaru QNX

A modern car still drives in the same way as the one you would have bought thirty years ago, it still has a steering wheel and all the other controls. What has changed in the cabin lies mostly beneath the dash, where enough computing power to launch several Moon shots takes care of everything from air-conditioning to entertainment. As you might expect these systems attract the curiosity of security researchers, and through their work we gain an insight into their operation.

[Scott Gayou] has a Subaru, a car that has an all-in-one entertainment system head unit that is typical of what you’d find across a host of manufacturers. His account of jailbreaking it is a lengthy essay and a fascinating read for anyone. He starts with a serial port, then an SSH prompt for a root password, and a bit of searching to find it was made by Harman and that it runs the closed-source realtime OS QNX. From there he finds an official Subaru update, from which he can slowly peel away the layers and deduce the security mechanism. The write-up lays bare his techniques, for example at one point isolating the ARM assembler for a particular function and transplanting it bodily into his own code for investigation.

Eventually he could penetrate the filesystem of the update, and from there he could find that while the root user had a password there were two other accounts that while heavily locked down, had none. The discovery came that files on USB drives plugged into the system were given user-level execute permissions, at which point under the locked-down user he could execute arbitrary code from USB drives. He could then create and modify copies of the device’s filesystem which he could flash onto it, and thus place a modified password validation function into it and gain root access.

Some Hackaday readers will be accomplished in security work such as this, but many of us are hardware specialists for whom it remains something of a dark art. A comprehensive and accessible write-up such as this one is therefore invaluable, because it gives us an insight into the techniques used and perhaps more importantly, into some of the security pitfalls a hardware engineer might unwittingly introduce into their creations.

QNX is a real-time operating system with a long history of appearances in industrial and automotive applications. Readers with long memories may recall their demo floppies from the 1990s which packed a fully functional GUI, Internet connectivity, and modern (for the time) web browser onto a single 1.44Mb floppy disk. We’ve talked about it in the past in a little detail, as when someone made a desktop OS using it.

Imitating Art In Life With A Reverse-Engineered Tattoo

In general, tattoo artists are not electrical engineers. That’s fine; the world needs both professions. But when you need a circuit designed, you’re better off turning to an EE rather than a tattoo artist. And you certainly don’t want an EE doing your new ink. Disaster lies that way.

Surprisingly, [Missa]’s tattoo of a heart-shaped circuit turned out at least to be plausible design, even if it’s not clear what it’s supposed to do. So her friend [Jeremy Elson] took up the challenge to create a circuit that looked like the tattoo while actually doing something useful. He had to work around the results of tattoo artistic license, like sending traces off to the board’s edge and stranding surface-mount components without any traces. The artist had rendered an 8-pin DIP device, albeit somewhat proportionally challenged, so [Jeremy] went with an ATtiny85, threw on a couple of SMD resistors and a cap, and placed two LEDs for the necessary blinkenlights. Most of the SMDs are fed from traces on the back of the board that resurface through vias, and a small coin cell hidden on the back powers it. One LED blinks “Happy Birthday [Missa]” in Morse, while the other blinks prime numbers from 2 to 23 – we’ll assume this means it was [Missa]’s 23rd birthday.

There’s a surprising amount of crossover between the worlds of electronics and tattooing. We’ve featured functional temporary tattoo circuits, prison-expedient tattoo guns, and even a CNC tattoo machine.

Continue reading “Imitating Art In Life With A Reverse-Engineered Tattoo”

Tucoplexing: A New Charliplex For Buttons And Switches

Figuring out the maximum number of peripherals which can be sensed or controlled with a minimum number of IOs is a classic optimization trap with a lot of viable solutions. The easiest might be something like an i2c IO expander, which would give you N outputs for 4 wires (SDA, SCL, Power, Ground). IO expanders are easy to interface with and not too expensive, but that ruins the fun. This is Hackaday, not optimal-cost-saving-engineer-aday! Accordingly there are myriad schemes for using high impedance modes, the directionality of diodes, analog RCs, and more to accomplish the same thing with maximum cleverness and minimum part cost. Tucoplexing is the newest variant we’ve seen, proven out by the the prolific [Micah Elizabeth Scott] (AKA [scanlime]) and not the first thing to be named after her cat Tuco.

[Micah’s] original problem was that she had a great 4 port USB switch with a crummy one button interface. Forget replacement; the hacker’s solution was to reverse and reprogram the micro to build a new interface that was easier to relocate on the workbench. Given limited IO the Tucoplex delivers 4 individually controllable LEDs and 4 buttons by mixing together a couple different concepts in a new way.

Up top we have 4 LEDs from a standard 3 wire Charlieplex setup. Instead of the remaining 2 LEDs from the 3 wire ‘plex at the bottom we have a two button Charlieplex pair plus two bonus buttons on an RC circuit. Given the scary analog circuit the scan method is pleasingly simple. By driving the R and T lines quickly the micro can check if there is a short, indicating a pressed switch. Once that’s established it can run the same scan again, this time pausing to let the cap charge before sensing. After releasing the line if there is no charge then the cap must have been shorted, meaning that switch was pressed. Else it must be the other non-cap switch. Check out the repo for hardware and firmware sources.

Last time we talked about a similar topic a bunch of readers jumped in to tell us about their favorite ways to add more devices to limited IOs. If you have more clever solutions to this problem, leave them below! If you want to see the Twitter thread with older schematics and naming of Tucoplexing look after the break.

Continue reading “Tucoplexing: A New Charliplex For Buttons And Switches”

Reverse Engineering Keeps Keck Telescopes On Track

Perched atop a dormant volcano far above the roiling tropical air of the Big Island of Hawai’i sit two of the largest optical telescopes in the world. Each 10-meter main mirror is but a single part of a magnificent machine weighing in at some 400 tons that needs to be positioned with incredible precision. Keeping Keck 1 and Keck 2 in peak operating condition is the job of a team of engineers and scientists, so when the servo amplifiers running the twelve motors that move each scope started to show their age, [Andrew] bit the bullet and rebuilt the obsolete boards from scratch.

The Keck telescopes were built over three decades ago, and many of the parts, including the problematic servo amps, are no longer made. Accumulated wear and tear from constant use and repeated repairs had taken their toll on the boards, from overheated components to lifted solder pads. With only some barely legible schematics of the original amplifiers to go by, [Andrew] reverse engineered new amps. Some substitutions for obsolete components were needed, the PCB design was updated to support SMD parts, and higher-quality components were specified, but the end result is essentially new amplifiers that are plug-in replacements for the original units. This should keep the telescopes on track for decades to come.

Not to sound jealous, but it seems like [Andrew] has a great gig. He’s shared a couple of his Keck adventures before, like the time a failed LED blinded the telescope. He’s also had a few more down-to-earth hacks, like fixing a dodgy LCD monitor and making spooky blinkeneyes for Halloween.

Putting An Out Of Work IPod Display To Good Use

[Mike Harrison] produces so much quality content that sometimes excellent material slips through the editorial cracks. This time we noticed that one such lost gem was [Mike]’s reverse engineering of the 6th generation iPod Nano display from 2013, as caught when the also prolific [Greg Davill] used one on a recent board. Despite the march of progress in mobile device displays, small screens which are easy to connect to hobbyist style devices are still typically fairly low quality. It’s easy to find fancier displays as salvage but interfacing with them electrically can be brutal, never mind the reverse engineering required to figure out what signal goes where. Suffice to say you probably won’t find a manufacturer data sheet, and it won’t conveniently speak SPI or I2C.

After a few generations of strange form factor exploration Apple has all but abandoned the stand-alone portable media player market; witness the sole surviving member of that once mighty species, the woefully outdated iPod Touch. Luckily thanks to vibrant sales, replacement parts for the little square sixth generation Nano are still inexpensive and easily available. If only there was a convenient interface this would be a great source of comparatively very high quality displays. Enter [Mike].

Outer edge of FPGA and circuit

This particular display speaks a protocol called DSI over a low voltage differential MIPI interface, which is a common combination which is still used to drive big, rich, modern displays. The specifications are somewhat available…if you’re an employee of a company who is a member of the working group that standardizes them — there are membership discounts for companies with yearly revenue below $250 million, and dues are thousands of dollars a quarter.

Fortunately for us, after some experiments [Mike] figured out enough of the command set and signaling to generate easily reproduced schematics and references for the data packets, checksums, etc. The project page has a smattering of information, but the circuit includes some unusual provisions to adjust signal levels and other goodies so try watching the videos for a great explanation of what’s going on and why. At the time [Mike] was using an FPGA to drive the display and that’s certainly only gotten cheaper and easier, but we suspect that his suggestion about using a fast micro and clever tricks would work well too.

It turns out we made incidental mention of this display when covering [Mike]’s tiny thermal imager but it hasn’t turned up much since them. As always, thanks for the accidental tip [Greg]! We’re waiting to see the final result of your experiments with this.

Under The Hood Of Leica Camera Firmware

There’s nothing quite like waiting for something you’ve ordered online to arrive. In [Alex]’s case, he’d ordered a new Leica camera, only to find out there was a six month backlog in shipping. Wanting to whet his thirst regardless, he decided to investigate the Leica website, and reverse engineered a whole heap of camera firmware. As you do.

[Alex] didn’t stop at just one camera, instead spreading his interest across whatever firmware Leica happened to have online at the time. This approach led to improved effectiveness, as there were similarities in the firmware used between different cameras that made it easier to understand what was going on.

There are plenty of surprise quirks – from firmwares using the Doom WAD data format, to compression methods used by iD software in old game releases. [Alex]’s work runs the gamut from plotting out GUI icons on graph paper, to building custom tools to tease apart the operation of the code. Sample components were even sourced from connector manufacturers to reverse engineer various accessories, too.

[Alex]’s methodical approach and perseverance pays off, and it’s always interesting to get a look under the hood of the software underpinning consumer devices. We’ve even seen similar work done to decode the mysteries of Pokemon cries.

[Thanks to JRD for the tip!]