Close
0%
0%

AND!XOR DC25 Badge

We're going bigger, better, more Bender.

Similar projects worth following
What: Bigger, better, more Bender
Why: Because you all liked our badge so much last year

We're starting to finalize the BOM and design. Here's what we know so far:

  • Roughly 2x bigger than last year
  • RF will work
  • Twice the bling
  • Larger screen
  • Hackable
  • More Bender

WHO:: We are 5 dudes from California with backgrounds in HW and SW engineering. We enjoy building and hacking things for fun.

WHAT:: We built a hackable, open badge for use at DEFCON 25 in Las Vegas and any other conferences in the future. The badge also serves as a dev board for hardware developers of any experience level from novice to expert sorcerer.

WHY:: The purpose is to put some really awesome hardware around the necks of a bunch of hackers and see what they come up with. We hope to encourage others to make use of the badge and come back with their own flavor in years to come, AND to promote embedded development across the community.

HOW:: Pure internet science. We've developed algorithms which calculate the spin rate of cat quarks for generating our ssh keys at a rate of (P+9)/((# of blackberry users)^2), where P is the probability that a cat will leave a house when a door is opened for them.

WHERE:: Caesars Palace, Las Vegas

WHEN:: July 27th - July30th, 2017

EXTRAS:: We are spending our free time and money outside of our busy work schedules to develop this from 3 separate locations across California. So we are definitely open and encourage feedback, suggestions, and features to be added onto the badge. If you complain that there are not enough blinky's happening then you are welcome to build your own. Feel free to Leave your comments below if you have questions, concerns, comments, philosophical statements, haiku's, or send us a tweet...that works too.

Twitter:: Check out AND!XOR, our official twitter account on twitter for daily and often hourly updates of the badge process.

  • Software Planning

    Zapp02/08/2017 at 23:56 0 comments

    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

  • Prototypes are GO!

    Zapp01/21/2017 at 02:37 0 comments

      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:

      1. We had the wrong connector for our display (we chose a top contact and needed bottom)
      2. 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.

  • Hackability

    Zapp01/07/2017 at 16:31 0 comments

      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:

      1. It required source code to modify the badge - which we didn't release until after DEF CON
      2. stm32duino is not a straightforward install - it requires many steps and is not managed through the Arduino IDE.
      3. 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.

  • Badge Art Contest

    Hyr0n01/04/2017 at 07:34 1 comment

      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.

      1. It was hidden somewhere on the internet....try our web page
        1. 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.
      2. View Page Source
          1. Well looky here, there's the name of the style sheet "andnxor.css". Lets type that in...
        1. 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?
        2. 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
        3. Load the Image in OpenStego
          1. 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...
          2. I even blurted out "C1E169852F1D95CC2DA7AA791E5F4EFF"
            1. Try cracking the hash
          3. All signs point to the password being "EXCELSIOR!"
        4. Cool, so you now have a PNG with something hidden inside of it, OpenStego, and a password. Extract it and what do you get......
      Read more »

    • Optimizing Display Code

      Zapp12/30/2016 at 18:00 0 comments

        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:

        1. Maximize bulk transfer speed - select the highest possible SPI clock rate the MCU and display will safely operate at
        2. Minimize latency between bulk transfers - utilize DMA to asynchronously transfer chunks while preparing the next chunk for transfer
        3. 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.

        Last Step

        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...

      Read more »

    • We're Back!

      Zapp12/30/2016 at 17:33 0 comments

      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

      "True cost of the Bender badge: takes 2x longer to walk con floor. So many questions about badge! "

      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.

    View all 6 project logs

    • 1
      1. Drink Beer
      2. Assemble Bender
      3. Profit

    View all instructions

    Enjoy this project?

    Share      

    Discussions

    Does this project spark your interest?

    Become a member to follow this project and never miss any updates