Making A Classic Chip From Discretes

December 31, 2017 by Jenny List 11 Comments

A hackspace discussion of voltage regulators within our earshot touched on the famous μA723, then moved on to its competitors. Kits-of-parts for linear regulators were ten-a-penny in the 1970s, it seems. A rambling tale ensued, involving a Lambda power supply with a blown-up chip, and ended up with a Google search for the unit in question. What it turned up was a hack from 2014 that somehow Hackaday missed at the time, the replication by [Eric Schlaepfer] of an out-of-production regulator chip using surface-mount semiconductors when his Lambda PSU expired.

Lambda were one of those annoying electronics companies with a habit of applying their own part numbers to commonly available chips in an effort to preserve their spares sales. Thus the FBT-031 in this Lambda PSU was in fact a Motorola MC1466, a dirt-cheap common part in the 1970s. Unfortunately though unlike the 723 the MC1466 has long passed out of production, and is rarer than the proverbial hen’s tooth.

Happily, these chips from the early 1970s were often surprisingly simple inside. The MC1466 schematic can be found on its data sheet, and is straightforward enough to replicate with surface-mount discrete components. He thus created a PCB that replicated the original pin layout even though it overlapped the original footprint. A few parts were slightly unusual, dual transistor arrays and a matched triple diode, but the result proved to be a perfect replacement for a real MC1466. Of course a project like this is almost too simple for [Eric], who went on to build the incredible Monster 6502.

If the data sheet lacks a schematic, never fear. You can always try reverse engineering the chip directly.

34C3: Using Your Car As Video Game Controller

December 30, 2017 by Christian Trapp 6 Comments

Despite the presence of human drivers, modern cars are controlled by computers. In his talk at the Chaos Communication Congress [Guillaume Heilles] and [P1kachu] demonstrate the potential of taking control of a car’s computer. This of course leads to the natural conclusion of emulate an Xbox controller and using the car to play computer games.

His research was limited by the fact that the only cars they had access to were the daily drivers of different members of [P1kachu]’s family, which meant that all tinkering had to be strictly non-destructive. Despite this, they achieved impressive results and deliver a great introduction into reverse engineering.

[P1kachu] used a RasPi and an OBD-II adapter to access the car’s CAN bus and begins the presentation with a quick overview of the protocol. He then briefly touches on security measures that he ran into, which are optional and their implementation varies widely between manufacturers. His first attempt to access the CAN bus was successfully blocked by a challenge-response algorithm doing its work. His mother’s convertible however provided no such obstacles and gaining access allowed him to map the position of the steering wheel and pedals to a game controller, using the car to play video games.

After this, [Guillaume] steps in and walks us through the teardown of a gadget that plugs into the OBD-II port and claims to do amazing things for your car’s mileage by reprogramming the ECU. The device was not brand specific and after having seen the variations in the ways different manufacturers implement the protocol, [Guillaume] and [P1kachu] doubted that the gadget was capable of even holding the information required to modify every known implementation out there. Listening to the output of the device, along with a quick analysis of the circuit followed by decapping the single chip they found, showed that their doubt was justified. The lecture closes with an extended Q&A that adds more information on car hacking. Those that don’t have access to a car can instead tear down hot glue guns, doppler modules or antique calculators.

Continue reading “34C3: Using Your Car As Video Game Controller” →

34C3: Fitbit Sniffing And Firmware Hacking

December 29, 2017 by Brian McEvoy 19 Comments

If you walked into a gym and asked to sniff exercise equipment you would get some mighty strange looks. If you tell hackers you’ve sniffed a Fitbit, you might be asked to give a presentation. [Jiska] and [DanielAW] were not only able to sniff Bluetooth data from a run-of-the-mill Fitbit fitness tracker, they were also able to connect to the hardware with data lines using test points etched right on the board. Their Fitbit sniffing talk at 34C3 can be seen after the break. We appreciate their warning that opening a Fitbit will undoubtedly void your warranty since Fitbits don’t fare so well after the sealed case is cracked. It’s all in the name of science.

There’s some interesting background on how Fitbit generally work. For instance, the Fitbit pairs with your phone which needs to be validated with the cloud server. But once the cloud server sends back authentication credentials they will never change because they’re bound to to the device ID of the Fitbit. This process is vulnerable to replay attacks.

Data begin sent between the Fitbit and the phone can be encrypted, but there is a live mode that sends the data as plain text. The implementation seemed to be security by obscurity as a new Bluetooth handle is used for this mode. This technique prevents the need to send every encrypted packet to the server for decryption (which would be for every heartbeat packet). So far the fix for this has been the ability to disable live mode. If you have your own Fitbit to play with, sniffing live mode would be a fun place to start.

The hardware side of this hack begins by completely removing the PCB from the rubber case. The board is running an STM32 and the team wanted to get deep access by enabling GDB. Unfortunately, the debug pins were only enabled during reset and the stock firmware disables them at startup (as it should). The workaround was to rewrite the firmware so that the necessary GPIO remain active and there’s an interesting approach here. You may remember [Daniel Wegemer] from the Nexmon project that reverse engineered the Nexus 5 WiFi. He leveraged the binary patching he used on Nexmon to patch the Fitbit firmware to enable debugging support. Sneaky!

For more about 34C3 we have a cheatsheet of the first day and for more about Fitbit security, check out this WAV file.

Continue reading “34C3: Fitbit Sniffing And Firmware Hacking” →

Reverse Engineering The Nintendo Wavebird

December 14, 2017 by Tom Nardi 21 Comments

