The AND!XOR team have somehow managed to outdo themselves once again this year. Their newest unofficial hardware badge for DEF CON 26 just arrived. It’s a delightful creation in hardware, software, and the interactive challenges built into both.
They call this the “Wild West of IoT”, a name that draws from the aesthetic as well as the badge-to-badge communications features. Built on the ESP32-WROVER module which brings both WiFi and Bluetooth to the party, the badges are designed to form a wireless botnet at the conference. Anyone with a badge can work to advance their level and take more and more control of the botnet as they do.
Check out the video overview and then join me below for a deeper dive into all this badge has to offer.
I’ve been following the development of this badge for many months. The team launched a Kickstarter which successfully raised $47,000 to build the badges, almost four times that of the previous year. I’m happy to see that those backers are now getting the badges in the mail with two weeks to spare before the con.
When looking at the design online it seemed huge, but with one in hand it’s actually a very reasonable size. The board is much narrower than last year’s badge — check out my review of that one — and moves down from three AA batteries to just two so it’s also much lighter. The solder mask is white with black silks screen that uses hatching for additional detail. Where the 2017 Bender used matte black finish, this one is glossy and it looks great. The gold plated copper accents are eye-catching in a good way. I think the use of the gold is a real improvement over last year’s design where it was not quite as obvious.
Bender’s Guts
The electronic components used this design are very interesting. The badge’s Hackaday.io project page doesn’t yet have a Bill of Materials, so I had to do some guessing. There is a tiny accelerometer whose part number I simply cannot read but I think I’ve figured out the rest.
The main processors is an ESP32-WROVER module. Modules are becoming the defacto standard for small-run wireless devices since they’ve previously passed FCC so your product won’t need to. Under that shielding is a 32-bit dual-core process that takes care of both WiFi and BLE while the antenna is build intot the black part of the module protruding beyond the can. GPIO handling for this module is made a lot easier by two of the other chip choices the team made.
A GreenPAK NVM handles the buttons. It’s a programmable device whose operation is akin to an FPGA or CPLD. It has been tasked with debouncing the buttons. When a debounced button press is detected, it throws an interrupt to a pin monitored by the ESP32 and makes the state information available via i2c. Another cool choice is the IS31FL3736 LED driver by ISSI that services the 31 RGB LEDs and the single red LED that is the eye of Bender. This chip scans a 12×8 matrix, and communicates with the processor via i2c as well. Rounding out the peripheral chips is a Silicon Labs CP2102N which provides the USB connectivity to the badge.
Log In, Walk South
I stayed up waaaay too late at last year’s DC trying to get root and solve some of the puzzles on the Bender on a Bender badge. This year’s puzzles seem even better. The badge has an “unlocks” screen that acts a scoreboard for the things you’ve discovered on the badge. The most likely avenue is through the serial port. Where last year there was a Bluetooth terminal, this year it’s USB which I think is more user friendly, plus it powers the badge rather than burning the batteries.
In the video I play around with the terminal for a few seconds so check that out. In addition to the commands you’d expect in a *nix shell, there is support for a text-based adventure game (think Zork). Playing this in a terminal window on my computer and seeing the ASCII art come up has a really interesting effect on me. Having this all running from a custom electronics badge (and not telnet over the Internet) has a nostalgic feel of the days of dial-up BBS games.
The botnet is something I didn’t explore much in previous years. The basics of it involve the badges forming a mesh network and providing mechanisms for you to take over other badges. I know that some people reverse engineered the protocols and wrote code to command badges in ways not originally intended by the design. We’d love to hear any stories you have of the botnets of years past so please leave a comment below!
It’s an Amazing Time for Custom Hardware
Now is the part of the review where I psychoanalyze the badge makers. It’s hilarious that you can trace an arc of the badge art from the innocent, unadulterated Bender of DC24, to the Hunter S. Thompson art of Bender on a Bender, and now this year he’s looking worse for wear as Wild West of IoT. I know from reading the project logs that this is West World inspired, but I can’t help but compare this to the evolution of AND!XOR as a group of people.
The time and creativity poured into the last three years is epic. With the first badge they didn’t know the full extent of what they were getting into. Now, the traps along the way are expected, but they still push themselves to take on new and interesting challenges, and to churn out a huge number of badges. I sure hope they choose to keep this up, because what we’re seeing from AND!XOR is a spectacle of the custom hardware universe that comes along far too rarely.
ESP32 so I give it fifteen minutes before they have automatic wifi deauthing installed. There are other badges using it as well so with so many stations transmitting the wifi spectrum will be even more chaos than usual.
Surely bender should be 6502 powered.
If you want a 6502-powered badge, you have to go for Lee Hart’s 40th anniversary 6502 badge from VCFMW
Heh, actually yes. I have long forgotten the episode+scene it was, but there was an episode where for some reason there was a very brief x-ray view of bender and for a fleeting moment you could see a chip with 6502 on it in his head.
ARP or DNS MITM and dos attacks and maybe distributed keyspace brute attacks. Maybe a rootkit with click-fraud
They probably don’t have strong kernel and isolation policies
A dedicated IC just for debouncing? Is that a thing now?
The Greenpak is apparently some sort of analogue, or part-analogue FPGA. Mixed-signals. It’s OTP and I’m not sure if you can program it at home or if it needs doing in the factory. It mentions you can, for testing, just program it’s bitstream RAM directly, rather than setting the OTP ROM, while you’re debugging, but then does that mean you need to keep power supplied as you remove it from the programmer to your circuit, or what?
Looks kind of interesting.
I can see why you’d want to debounce the keys if they’re triggering an interrupt on the main CPU. But why not just read them through GPIOs instead, by polling? That’s what pretty much everyone else does for buttons. The ESP doesn’t look short of pins for the stuff that’s attached. Were they sponsored by the chip makers or something to use seemingly superfluous parts?
Howdy! Zapp here.
Primary purpose is to debounce buttons and provide an interrupt to the ESP32. Each year we’ve tried different methods of debouncing resulting in the same thing to our code: an 8-bit mask of current button state. DC24 we did a software debounce, DC25 we did an RC debouce with some SW, and this year Greenpak. This was more of an exercise of what can we try that’s different. There other hidden things inside but primary purpose is buttons.
Regarding GPIO, we have none left. Like 0. Technically IO0 is available but that’s shared with SDIO and the UART programming interface, dual purposing it for buttons causes issues. So the Greenpak serves as a GPIO extender while using the same I2C pins as the accelerometer.
One of the neat things about the Greenpaks is that the entire memory space, all 256 bytes of it, is accesible over I2C. Most of it is writeable too. In fact this is exactly how you test during development. The IDE writes 256 bytes over the memory space and the Greenpak changes its functions. Before we went the factory programmed route, our plan was to write the 256 bytes to Greenpak RAM on every start, but that turned out to be unnecessary except our interrupt pin logic was incorrect from the factory burned images and we overwrite a single byte during boot to correct it and all is well.
Yes we were sponsored. But that came after it was incorported into our design. I emailed them asking for how I could buy pre-programmed chips in less quantity than they typically sold them and they hooked us up with 700.
Maybe it’s also doing something else, but they don’t wanna give that away yet.