DoomFurb

• 

  Our current, living test specimen

• 

  How you feel at the start of a hackathon

• 

  SPI Data Line. (Blue is SCK, Yellow is Slave In, and Purple is Slave Out.

• 

  The 12 MHz clock line of the SPI bus during the initial load. To prevent aliasing, we used the maximum speed we had, 24MHz to read.

• 

  SPI bus bootup script

• 

  Initial SPI Flash decoder response (Note that the chip is wrong. We're not sure if we're wrong or it is, but something is wrong!)

• 

  A single 256 bit page read

Inspiration

If you've seen Doom 1993 running on various platforms it was never intended to run on, you'd know that the game can run with some very low system requirements, and most modern embedded hardware is more than sufficient.

On the flip side, modern toys are getting smarter. Hasbro's Furby Connect, released in 2016, has a decent processor, enough space, and two 128x128 LCD screens. More importantly, some guy discovered that the Bluetooth is completely unprotected. The plan is simple: compile Doom for the processor, upload to the Bluetooth as a firmware update, and play.

What it does

Unfortunately, it's not quite that easy in practice. As of now, the Furby just laughs and farts.

The processor is 16 bits, and the NAND Flash is large enough to theoretically be able to store Doom, but we're still in the process of interfacing with the CPU. The processor itself is the GeneralPlus GPL162004A, which has it's own proprietary, wholly undocumented instruction set, u'nSP, which makes working with it a massive challenge.

The end goal is to have Doom displayed on the two 128x128 LCD eyes, and be controlled by the joystick antenna, but the first hurdle is finding a location and method to insert and run any form of executable code.

How we built it

We started by pulling down Furbhax's initial work on reverse engineering the Furby's NAND Flash and SPI Flash chips. They had recovered a hex dump of the chips in a prior hackathon but did not have the time to reverse engineer beyond that. Using this as a starting point, we identified the memory mapping of the SoC and generated a control flow graph using a disassembler and static analysis.

Using a metastable rig and a logic anaylizer, we recorded the initial call to the SPI Flash during bootup. We hypothesized that since NAND Flash can only be read in pages, the Furby had to load some smaller segments of code or variables from the SPI Flash into RAM before it could be used. Since that data had to pass through the SPI bus, theoretically, if the executable code was loaded from SPI Flash, we would be able to see it.

After recovering the beginning of the code and several write packets, we compared the 256 bit writes segments to the SPI Flash data, and found the sum of the segments matched.

Somewhere in the process of having their central nervous systems removed, our beloved Ah-Tah and Tah-Lo passed away. No victory without sacrifice.

Challenges we ran into

Almost all hardware we were working with required either proprietary programmers we didn't have (like the processor) or an undocumented component (Like the LCDs AND the processor). The processor uses a proprietary and undocumented instruction set that we will have to write a disassembler for (who uses 16 bit chars anyway?).

Due to the fact that Furbies are consumer products that were never intented to be maintained in any way, there was a severe but understandable lack of exposed test points, which narrowed our reverse engineering attack vectors.

Accomplishments that we're proud of

Identifying how the firmware is mapped to memory to gain a starting point on reverse engineering the software.

In addition, we used a logic analyser to pull addresses from the Furby bootup script and relate it to the decompiled hex dump of the SPI Flash.

Its nothing tangible, but its an accomplishment and gets us closer to understanding furbish biomechanics.

What we learned

• Significant problems faced when interfacing with hardware buses, including signal aliasing giving improper values from the SPI line.

• Without an interface to the processor, reprogramming is difficult, if not impossible.

• Furbies are super annoying. Remove their speakers before beginning work.

• Furbies turn off after 1 min of inactivity, but using solder to short the switch on the tail will cause them to fart indefinitely, keeping them on.

Quotes

• "If you stare at hex for long enough, the answer will reveal itself. You just might not understand the answer." ~Scott
• "I still don't think we know for absolutely sure what processor this actually is." ~Sam, 1:00am Sunday
• "Show me the Carmax!" - Both
• "I think I highhandedly effected the market for second-hand furbies" - Scott, after spending $250 on 8 furbies
• "Do you think we can get 60 fps on a Furby if we put a 1080ti in it?"

What's next for DoomFurb

Buying a GeneralPlus Programmer to upload firmware and interface with the CPU.

Put more effort into reverse engineering the app that serves firmware updates, as well as the internals of those "furbware updates" themselves using a wireshark and some sort of proxy.

If, by chance, Furbies can be programmed through their unsecured bluetooth chips, that opens the possibility for furbies to reprogram each other. It might be possible, sometime in the future, to model pathogen spread by create a furby "virus" that infects one furby, and then that furby will reprogram and infect other furbies nearby.

Built With

• electrical-engineering
• furby-connect
• memes
• reverse-engineering
• selfloathing
• staring-at-hex