Readers who were firmly on Team Nintendo in the early 2000’s or so can tell you that there was no accessory cooler for the Nintendo GameCube than the WaveBird. Previous attempts at wireless game controllers had generally either been sketchy third-party accessories or based around IR, and in both cases the end result was that the thing barely worked. The WaveBird on the other hand was not only an official product by Nintendo, but used 2.4 GHz to communicate with the system. Some concessions had to be made with the WaveBird; it lacked rumble, was a bit heavier than the stock controllers, and required a receiver “dongle”, but on the whole the WaveBird represented the shape of things to come for game controllers.

Finding the center frequency for the WaveBird

Given the immense popularity of the WaveBird, [Sam Edwards] was somewhat surprised to find very little information on how the controller actually worked. Looking for a project he could use his HackRF on, [Sam] decided to see if he could figure out how his beloved WaveBird communicated with the GameCube. This moment of curiosity on his part spawned an awesome 8 part series of guides that show the step by step process he used to unlock the wireless protocol of this venerable controller.

Even if you’ve never seen a GameCube or its somewhat pudgy wireless controller, you’re going to want to read though the incredible amount of information [Sam] has compiled in his GitHub repository for this project.

Starting with defining what a signal is to begin with, [Sam] walks the reader though Fourier transforms, the different types of modulations, decoding packets, and making sense of error correction. In the end, [Sam] presents a final summation of the wireless protocol, as well as a simple Python tool that let’s the HackRF impersonate a WaveBird and send button presses and stick inputs to an unmodified GameCube.

This amount of work is usually reserved for those looking to create their own controllers from the ground up, so we appreciate the effort [Sam] has gone through to come up with something that can be used on stock hardware. His research could have very interesting applications in the world of “tool-assisted speedruns” or even automating mindless stat-grinding.

80’s Smartwatch Finally Plays Tetris

November 14, 2017 by Tom Nardi 19 Comments

While the current generation of smartwatches have only been on the market for a few years, companies have been trying to put a computer on your wrist since as far back as the 80s with varying degrees of success. One such company was Seiko, who in 1984 unveiled the UC-2000: a delightfully antiquated attempt at bridging the gap between wristwatch and personal computer. Featuring a 4-bit CPU, 2 KB of RAM, and 6 KB of ROM, the UC-2000 was closer to a Tamagotchi than its modern day counterparts, but at least it could run BASIC.

Ever since he saw the UC-2000 mentioned online, [Alexander] wanted to get one and try his hand at developing his own software for it. After securing one on eBay, the first challenge was getting it connected up to a modern computer. (Translated from Russian here.) [Alexander] managed to modernize the UC-2000’s novel induction based data transfer mechanism with help from a ATtiny85, which allowed him to get his own code on the watch, all that was left was figuring out how to write it.

With extremely limited published information, and no toolchain, [Alexander] did an incredible job of figuring out the assembly required to interact with the hardware. Along the way he made a number of discoveries which set his plans back, such as the fact that there is no way to directly control individual pixels on the screen; all graphics would have to be done with the built-in symbols.

The culmination of all this hard work? Playing Tetris, naturally. Though [Alexander] admits that limitations of the device’s hardware meant the game had to be simplified a bit, he’s almost certainly having more fun than any of the UC-2000’s original owners did with this device. He’s setup a GitHub repository for anyone who wishes to join him in this brave new world of vintage wrist computing.

[Alexander] isn’t the only one experimenting with fringe wearable computers. We’ve seen our fair share of interesting smartwatches, featuring everything from novel input methods to complete scratch-builds.

Continue reading “80’s Smartwatch Finally Plays Tetris” →

Reverse Engineering The Nintendo Switch Joy-Cons

November 6, 2017 by Lewin Day 26 Comments

The Switch is Nintendo’s latest effort in the console world. One of its unique features is the Joy-Cons, a pair of controllers that can either attach directly to the console’s screen or be removed and used individually. But how do they work? [dekuNukem] decided to find out.

The reverse engineering efforts begin with disassembly. Surprisingly, there is no silkscreen present on the board to highlight test points or part numbers. This is likely ~~to conflate~~ intended to stymie community efforts to work with the hardware, as different teams may create their own designations for components. Conversely, the chips inside still have their identifying markings present, which does ease identification somewhat.

There are some interesting choices made – the majority of the buttons are scanned in a matrix configuration by the on-board microcontroller, making it harder to spoof button presses. The controllers communicate over Bluetooth, switching to a physical serial connection when attached directly to the screen. This runs at a blistering 3,125,000 BPS after the initial handshake is completed.

Overall it’s a fairly comprehensive reverse engineering effort, and [dekuNukem] has provided excellent detail in the writeup for anyone else looking to get involved. There’s still some work left to do, like investigating the rumble messages, but it’s an excellent start and very comprehensive.

Perhaps you’re more interested in older Nintendo hardware? Check out this comprehensive effort to figure out NES console-to-cartridge security methods.

Reverse Engineering Guitar Hero

September 25, 2017 by Al Williams 11 Comments

What do you do when a ten-year-old video game has a bug in it? If you are [ExileLord] you fix it, even if you don’t have the source code. Want to know how? Luckily, he produced a video showing all the details of how he tracked the bug down and fixed it. You can see the video below. You may or may not care about Guitar Hero, but the exercise of reverse engineering and patching the game is a great example of the tools and logic required to reverse engineer any binary software, especially a Windows binary.

The tool of choice is IDA, an interactive debugger and disassembler. The crash thows an exception and since [ExileLord] has done some work on the game before, he was able to find a function that was creating a screen element that eventually led to the crash.

Continue reading “Reverse Engineering Guitar Hero” →