12/30/2016 at 17:33 •
We can't say this enough, but we were blown away by the response we got from the DEF CON community last year. DC24 was an amazing experience, we met so many great people. Our experience from the conference can be summed up in this tweet by @wookie_p
The plan for DC25 was to take a few months off and come up with ideas. This didn't exactly happen, we went right into testing and prototyping. We have an initial list of 30+ features to incorporate, a BOM, and design. We aren't ready to release many of those details yet. But here's what we are ready to say:
- It will be bigger - roughly twice the surface area of last year's badge
- There will be more - at least double, this is dependent on how much money we can come up with as a group
- The BOM has doubled in cost - we will try to keep the final cost in check through crowd funding and sponsorships TBD
- We will not be doing production by hand
- The badge will not be running Arduino - sorry Zapp can't handle the IDE any longer
- The badge will be hackable - bring your SWD tools
- There will be a lot more bling
- The RF will work
Stay tuned, we will continue to use Twitter and Hackaday.io to release details.
12/30/2016 at 18:00 •
Over the past few months I have been working on custom drivers for various peripherals for our badge. Most of this is to learn how to build the drivers and the underlying hardware. This would have been an impossible task for me just a year before working on our DC24 badge. At this point I've come up with a custom display driver which I believe is as close to optimized as I can get it. In the process here are the factors that need to be considered:
- Maximize bulk transfer speed - select the highest possible SPI clock rate the MCU and display will safely operate at
- Minimize latency between bulk transfers - utilize DMA to asynchronously transfer chunks while preparing the next chunk for transfer
- Minimize data to be transferred - reduce color depth, pixels, and commands to be sent
During prototyping we've been limited to 8 Mhz on the SPI bus. At 320x240 16-bit, a single frame requires 1.2 Mbits! Over SPI, the render can take seconds. No where close to what we need.
One of my favorite tools as of late is my Saleae 8 channel logic analyzer. It's nice and compact enough to travel with me for work too.
For displays like the ILI9341 (pictured), the typical command sequence is to set a window (0x2A and 0x2B commands) with the X and Y dimensions followed by raw pixel data. Below is a trace of the window command. Taking 69 usec to transfer 10 bytes (0x2A, start x, end x, 0x2B, start y, end y). The coordinates are 16-bit integers. Also notice the delay between transfers as the MCU is executing other commands.
To draw a single pixel, the address command above plus a 16-bit color must be sent to the display - 12 bytes total! That's a lot of overhead for one pixel.
Here's what drawing Bender on a 128x128 display at 16-bits looks like. In this case the window is set to 0, 128, 0, 128 then 16-bit colors are streamed to the display.
Looking at the clock line, notice there are gaps here that we should be able to optimize out. Rendering appears to take 682 msec. Zooming way in we see there is a lot of space between transfers. Toggling the CS line seems to be wasting time. Data is being transferred two bytes at a time because it's being converted from a 24-bit BMP pixel-by-pixel.
So How Do We Improve This?
An easy way is to remove the BMP overhead by pre-processing the images. The display is in 16-bit 565 mode. By converting the image to 565 big-endian raw data using ffmpeg we can stream the pixels in the display's native format. The following command will convert an image to 565be raw format.
ffmpeg -i RED.BMP -f image2 -s 128x128 -pix_fmt rgb565be RED.raw
In addition we can remove some of the SPI blocking to reduce delays. The image below shows the flash memory and LCD transfers occurring asynchronously.
The transfer in green is the LCD and red is the flash memory being setup to read the next chunk of the image. Notice the pixel data has fewer gaps. We are simply reading the 565BE data from flash and streaming it to the LCD. At this point we can draw 10.5 FPS.
The flash setup time is wasting quite a bit of time, roughly 800 usec. We're paying this penalty many times per frame. To reduce the number of times occurs we can make a classic tradeoff between memory and performance. Next step is to increase the chunk size from 2 rows to 32 rows per transfer. This uses about 8k of memory and gives us a nice speed boost to 11.7 FPS.
The transfers are basically blocking each other at this point. Again in the image above LCD is on the top and flash is on the bottom.
Now that large chunks of pixel data can be read and streamed to the LCD very quickly, the last step is to send the pixel while the flash is reading the next frame. I can only transfer 254 bytes at a time, but can do so asynchronously. The trick is to setup the next 254 bytes of the chunk soon after the first returns but not interrupt the flash transfer. This allows the flash to be read with very little disruption setting up the next 32 rows of image data while the last are being sent.
In the image above, the 32 rows are clearly defined. The image is 128 pixels tall so 4 transfers of this size are required to draw a full frame. The flash is a bit slower than the LCD and ends up slowing the LCD down a bit. The green box highlights a full frame. Note the LCD does not start until the first chunk of data is read from the flash. But the flash rarely stops.
At this point we're able to draw 17.5 FPS, excelsior!
Putting it all together
What I learned through this whole process, is allow the hardware to do what it does best. Give it very large chunks of data to transfer and let it do so in the background. Even with a 64 Mhz MCU, my code will slow down the transfer greatly. Once data can be streamed in large chunks, do so in parallel with other operations to maximize efficiency. At the beginning of this process, even with DMA enabled, it took me 685 msec to draw a single frame from flash. I am now down to 57 msec. Although I can go further, with -O3 gcc optimization it's down to 52 msec but this introduces other bugs I need to fix. So for now I'll stick with -O0.
01/04/2017 at 07:34 •
So from the public's POV, you saw this on our Twitter feed. We decided to get the hype train going a little early and threw a game together to give the l337 H@x0r community of DEFCON something to do over the holiday break. BEFORE READING ANY FURTHER, KNOW THAT THIS IS AN UBER SPOILER OF THE CONTEST STEPS. IT HAS BEEN WON ALREADY, BUT IF YOU STILL WANT TO GIVE YOUR SKILLS A SHOT, DONT READ FURTHER...or if you're the kind of person who racked out their NES checklist with a Game Genie to skip past the hard parts so you could have lunchtime bragging rights of the final boss details, by all means keep reading ;) And if you're too young to know what a Game Genie is...sigh...
Anyway, about a month ago over a much inebriated brewery board meeting, we locked down a functional baseline of our DC25 badge. At some point, we started thinking of ways to have fun with a contest, and thus this cluster fuck was born. Over a lot of booze.
We figured, since we were going to give away a free badge, you should f-ing work for it. Instead of going the route of a certain genre of our DC interests, we decided to just layer and sandwich a bunch of stuff together. We knew since mid-October-ish (thats a word right?) we were going to do something, so we started tweeting out easter eggs and hiding stuff in youtube videos we knew we could use later on... It could have been the booze talking too...
Now at the same time when the contest started, we were running a booster campaign. https://www.booster.com/andnxor Designing and Prototyping badges isn't cheap. It costs us a lot of money. So we we're boosting with shirts that contained a silhouette of the badge design. It had a cryptic message: 42 59 54 45 20 4d 59 20 53 48 49 4e 59 20 4d 45 54 41 4c 20 42 41 44 47 45 21
I wont give that one away, but cmon, find your favorite HEX to ASCII converter. So instantly we got many MANY guesses that, that was the secret phrase. Well our tweet said "badge design" and this is an outline. Doesn't show you much. To be fair, we quickly told everyone it had nothing to do with the Booster site. But that was a good warm-up for things to come.
Okay so, in step by step, lead you by the hand fashion, here's a typical way someone could have gone about winning the contest.
- It was hidden somewhere on the internet....try our web page
- There's only a couple of images, if one tried to download MANBEARPIG (which we referred to a ridiculous amount of times on Twitter) you would notice you cant. We blocked it out with CSS.
- View Page Source
- Well looky here, there's the name of the style sheet "andnxor.css". Lets type that in...
- Looks like someone updated the manbearpig.png with a new version "v2" thats odd. Lets download it. Now that we know the file name, you can just type it in the browser address, and save as. Wow that took forever right? Well most people wouldnt notice cuz their interweb speeds are so fast. But look at the file properties. Isn't it a little odd that you have a BLACK AND WHITE PNG image that's 800kb?
- Steganography - the practice of concealing messages or information within other nonsecret text or data. Now this is where paths can diverge on solving the puzzle. You could verify something is hidden the proper way, load it in a hex editor, and notice the regularly unused bits of the image have data in them. Or just hack around. There's many steganography applications out there, even fewer are free and open source
- Load the Image in OpenStego
- Given the shit I've put you through thus far, you should assume its just not that easy. Of course we damn well password protected it. There were many hints thrown out on twitter, youtube and chats...
- I even blurted out "C1E169852F1D95CC2DA7AA791E5F4EFF"
- All signs point to the password being "EXCELSIOR!"
- Cool, so you now have a PNG with something hidden inside of it, OpenStego, and a password. Extract it and what do you get...
- Well shit there's the badge art which we will be screening on to the PCB. Awesome right? Well, we hope you think its awesome. But this was a contest to win a free badge and you had to tweet the secret word. And we're some god damn assholes that put something in wingdings.
- Translation Time
- Be careful, its not so easy to visually translate images. You lack the luxury of copy/paste and OCR doesnt work on wingdings.
- GJRRG @NAQaKBE "QRNQORRS" SVEFG CREFBA JVAF N ONQTR
- Cypher Time
- So at this point we didnt really try too hard, we figured who made it past the steganography it would just be a race at this point. So ROT13 it is !
- TWEET @ANDnXOR "DEADBEEF" FIRST PERSON WINS A BADGE
- We'll kids, thats it. Give a shout out to @compukidmike. And just as important, let us know what you think in the discussion section below. This was my first attempt at creating a puzzle that literally hundreds of people were competing over and messaging us non stop over the holiday. Even more so, what do you guys think of the badge art? Until further project updates, this is Hyr0n - signing off.
- It was hidden somewhere on the internet....try our web page
01/07/2017 at 16:31 •
DEF CON 24
One of the basic features of our DC24 badge was design for hackability. Personally, the badge project was a journey into embedded electronics. I got started with an Arduino and a breadboard, this is what I was familiar with. I designed Bender along those lines. The hardware was inspired by the Maple Mini from Leaf Labs and Espruino (both STM32F013) and ran an Arduino framework called stm32duino. We exposed as much IO as possible around Bender's eyes, provided SWD and FTDI interfaces, and USB for UART and DFU.
We know of one user hacking their badge. @mediumrehr added his own cigar PCB and spectrum analyzer to Bender. It was amazing to watch and that his design fit so well.
This approach had some issues, however:
- It required source code to modify the badge - which we didn't release until after DEF CON
- stm32duino is not a straightforward install - it requires many steps and is not managed through the Arduino IDE.
- The SWD interface was not enabled in the firmware - we released an update that enables it but at DEF CON it was not working
All in all we were very happy with the badges, we know of at least two people who have created their own Benders from github so it can't be that hard. If you see anybody with it a Purple Bender, buy them a drink. They made it themselves and it was not easy.
DEF CON 25
Based off our experience at DEF CON 24, our goal remains the same: Make the Badge Hackable but we want to see your hacks in Las Vegas. We want you to share your hacks. So we're changing things up. This year's badge is not based off a development board. It is completely original. There will be no USB but there will be SWD. We will expose as much GPIO as we can. And we will provide physical dimensions where it makes sense. Finally, we want the barrier-to-hacking to be as low as possible. How? We're not sure yet, but last year the goal was nothing more than a laptop, the Arduino IDE, and stm32duino.
01/21/2017 at 02:37 •
Well we missed our January 18th target by 2 days, but the prototype design has been ordered. We hope to have them in house by February 15th. This gives us about 2 weeks of slack time in case the fab and assembly takes longer than expected.
We did an initial prototyping round back November but did not map the pins properly. This meant most of the peripherals simply didn't work. We learned a few things but had to revert to our dev kits for development and prototyping.
To avoid issues with today's prototypes we ordered an interim "Risk Reduction" test board from OSH Park. This included most peripherals from the BOM we were concerned with and allows us the flexibility to breadboard some of our assumptions. Two issues were identified:
- We had the wrong connector for our display (we chose a top contact and needed bottom)
- The display connector footprint was missing solder paste layer
We were able to work around both issues and test the display (which works quite nicely) and even found a better, cheaper, and stronger connector. Win win! As a final step, several PCB layers were printed (actual size) to verify footprints and size. A comparison with our DC24 badge is below.
While we wait impatiently for the prototypes to arrive, we're using the risk reduction board and dev kit to continue software development.
02/08/2017 at 23:56 •
Badge development is in full swing with our first 6 prototypes expected to arrive next week. We're patiently refreshing the order status page hoping something changes.
August through December were spent prototyping various hardware and testing out ideas. The software was developed specifically for those tests and not as badges. In January we started a new Eclipse project that will take us all the way to DEF CON. We ported some of the drivers from prototyping over to the master project and created our backlog in the issue tracker. The backlog continues to grow as we add more detail to our ideas and use the software.
To manage the work, we've setup a series of milestones for the software:
- v0.1.0 - Jan: Initial drivers for all hardware on hand, demonstrate badge basics and UI
- v0.2.0 - Jan: Focus on porting bling and supporting APIs. Explore new bling concepts. Refine UI. Work on Secret Feature 1 and initiate Secret Feature 2.
- v0.3.0 - Feb: Focus on Secret Feature 3 and getting badge software to run on prototypes once they arrive.
- v0.4.0 - Mar: Refinement of Secret Feature 2. Hopefully merge Secret Feature 4. Port some games / major features from DC24.
- v0.5.0 - Mar: Cyphercon release. This will be the software that runs when we take the prototype to Cyphercon. Refine bling, fix bugs, cleanup UI. Any secret feature work will be hidden.
- v0.6.0 - Apr: Complete Secret Feature 2.
- v0.7.0 - May: Possible Layer One release. More cleanup. Complete Bling. Merge Secret Feature 5.
- v0.8.0 - Jun: Feature-complete. Used for test to identify issues.
- v0.9.0 - Jun: Final testing release, no new features, only fixes.
- v1.0.0 - Jul: Final release