Inside This Year’s Queercon Badge

August 7, 2017 by Brian Benchoff 11 Comments

At this point, it’s not really correct to describe DEF CON as a single, gigantic conference for security, tech, and other ‘hacky’ activities. DEF CON is more of a collection of groups hosting villages, get-togethers, meetups, and parties where like-minded individuals share their time, company, electronic war stories, and whiskey. One of the largest groups measured by the number of rideable, inflatable unicorns is Queercon, a ‘conference within a conference’ dedicated to LGBT causes, a rager of a party, and a killer conference badge.

The Queercon badge is always a work of art, and this year is no exception. Last year, we took a look at an immaculate squid/cuttlefish badge, and a few years before that, the Queercon badge was a beautiful 3.5″ floppy embedded with far too many RGB LEDs. This year’s Queercon badge was equally as amazing, quite literally pushing badgecraft into another dimension. The folks behind the Queercon badge just wrote up their postmortem on the badge, and it’s an excellent example of how to push PCBs into the space of human interaction.

The development of the 2017 Queercon badge had a really tough act to follow. Last year’s Blooper squid/cuttlefish badge is a high point in the world of functional PCB art, and by January of this year, the team didn’t know where to take badgecraft next.

In the end, the QC badge team decided on a ‘failsafe’ design — it wasn’t necessarily going to be the best idea, but the design would minimize risk and development time.

The two obvious features of this badge are an incredible number of tiny RGB LEDs, and very strange hermaphroditic edge connectors, allowing these badges to be plugged together into a panel of badges or a cube. What does this badge do? It blinks. If you have five friends, you can make something that looks like the Companion Cube from Portal.

Hardware

The killer feature for this badge is a vast array of RGB LEDs. Instead of going with WS2812s or APA101s, the Queercon badge team found simple, 0604 RGB LEDs, priced at about $0.026 a piece. There are 73 LEDs in total, all driven by the same TI LED driver used in previous years, combined with two shift registers and 15 FETs to control the LED commons. Although the LED driver is able to address all 219, and even though the badge is powered by a 32-bit ARM Cortex M3 microcontroller, this is pretty much the limit of how many LEDs can be controlled with this setup.

The Queercon badge always has a bit of interconnectedness built in, and this year is no exception. This year the badge uses a strange universal connector mounted along the four sides of the badge. When one badge is plugged into the other, they mate producing a ‘fabric’ of glowing badges. The range of motion on this connector allows for 180 degrees of rotation, but surprisingly most Queercon badge holders only assembled single planes of badges. It took a bit of cajoling from the badgemakers to get people to assemble a cube, and no other weird shapes were constructed out of multiple badges. If anyone likes this idea of interconnected badges, I would like to personally suggest equilateral triangles — this would allow for icosahedrons or hexagon-based solids.

A Game

A badge wouldn’t be complete without a game, and the Queercon badge has it in spades. The UI/UX/graphics designer [Jonathan] came up with a game loosely based on a game called ‘Alchemy’. Every badge comes loaded with a set of basic elements (air, fire, water, earth), represented as pixel art on the 7×7 RGB LED matrix. Combining these elements leads to even more elements — water plus fire equals beer, for example. Think of it as crafting in Minecraft, but with badges.

Starbucks was responsible for sponsoring a portion of Queercon this year, so ten special badges were loaded up with a fifth element: coffee. Elements derived from the coffee element required a Starbucks sponsor badge.

As we all expect from a DEF CON badge, there was a crypto challenge and contest. The full write up is available here, with the solution somewhat related to a cube of badges.

A Complete Success

When the badges came back from the fab house, the failure rate for this year’s Queercon badge was 0.7%. That’s an amazing yield for any independent hardware badge, and is honestly one of the most impressive aspects of this year’s Queercon. Failure modes during the con were probably related to spilling a drink on a badge, although there was a rash of failed CPUs. This is probably related to ESD, and during the con rework of failed badges was basically impossible because of drunk soldering in a dimly lit hotel room.

If there’s one failure of this year’s Queercon, it’s simply that it’s becoming too popular. From last year, Queercon saw 200% growth for the main party, which meant not everyone got a badge. That’s unfortunate, but plans are in the works for more inventory next year, providing DEF CON 26 isn’t cancelled, which it is. A shame, really.

All The Hardware Badges Of DEF CON 25

August 4, 2017 by Mike Szczys 22 Comments

Hardware is the future. There is no better proof of this than the hardware clans that have grown up around DEF CON, which in recent years has become known as Badgelife. I was first drawn to the custom hardware badges of the Whiskey Pirates at DC22 back in 2014. Hardware badges were being made by several groups at that time but that was mainly happening in isolation while this year the badge makers are in constant contact with each other.

