We had our biggest Breakfast at DEF CON ever on Sunday. So big, in fact, that the carefully laid plans went awry immediately.
This is the fifth year we’ve hosted the event, which kicks off the final day of DEF CON with some hardware show-and-tell. We really thought we had it all figured out, since this time we actually booked a space in Paris hotel. For the first three years we were just banditing the space — asking everyone to show up at this place and it’ll become an event. Last year we planned to have it in the Hardware Hacking Village, but the casino stopped us from bringing in pastries that morning and we ended up camping out in a dining area that wasn’t open until the afternoon.
Last weekend we had a cafe booked, with pastries and coffee on order. The only problem is that you are all too awesome. We had a couple hundred people show up and the cafe didn’t want us standing, which limited our space to the number of booth seats available. No worries, as is the tradition we spilled out into a lounge area on the casino floor and enjoyed ourselves!
Here’s some of the hardware that showed up at this gathering.
Year over year, the Queercon badge is consistently impressive. I think what’s most impressive about these badges is that they seemingly throw out all design ideas from the previous year and start anew, yet manage to discover a unique and addictive aesthetic every single time.
This year, there are two hardware badges produced by the team composed of Evan Mackay, George Louthan, Tara Scape, and Subterfuge. The one shown here is nicknamed the “Q” badge for its resemblance to the letter. Both get you into the conference, both are electronically interactive, but this one is like a control panel for an alternate reality game (ARG) that encourages interactivity and meaningful conversations. The other badge is the “C” badge. It’s more passive, yet acts as a key in the ARG — you cannot progress by interacting with only one type of badge, you must work with people sporting both badge types so that Queercon attendees who didn’t purchase the Q badge still get in on the fun.
The most striking feature on this badge is a custom membrane keyboard tailored to playing the interactive game across all badges at the conference. But I find that the eInk screen, RJ12 jack for connectivity, and the LED and bezel arrangements all came together for a perfect balance of function and art. Join me after the break for a closer look at what makes this hardware so special.
Mike Szczys and Kerry Scharfglass recorded this week’s podcast live from DEF CON. Among the many topics of discussion, we explore some of the more interesting ways to move a robot. From BB-8 to Holonomic Drives, Kerry’s hoping to have a proof of concept in time for Supercon. Are you using On-Chip Debugging with your projects? Neither are we, but maybe we should. The same goes for dynamic memory allocation; but when you have overpowered micros such as the chip on the Teensy 4.0, why do you need to? We close this week’s show with a few interviews with badge makers who rolled out a few hundred of their design and encountered manufacturing problems along the way. It wouldn’t be engineering without problems to solve.
Take a look at the links below if you want to follow along, and as always tell us what you think about this episode in the comments!
Bluetooth Low Energy (BLE) 5 has been around since 2016 with the most recent version 5.2 published just this year. There’s not much hardware out there that’s using the new hotness. That didn’t stop [Damien Cauquil] from picking apart BLE 5’s new frequency hopping techniques and updating his BtleJack tool to allow sniffing, jamming and hijacking hardware using the new protocol.
As you can imagine, the BLE standard a complicated beast and just one part of it is the topic here: the PRNG-based frequency hopping scheme that is vastly different from BLE 4.x and earlier. The new standard, called Channel Selection Algorithm (CSA) #2 — uses 65535 possible channels, compared to just 37 channels used by its predecessor. Paired devices agree to follow a randomized list of all possible channels in sequence so that they remain in synchronization between hops. This was put in place to help avoid collisions, making it possible for many more BLE devices to operate in close proximity. This is important to note since it quickly becomes obvious that it’s not a robust security measure by any means.
To begin channel hopping the two devices must first agree on an order in which to hop, ensuring they’ll meet one another after each leap. To do so they both run the same 32-bit seed number through a PRNG algorithm, generating a list that will then be followed exactly in order. But it turns out this is not very difficult to figure out. All that’s needed is the access address whose top 16-bits are publicly available if you’re already sniffing packets, and the bottom 16-bits is the counter that increments the hop address list.
If you want to jam or hijack BLE 5 communication you need to establish which “randomized” channel list is being used, and the value of the counter that serves as an index to this list. To do so, [Damien] sniffs packets on two different channels. These channels will be used over and over again as it loops through the channel list, so calculating how much time occurs between each channel indicates how far apart these channels are on the list.
In practice, [Damien] first implemented a sieve (the same concept as the Sieve of Eratosthenes for finding primes) that starts with a list of all possibilities and removes those that don’t contain a matching timing between the two channels. Keep doing this, and eventually, you’ll whittle your list down to one possible channel order.
This certainly worked, but there were timing issues that sometimes meant you could learn the seed but couldn’t then sync with it after the fact. His second approach uses pattern matching. By measuring hops on 11 consecutive channels, he’s able to synchronize with target devices in a minute or less. From there, jamming or hijacking methods come into play. The randomization of this scheme is really marginal. A more robust technique would have used an internal state in both devices to generate the next hopping channel. This would have been much more difficult for an attacker to figure out. From the device perspective, CSA #2 takes very little computation power which is key for power-sipping IoT devices most often using BLE.
As mentioned before, [Damien] had trouble finding any hardware in the wild using the BLE 5 standard. His proof of concept is built on a pair of nRF52840 development boards. Because it needs more testing, the code hasn’t been merged into the main version of BtleJack, but you can still get it right now by heading over to BtleJack repo on GitHub.
Scarcity on the Internet is the siren song of bot writers. Maybe you’ve lost an eBay bid in the last milliseconds, or missed out on a hacker con when tickets sold out in under a minute — your corporeal self has been outperformed by a bot. But maybe you didn’t know bots are on a buying frenzy in the hyped-up world of fashion. From limited-run sneakers to anything with the word Supreme printed on it, people who will not accept any substitute in wearing the rarest and most sought after are turning to resellers who use bots to snag unobtanium items and profit on the secondary market.
At DEF CON 27 [FinalPhoenix] took the stage to share her adventures in writing bots and uncovering a world that buys and sells purchasing automation, forming groups much like cryptocurrency mining pools to generate leads on when the latest fashion is about to drop. This is no small market either. If your bots are leet enough, you can make a ton of cash. Let’s take a look at what it takes to write a bot, and at the bots-for-sale economy that has grown up around these concepts.
The internet is built with bots in mind and we have Google to thank for this. Their major innovation was moving us off of a curated internet to one that is machine crawled. Everyone wants good Google juice and that means building a site that is friendly to the Google bots that crawl and index the internet. This makes automation for your own purposes quite a bit easier. Namely, the monitor-bots that are used to detect when a retailer has the latest in stock. [FinalPhoenix] demonstrated a simple script that grabs the XML site map, parsing it for newly in-stock items, flagging them when found. But here’s the killer — if your monitor bot is a good one, you can turn it into a discord channel and sell subscriptions to others playing the reseller game, to the tune of $15-30 a month per subscriber.
Once your bot reports stock, the race is on to buy it before anyone else can. For this, you could use the APIs of the site, but that’s time-consuming and a lot easier for retailers to detect and block bot usage. For this part of her botting tools [FinalPhoenix] likes to use web-based bots that go through a browser framework like Chromium and allow obfuscation techniques like scrolling, clicking other items, random pauses, and other simple-minded actions that make your bot appear to be only human. In the examples for this talk, the Puppeteer framework was used for this purpose. In the end, the main role of this part of the bot is to use a verified account to complete the purchase as fast as robotically possible, which is why they’re called buy-bots. Retailers do have some tricks to combat these web-based attacks like adding secret keys in the DOM that need to be sent with the next post, but these are easy to discover and incorporate into the scripts.
This raises up another interesting part of the scheme, the verified accounts. For the best chance at profit, you need multiple accounts, each used just one time to avoid your buy-bot being detected by the retailer. For this, [FinalPHoenix] turns to services that sell accounts in packages of 500-10,000 and cost around just $5-10 per batch.
But wait, here’s where it gets really wild as recursion takes hold. Yes, these buy-bots are for sale (from sites like AIO Bot and usually around $300-1500), but they’re sold in limited quantities so that it’s harder for retailers to notice and take countermeasures. Just like how the clothing was limited release and incentivized bots-wielding resellers to enter the market, there is a secondary market for the bots themselves. [FinalPhoenix] reports that reselling one of these bots can yield $1000-1500 in profit. The same principles apply, and so what we’ve ended up with is bots buying bots to buy clothes. Who knows how many levels of bot-bot transactions there are, but it certainly feels like turtles all the way down.
Bot-based high-speed trading is the real way to make major bank on the securities market. Your average hacker is shut out of that “legitimate” business, but any enterprising programmer has the option of automating whichever reseller market they find most interesting. This breaks the public trust in commerce — buying quality products from a seller connected to their production for a reasonable price. If frustrates the manufacturer, alienates the consumer, but there appears to be little in place preventing it.
We’ve all stared at that button in the elevator with the phone icon on it, supremely confident that if the cab came to a screeching halt while rocketing up to the 42nd floor, a simple button press would be your salvation. To be fair, that’s probably true. But the entire system is not nearly as robust as most people think.
Friday at DEF CON 27, [Will Caruana] took the stage to talk about phone phreaking on an elevator. The call buttons first appeared on elevators in 1968 as actual phone handsets, eventually becoming a mandated feature starting in 1976. Unfortunately, the technology they use hasn’t come all that far since. Phone modules on elevators did benefit when DTMF (touch tones) and voice menu systems rolled around. But for the most part, they are a plain old telephone service (POTS) frontend.
[Will] spends his spare time between floors pressing the call button and asking for the phone number. It’s the lowest bar of social engineering, by identifying yourself as an elevator service technician and asking for the number he is calling from. His experience has been that the person at the other end of the phone will give you that number no questions asked nearly every time. What can you do with a phone number? Turns out quite a bit.
The keys to the castle are literally in the elevator phone user manuals. The devices, shipped by multiple manufacturers, come with a default password and [Will’s] experience has been that nobody changes them. This means that once you have the phone number, you can dial in and use the default password to reprogram how the system works. This will not let you directly control the elevator, but it will let you speak to the people inside, and even change the call-out number so that the next time that little button is pressed it calls you, and not the phone service it’s intended to dial. That is, if the system was even correctly set up in the first place. He mentioned that it’s not too hard to find elevators that don’t have their location set up in the system — if you do need help, it may be hard to figure out which elevator you’re actually in. There have also been instances where these call the 24-hour maintenance staff for the building, a bewildering experience for sleepy personnel who didn’t sign up for this.
Yesterday we published a first look at the hardware found on the DEF CON 27 badge. Sporting a magnetically coupled wireless communications scheme rather than an RF-based one, and an interesting way to attach the lanyard both caught my attention right away. But the gemstone faceplate and LED diffuser has its own incredible backstory you don’t want to miss.
This morning Joe Grand — badge maker for this year and many of the glory years of hardware badges up through DC18 — took the stage to share his story of conceptualizing, prototyping, and shepherding the manufacturing process for 28,500 badges. Imagine the pressure of delivering a delightful concept, on-time, and on budget… well, almost on budget. During the talk he spilled the beans on the quartz crystal hanging off the front side of every PCB.