We're not really in favour of pre-built shiny throwaway electronic conference badges. As clever as such badges often are, they often end up in drawers or landfill and are made with rare-earth metals of often unsustainable origin. Getting attendees to build badges reduces the unnecessary use of rare-earth metal-based components as not everyone will build one.
When an attendee builds one of our badges, they’ve usually learned a whole load of new skills in the process. They’ll have learned how to solder, about the various components on the board and they have a personal stake in the badge. For many people a self-built badge is a piece of personal pride and many of the badges we’ve designed take pride of place back at the office.
In early 2017 Marizel and I started looking into the idea of a badge framework. As great as the HIDIOT is for beginners, taking 45 minutes to assemble at a conference is a lot to go through. While custom HIDIOT boards are competitive for fancier conference badges, they’re expensive for events with lower budgets.
As we’re doing more events, it’s essential we have an easily expandable framework that can be used to rapidly prototype and turnaround designs at low cost to the event. We built two badge products to test out the framework. The next step is a reference badge using the framework’s components, which we aim to have up on the Tindie store by March 2019. This reference badge showcases the different functionality available and ties into another project we hope to launch in October 2019, after a test at 44CON in September.
The BSides Lisbon badge design concept
From concept to delivery, the BSides Lisbon badge in total took around 7 months. This involved 3 prototype builds, substantially less than the 44COIN (1 year and 5 prototypes). Now the hardware platform has more or less stabilised we aim to get the prototypes down to 1 iteration with a 3 month turnaround time for a basic badge. Initially Bruno from the BSides Lisbon team reached out to me. I owed BSides Lisbon a talk after ducking out due to illness the previous year, so he knew we wouldn’t turn him down!
I started work on a few badge ideas. Using the framework under development, the badge needed to be:
- Max 15 minute build time for someone who’s never soldered before
- Cheap! (Under 5 Euro in quantity)
- Have some sort of follow-on action for people to do
I started looking into things that are iconically Portuguese, like the Barcelos Rooster, Cristiano Ronaldo and the Pastel de Nata. With the exception of the nata, these weren’t really from Lisbon, and building a PCB easily identifiable as a nata (instead of a round badge) would be very difficult. In the end, we started with a copy of the BSides Lisbon logo which included the Raven, one of the symbols of Lisbon.
The BSides Lisbon logo also gave us 3 starting points for LED placements: The two circles on the left and of course the Raven’s eye. The next point of inspiration was the Portuguese flag.
If we map the colour from the flag over the badge, we can see that the ideal setup for our LEDs would be a green LED on the left, a yellow LED in the middle and a red LED on the right.
LEDs work differently to conventional electric light sources. Their colour is usually defined by the composition, and use quirks in quantum mechanics to create light at specific wavelengths. Generally, the shorter the wavelength, the more energy is needed. This has a substantial impact on options for powering the badge.
Because our badge was fairly small, our battery needed to be small too. In this case we opted for the CR2016, the thinner variant of the popular CR2032 coin cell battery. The CR2016 has some interesting qualities that are really useful for reducing the total amount of parts. Remember, fewer parts equals lower cost and less build time at the event.
Sadly, the power output of the CR2016 also introduces some constraints on the types of LED that can be used. Our normal Red LEDs are fine, but shorter wavelengths get more difficult. We went with yellow and green LEDs from Broadcom operating at 585 and 565nm wavelengths. Quick tests proved that the LEDs would work, and we quickly assembled and tested the first prototypes from China.
To save on power we’d have the LEDs slowly fade in and out, with 2 LEDs on at any one time. This would give us a battery life of days to weeks on a single CR2016 battery depending on what else we did.
We then had to put development on hold while I worked on 44COIN. 44COIN uses the same fundamental architecture with 5 LEDs instead of 3. It’s a basic LED spinner with a random number of spins, allowing it to be used as a decision-making toy.
Same framework, different badge
If you look at the 44COIN prototype you can see we use 5 red LEDs, an ATTiny85 MCU and a single tactile switch (button) to trigger the coin’s program. 44COINs are powered up on reset, run a series of circular loops for a random amount of time and then go to sleep. This lets the 44COIN run for weeks on a single CR2016 cell battery.
I decided to add serial port functionality to the 44COIN, so it could be used to provide clues in the cryptocurrency heist Alternate Reality Game taking place at the event. Initially I managed to get a full 115200 baud serial port working off a 1mhz ATTiny85 powered from a coin cell, but as the cell’s power dropped the serial port became less stable. Consequently, I settled on a slower speed for the 44COIN. As this was transmit only, this was easy to implement.
Once I had a stable serial port and power management, I was ready to return to the BSides Lisbon badge.
Finishing up the BSides badge
One of the lessons learned from the 44COIN was the placing of the reset button. it worked well for the 44COIN, but for the Bsides badge, having the reset button at the front of the badge would mean people would use their finger. Having it at the back meant attendees would use their thumb, which is a little more comfortable for some reason.
Due to issues with customs at our end, shipping was tight but we turned up with all of the badges, and the guys in Lisbon had all of the batteries. An unexpected problem was that the CR2016 batteries used in Lisbon had a small dip in them, meaning that they didn’t make proper contact with the PCB’s battery pad. This was easily solved by dropping a little solder onto the pad. We also had issues with not routing a ground pin to the serial headers, making it slightly harder for people to connect USB to serial bridges. We managed to solve this at the time with bodge wires, but we’ve already decided that future badges should have full headers.
We ran a full continuous soldering workshop throughout the event, which was for the most part totally rammed, sometimes with queues 3-4 people deep in every direction. Even with a 15 minute build time, hundreds of people built their badges over the day and a half event.
I also did a talk on reversing approaches to microcontroller firmware. It was amazing spotting the sea of green, yellow and red lights blinking in the dark from the stage.
At this point, if you’re interested in talking to us about a custom badge for your event, I’d suggest contacting us via email. What follows is a minor dive into the software on the badge, and it involves inspecting live memory structures. We’re going to keep working on the software for the framework, and build it into something more step-by-step for attendees over the year.
Diving into the badge’s brain
After adding a serial port to the BSides Lisbon badge design, I started working on a simple challenge based on the ancient game Nim. In Nim, two players take turns to remove sticks from a pile. The person who removes the last stick loses. Because this was Lisbon, I’d gone with a nata theme.
I was uncomfortable with this, as while it meant people would learn how to use a serial port to play the game, it wasn’t really pushing them further. I wanted people to be able to turn up having never soldered, and leave having:
- Hunted for a serial port
- Connected and got it talking
- Messed around inside the microcontroller
While I’d been working on the framework I’d developed a real-time machine monitor sketch influenced by radare and various 8-bit monitors I’d used in the past that allowed me to dump various sections of the ATTiny’s RAM, program RAM and EEPROM while code was running. With some minor changes, I could tie my firmware analysis talk into the badge, and let people explore the very soul of this new machine, or at least it’s brain.
The brain behind the badge is the ATTiny85, the same as the one used in the HIDIOT. The ATTiny85 uses what’s called a modified Harvard architecture, in which executable code and data are kept (mostly) separate. There are 3 types of memory in the ATTiny85:
- 512 bytes of regular RAM (data only)
- 512 bytes of EEPROM (data only)
- 8 kilobytes of flash program memory (code and data)
I wanted people to be able to trigger their own light sequences, or otherwise change the way the badge works, which meant the machine monitor had to be integrated into the badge.
When analysing firmware for Harvard architecture devices, I typically look for memory structures that point to executable code in other areas of memory. If we can overwrite the structures with alternative values, we can make it execute other sections of executable code to achieve different results. This is called Return Oriented-Programming in exploit development parlance.
I integrated this into the badge, using a tables of pointers for the debugger menu. I also added extra functionality to call up to 16 addresses stored in the first 32 bytes of the EEPROM. This meant that people could set their own pin values, turn lights on and off, integrate their own delays - all they had to do was pull the firmware off the badge chip, disassemble it, look for the code in the monitor and store their gadget chain in the EEPROM.
We already have some initial work done on taking this further, and will release an updated version with some instructions on how to (ab)use it with our reference badge released later this year.
The hardest part of all of this is documentation. We want events to have badges that are as well documented as the HIDIOT, for people who’ve never soldered before, never connected to serial pins before, never exploited memory corruption vulnerabilities before. It’s quite a task, but one we’re looking forward to tackling.
Never miss a post
Like what you see?.
Get our latest electronics and security content in your mailbox. We won't send you spam. Unsubscribe any time.