Project Logs

Collapse

• DC26 Retrospective

  Zapp • 09/01/2018 at 04:19 • 0 comments

  Wow! Another fantastic year. We can’t believe how far we’ve come since our very first badge at DEF CON 24.  Watching the other badge makers come up with new and interesting designs has been equally fun.

  This year we set out to improve our overall manufacturing process, build a badge with a kickass design (including add-ons), create something folks can learn with, and make people say “WTF?” when they see it.

  Looking back, we achieved those goals.

  
  

  Design

  Our design for DEF CON 25 was very popular, using a Fear and Loathing in Las Vegas theme is an easy win. People loved it. We had to up our game. But we struggled to top it. Bender and Hyr0n spent weeks bouncing competing western themes off each other but nothing really clicked. Finally we called in professional help, Doc from the Packet Hacking Village immediately came through and knocked it out of the park. We can’t say enough how grateful we are for his help and his amazing skills.

  Zapp worked with him over several weeks to refine the design and shading to optimize the PCB manufacturing process.

  Hardware

  From a hardware perspective our DEF CON 25 design was relatively simple. We used a wireless module, SD card, screen, and LEDs. At the time it was a complex design for us, just barely testing our skills. For DC26 we felt the need to step it up a notch or three in complexity.

  Screen

  We upgraded from a 128x128 color LCD to a 220x176 color LCD. The additional pixels required a lot more memory and faster SPI bus to push more pixels to the display. The ESP32 afforded us a 40mhz SPI bus, 4-bit SD card with 40mhz clock. In testing we were able to push the display at 30 FPS or 22Mbps - that’s a lot of Rick Astley. However, due to the notorious SD card, we ended up reducing that to 12 FPS or 9Mbps.

  We’re still not sure exactly the part number the screen is. Zapp found one seller on Taobao and the only way he can confirm the part is by looking at the ribbon cable. Still we were able to source enough screens, plus spares, to get the job done.

  ESP32

  Zapp spent a lot of time this year looking for a new module. While we loved the BMD-300 from Rigado, we needed more RAM and a faster SPI bus. ESP32s seemed popular and the SDK had matured so we bought some dev boards and got to work. There is an impressive ecosystem around the ESP32, lots of great examples (other than the Arduino ones), and Espressif is very actively building the SDK. We ended up with the WROVER32 modules due to the 4MB of RAM critical for LULZCODE and a double buffered display.

  From a spec perspective, the ESP32 modules are impressive. Similar ARM modules simply don’t match them on paper. But there’s no such thing as a free lunch and it turns out it’s difficult to make efficient use of all that power.

  4MB sounds like a lot but it turns out, the most critical RAM in the ESP32 is the DMA memory. Not only that but the largest users of the RAM are in the SDK. We continually found ourselves competing for DMA memory with ourselves. When we ran out of DMA memory, suddenly our SPI bus stopped working. Wifi seemingly ignored settings to use the 4MB of RAM for its buffers and quickly filled DMA memory causing bling to crash.

  On top of that we found the architectural documentation of ESP32 to be lacking. The SDK API is well documented but typical app notes and reference designs/pointers were not available. This caused us to learn lessons like DMA memory the hard way.

  Did you know you can’t access NVS from an ISR? We do now.

  Did you try extracting our firmware from the chip or anyone else’s using an ESP32? You most likely can. While read back protection is a common practice in the security community, Espressif chooses a scheme called encrypted flash. This prevents read back and you can only do it...3 times before a write fuse is permanently blown. W...T…F…. So imagine if our badge was a real consumer IoT device being sold on shelves? You have to choose between protecting your firmware...

  Read more »

