DC27 DOOM SAO - Hurt Me Plenty

A project log for AND!XOR DC27 Badge

The trilogy is done

hyr0nHyr0n 07/18/2019 at 05:480 Comments

We’ve been lucky this year to have Cr4bf04m on our team, aka LonghornEngineer, aka Parker Dillmann. He shared our goal of the DC27 project to make the badges free during hacker summer camp. Aside from philanthropist backers and generous sponsors (Urbane Security, MacroFab, Mouser, and Rigado), a way we helped raise funds this year was though designing three Shitty Superior Add Ons (SAO). Why aren’t they shitty? Because in the same way we want our badges to be more than some blinky lights and FR4… Our SAOs are actual embedded devices with MCU’s, firmware, challenges, easter eggs, and present some useful function which hackers can explore and learn from. Cr4bf04m wanted to engineer an add on which was a hardware hacking tool...that also displayed the face of our beloved space marine while fighting demons on the I2C bus. It’s open source, leverages the SAO v1.69bis standard, and is Arduino compatible so it’s easy to add your own functionality. The design has been discussed on the Macrofab Engineering Podcast (MEP) recently and after a long couple of weeks finalizing the firmware, here’s what the team has to show for this hardware hacking tool.



The video at the top showed us going through the menu to exercise the functionality, below is an explanation of what those features entail.

DOOM Guy Interface

To claim one leverages SAO v1.69bis, means more than just providing 3V and GND... one needs to interact with the badge over I2C and GPIO. Through I2C integration, the DOOM SAO makes use of the AND!XOR SAO Reference Design and implements a menu accessible over serial UART.

Before we get in to the interface, a few technical details need to be understood. For I2C, virtual EEPROM was implemented as below based on the AT24C32 using a 7-bit address of 0x50.

The addressable space of the EEPROM then follows as:

The leads to the DOOM SAO EEPROM at 0x50 having the following:

With v1.69bis a GPIO interface was added to the standard for the badge to have additional control of the SAO. We have to use that too!

All of this combined means its fully bonafide v1.69bis compatible with badges (that choose to interact with SAOs). Such as, when it gets plugged in to a badge, special things may happen… But this also means a lot should be provided to the hacker via an easy interface. Plug in that SAO using the latest in circa 2000 19 Year Old USB Micro Technology 21st Century USB-C technology, open your favorite serial terminal application, and use the following:

So in this example (and as you saw in the video above), we modified the Health Address (4) and set the value to 5 (really almost dead). The end result is the DOOM Guy face gets super near death bloody. Enable anger at address (5) set to true (1), he’ll show those gritting angry teeth. The point of this is to let you modify the animation however you want and interact directly with the EEPROM. Given this is addressable over I2C, the host badge can control it as well ;)

DOOM Guy Bus Sniffer

Maybe some interesting things are happening to your SAO and you are curious what on earth the badge and SAO are doing? The DOOM Guy Bus Monitor specifically filters out and decodes the I2C data being sent to the SAO interface in a hoomahn readable format. Consider this your poor man’s logic analyzer, with SAO decoding. There...your Saleae doesn’t have SAO decoding, which is shocking considering the SAO is the fastest adopted embedded standard (not verified, but Benchoff said it on the internet so it must be true). Who knows what you’ll find...other badge maker’s ID’s, magic bytes, unlock codes...

I2C Bus Sniffer

Expanding on the concept of the poor man’s logic analyzer, what about exposing the entire I2C bus? Cr4bf04m ported an I2C sniffer project to the SAO. Many badges have two or more SAO interfaces, some SAO’s are even expanders. Plugging in a DOOM SAO into a badge with this configuration, would not only let you see the data between the badge and DOOM, but the badge and other SAOs, as well as the entire traffic capture. You get the entire I2C bus. Below you can see I2C bus data as well as modifying the health of the DOOM SAO (Dev=0x50), Writing Data (W.Data=) at Address (04) the value of 20: Dev=50 W.Data=04.20. Ignore Dev=64, that’s another device on the badge we tried to leave silent to minimize the I2C noise in this capture.