A slack channel just for those working on their own DEF CON badges sprung up. This served as tech support, social hour, and feature brainstorming for all on the channel. In the past badges were developed without much info getting out during the design process. This year, there was a huge leap forward thanks to a unified badgelife API: the badge makers colluded with each on a unified communcations protocol. In the multitude of images below you frequently see Rigado modules used. These, and some others using different hardware, adopted a unified API for command and control, both through makers’ “god mode” badges, and for wireless gaming between participant badges.

I was able to get into the badge makers meetup on Thursday of DEF CON. What follows is the result of a frantic few hours trying to get through the sheer volume of badges and people to share with you all the custom hardware on display. One thing is for sure — there were literally thousands of custom badges built and sold/distributed during DEF CON. I can’t wait to see what the artisanal hardware industry will look like in five years time.

Continue reading “All The Hardware Badges Of DEF CON 25” →

Look What People Brought To Breakfast At DEF CON

August 1, 2017 by Mike Szczys 14 Comments

Sunday was our Breakfast at Hackaday meetup and a swarm of folks showed up, take a look at the hardware they brought with them! Vegas can be a tough place to set up a meetup — especially if you don’t want to rent a room. We filtered into a Starbucks across the street from Caesar’s and ended up packing the high-top table areas. It turns out you get a really funny look from the baristas when you go through the coffee line and ask for four dozen pastries and a few buckets of coffee.

About 30 minutes before official start

Too busy talking hardware to look

The size of the space made it hard to get a picture of the entire crowd. I did manage to get a posed photo with the people who showed up about a half hour early. Once it filled up all I got for crowd shots were people with their back to me and heads down comparing hardware projects — that might actually be more appropriate for DEF CON where people generally don’t want to be photographed (case in point our bandanna wearing friend).

Swag, pastries, and RF hacking

print your Storm Trooper helmet

custom headgear

There was a ton of different hardware on hand. If you look at a picture of the swag and pastries tables, look closely at the high-top behind that. There were a couple of people hacking on RTL-SDRs before we arrive (which means they were at least 45 minutes early).

I’m a fan of wearing your hardware projects at events and this year was really great for that. First, a Captain Phasma helmet from The Force Awakens. It’s 3D printed in ABS, using an acetone/ABS slurry to glue (actually to weld) the parts before sanding and painting to finish the job.

Dragonfly badge (proper name: Sympetrum)

AND!XOR badges within BT range

Most of the hacks on hand were unofficial hardware badges built specifically for DEF CON. I was at the Badge Build’s meetup and have a megapost on everything I saw there coming out a bit later. But here we get a look at the dragonfly badge which [Kerry] brought along with him as well as the rectangular PCB that was the prototype. The AND!XOR crew was in the house and I decided to bug [Hyr0n] about the password hashes I was trying to crack from their badge’s firmware. He pulled up the app and it wasn’t surprising to see so many of the Bender on a bender badges in the area. Their botnet was a huge hit this year!

At some point, I was handed this book-like box which had been laser cut and etched out of plywood. It’s a beautiful piece and I had no idea what I would find inside. Turns out it’s a complete quadcopter-badge fun kit. I must have been so enthralled with the electronics when we covered this badge a few weeks back that I completely missed the beautiful box they built for it.

Inside the box, you’ll find two versions of the badge (one that flies, the other that blinks and has a red PCB handkerchief), a separate PCB that is the controller, and a goodie bag with extra batteries and charging hardware. We didn’t fire this up at the meetup, but we’ll have it at the Hackaday Superconference for you to play with. It was really great to get a group picture with so many of the people who worked on making this badge happen.

There was one high-top over in the corner that had been mobbed with people all morning and I only got a look at it when the crowd started to clear out around noon. [Brian McEvoy] built a custom controller for OpenSCAD and did a great job of bringing along a demo. A tablet is running the software, with the controller connected via USB. There are 3 knobs on the right that allow you to adjust height, width, and depth. The fourth knob is for adjusting precision. That precision is displayed in a very clever way. You can see the LED strip with has a red dot on the right (the decimal point) and three colored pixels to the left of it. These are the tens, hundreds, and thousands, but just turn the crank until the red dot is at the other end of the strip and you’ll be setting precision to tenths, hundreths, etc. [Brian] even added a button you can hold down to 10x the precision without making a permanent adjustment. The project is driven by a Teensy LC board.

Is wonderful to see the Hackaday Community turn out for a meetup like this even though so much other stuff is going on at DEF CON. Thank you to all of you for coming to say hi, share your stories, and show off your handy work!

“Borrow” Payment Cards With NFC Proxy Hardware

July 31, 2017 by Mike Szczys 31 Comments

