Cracking The Sega Saturn After 20 Years

July 11, 2016 by Brian Benchoff 48 Comments

When it was released 20 years ago, the Sega Saturn was by far the most powerful video game console available. It was a revolutionary device, had incredible (for the time) graphics, and a huge library of IP Sega could draw from. The Saturn was quickly overshadowed by the Sony Playstation, and soon these devices found themselves unused, unloved, and fetching high prices on the collectors market.

After finding a Sega Saturn on a trip to Japan, [jhl] decided he would like to write some code for this machine. Unlike earlier consoles, where Flash cartridges are readily available, or later consoles, where writing directly to the on-board storage is easy, bringing up a development environment for the Saturn isn’t easy. The best method is installing a mod chip and working off of burned CDs. Instead of writing a game or two for the Saturn, [jhl] got distracted for a few years and developed an optical drive emulator.

According to [jhl], the design of the Sega Saturn is tremendously complicated. There’s an entire chip dedicated to controlling the CD drive, and after some serious reverse engineering work, [jhl] had it pretty much figured out. The question then was how to load data onto the Saturn. For that. [jhl] turned to the internal expansion port on the Saturn. This internal expansion port was designed to accept an MPEG decoder card for playing video CDs on the Saturn, but the connector presents the entire bus. By attaching a Game Boy Flash cartridge, [jhl] was able to dump the ROM on the CD controller.

With a little bit of work, a fast ARM microcontroller, and a CPLD for all the logic glue, [jhl] was built an adapter to push CD data to the Saturn through this internal expansion port. Not only is this a boon for homebrew Saturn development, but this build also completely replaces the CD drive in the Saturn – a common failure point in this 20-year-old machine.

The formal release for this ultimate Saturn crack isn’t out yet, but it’s coming shortly, allowing anyone who still has a Saturn to enjoy all those very blocky games and develop their own games. You can check out a short, amateur documentary made on [jhl]’s efforts below.

Continue reading “Cracking The Sega Saturn After 20 Years” →

Put A Reverse Engineered Power Meter In Your Toolkit

July 11, 2016 by Elliot Williams 22 Comments

It seems that one can buy cheap power meters online and, well, that’s it. They work just fine, but to use them for anything else (like datalogging or control or…) they need a bit more work. The good news is that [Thomas Scherrer], alias [OZ2CPU], just did that reverse engineering work for us.

Inside these budget power meters, you’ll find an LCD driver, a power-monitoring chip, and an STM32F030, which is a low-cost ARM Cortex M0 chip that’s fun to play with on its own. [Thomas] traced out the SPI lines that the power-monitoring chip uses to talk to the microcontroller and broke in to snoop on the signals. Once he got an understanding of all the data, tossing an ATmega88 chip on the SPI line lets him exfiltrate it over a convenient asynchronous serial interface.

If you’re going to do this hack yourself, you should note that the internals of the power meter run at line voltage — the 3.3 V that powers the microcontroller floats on top of the 230 V coming out of [Thomas]’s wall plug. He took the necessary precautions with an isolation transformer while testing the device, and didn’t get shocked. That means that to get the serial data out, you’ll need to use optoisolation (or radio!) on the serial lines.

Now that we know how this thing works on the inside, it’s open-season for power-management hacks. Toss a mains socket and an ESP8266 in a box and you’ve got a WiFi-logging power meter that you can use anywhere, all for under $20. Sweet.

Custom Firmware Unlocks Fitness Tracker

July 3, 2016 by Elliot Williams 17 Comments

[Mikhail] sent us a teaser video for a hack he’d done (embedded below). He takes a Bluetooth LE fitness tracker dongle and reflashes it spit out the raw accelerometer data and trigger events. He then wrote a phone app that receives the data and uses the device as an alarm, an on/off switch, a data-logging device, and more.

