RII was thrilled to sponsor the inaugural RE//verse Conference—a premier reverse engineering, vulnerability research, and malware analysis event. As part of this sponsorship, we had a large table in the vendor room to showcase RII and engage with attendees. Our engineers have been to many great conferences over the years and have preferred when sponsors host engaging activities or challenges—instead of just tables lined with swag.

In that vein, we designed a customizable LED badge, provided in conjunction with a two-pronged competition for the “best” light show and a reverse engineering (RE) challenge. This blog post explains how we created the concept, executed the engineering, and the results from running the event—all from the perspective of a first-time badge designer. Although many fantastic people contributed to the effort, I’ve written this post in first person to reflect my experiences as a software engineer as I pursued this pet project, and RII gave me the avenue and resources to bring this vision to life. There are certainly more talented electrical engineers here who can design and explain complex printed circuit boards (PCB) more professionally than I can.

If you are interested in seeing what we provided to the participants for the event, please visit the associated Github repo.

Concept

After attending multiple events, I noticed there were many visually interesting badges; however, they were all configurations of LEDs, a battery, and little to no other functionality. As a computer science graduate who has trended closer toward hardware-oriented projects throughout my career, I wondered how hard it would be to add a tiny microcontroller to make the LEDs programmable. Additionally, the recent availability of full-color PCB silkscreens provided a cool visual design opportunity.

With our sponsorship of the inaugural RE//verse event coming up, this was a great chance to make my first attempt at badge design and provide an interactive activity that would be small enough to be a digestible side quest during a two-day conference. The primary goal was to successfully make a badge with programmable LEDs. The stretch goal was making an RE challenge. I decided to start by designing the PCB—all the way from a breadboard prototype to a first-draft, full-color PCB.

Design

Our design phase had three discrete steps: selecting electrical components and breadboarding, designing the PCB outline and silkscreen, and laying out the circuitry.

Component selection

The most consequential component in this project is the microcontroller. Some internet searches about the simplest microcontrollers had multiple PIC variants from Microchip. I had some limited prior experience with PIC devices from an unrelated side project. There were some recommended common variations (e.g., PIC18F452, PIC16F877A), but even those were technical overkill. To programmatically control the badge LEDs, we just needed enough general-purpose input/out (GPIO) pins—not peripherals like Universal Synchronous Receiver/Transmitter (UART), Serial Peripheral Interface (SPI), or Inter-Integrated Circuit (I2C) protocols. Filtering through Microchip’s offerings, I selected a candidate: the PIC16F54.

Power requirements for the PIC16F54 are low, requiring 2.0–6.5V. I also wanted the badge to work with a simple coin battery like many other badges, and the common CR2032 is 3V. I wanted the simplest option to avoid worrying about additional resistors to reduce voltage to the LEDs. I picked white, green, and blue LEDs because they can tolerate 3V, whereas red, orange, and yellow LEDs operate at lower voltages and 3V would burn them out.

A surprising (to me) characteristic of the PIC16F54 is that it has no internal clocks. After some frustrating errors and more thorough datasheet diving, I realized that even the simplest, lowest-precision oscillator was still an external concept and required additional circuitry. A resistor-capacitor (RC) oscillator, as the name indicates, constantly charges and discharges a capacitor to alternate a line high and low. Some Googling uncovered this forum with some recommended ohm and farad ranges. I repurposed a 10k ohm resistor and 200pF capacitor from a donor board I had laying around, and it worked well enough—for me at least.

With components chosen and scattered on my desk, I was ready to make a breadboard prototype. (In reality, the breadboarding and power supply were an iterative part of this whole process, which is how I found and fixed the RC oscillator problem). With a simple program to alternate the GPIO pins high and low, I was able to visually test the design. Once the circuit worked, the only addition needed was an on/off slide switch and a battery, leaving me ready to translate the breadboard prototype circuit to a PCB layout.

PCB Layout

The first consideration in designing this PCB layout was defining a board outline. Knowing I wanted a full-color silkscreen and looking at popular manufacturers, I selected JLCPCB to print the PCB. They allow a 100mm x 100mm PCB size before price starts increasing due to size, so I didn’t want to exceed that threshold. I had an initial concept of our company mascot, Caticus, with a ring of LEDs around him. I also wanted to provide a huge shout out to our visual designer and editor, who took that loose description, created the board outline, arranged the LEDs, and designed the cover graphic. With the outline footprint, graphic, and LED placement, I was ready to move onto component layout and circuitry design.

Circuitry

There’s really not much to describe about the circuitry because it’s so simple, and I’m also not an electrical engineer. I just had to lay out my breadboard prototype, add the slide switch and battery, and draw lines between everything without crossing (or at least use different vias and planes to connect them). I ended up using a four-layer PCB. I almost certainly could have gotten away with a two-layer design and some more experi{mentation,ence}. For convenience, I dedicated one plane to be the ground plane and needed two additional planes to cross traces on top of each other. The fourth plane is unused.