Contactless payments are growing in popularity. Often the term will bring to mind the ability to pay by holding your phone over a reader, but the system can also use NFC tags embedded in credit cards, ID card, passports, and the like. NFC is a reasonably secure method of validating payments as it employs encryption and the functional distance between client and reader is in the tens of centimeters, and often much less. [Haoqi Shan] and the Unicorn team have reduced the security of the distance component by using a hardware proxy to relay NFC interactions over longer distances.

The talk, give on Sunday at DEF CON, outlined some incredibly simple hardware: an NFC antenna connected to a PN7462AU, an NRF24L01 wireless transceiver, and some power regulation. The exploit works by using a pair of these hardware modules. A master interfaces with the NFC reader, and a slave reads the card. The scenario goes something like this: a victim NFC card is placed near the slave hardware. The master hardware is placed over a payment kiosk as if making a normal payment. As the payment kiosk reader begins the process to read an NFC card, all of the communications between it and the actual card are forwarded over the 24L01 wireless connection.

The demo video during the talk showed a fast-food purchase made on the Apple Pay network while the card was still at a table out in the dining area (resting on the slave hardware module). The card used was a QuickPass contactless payment card from China UnionPay. According to a 2016 press release from the company, over two billion of these cards had been issued at the time. With that kind of adoption rate there is a huge incentive to find and patch any vulnerabilities in the system.

The hardware components in this build aren’t really anything special. We’ve seen these Nordic wireless modules used in numerous projects over they years, and the NXP chip is just NFC build around an ARM core. The leaps that tie this together are the speed-ups to make it work. NFC has tight timing and a delay between the master and slave would invalidate the handshake and subsequent interactions. The Unicorn team found some speedups by ensuring the chip was waking from suspend mode (150 µS) and not a deeper sleep. Furthermore, [Haoqi] mentioned they are only transmitting “I/S/R Block Data” and not the entirety of the interaction to save on time transmitting over the 24L01 wireless link. He didn’t expand on that so if you have details about what those blocks actually consist of please let us know in the comments below.

To the card reader, the emulated payment card is valid and the payment goes through. But one caveat to the system is that [Haoqi] was unable to alter the UID of the emulator — it doesn’t spoof the UID of the payment card being exploited. Current readers don’t check the UID and this could be one possible defense against this exploit. But to be honest, since you need close physical proximity of the master to the reader and the slave to the payment card simultaneously, we don’t see mayhem in the future. It’s more likely that we’ll see hacker cred when someone builds a long-range link that lets you leave your NFC cards at home and take one emulator with you for wireless door access or contactless payments in a single device. If you want to get working on this, check out the talk slides for program flow and some sourcecode hints.

Michael Ossmann Pulls DSSS Out Of Nowhere

July 29, 2017 by Mike Szczys 23 Comments

[Michael Ossmann] spoke on Friday to a packed house in the wireless hacking village at DEF CON 25. There’s still a day and a half of talks remaining but it will be hard for anything to unseat his Reverse Engineering Direct Sequence Spread Spectrum (DSSS) talk as my favorite of the con.

DSSS is a technique used to transmit reliable data where low signal strength and high noise are likely. It’s used in GPS communications where the signal received from a satellite is often far too small for you to detect visually on a waterfall display. Yet we know that data is being received and decoded by every cell phone on the planet. It is also used for WiFi management packets, ZigBee, and found in proprietary systems especially any dealing with satellite communications.

[Michael] really pulled a rabbit out of a hat with his demos which detected the DSSS signal parameters in what appeared to be nothing but noise. You can see below the signal with and without noise; the latter is completely indiscernible as a signal at all to the eye, but can be detected using his techniques.

Strong DSSS Signal, no noise

Same DSSS signal not apparent

Detecting DSSS with Simple Math

[Michael] mentioned simple math tricks, and he wasn’t kidding. It’s easy to assume that someone as experienced in RF as he would have a different definition of ‘simple’ than we would. But truly, he’s using multiplication and subtraction to do an awful lot.

DSSS transmits binary values as a set called a chip. The chip for digital 1 might be 11100010010 with the digital 0 being the inverse of that. You can see this in the slide at the top of this article. Normal DSSS decoding compares the signal to expected values, using a correlation algorithm that multiplies the two and gives a score. If the score is high enough, 11 in this example, then a bit has been detected.

To reverse engineer this it is necessary to center on the correct frequency and then detect the chip encoding. GNU radio is the tool of choice for processing a DSSS capture from a SPOT Connect module designed to push simple messages to a satellite communication network. The first math trick is to multiply the signal by itself and then look at spectrum analysis to see if there is a noticeable spike indicating the center of the frequency. This can then be adjusted with an offset and smaller spikes on either side will be observed.

When visualized in a constellation view you begin to observe a center and two opposite clusters. The next math trick is to square the signal (multiply it by itself) and it will join those opposite clusters onto one side. What this accomplishes is a strong periodic component (the cycle from the center to the cluster and back again) which reveals the chip rate.