• LULZCODE

  Hyr0n • 07/19/2018 at 16:15 • 0 comments

  Rather than repeat a lot of existing information, this serves as a pointer to our online documentation for LULZCODE hosted at geocities and youtube. You WILL need to know this in order to hack the badge ;) 
  

  Link: LULZCODE Technical Documentation

  Link: YouTube Demonstration - Flappy Bird (Pt 1/2)

  Link: YouTube Demonstration - Flappy Bird (Pt 2/2)

  (Sorry for two parts, interwebs kept dropping)

  LULZCODE IZ DESIGND 2 CONTROL NEARLY ALL ASPECTS OV TEH AN!XOR INDIE BADGE 4 DEF CON 26. 2 ACCOMPLISH DIS WE NEEDD 2 EXTEND LOLCODE 2 MEET R NEEDZ.

  HOW IZ LULZCODE DIFFERENT?
  NEARLY ALL LOLCODE 1.2 FEATUREZ HAS BEEN CARRID FWD. WE ESSENTIALLY DOUBLD TEH LANGUAGE SIZE 2 MEET R NEEDZ. WAN IMPORTANT FEACHUR DAT WUZ REMOVD WUZ UNICODE AS IT REQUIRD 2 MUTCH FLASH STORAGE. WE ALSO MAK USE OV BUKKITS WHICH R NOT FULLY SUPPORTD IN LOLCODE.

  WUT IZ LULZCODE 4?
  AFTR READIN OVAR TEH LOLCODE SPEC SEVERAL TIEMS AN FIGHTIN BAK TEH TEARS WE REALIZD IT LIKELY TURIN-COMPLETE. IT HAD EVRYTHIN WE NEEDD. EXCEPT IT DIDNT WERK WELL ON MICROCONTROLLR. IN FACT, IT ONLY HAD BASIC USR INPUT AN OUTPUT. 4 R BADGEZ WE NED LANGUAGE DAT LETS US CONTROL TEH LOW-LEVEL PERIFERALS. SO LULZCODE WUZ BORN. AN EXTENSHUN OV LOLCODE 2 SUPPORT MICROCONTROLLERS.

  LIMITASHUNS
  NOT EVRYTHIN WUZ EXPOSD IN LULZCODE. IT TURNS OUT MODIFYIN LANGUAGE IZ LOT OV WERK. RATHR WE TOOK MOAR PRAGMATIC APPROACH AN STARTD WRITIN R BADGE CODE IN LOLCODE DEN EXTENDIN TEH LANGUAGE WHEREVR WE NEEDD IT.

  LULZCODE MEMS USAGE IZ VRY HIGH. IN FACT AN AVERAGE LULZCODE SCRIPT CAN USE UP 2 100KB OV HEAP MEMS. THAZ 5 TIEMS WUT R FURST BADGE HAD 4 MEMS. 4 DIS REASON WE R RUNNIN TEH BADGE ON AN ESP32-WROVR WHICH GIVEZ US 4MB OV EXTERNAL SPI RAM.

  LULZCODE IZ SLOW. VRY SLOW. IZ INTERPRETTIN STRINGS SO LOAD TIEM TAKEZ AWHILE. ONCE TEH PARSE TREE IZ IN MEMS (C ABOOV) ITZ PERFORMANCE IZ K BUT NOT GREAT.

  LOLCODE 1.2 SPEC 4 MOAR ON LOLCODE C: HTTPS://GITHUB.COM/JUSTINMEZA/LOLCODE-SPEC/BLOB/MASTAH/V1.2/LOLCODE-SPEC-V1.2.MD

• Yet another way to debounce a button

  Zapp • 05/24/2018 at 15:04 • 0 comments

  First things first. We did get a small sponsorship in the way of free parts and development kits from Dialog Semiconductor. This occurred after we had designed and prototyped with the Greenpak. This post is not sponsored in any way and our own thoughts / opinions.
  

  Trying something new

  If you've heard us speak at various conferences and meetings (Cyphercon, Hackaday Super Conference, Layer One, Macrofab, DC858/619), you undoubtedly heard us mention the desire to use an FPGA in our designs but could never justify it with use cases or functions the user cared about. Just because you can use hardware, doesn't mean you should. 

  These badge projects are concerted efforts by our team members to expand and learn new things. Now on our third major badge we have a third technique for debouncing. Enter the Greenpak.
  

  Calling it an FPGA is quite a stretch but the methodology is similar.
  

  Last summer I listened to The Amp Hour with Michael Ossman as a special guest. He mentioned wanting to play with Greenpaks and putting them into a development mode that was barely documented to do fun things with it. After some quick research I added it to our ideas list for DC26 and around October timeframe purchased a development kit. Soon after I was blinking LEDs.

  Creating a Debouncer

  To create the GreenPak logic, a specialized designer must be used. Fortunately the interface is all drag and drop. It takes a little getting used to coming from an EDA tool like Kicad, but isn't the worst. It would be nice to see improvements to how the line junctions are drawn and make them act like other tools, but oh well.
  

  After trying several examples and getting unusually excited by blinky lights, I finally got to work on my primary task, using the Greenpak to debounce 7 buttons while minimizing GPIO usage on our MCU.
  

  The key is to create a CNT block that is fed by a button.
  Each block is multi-purposed. In the components list all available blocks are listed, of these several of the 3-bit and 4-bit LUTs could be repurposed into CNT blocks.
  The trick to button debouncing is to measure the delay the button stays low. In this case I fed in OSC/64 to get a 390.625 Hz frequency. The counter counts 15 ticks and is helpful enough to provide a typical delay time of 40.96ms, a healthy debounce delay.  Note the Non-inverted(OUT) which will send a low signal after 40.96ms (button is connected to GND).
  

  Generating an Interrupt

  The next step is to combine the outputs of the debouncers into one pin that goes high when any button is pressed. This is also straightforward.
  

  
  Using a combination of LUTs I'm able to generate the appropriate high value on Pin 10 when any button is pressed. To get this right it took a lot of trial and error as what I thought was appropriate logic usually ended up backwards from what I was expecting.
  

  But Wait, How Do You Read the Button State?

  This is where the magic of the Greenpak comes into play. I2C.

  Pins 8 and 9 on my particular Greenpak are hardwired for I2C. By default the Greenpak will listen for address 0x00, which is a poor design choice for shared buses. It can be overridden in the design tool which is exactly what I did as the Greenpak lives on a shared bus on our badge.
  
  It turns out all the Greenpak is 256 bytes of ROM (writeable once by a dev kit or factory) and 256 bytes of RAM which the ROM is copied into on startup. All LUT states are stored in RAM and addressable over I2C. WOW. You just need to know where to look in the datasheet - it turns out it's more trial and error than I thought.
  
  The CNT blocks from earlier share their output state in a single byte at address 0xF2. Getting the state of each button is a simple bitmask. All the MCU has to do is listen for a rising edge on the interrupt pin then read 0xF2 to check the button states.

  Getting our own part number

  Something completely unexpected, when Dialog flashed our Greenpaks they also...

  Read more »