I started designing in KiCad as I recognized the name, and it seemed like the de facto standard for open-source PCB design—and it worked great! Although I encountered one hiccup once I completed the design and tried to order it from JLCPCB using exported Gerber files. As it turns out, JLCPCB needs you to use their EasyEDA software to generate Gerber files (especially when trying to print full-color silkscreens). Translating from one application to the other was fairly simple, but I did have to address some minor issues (reconnecting some components and the nets they were on). Additionally, it turns out that even though EasyEDA allows you to select blind vias, once you submit your order, they review it, and tell you they actually don’t support blind vias. 🤷. Once resolved, I submitted a minimum order of 5 boards to do a test run and waited the 1–2 weeks for production!

After the first PCB batch arrived, visual inspection looked great. Even with warnings from JLCPCB that some lines on the full-color silkscreen were too narrow, it printed fine. Once the components arrived, I fired up the soldering iron, assembled it all, flashed the software, and it all worked on the first try! However, the resistor and capacitor I chose, even though their description said “hand solder”, were still crazy small and took time to get right. In fact, they were small enough that when building two different badges, the difference in the amount of solder used on each board was changing the resistance and capacitance of the circuit, affecting clock speed. This wouldn’t be good as everyone’s software would run at different speeds, causing some light patterns to be too fast or slow. Assembly time would also increase just to solder these tiny components. I noted these as changes to make when I was ready for a full production run.

The RE challenge

With assembly working, I made the sample light pattern. Programming software for such a constrained microcontroller could be a separate blog post (2-level deep call stack, 19 bytes of global data, and 512 words of program memory) but is left as an exercise for the reader.

I now officially had the minimum viable product, all the way to production and software, to host the March Madness bracket-style badge programming competition. At this point, I’m ahead of schedule, so I started looking into how to implement an RE challenge in theme with the RE//verse conference topics. Step 1 was identifying what inputs were available to the PIC16F54, and this was clear. I already needed to expose the in-circuit serial programming (ICSP) pins to allow people to flash their own code onto the badges. I decided to reuse that interface and added code to set the ICSP data and clock pins as input and read from them.

But… it didn’t work! I couldn’t get the code to behave correctly. From a private training event we hosted at RII, I’d known about the concept of pull-up and pull-down resistors (i.e., resistors connected to power or ground per desired target state), but I didn’t really understand the application. Here, I learned the actual application. If you’re going to rely on a pin as input, you need to ensure it’s not floating (i.e., an undefined state of neither high nor low voltage). As such, you must pull the input up or down by default, so your input can be clearly identified (if it’s not always being actively driven externally). I “prototyped” a couple of pull-down resistors onto the PCB, tested it, and immediately the code worked as expected.

Manufacturing Run #2

Now with an RE challenge designed and tested on hardware, I revised the PCB with two noticeable improvements: larger resistor and capacitor footprints to facilitate hand soldering, and additional pull-down resistors to implement the RE challenge. Now for the tough decision: do I order another trial run of 5 boards, test it, and then order a full (120 count) run? Or do I order all the boards immediately to expedite delivery and reduce cost—with the chance that an unforeseen issue exists?

I was confident based on how well the first run went, and I noted that a run of 5 costs about ⅓ as much as a run of 120. Money isn’t everything, but the cost of making small orders is significantly higher per unit than the marginal cost of ordering in larger quantities. So, I went for the 120, assembled two myself for testing (with no issues—whew), and now we were ready for full-scale assembly.

PCB Assembly

I wanted part of this experience to provide RII team members with an opportunity to solder and work with multimeters in a low-risk setting, preparing them for possible program work where they might need to do hardware-oriented tasks. Thus, it was an intentional decision to not order pre-populated PCBs from the manufacturer. After multiple nights of training and rotating volunteers to experience different portions of the assembly process, we had >95% problem-free boards ready to give out at RE//verse. A huge thank you to everyone who voluntarily spent some late nights at soldering parties!

As a side note, because I knew we would be assembling these PCBs ourselves, I picked components without considering which ones JLCPCB listed in their inventory. What I overlooked is that if we want to order another run, I’m unable to change my mind and just get them populated during manufacturing without either redesigning the PCB with the right components and footprints, or supplying my own components to JLCPCB via their consignment process. Additionally, instead of ordering my own components in small quantities and paying higher per-unit costs, I’ve heard secondhand that PCB manufacturers will provide bulk component pricing for items in their inventory, even if you only get a few of them..

Event

After a long buildup and a lot of work, I, and everyone that helped make this happen, were thrilled that everything went off without a hitch, and conference attendees engaged with our challenges. We gave away the vast majority of the badges, and had 6 solving teams or individuals, taking between 3.5 and 24 hours to solve the challenge, with a median of ~20 hours. Our first place programming competition winner wrote their own pulse width modulation (PWM) implementation, allowing customized fading in and out, dimming, and also synchronized it to music. Post-event voluntary feedback gave us an average 9.75/10 for enjoyability and an accessible 5.5/10 for difficulty.

RE//verse hosts an hour of lightning talks during the last hour of the conference. I was pleased to present an introduction to the PIC16F54 architecture, and the intended solution for our RE challenge. You can find the video of that lightning talk here:

Conclusion

The process from design, assembly, and event execution went far smoother than I anticipated as a first-time badge designer. However, there are still some lessons to be learned:

Start with the right CAD tool for your vendor
Pick parts in your vendor’s inventory to have the option of vendor assembly, even if you are not sure you want it
Add some resistors for each LED to reduce brightness and allow more variety in LED colors

PICs or it Didn't Happen: Designing a Sponsor Badge for RE//verse 2025