Detecting symbols within the chip is another math trick. Subtract each successive value in the signal from the last and you will mostly end up with zero (high signal minus high signal is zero, etc). But every time the signal spikes you’re looking at a transition point and the visualization begins to look like logic traced out on an oscilloscope. This technique can deal with small amounts of noise but becomes more robust with a bit of filtering.

This sort of exploration of the signal is both fun and interesting. But if you want to actually get some work done you need a tool. [Michael] built his own in the form of a python script that cobbles up a .cfile and spits out the frequency offset, chip rate, chip sequence length, and decoded chip sequence.

Running his sample file through with increasing levels of noise added, the script was rock solid on detecting the parameters of the signal. Interestingly, it is even measuring the 3 parts per million difference between the transmitter and receiver clocks in the detected chip rate value. What isn’t rock solid is the actual bit information, which begins to degrade as the noise is increased. But just establishing the parameters of the protocol being used is the biggest part of the battle and this is a dependable solution for doing that quickly and automatically.

You can give the script a try. It is part of [Michael’s] Clock Recovery repo. This talk was recorded and you should add it to your reminder list for after the con when talks begin to be published. To hold you over until then, we suggest you take a look at his RF Design workshop from the 2015 Hackaday Superconference.

Injecting Code Into Mouse Firmware Should Be Your Next Hack

July 29, 2017 by Mike Szczys 22 Comments

Here’s a DEF CON talk that uses tools you likely have and it should be your next hacking adventure. In their Saturday morning talk [Mark Williams] and [Rob Stanely] walked through the process of adding their own custom code to a gaming mouse. The process is a crash course in altering a stock firmware binary while still retaining the original functionality.

The jumping off point for their work is the esports industry. The scope of esporting events has blown up in recent years. The International 2016 tournament drew 17,000 attendees with 5 million watching online. The prize pool of $20 million ($19 million of that crowdfunded through in-game purchases) is a big incentive to gain a competitive edge to win. Contestants are allowed to bring their own peripherals which begs the questions: can you alter a stock gaming mouse to do interesting things?

The steelseries Sensei mouse was selected for the hack because it has an overpowered mircocontroller: the STM32F103CB. With 128 KB of flash the researchers guessed there would be enough extra room for them to add code. STM32 chips are programmed over ST-Link, which is available very inexpensively through the ST Discovery boards. They chose the STM32F4DISCOVERY which runs around $20.

Perhaps the biggest leap in this project is that the firmware wasn’t read-protected. Once the data, clock, and ground pads on the underside of the board were connected to the Discovery board the firmware was easy to dump and the real fun began.

They first looked through the binary for a large block of zero values signifying unused space in flash. The injected firmware is designed to enumerate as a USB keyboard, open Notepad, then type out, save, and execute a PowerShell script before throwing back to the stock firmware (ensuring the mouse would still function as a mouse). Basically, this builds a USB Rubber Ducky into stock mouse firmware.

There are a few useful skills that make taking on this project a worthwhile learning experience. To compile your custom code correctly you need to choose the correct offset address for where it will end up once pasted into the firmware binary. The vector table of the original code must be rewritten to jump to the injected code first, and it will need to jump back to the mouse execution once it has run. The program flow on the left shows this. Both of these jumps require the program counter and registers to be saved and restored. The ARM stack is subtractive and the address will need to be updated to work with the added code.

The talk ended with a live demo that worked like a charm. You can check out the code in the MDHomeBrew repo. In this case the PowerShell script adds keyboard shortcuts for DOOM cheats. But like we said before, the experience of getting under the hood with the firmware binary is where the value will be for most people. With this success under your belt you can take on more difficult challenges like [Sprite_TM’s] gaming keyboard hack where the firmware couldn’t easily be dumped and an update binary was quite obsfucated.

Sunday: Breakfast At DEF CON

July 25, 2017 by Mike Szczys 6 Comments

Nurse your hangover by having Breakfast at DEF CON with Hackaday this Sunday. You’re invited to our yearly ritual by marking the beginning of the end with coffee and pastries at 10:30 am.

Choosing an exact location in advance is always tricky (anyone who’s been to DEF CON understands). We’ll pick a place once we hit town later this week. For now, head over to the Breakfast at DEF CON event page and hit the “join the team” button on the bottom left so we can let you know when we’ve found the perfect location for the breakfast meetup.

Extra internet points go to those who bring some hardware to show off… and especially for anyone who is making this the end of their Saturday rather than the beginning of Sunday. [Brian] and [Mike] will be there, joined by our friends [Jasmine] and [Shulie] who are on the scene for Tindie, a sponsor of the IoT Village this year. See you on Sunday!