Reverse engineering a wireless protocol

logic

Like all good tinkerers, [Andrew] decided to figure out how his wireless security system worked. Yes, it’s an exercise in reverse engineering, and one of the best we’ve seen to date.

After breaking out the handheld spectrum analyzer and TV tuner SDR, [Andrew] cracked open a few devices and had a gander at the circuit boards. The keypad, PIR sensor, and base station all used a TI radio chip – the CC11xx series – that uses SPI to communicate with a microcontroller.

Attaching a logic analyzer directly to the radio chip and reading the bits directly, [Andrew] started getting some very good, if hard to understand data. From the security system specs, he knew it used a ’20-bit code’, but the packets he was reading off the SPI bus were 48 bits long. The part of this code was probably the system’s address, but how exactly does the system read its sensors?

The easiest way to figure this out was to toggle a few of the sensors and look at the data being transmitted. With a good bit of reasoning, [Andrew] figured out how the alarm system’s code worked. This theory was tested by connecting one of the radios up to an Arduino and having his suspicions confirmed.

While [Andrew]‘s adventure in reverse engineering is only a benefit for people with this model of security system, it’s a wonderful insight into how to tear things apart and understand them.

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]

Reverse engineering challenge starts off simple

img_20130326_102537

We love seeing hard-core firmware reverse engineering projects, but the number of hackers who can pull those off is relatively small. It’s possible to grow the ranks of the hacker elite though. A hackerspace is a great place to have a little challenge like this one. [Nicolas Oberli] put together a capture the flag game that requires the contestants to reverse engineer Teensy 3.0 firmware.

He developed this piece of hardware for the Insomni’hack 2013 event. It uses the Teensy 3.0 capacitive touch capabilities to form a nine-digit keypad with a character LCD screen for feedback. When the correct code is entered the screen will display instructions on how to retrieve the ‘flag’.

To the right you can see the disassembly of the .elf file generated by the Arduino IDE. This is what [Nicolas] gave to the contestants, which gets them past the barrier of figuring out how to dump the code from the chip itself. But it does get them thinking in assembly and eventually leads to figuring out what the secret code is for the device. This may be just enough of a shove in the right direction that one needs to get elbow deep into picking apart embedded hardware as a hobby.

[Read more...]

Extending old games with reverse engineering and MAME

HEX

For last year’s Toorcamp, the folks over at DorkbotPDX helped out with the Church of Robotron installation. A religion founded on the prophesy of a cybernetic uprising in the year 2084 is a little esoteric even for us, so the Dorkbot crew wanted a way to make playing Robotron: 2084 a little more visceral. Using MAME and a few debugging tools, they were able to read the memory of a machine playing Robotron to extend the game into the physical world. When the player dies, lights go off, alarms sound, and the prophet of the Church of Robotron is pleased.

The setup at the Church of Robotron included a machine running MAME with a Robotron ROM. When events happened in the game, such as lasers firing or a player death, physical events would be triggered. To do this, the Dorkbot team read the memory locations of a game of Robotron at different times and found memory locations tied to in-game events. On their blog they go over using the MAME debug tool to detect a player’s death which can then be translated into physical apparitions for the Church of Robotron.

It’s a very cool hack, and one we wish we had a video of. Having a plastic ghost hit a player while playing Pac-Man seems like an awesome idea, and with the Dorkbot tutorial, it looks fairly easy.

Digging deep into how the 8085 processor’s registers were designed

8085-register-reverse-engineering

Hardware design enthusiasts should already be salivating just looking at this image. But [Ken Shirriff's] write-up on how the 8085 processor’s registers were designed will put you in silicon reverse-engineering heaven. He manages to get to the bottom of the tricks the designers used to make register access as efficient as possible, like routing some through the ALU on their path elsewhere.

We’re certainly not experts in studying dies like the one seen above. Luckily [Ken] does a great job of zooming in on important parts, then dissecting how they work by representing the silicone image as a functional flow chart. One of the parts which we found most interesting is the WZ temporary registers. These are a set of internal registers that are not accessible to the programmer. They’re only used internally by the chip. They act as temporary storage for multiple operand functions, and also hold register addresses for a handful of instructions (JMP, CALL, RST, etc.).

If you’re more interested in how images of these chips are attained you should do some searching on Hackaday. Just last week we featured one such project in a links post.

[via Reddit]

Dissecting a firmware image

dissecting-a-firmware-image

[Leland Flynn] did a great job of picking apart the firmware image for a Westell 9100EM FiOS router. Unfortunately he didn’t actually find the information he was looking for. But he’s not quite done poking around yet either. If you have never tried to make sense of an embedded Linux firmware image this serves as a great beginner’s example of how it’s done.

He was turned on to the project after port scanning his external IP and finding a random login prompt which he certainly didn’t set up. Some searching led him to believe this is some kind of back door for Verizon to push automatic firmware updates to his router. He figured why not see if he could yank the credentials and poke around inside of the machine?

He started by downloading the latest firmware upgrade. Running ‘hexdump’ and ‘strings’ gives him confirmation that the image is based on Linux. He’s then able to pick apart the package, getting at just the filesystem portion. His persistence takes him through extracting and decompressing three different filesystems. Even though he now has access to all of those files, broken symlinks meant a dead-end on his login search.

Digging deeper into the Apollo Saturn V LVDC

LVDC-NAND-proto

[Fran] went all-out with her reverse engineering of the Apollo Saturn V LVDC board. Regular readers will remember that she was showing of the relic early this year when she took the board to her Dentist’s office to X-ray the circuit design. Since then she’s been hard at work trying to figure out how the thing functions using that look inside the board and components. When we say ‘hard at work’ we really mean it. Not only did she explore many different theories that resulted in dead ends, she also built her own version of the circuits to make sure they performed as she theorized. Above you can see her version of the NAND/AND gates used on the hardware.

We find her explanation of how the logic devices were originally fabricated to be very interesting. They started with a ceramic substrate and used additive processes to form the traces and add the gates. We’ve embedded her video explanation after the jump.

[Read more...]