Serial UART Sniffer

More poor man’s analyzer! This time, for serial UART. However what makes this interesting is the approach of doing it in line via a man-in-the-middle. Hyr0n has to thank Joe Fitz for his Hardware Hacker training that gave him the idea. This allows you to passively MITM another embedded system's serial UART line. Connect the source's serial TX to the SAO RX Pin PB23. Connect the target's serial RX to the SAO TX Pin PB22. Choose the appropriate baud rate and byte translation (ASCII or DEC). In this example we will MITM the Classic DC24 Bender SAO. The original DC24 Bender Badge had a USB connector at the bottom to access the serial terminal. Our Bender SAO...has three small through hole interfaces..wonder what that is for?

This is the cleanest rats nest we could make. For reference: the BENDER (TX) -> DOOM PB23 (RX) ~ YELLOW; DOOM PB22 (TX) -> FTDI (RX) ~ YELLOW; BENDER RX -> FTDI (TX) ~ ORANGE. Essentially the TX line is getting MITM from the DOOM SAO. Here’s what happens…

As you can see, everything that goes between the source and it’s target can be passively sniffed in real time without affecting its functionality. Many embedded devices, while not efficient or common as it use to be, leverage serial UART to transfer data internal to the device (not just user interface terminals).

EEPROM Persistence

Whenever the SAO loses power it resets to its default state. However, what if you want it so DOOM Guy is always angry and bloodied? Persistence. Hyr0n ported over a project which leverages the SAMD21 internal non-volatile memory for storage. This is convenient, but it is DANGEROUS. Non-volatile storage is meant for flashing the program, not frequently writing data. It tends to wear out. Since you won't be changing your settings 10,000+ times you should be okay. But we stress that it is OFF by default, turn it on, make the changes you want, then turn it off. You don’t know how other badge makers are leveraging the SAO EEPROM and may be making thousands of writes a minute/hour/etc. Given that, you are presented with the warning below…

Custom Application Mode

Most importantly, this SAO was designed to be built upon. It is an Arduino compatible dev board, the GPIO of the SAO have been broken out for your hacking, and the firmware is even stubbed out waiting for you to add some code of your own. Need some ideas? Everything we provided as functionality is passive. What if you were more offensive? Go back to the SAO Design Reference EEPROM...there’s a finite amount of maker ID’s and values one could enumerate over in a for loop… How about the serial sniffer, it’s practically begging to be a hardware implant the size of 800 grains of rice. The GPIO on the side, could probably have some really badass twisty through hole LED blinky contraption...or a TV B Gone… We’re curious to see what folks come up with and want to share back on GitHub!

void mode_5_custom_appliaction() {
 //This section is for others to add their own code for custom functionality
 if(menu_display_5) {
    SerialUSB.println("**Custom Application**");
    SerialUSB.println("No custom code added yet. How sad.");
    SerialUSB.println("To get started visit ~");
    SerialUSB.print("Press Q to quit back to the main menu: "); 
    menu_display_5 = false; //this prevents infinite printing of the menu in loop  
  // Press (Q or q) to quit back to main menu
  incomingByte =;
  if((incomingByte == 'q') || (incomingByte == 'Q')){
    SerialUSB.print((char)incomingByte); //echo user selection to the USB terminal
    SerialUSB.println(" \n");
    sao_mode = 0;
    menu_display_0 = true;
    menu_display_5 = true;

In Closing...

We hope you have fun with this SAO. We hope you hack some badges or other embedded devices with it too. There are still some left at our shop as well if you are interested in a pre-built one and want to support the cause. We're going to take any remaining stock to Hacker Warehouse in the vendor area at DEF CON. It’s also completely open source on GitHub so you can build your own. As for the one's people have ordered, we are flashing them this weekend and will be shipping very soon. See you at hacker summer camp in a couple weeks! (Badge coming very very soon too…)