VeriFind AuthentiCache: An overly-complicated approach to geocaching. (sorry, I know the pictures suck!) by J. Aaron Holmes, N7OE Welcome, visitor .   Spring has sprung, and you know what that means, right?  ...  Wrong.  It means it's time for all you GPS lubbers to dust off your GPS units and start seeking geocaches!  But this year, you might find some purely virtual plunder among the cat-shaped erasers, key chains, and miniature troll dolls.  But first, some background: Background My friend Leo and I got started geocaching in the summer of 2005.  The puzzle aspects amused me, as did the opportunity to play with technology while getting some exercise ;-)  After finding a few caches, we started thinking about where/how to hide our own.  While discussing this, an interesting thought occurred:  What if we replaced the usual cache of unwanted junk with a cache containing some kind of unusual artifact?  Rather than taking it from the cache, finders would jot down some properties of this artifact, and these could be used later to verify that the finder really did find the cache.  Better still, the right choice of artifact might permit unique identification of finders. Artifacts A tablet of sticky-note-sized paper pre-printed with codes would work, but didn't seem nearly "cool" enough.  One of my first thoughts was that this artifact might be a polyhedron covered with letters.  Instructions in the cache might tell the finder to pick a face and write down the letter, then write down four more letters such that each came from a face adjacent to the face from which the previous letter was taken (does that make any sense?).  Thus, finders would depart with a five-letter "word" which, given a computer model of the object, could be verified (e.g., by a web page).  I still like this idea and may try to implement it someday, but being a computer nerd, I opted for a computerized solution: Inspired in part by SecurID and other commercial code-generating devices, I set about building my own.  It would generate seemingly random strings of letters, similar in appearance to the CD keys one uses to register Windows.  The cache finder would activate the device, write down the code it spit out, then submit the code for verification later.  The code would be what the finder took with them, as opposed to the usual odd or end. Prototype Putting a microcontroller-based device in a mason jar and burying it in the woods doesn't seem like such a hot idea unless the device is really, really cheap!  Though unusual, theft of entire caches is not unheard of.  So without considering the difficulty of interfacing the parts, I started out by buying the cheapest LCD display and the cheapest 14-pin PIC microcontroller available.  The 16x2-character display (Lumex LCM-S01602xxx), is a mere $5 from DigiKey!  The PIC16F630 MCU costs about a buck.  I had boatloads of '688s in my parts bin, but bought the '630s anyway because I like the idea of using the wimpiest MCU possible for each project, and the '688 has all sorts of extra integrated devices (e.g., USART, ADCs, etc.). I was later relieved to discover that the obscure controller on the Lumex display module is a clone of the well-known Samsung S6A0069 controller.  I immediately located a PIC18 driver for the Samsung part, which took only a few hours to port over to the PIC16F630 (mostly timing fixups and pin reassignments).  The PIC16F630 isn't supported by PIC-C Lite, so it was assembly all the way--my first all-assembly PIC project!  Aaahh!!! Above:  You can see that the device is really little more than a PIC and a display module. How it works Without completely giving it away, here's the gist:  The device contains a number of timers whose states are persisted in non-volatile memory.  The timers keep track of how many times the device has been powered on, how long the device has been powered on, and also seed a pseudorandom number generator.  The timers, together with a checksum, are obfuscated using a rudimentary sort of private key cryptography, then output to the display as three four-letter words.  Fortunately, the use of only just over half the alphabet prevents the occurrence of any obscenities :-) When powered on, the device waits a few seconds, then emits a code (see top of page for an example).  The wait is there to prevent wasting of codes by repeated, rapid use of the device (and power bounce), and also makes it harder to study the output for patterns.  I'm not sure how truly necessary that is, but it seemed like a good idea.  Hard to imagine where the motivation to "hack" such a device will come from, but you never know... Next steps Though I have yet to create a web page to verify the codes, I have produced a standalone C# app for Windows that will do so, and this should be easily converted into a web applet.  As for finalizing the device, I'm in the process of soldering everything to a perf board which will be mounted inside a plastic enclosure with a single large red button (hopefully nobody is scared to press it! :-)) When I have it finalized and ready to hide in a cache, I'll report back with details.  More info soon! --- Questions, comments, etc....?  Feel free to mail me. 73, J. Aaron Holmes, N7OE Page last updated: March 31, 2006. Go back to silicon-arcana.com