Reverse Engineer Your Robot Lawnmower

May 4, 2016 by Elliot Williams 21 Comments

Your home is your castle, and you are king or queen of all you survey. You’ve built your own home-automation system from scratch. Why would you possibly settle for the stock firmware in your robotic lawnmower? [Daniel Wiegert] wouldn’t either, so in Project Landlord he has started to reverse-engineer it.

You can hardly blame him. The Worx Landroid‘s controller board uses an NXP LPC1768 ARM Cortex-M3, and the debug pins are labelled on the backside. The manufacturer didn’t protect the flash memory. It’s just begging to have its firmware dumped. So far, [Daniel] has managed to both brick and unbrick the device, and has completely mapped the controller’s pinout, so he’s on his way to complete control.

Right now, he’s got a working proof-of-concept firmware on his GitHub that’s able to drive the machine around a little bit and set the brakes. It’s running FreeRTOS, and [Daniel] is looking for other people to get in on the project. He’s done the hard initial work, so get in there and reap the rewards! Just don’t neglect to remove the blade before custom firmware.

Will custom firmware in a robotic lawnmower change the world? Probably not. But it is awesome, and will certainly make a difference in the lives of people whose robot mowers continually get stuck behind the hydrangeas.

The HackadayPrize2016 is Sponsored by:

Reverse-Engineering DebugWire

April 7, 2016 by Elliot Williams 12 Comments

Has this ever happened to you? You start out on a reverse-engineering project, start digging in, and then get stumped. Then you go looking on the Internet for help, and stumble across someone who’s already done exactly what you’re trying to do?

[Geekabit] wrote us with a version of this tale of woe. In his case, the protocol to be reversed was Atmel’s debugWire protocol for debugging on low-pin-count parts. There are a number of websites claiming it’s “secret” or whatever, but it actually looks like it’s just poorly documented. Anyway, [RikusW] seems to have captured all of the signals way back in 2011. Good job!

The best part of [geekabit]’s story is that he had created the Wikipedia page on debugWire himself to inspire collaboration on reverse-engineering the protocol, and someone linked in [RiskusW]’s work. When [geekabit] picked up the problem again a bit later, he did a bit of web research and found it solved — on the page that he started.

Maybe it’s not a tale of woe after all, but a tale of unintentional collaboration. Anyway, it serves as a reminder that if you’re interested in the destination more than the voyage of discovery, it never hurts to do your research beforehand. And now we all know about the low-level details of the debugWire protocol. Anyone written up a driver yet?

Thanks [geekabit] for the tip and the story! Image from ATmega32-AVR, which explains nicely how to use the Dragon in debugWire mode.

Take The Long Road To A Precise Laser PCB Exposer

April 6, 2016 by Gerrit Coetzee 23 Comments

According to [diyouware], inside of every HD-DVD player is a gem of laser engineering with the designation of PHR-803T, and it’s just begging to be converted into a PCB exposer. Following along similar hacks which tore the laser diode out of Blu-ray players to expose PCBs, they wanted to use the whole PHR-803T unit without disassembling it, and to try to enable all of its unique features.

They envisioned something simple like a scanner for their machine. Just place the PCB on top of a glass sheet, close the lid, and click print. Unfortunately, moving the laser itself just caused too much vibration. So they switched to an inverted delta robot and named it TwinTeeth. In this design, the laser would stay still and the PCB would move.

What follows next is a seriously impressive journey in reverse engineering and design. The PHR-803T had no data sheet, but a ton of features. For example, it can autofocus, and has three different laser diodes. So many interesting problems were found and solved. For example, the halo from the laser caused the surrounding photoresist to cure. They solved it by adding a glass plate with a UV filtering film on it. Only the most focused point of the laser could punch through.

Another adventure was the autofocus. They wanted to autofocus on all four corners of the board. The PHR-803T was designed to read HD-DVDs so can focus a beam to far below 0.01 mm. They got autofocus working with the UV laser, but couldn’t use it on the PCB without curing the photoresist. So they put a piece of aluminum foil at a known level to start. Then they realized they could use the red or infrared diodes to focus instead. Now they can level the PCB in software, and focus the diode without curing the photoresist.

In the end they have an inverted-delta mini PCB factory. It can produce boards around the size of an Arduino shield with a resolution of 600 DPI. Their machine also has attachments for drilling and solder paste dispensing. Check out the video of it in action.
Continue reading “Take The Long Road To A Precise Laser PCB Exposer” →

Game Boy Camera Cartridge Reversed, Photos Dumped

March 8, 2016 by Elliot Williams 12 Comments

There’s something magical and nostalgic about extremely low resolution in this era of mega-megapixels on every cell phone. And the Game Boy’s big bulbous camera module just looks so cool. [Robson Couto] didn’t stop at simply using the camera — that’s been done before — but actually reversed the card’s protocol so that he could leave it entirely intact. As you can see from the banner image, it was a success.

A project like this doesn’t get done overnight, and [Robson] drew on a lot of his own previous work as well as the work of others. For instance, he’d already made a board that interfaces Game Boy Paks to his PC through an ATmega32 and a serial port. He’d also written software that understands the card header format on the PC side. So dumping the ROMs contents should be no problem. But of course, it was.