We thought it was cool enough that we asked [Mikhail] for more detail, and he delivered in spades! Inside the device is a Nordic NRF51822, their ARM Cortex + Bluetooth chip, an accelerometer, and a bunch of LEDs. [Mikhail] mapped out the programming headers, erased the old flash, and re-filled it with his own code. He even added over-the-air DFU re-flashing capability so that he wouldn’t have to open up the case again.

Continue reading “Custom Firmware Unlocks Fitness Tracker” →

Puzzling Out An 80s Puzzle Toy

June 29, 2016 by Gerrit Coetzee 15 Comments

[Ido Gendel] looks back a time in the 80s when kids would learn by answering the questions to quizzes on their “TOMY Teacher,” or, “Sears Quiz-A-Tron”. There’s a bit of a conundrum with this toy. How did it know which answers were correct. Chip memory of any kind wasn’t the kind of thing you’d sweep into the dust bin if you had extras like it is now; it was expensive.

To use the toy, the child would place the notebook in the plastic frame on the device. They’d open the page with the quiz they would like to take. Printed in the upper left hand corner were three colored squares. There was a matching set of colored buttons on the device. They’d press the corresponding buttons in order from top to bottom and then the machine would magically know which answers on the quiz were correct.

[Ido] wondered how the machine handled this information. Was there an internal table for all 27 possible codes? Did it generate the answer table somehow? He sat down with a spreadsheet filled with the notebook code on the left and the corresponding correct answers on the right. Next he stared at the numbers.

He eventually determined that there was a pattern. The machine was using the colored squares as the input for a function that determined what the answers were. A table would have only taken up 68 bytes, but with one 80s chip on board, sounds to play, and lights to switch on and off, the machine needed all the free space it could get.

Reverse Engineering The OWON SDS7102 Oscilloscope

June 29, 2016 by Jenny List 23 Comments

It is something of a rite of passage for an electronics enthusiast, the acquisition of a first oscilloscope. In decades past that usually meant a relatively modest instrument, maybe a 20MHz bandwidth and dual trace if you were lucky. Higher spec devices were eye-wateringly expensive monsters, not for the Common People.

We are fortunate that like most other areas of technology the world of test equipment has benefited in the last few years both from developments in digital technology and from the growth in Chinese manufacturing. If your first ‘scope is that second-hand 20MHz CRT you will probably secure it for pennies, and the first ‘scope you buy new will probably have a spec closer to those unattainable super-scopes of yesteryear. Gone is the CRT and timebase generator, in its place a TFT, system-on-chip, and super-fast A to D converter.

[Christer Weinigel] has just such an entry-level modern digital ‘scope, an OWON SDS7102. He comments that it’s got an impressive spec for its price, though the input is noisier than you’d expect on a more expensive device, and the software has one or two annoying bugs. Having owned it for a while, he’s now subjected it to a lengthy teardown and reverse engineer, and he’s posted his findings in a succession of blog posts.

[Christer]’s interest lay mainly in the OWON’s digital section, it seems there is already a substantial community paying attention to its analog front end. He’s deduced how its internals are connected, ported Linux to its Samsung SoC in the scope, succeeded in getting its peripherals working, and set to work programming the Xilinx FPGA that’s responsible for signal processing.

The series of posts is a fascinating read as a run through the process of reverse engineering , but he points out that it’s quite a lot of information. If you are just interested in how a cheap modern oscilloscope works, he says, he suggests reading his post in which he recaps on all its different components.

He also makes a plea for help, he’s no slouch on the ‘scope’s software but admits he’s a bit out of his depth on some aspects of the FPGA. If you’re an FPGA wizard with an interest in ‘scopes, he’d like to hear from you.

This isn’t the first time we’ve featured ‘scope reverse engineering here at Hackaday, though it may be more in-depth than others. In the past we’ve seen a Uni-T screen grab protocol laid bare, and an investigation of a Rigol 1054Z.

Reverse Engineering Quadcopter Protocols

June 28, 2016 by Brian Benchoff 21 Comments