• Badge ARG / Console / Command Line Puzzle / Whatevs U Call it

  Hyr0n • 05/14/2018 at 16:04 • 1 comment

  So the best way to start this log is brutal honesty, I just don't know what to call it. It could be that I was up late coding the badge and watching Westworld until a few hours before my flight (then decided to pack last minute). It could be due to the morning airport mimosas, ginger-ale, and vodka cheersing my liver at 30000 feet right now too. Probably a combo of "all the above."

  There's many different words we all use for the same thing here. Originally, in the Joe Grand days of badgery, you would just hear of them being called hardware hacking challenges. Then it turned into puzzles. Then devices like the Sparkfun Harp started using the term Alternate Reality Gaming (ARG) / Hardware Alternate Reality Prototype (HARP), since it was an electronic hardware based puzzle that went beyond the device using external mediums and a story line to immerse the player in a challenge beyond the puzzle itself. Well this year we've increased the hacker difficulty from simple Easter eggs to actual hacking challenges on the badge, which are accessed through a command line interface / UART console, text based adventure RPG...ARG...thing; think of playing Colossal Cave but your actions in the game use the badge hardware to cause things to happen..in real life. As you can see it's a lot of stuff, but overall it's a bunch of hacker challenges, meant to entice you for some fun, and perhaps the first few people who solve the AND!XOR "thing" will get something special... 

  Can we agree on wut 2 call this?

  But first things first, help us name this shit. Nothing surprises us more than the creativeness of the internet. Do your worst internet, do your worst. We 100%  promise to use whatever recieves the most votes, but please lets make it somewhat describe the fact that this is a challenge, a puzzle, a type of ARG, etc... For the purposes of this write up, I'll refer to it simply as "the console."

  TAKE A QUICK SURVEY AND LET US KNOW WHAT YOU THINK

  Prior Work At Consoling

  We have used embedded UART one way or another on our past two badges. We're hackers, we like command like interfaces, especially when it's green on black. DC24 Bender had an integrated console over UART, solving a couple of puzzles and discovering Easter eggs provided unlocks on the badge (more bling, games, etc). Last years DC25 bender built on that concept, except the console was done over wireless from a fone app @bitstr3m wrote, and allowed anyone to wirelessly terminal in to your badge. It dovetailed in to our BOTNET game as a backdoor in about 500 badges with a default root password... but... more people downloaded it AFTER the CON when they got home to mess with the badge than during the CON (we had about 70 people using the wireless console during DC25). So... metrics...lessons learned, going back to an embedded console (non RF based for interfacing) and focusing more on a single player aspect of hacking challenges.

  By hacking challenges, we mean that yes you will actually hack the badge. Not dumb shit life hack it "e.g. hack BUTTON with FINGER" (okay there is some of that...) but actually attempt to circumvent the security of the badge presented in this alternate text based world in order to achieve intel and l337ness. I am not going to give hints as to what those types of challenges will be (since that would ruin the surprise), but they involve the various skill-sets you would find throughout the DEF CON Villages. They also are limited to things we can do with our badge, which includes LEDs (blinks, colors), RF, Hardware Interfaces (Shitty, I2C, SPI,  JTAG), etc... So if you do not understand how to accomplish a certain type of challenge, this is your queue to go get a bunch of beer / liquor / wine / absinthe / defcoin and approach the nice people at the villages with a "Hey there! Im a padawn Haxor, I would love to learn how to <INSERT SKILL HERE> so I could try and defeat this AND!XOR badge console arg challenge thing, i don't have much, but...

  Read more »

• Kickstarter Funding Successful

  Hyr0n • 05/11/2018 at 02:21 • 0 comments

  It's been a month since we launched and crowdfunded our DC26 project on Kickstarter. W00t!  It was later than last year, so the HaD page being kicked off is happening a bit later, but that's okay :) 

  So to sum up what we've been working on? Refining the badge-craft, a different take on blinky layout, as well as better silkscreen art from our friend Doc and a western theme. Based on feedback from folks, were upgrading (and completely rewriting) BOTNET from the ground up to be different. Single player games will be on the badge for line con, and a multitude of badge hacking puzzles for your weekend challenge. We are also supporting the #Defcon 26 Shitty Add-Ons interface as well as adding in some secret lulz and hacks for a surprise at the con.

  Aside from that...from DC25 until now, we were lucky enough to speak at the Hackaday SuperCon about our thoughts on the engineering process behind making badges and MacroFab had us on their podcast when we went to their fab site in Houston and saw our prototypes being made.

  More technical details coming shortly, were getting ready to lock down the functions this month, so in the mean time watch that youtube video and listen to the MEP! 

View all 5 project logs