R00tz Asylum 2014

I took Ethan to the event run in parallel with DEF CON, R00tz Asylum.  I think he had a blast as they covered a lot of traditional hacker topics at multiple levels of complexity.  The highlights are below.

Structure

The event was held in the Crown Theater at the Rio.  It was about a 10 minute walk from DEF CON proper.  The separation was nice as it made for a more quiet and contained experience.  The stage was occupied by a speaker almost all the time.  Spread around the perimeter (mezzanine?) were tables with activities that changed every day.  Kids could choose to listen, play or work on challenges.  Most activities stayed the entire day, though some were more transient.

This setup was advantageous for my son.  He has little ability to focus on any one thing for an extended period of time, so the variety of activities was nice.  Much like its parent conference, R00tz Asylum did well when it focused on hands-on learning.  Toool, Google and Wickr held contests and learning opportunities that pushed attendees and their parents to participate together.  In particular, Ethan loved the puzzles, and I finally got him to solder something.  He did a bang-up job.

Speakers

The speaker experience was less than optimal with a few notable exceptions.  The stand-outs were Gene Bransfield's hilarious "Weaponizing your Pets" and Meredith Patterson's engaging activity "The Telephone Game" about Man-in-the-Middle attacks.  Special mention goes to @muffenboy and Esau Kang for being kid attendees and speakers.  For the rest, it would be good to learn that speaking to children is not the same as speaking to hackers, and most talks were too technical, lacked a hands-on component, and thus ended up being torture for the little ones.  From speaking with the organizers, I can tell this is something they are trying to focus on next year.

The Gift

R00tz Asylum is the opposite of DEF CON in one respect: it relies on sponsors to add pizzazz and to make ends meet.  One of those traditions that may or may not hold in coming years is the gift of a hackable piece of technology to attendees.  This year brought ASUS Chromebooks care of Google.  My son was enthralled, and I spent most of the conference convincing him to get off the Chromebook and out to the activities.  By the end of the conference, we had Linux in addition to Chrome, and we were running Wireshark thanks to perseverance by Joe and Chris, a father/son team.  This effort won Chris a trophy, even.  My son begged me to put Minecraft on there, but then quickly forgot how to get back to it and reformatted his Chromebook undoing all our hard work.  Hats off to Google, and congrats to Chris on the win.

Hardware Hacking

By far, my favorite part of the conference was the Hardware Hacking table.  Not only did the goodie bag include a HakTeam Throwing Star LAN Tap, but a table full of old equipment was available from which attendees could rip apart and salvage components.  The LAN Taps were used in an activity that taught wireshark and packet sniffing.  The hardware component salvage table was exploited for speakers, LEDs, gears and motors for all sorts of toys.  I am definitely bringing projects for Ethan next year.  I already recommended the salvage table to the official DEF CON Hardware Hacking Village.  Las Vegas thrift shops may see a run on their printers, VCRs and routers before next year's conference.

Lock picking

The one talk and table I was surprised that Ethan was interested in was from Toool.  Their interactive 101 talk caught his attention, and we worked on a lock at their companion activity table.  Though he ended up losing interest before successfully opening a lock, it gave me a clue of the type of activity he could do on his own between conferences.

Going Forward

I would definitely recommend any hacker parent to bring their child to R00tz Asylum.  Its expanding and evolving to be a great summer camp weekend that dovetails with the DEF CON experience.  As the organizers ger more experienced, I expect the content to grow and change to fit the kids and their interests.  We all started somewhere, and I hope R00tz is that start for the next generation.  I started a subreddit for R00tz, though it hasn't taken off.

As for Ethan and I, we are preparing a talk on how to hack Skylanders figures.  We hope it will be a fun combination of encryption, hardware hacking and games that will draw the attention of attendees and inspire them to really dig in and explore the technology that is used around them every day.

Resources to Check for Dead Links on a Website

http://www.brokenlinkcheck.com/
This external service hits your site and follows each link.  It is intelligent enough to check for loops.  Since it is an external service, it may artificially drive up hit count.


Check My Links Chrome Extension
This very handy chrome extension checks link status and places the results in-line.  Fairly turn-key, it even keeps a list of links to not follow that you can add to as you go along.  It seems to have trouble with blogspot controls and extensions, though adding them to the blacklist might be the solution.

Xenu's Link Sleuth
Heard about this one on UTest.  I am eager to try it out.  Free, long history, and automatable: all the right pieces for success.

Add more as you find them to the comments.

StarWest 2014

I viewed StarWest's Virtual Conference offering again.  This and the affiliated Better Software conference are run by Techwell.  A few observations.

1. I loved the talk on Healthcare.gov given by Ben Simo (@QualityFrog).  He communicates how easy it would have been to predict, find and fix the problems that would plague that site for more than a year.  It was a good choice putting him on keynote.
2. To attend one of these conferences will run you or your company into the thousands of dollars.  Attending the tutorials is even more.  This in spite of being sponsored by some of the biggest software providers in the industry.  We are bombarded by ads for the latest ALM or bug tracking tool and they are called talks.  What is such sponsorship getting the attendees?  Who is benefiting from this other than the organizers?  If the conference organizers were a not-for-profit, would they charge the same amount?
3. The online offering tries to simulate the networking opportunities for those who could not attend.  It tries to simulate the marketing side too by giving attendees contact info to vendors.  What about the testing opportunities?  With more than half the talks about web app testing, why aren't tutorial sites and learning apps available and promoted to virtual attendees?