Necessity is the mother of invention, but cheap crap from China is the mother of reverse engineering. [Michael] found a very, very cheap toy quadcopter in his local shop, and issued a challenge to himself. He would reverse engineer this quadcopter’s radio protocol. His four-post series of exploits covers finding the right frequency for the radio, figuring out the protocol, and building his own remote for this cheap toy.

[Michael] was already familiar with the capabilities of these cheap toys after reading a Hackaday post, and the 75-page, four language manual cleared a few things up for him. The ‘Quadro-Copter’ operated on 2.4GHz, but did not give any further information. [Michael] didn’t know what channel the toy was receiving on, what data rate, or what the header for the transmission was. SDR would be a good tool for figuring this out, but thanks to Travis Goodspeed, there’s a really neat trick that will put a 2.4GHz nRF24L01+ radio into promiscuous mode, allowing [Michael] to read the transmissions between the transmitter and quadcopter. This code is available on [Michael]’s github.

A needle in an electromagnetic haystack was found and [Michael] could listen in on the quadcopter commands. The next step was interpreting the ones and zeros, and with the help of a small breakout board and soldering directly to the SPI bus on the transmitter, [Michael] was able to do just that. By going through the nRF24 documentation, he was able to suss out the pairing protocol and read the stream of bytes that commanded the quadcopter.

What [Michael] was left with is a series of eight bytes sent in a continuous stream from the transmitter to the toy. These bytes contained the throttle, yaw, pitch, roll, and a ‘flip’ settings, along with three bytes of ‘counters’ that didn’t seem to do anything. With that info in hand, [Michael] took an Arduino Nano, an nRF04L01+ transceiver, and a Wii nunchuck to build his own transmitter. If you’re looking for a ‘how to reverse engineer’ guide, it generally doesn’t get better than this.

You can check out a video of [Michael] flying his Wiimoted quadcopter below.

Continue reading “Reverse Engineering Quadcopter Protocols” →

An Improved WiFi Connected E-Ink Display

June 12, 2016 by Donald Papp 22 Comments

[David] created a great looking e-ink WiFi display project that works a little like a network-connected picture frame with a few improvements over other similar projects. With the help of an ESP8266 it boots up, grabs an 800×600 image over the network, updates the screen, then goes back to sleep. Thanks to some reverse engineering, he was able to make his own firmware for the onboard controller to handle the low-level driving of the display. Since e-ink displays require no power to hold an image and the rest of the unit spends most of the time either asleep or off, power use is extremely low. [David] hopes to go months without needing to recharge the internal lithium-polymer battery.

eink_back — Lithium-polymer charger (top left); Single-cell lithium-polymer battery (center); pullups and power cutoff for nonessential electronics (green board, lower right); ESP866 (lower left).

We previously featured another WiFi-connected e-ink display project that was in fact also the inspiration for this version. [David] uses a 4.3″ 800×600 GDE043A e-ink display and wrote his own firmware for the STM32F103ZE ARM CortexM3 SoC used as a display controller, a process that required some reverse engineering but was aided by the manufacturer providing a closed-source driver for him to use. [David] writes that some reverse-engineering work for this display had already been done, but he had such a hard time getting a clear understanding from it that he reverse engineered the firmware anyway and used the documents mainly for validation and guidance.

As a result, [David] was able to make use of the low-level driver electronics already present on the board instead of having to make and interface his own. E-ink displays have some unusual driving requirements which include generating relatively high positive and negative voltages, and rapidly switching them when updating the display. Taking advantage of the board’s existing low-level driver electronics was a big benefit.

The ESP8266 rounds out the project by taking care of periodically booting things up, connecting to the wireless network and downloading an image, feeding the image data to the STM32 to update the display, then disconnecting power from all non-essential electronics and going back to sleep. We especially like how the unit automatically creates a WiFi access point to allow easy (re)configuring.

There’s one more nice touch. [David] goes the extra mile with server software (in the form of PHP scripts) to design screens for the display with data like weather forecasts, stock prices, and exchange rates. Check it out in the project’s github repository.