[Robson] could read one bank of memory, but not any of the others. It turns out that the camera pack uses a clock signal that not many other cards use. It took [Robson] some serious work — a lot of it false starts and dead ends — to get this particular part working.

If you’re into Game Boy hacking, give [Robson]’s writeup a good read. Also note that he’s got fantastic links to previous research in all of his posts. If you couldn’t care less about keeping the cartridge intact, you can simply interface the camera with a TI calculator, use the camera to transmit Morse code, or simply add a thermal printer for a low-res instant camera with style.

Hacking The Internet Of Things: Decoding LoRa

January 31, 2016 by Elliot Williams 20 Comments

Getting software-defined radio (SDR) tools into the hands of the community has been great for the development and decoding of previously-cryptic, if not encrypted, radio signals the world over. As soon as there’s a new protocol or modulation method, it’s in everyone’s sights. A lot of people have been working on LoRa, and [bertrik] at RevSpace in The Hague has done some work of his own, and put together an amazing summary of the state of the art.

LoRa is a new(ish) modulation scheme for low-power radios. It’s patented, so there’s some information about it available. But it’s also proprietary, meaning that you need a license to produce a radio that uses the encoding. In keeping with today’s buzzwords, LoRa is marketed as a wide area network for the internet of things. HopeRF makes a LoRa module that’s fairly affordable, and naturally [bertrik] has already written an Arduino library for using it.

So with a LoRa radio in hand, and a $15 RTL-SDR dongle connected to a laptop, [bertrik] got some captures, converted the FM-modulated chirps down to audio, and did a bunch of hand analysis. He confirmed that an existing plugins for sdrangelove did (mostly) what they should, and he wrote it all up, complete with a fantastic set of links.

There’s more work to be done, so if you’re interested in hacking on LoRa, or just having a look under the hood of this new modulation scheme, you’ve now got a great starting place.

“Hello Barbie” Not An IoT Nightmare After All

January 29, 2016 by Elliot Williams 25 Comments

Security researchers can be a grim crowd. Everything, when looked at closely enough, is insecure at some level, and this leads to a lot of pessimism in the industry. So it’s a bit of a shock to see a security report that’s filled with neither doom nor gloom.

We’d previously covered Somerset Recon’s initial teardown of “Hello Barbie” and were waiting with bated breath for the firmware dump and some real reverse engineering. Well, it happened and basically everything looks alright (PDF report). The Somerset folks desoldered the chip, dumped the flash ROM, and when the IDA-dust settled, Mattel used firmware that’s similar to what everyone else uses to run Amazon cloud service agents, but aimed at the “toytalk.com” network instead. In short, it uses a tested and basically sound firmware.

The web services that the creepy talking doll connected to were another story, and were full of holes that were being actively patched throughout Somerset’s investigation, but we were only really interested in the firmware anyway, and that looked OK. Not everything is horror stories in IoT security. Some stories do have a happy ending. Barbie can sleep well tonight.

Source: Flibble CC-BY-SA 3.0 https://commons.wikimedia.org/wiki/File:Acorn-ARM-Evaluation-System.jpg

Reverse Engineering The IPhone’s Ancestor

January 3, 2016 by Brian Benchoff 59 Comments

By all accounts, the ARM architecture should be a forgotten footnote in the history of computing. What began as a custom coprocessor for a computer developed for the BBC could have easily found the same fate as National Semiconductor’s NS32000 series, HP’s PA-RISC series, or Intel’s iAPX series of microprocessors. Despite these humble beginnings, the first ARM processor has found its way into nearly every cell phone on the planet, as well as tablets, set-top boxes, and routers. What made the first ARM processor special? [Ken Shirriff] potsed a bit on the ancestor to the iPhone.

The first ARM processor was inspired by a few research papers at Berkeley and Stanford on Reduced Instruction Set Computing, or RISC. Unlike the Intel 80386 that came out the same year as the ARM1, the ARM would only have a tenth of the number of transistors, used one-twentieth of the power, and only use a handful of instructions. The idea was using a smaller number of instructions would lead to a faster overall processor.

This doesn’t mean that there still isn’t interesting hardware on the first ARM processor; for that you only need to look at this ARM visualization. In terms of silicon area, the largest parts of the ARM1 are the register file and the barrel shifter, each of which have two very important functions in this CPU.

The first ARM chip makes heavy use of registers – all 25 of them, holding 32 bits each. Each bit in a single register consists of two read transistors, one write transistor, and two inverters. This memory cell is repeated 32 times vertically and 25 times horizontally.

The next-largest component of the ARM1 is the barrel shifter. This is just a device that allows binary arguments to be shifted to the left and right, or rotated any amount, up to 31 bits. This barrel shifter is constructed from a 32 by 32 grid of transistors. The gates of these transistors are connected by diagonal control lines, and by activating the right transistor, any argument can be shifted or rotated.

In modern terms, the ARM1 is a fantastically simple chip. For one reason or another, though, this chip would become the grandparent of billions of devices manufactured this year.