Maybe DEF CON has spoiled me.  $200 for the most frenetic hands-on conference over twice the number of days?  A lot of that is a labor of love and volunteers, but then again most of it is also not sponsored by corporations too.  Maybe I need to bring DEF CON to testers, or testers to DEF CON.  See what shakes out.

Cards Against Mormonism

My brother and I grew up Mormon, but we no longer identify as such.  Nevertheless, the culture is unique, and there are many opportunities for squick, in-jokes and dark humor.  So, like everyone and their mothers, we decided to roll some of those up into an unofficial Cards Against Humanity expansion: Cards Against Mormonism.  A reminder: you may not get some of the jokes if you have never been Mormon, lived in Utah or or are otherwise considered a Gentile.  However, we took great pains to limit the amount of Utah-specific jokes.

The cards themselves were brainstormed under the influence of alcohol and put through the refiner's fire until about 100 unique cards (33 Black and 80 White) emerged.  Once the list was solid, we copied it into the brilliant Cards Against Humanity custom card batch processor.  It worked flawlessly the first time marking Pick 2's and adjusting fonts as needed.  This spat out two PDFs perfect for printing your own Mormon expansion to Cards Against Humanity.

This set is formatted to match the free print-and-play PDF still available on the CAH Website.  Like that set, it is shared under a Creative Commons BY-NC-SA 2.0 license.  You can see the original doc with those that did and didn't make it in Google Docs if you want to try your own hand at it and bring some apostasy to game night.

Sincerely,
DuncanYoudaho and FannyAlgersAbortion

Download Links:
White Cards
Black Cards

Test Early, Test Often

Of late, I have been enamored of testing techniques that come earlier and earlier in the development cycle. It can be called static analysis, design auditing, prospective testing, shift -left or the like, but the research is in: testing before you get something bears fruit in most organizations.  Here I present a few examples from my own experience.

At the start of a sprint, we leave Sprint Planning with the requirements.  The next interaction with developers is when we review their Developer Design Overview document that spells out the development approach and helps QA scope their testing effort.  This developer had chosen to put an error message into a file usually reserved for configuration.  QA saw the DDO and raised concerns immediately.  Why was a message being added to this file when they were usually reserved for the language DB?  With this one question, before QA saw the code, we changed the trajectory of development.  The fix was in before we got our first build, and the story closed with the Sprint instead of carrying over with the do-over.

An even earlier example came when we looked to implement secure communications between two servers.  While I couldn't code my own implementation, I was able to provide recommendations at design-time by staying educated and confirming my understanding with developers who had dealt with crypto.  By starting early, we were on surer footing when troubleshooting and confirming the implementation was sound.

As the examples above illustrate, QA often saves time for developers by defending standards and consistent implementation early in the cycle, but that is not the only savings that comes from shifting left.  Often, test environment issues can also be aided by an early understanding of requirements.  In one case, as story had carried over from a previous sprint which meant we were already behind.  The roadblock was a production issue pulling the developer away from the story.  Instead of sitting on our laurels, QA worked with the configuration manager to make sure our test environments were ship shape before the code was completed.  When the developer's changes passed build verification, we were off and running almost instantly.  Not only did our preparation help us get to the work of testing faster, but it also helped us close more stories as environments were made ready before they could become an obstacle. Not only was I able to test early, but it lead to me testing more and in greater depth.

Most modern test engineers have their own war stories from early testing.  For every story where requirements changed and early notes became meaningless, there are ten stories where early questions lead to greater clarity, fewer bugs, and more time for digging in.  I consider projects that foster this early access for QA to be among the most fruitful and least volatile.

RadioShack LED Strip Driver

I modified the Pololu RGB LED Strip drivers from version 1.2.0 to support Radio Shack's behind the times model that is 30 LEDs controlled in 3-diode sections.  I had to swap the colors around to match this pinout, and I changed the struct to a class (because why not).

The fix was to physically reorder the declaration of red/gree/blue variables in the struct declaration.  This way, when the information is written to the strip, it is sent in a different (and now correct) order.  You can make the fix yourself by changing the file PololuLedStrip.h:

typedef struct rgb_color  {    

   unsigned char red, green, blue;  

} rgb_color;

becomes:

typedef struct rgb_color  {    

   unsigned char green, blue, red;  

} rgb_color;

And here it is on GitHub: https://github.com/RangerDan/RadioShackTricolorLEDStrip

I should probably talk to Pololu on licensing concerns here.  I found the license from the original driver and copied it into my repo.  I couldn't figure out how to fork this properly, so I just re-uploaded it until I understand git a bit better.

C3BO: Proof of Concept using Timbermanbot Schematic

This post is part of a series about building electro-mechnical PIN-cracking robots, R2B2 and C3BO.



This is a proof of concept for @JustinEngler's C3BO (https://github.com/justinengler/C3BO) using transistor controlled relays. It was prototyped by modifying Blink from the Arduino sample project.

The schematic was obtained from Timbermanbot (https://github.com/vheun/ArduinoPlays...) as seen on Hackaday (http://hackaday.com/2014/07/26/pwning...).

In the video, You'll notice I've replaced the touchpad for your finger with a wire to the headphone jack's ground as the circuit ground. The two pieces of copper tape were no longer sticky enough to stay by themselves, so I am holding them down. They press two and 5 with about 8 key presses per second.