Defeating the SentriLock Realtor Lockbox

It's been a long time since I've done any physical security hacking, but recently I came across an interesting vulnerability almost by chance.

For some time I've had an old SentriLock Realtor lockbox kicking around in the garage. It's the type of thing your real estate agent puts on the door while your house is on the market so other agents can get the key to show your house. I didn't have any way to get it open, so I'd never made any attempt to figure out how it worked. Last year I did a liquid nitrogen demo for a bunch of friends - we spent an evening breaking things and making ice cream. While I was gathering up things to freeze and break, I came across the lockbox. I threw it in the pile, and when we were done shattering carnations and racquetballs, we soaked the lockbox for a couple of minutes and attacked it with a sledge hammer. The box held up reasonably well, but a solid blow to the key compartment door shattered it.

The unit sat on a table for about a year, and recently I saw it there and realized that with the compartment open, the only thing holding it closed was a pair of screws. I took them out with my Leatherman and opened it up.

(Pictures to follow later, I left the unit in the shop and I'm blogging from home on a dull Sunday night.)

There's a single circuit board in the unit with the contacts for a rubber keypad on one side and components on the other. The only actuator is a small gear motor that drives the latch mechanism. This is where I noticed a design flaw.

The motor's leads connect to the PCB near the '1' button on the keypad, and the pads are exposed on the keypad side. The keypad itself is soft silicone rubber, and the PCB is separated from the front of the housing by the thickness of the silicone sheet. Therein lies the problem: If you rip off the '1' button (or the do-not-disturb indicator) you can stick a couple of angled probes (I used curved tweezers) into the hole and inject a voltage directly to the latch motor. With properly constructed probes, you could probably do this by piercing the keypad and not have to damage it significantly. As it is, you could easily stick the button back on with some silicone adhesive around the edges and very likely avoid detection.

My unit was pretty significantly damaged by the beating it took from the sledge hammer, so I can't do a proper demo here. If anyone happens to have an undamaged unit they'd like to contribute, I'd be happy to give it a shot.

I emailed the company to inform them of my discovery, and to my surprise I received a response from the founder and CEO, Scott Fisher, within an hour. He stated that the model I've got hasn't been made in a few years, and that there have been improvements since then. Based on the white paper for their new model, it sounds like they're meeting significantly more stringent security standards these days.

The chances of anyone using this flaw to break into a house are pretty slim, especially when a rock through a window will accomplish the same thing. What's most interesting to me is the gap in their analysis of the threat space that this vulnerability would imply. The mechanical construction of the lockbox seems to be more than adequate - I'd certainly have had a lot of trouble forcing it by less violent means than I used, especially if it was still hanging on a door. And presumably the smart card system has a reasonable degree of security (though this is something I'd also like to check out if I had time), but it's like they didn't anticipate a direct electrical attack on the PCB. Simply relocating the motor leads would have made it considerably more difficult to exploit - there could still be other interesting traces accessible through the keypad openings, but they'd take considerably more precision to tap into.

It also seems likely that it was an economic decision that led to the flaw. Using a single PCB to handle both the control functions and the keypad undoubtedly reduced component costs, mechanical complexity, and assembly time, but compromised the design in a way that would not be tolerated in something like an electronic safe or an alarm system.

In fact, next time I'll cover the cheap Chinese safe I just got on eBay - and how they got the keypad separation right, but still managed to leave the safe vulnerable to a simple, non-invasive attack that lets an unskilled intruder open it in seconds without any tools. It's simultaneously an interesting flaw and kind of a bummer, since I'd intended to actually keep stuff in the safe.

Update (5/9/2011): Scott Fisher at SentriLock says my approach won't work with an undamaged unit, but declined to elaborate. If anyone has one that hasn't been beaten on with a sledge hammer and frozen to -320 F, let me know and we can see if he's right.

Black Rock City Navigator

Black Rock City 2010 Satellite Image

For those not familiar with Burning Man, the week-long festival is held on a dry lake bed in Nevada's Black Rock Desert. The ephemeral Black Rock City, temporary home to more than 50,000 people, is shaped like a giant 'C' and features a network of streets arranged in a polar grid. While navigation is usually simple -- provided the navigator is sufficiently sober to read and comprehend street signs -- blowing dust can create frequent white-out conditions with near-zero visibility, and all of the street signs are traditionally swiped as souvenirs toward the end of the event.

While the fine folks at Burning Man Earth do an excellent job mapping the city each year and can provide maps for hand-held GPS receivers and smart phones, I decided that I wanted to build something more unique and specialized for navigating at my first Burn.

In the customary manner of many Burning Man projects, this started out as a grand concept involving a lot of blinking lights and machined brass, and ended as something considerably less grand and more rushed, but surprisingly functional nonetheless.

My initial idea for a ‘golden compass’ style device turned out to be a bit beyond my machining skills – or at least my time-management skills. Instead, I chose a 4” black sewer pipe end cap as the housing for the navigator. I did apply some green metallic star stickers, though, which I think really added something.


The size meant it wouldn’t be suitable for carrying in a pocket or on my wrist, but it would fit on my bicycle handlebars just fine. I even found a ball and socket swivel with a quick-release that worked beautifully for this purpose. I’m still not certain why I had a box of swivel mounts in my shop – most likely Electronic Goldmine had a sale on them a few years ago – but sometimes my pack rat nature pays off.

The next challenge was the display. I considered a cross-needle meter, but they're hard to find, and would be hard to see in the dark. I also thought about a persistence-of-vision display with a rotating LED array, but not having dealt with slip rings before, I wasn't sure I could get rotating contacts to work right on the first try. I looked at a few other options and decided on a linear array of LEDs rotated by an R/C servo, underneath an engraved acrylic map of the city. The servo would move the array into the proper position and a single LED would light to indicate the user's location.

I'd never used servos before and I'm not great with mechanical design, so I was a little worried about that part. I had a few servos kicking around in the shop, so I plugged one in and started experimenting. They turned out to be easier than I expected to work with, but I quickly discovered a flaw in my plan: the servos only had about 170 degrees of travel, and I needed to cover at least 240 degrees on the semicircular city map.

I decided against trying to modify a servo (or rather, I broke one in the attempt and decided it wasn't worth the trouble) and didn't want to use an expensive sail winch type, so instead I made the pointer board with two LED arrays at a 90-degree angle. By selecting one array or the other, I could move the pointer LED across 280 degrees.

Electrically, I kept the design about as simple as I could. The main board has a Freescale MC9S08AW32 microcontroller, voltage regulator, and hookups for the pointer board, GPS receiver, and servo. The pointer board has another MC9S08AW32 and two arrays of 32 super-bright green LEDs. The MCU on the pointer board simply turns on and off LEDs in response to serial commands from the main MCU. I'd considered a few designs with specialized demultiplexer/driver parts, but realized there wasn't much point when I had a tray full of suitable MCUs on hand (costing somewhere under $4 each), and the slave software would only take a few minutes to write.

Disassembled

The software for the main board mostly reused bits and pieces that I'd written for other projects. The NMEA 0183 parser for the GPS receiver data and the routines to calculate distance and bearing were the most important of these. These were swiped straight from my Tracker2 source code, which is GPL'd and available at www.argentdata.com/community. I tweaked the distance calculation (a rough approximation since the Tracker2 doesn't need exact distances) for minimum error at the latitude of Black Rock City, but left the rest unmodified. Everything else was fairly simple logic to glue it all together, move the servo, and select an LED to turn on.

The best map I could find of the city was in PDF format, so I imported it into Photoshop, cleaned it up a bit, and exported it to the Dr Engrave program that came with my MDX-20 milling machine. Of the fluorescent acrylic sheets I had on hand, orange and green seemed to work best. I chose green to match the LEDs and my bicycle. Getting good engraving results took some experimentation with tools and settings, but I only wasted a few 6"x6" acrylic sheets before I got it right. For the depth I needed, a 1/32" end mill did a better job than a 60-degree engraving bit, and I found that engraving the back side worked better than engraving the front.


I wasn't quite sure how I was going to mount the servo, so I started by cutting a disc from 1/16" black G-10 Garolite - basically printed circuit board material without the copper. I did this part early on and made a cutout for the small servo I was using, but broke that servo and had to use a larger one that wouldn't fit the hole. I'd intended to use standoffs to mount the disc to another disc, or to the bottom of the housing, but somewhere along the line I discovered that it fit snugly at the bottom of the end cap and that I could hot-glue the larger servo directly to it. This turned out to be good enough, and actually made it easier to align everything later on.

Note the complete lack of use of the mounting holes

The build process took an evening or two of design and PCB layout work and most of a weekend of building, coding, and testing. With the exception of the green LEDs (the ones I had weren't bright enough), the PCBs, and, of all things, a simple toggle switch (why didn't I have any of those?), all of the parts and materials were already available in the shop.

Some final tweaking was done in the RV on the drive to Nevada. Of particular concern was the need to get the servo and map disc aligned. To this end I wrote a self-test sequence that would rotate the pointer to the leftmost road, wait a couple of seconds, and then rotate to the rightmost road, all while cycling through all of the LEDs on both arrays. This made for a nice start-up demo and let me easily adjust the disc to match the servo.

Finished display in operation

Calibration of the map requires three elements: the map center coordinates, the compass angle of the first street, and the scale of the map. The first I got from Haggis at Burning Man Earth and was well-known in advance since the entire city is laid out around a marker spike driven at that point. The second wasn’t explicitly stated on the map I had, but I made an educated guess. The last was the least certain, but again I made a guess and got it pretty close. I refined my guesses using readings from a handheld GPS receiver once I was on the playa.

The indicated position was still off a bit in some parts of the city and I never had the time to track down the source of the error (perhaps some non-linearity in the servo’s response?) but everywhere it was within half a block, good enough for basic navigation. If I’d had time to add the planned LCD character display it would have been easier to debug.

Responses to the gadget ranged from the jaded but polite (“Is that a playa compass? Cool.”) to the… ah, ecstatic (“Ohmygod that is so &%@#ing AWESOME! YES! Can I take a picture? I LOVE it!”)

Ooh... shiny!

The source code is full of unfinished and unused junk and the board layouts were quick and dirty, but both are available here (C source for CodeWarrior, schematic and board layout in Eagle PCB). I've also got several extra sets of boards on hand - I don't want money for them, but I'll consider on-playa trades for food, shiny objects, or what have you at Burning Man this year!

Parts sources:

Digi-Key for processors, LEDs, and such
Strike Models for servos
Delvie's Plastics for fluorescent cast acrylic
McMaster-Carr for Garolite sheet, screws, and end mills
Argent Data Systems (i.e., from my own warehouse) for the GPS receiver
Orchard Supply Hardware for the ABS sewer pipe cap

Eye photo courtesy of Flickr user Monkey Boson (CC-attribution license)

SugarSync disaster

It's not often that I have such a bad experience with a product or service that I feel like I need to write about it, but I'm downright angry with SugarSync. I set up this service several months ago to keep files (source code, business documents, and reference materials mostly) in sync between my home desktop, office desktop, workbench, and laptop. It seemed to be working OK at first, but things got progressively worse as time went on.

Here's the shared folder where I keep my Quickbooks files:

Argent Data Systems (from Jupiter) (Backup Apr 04,2010  06 26 PM).QBB
Argent Data Systems (from Jupiter) (Backup Jun 05,2010  06 40 PM).QBB
Argent Data Systems (from Jupiter) (Backup Mar 01,2010  08 04 PM).QBB
Argent Data Systems (from Jupiter) (from Workbench).QBW
Argent Data Systems (from Jupiter) (from Workbench).QBW.ND
<dir> Argent Data Systems (from Jupiter) - Images
Argent Data Systems (from Jupiter).QBW
Argent Data Systems (from Jupiter).QBW (from Workbench).ND
Argent Data Systems (from Jupiter).QBW.ND
Argent Data Systems (from Jupiter).QBW.TLG
Argent Data Systems.QBW.ND
Argent Data Systems.QBW.TLG

Keep in mind that I only have Quickbooks installed on one machine, so these files have never been opened or locked on another PC. Yet the files show up like they were edited in multiple places at the same time and the service couldn't resolve the conflict.

Much, much worse is what it did to my source code. I'd work on a project, come back a few days later and edit some more, and then find out that when I'd opened it the second time it had synced an old copy from another PC and I was editing that one. I've had to spend a lot of time with a diff utility trying to merge the changes.

Their support is worthless. All I can get out of the SugarSync people is that it's working as designed and making duplicates of locked files. Yet somehow it also manages to do this with files in my music collection that haven't been edited since 1997. It's also truncated photo files and made them unusable immediately after they were synced.

It looks like I essentially paid $99 to have an application trash my files in insidious ways. Avoid this service. I still need file sync, so I'm going to look into Dropbox or another competitor, but I'm very unhappy with how this turned out.

Cuyama Balloon Launch

Just got back from a very successful high-altitude balloon launch. The original intent was just to prove some hardware and software modifications prior to a bigger upcoming launch, but at the last minute I decided to fly a camcorder in addition to the tracker payload. I put together a housing for the camera yesterday in about 10 minutes, milling out a chunk of foam on the MDX-20 and taping on a piece of scrap polycarbonate for a window.

The kids and I left home around 6:15 this morning and set up in a field by Cuyama Elementary around 7:30. We had some ground equipment hiccups - my netbook (normally good for 4-5 hours on one charge) was totally dead, for starters. Apparently either the serial adapter or the USB GPS receiver I'd plugged in the night before had kept it from hibernating properly. My TH-D7 also refused to turn on, despite having been on the charger all night.

The nuvi 350 and Tracker2 combination was working just fine, though - the only deficiency being that I hadn't set it up to be able to see the balloon's altitude. The D7 provided that, so long as it was plugged in to the car, so it wasn't a major problem.

Launch was at 7:45 in very light winds. It was immediately clear that the balloon was rising more slowly than planned - I think I miscalculated when setting up my calibration weight. The ascent rate was about 400 feet/minute rather than the planned 1000 feet/minute. This pretty much threw my predictions flight path predictions out the window. We drove out to Mettler anyway and stopped there to see what it would do.

When it looked like the balloon was going to keep heading east at 50+ MPH, I decided to take 138 out to 14 and hope that it'd make it over the mountains. Before I made it to 14, though, the balloon turned completely around and headed west again. We circled all the way up to 58 and were somewhere between Tehachapi and Arvin when the balloon burst. Bill Brown, WB8ELK, called me at about this point to provide his landing prediction.

Rod, WB9KMO, had joined in the chase not long after the launch and was first to the landing area - which turned out to be only a few miles from where we'd stopped in Mettler. We met up with him about a mile from the last APRS fix, and followed that to within 1/4 mile of the landing site. I got about 50 yards from the car before I spotted the foam payload housings and the remains of the balloon in a plowed field.

Everything was intact, and I got about 2 hours of video from the Flip camera. Not enough to capture the burst and impact, unfortunately, and it spins about as much as I'd expected, but for a 10-minute job I can't really complain.

The maximum altitude reached was 113,876 feet - not too bad for an 800-gram balloon. Payload weight was about 350 grams, most of which was the camera. The lowest recorded internal temperature was -19 Celsius, and the lowest pressure was 381 Pascals. Total flight duration was about 3 hours 20 minutes.

This whole thing involved rather more driving than I was expecting, but I'm very satisfied with the results. The updated tracker firmware performed flawlessly, the GPS receiver worked as expected at high altitude, it withstood very cold temperatures over a much longer than expected flight, and the lighter, less tangle-prone 16" rubber duck antenna proved to be more than adequate, even at 500 mW.

Video to follow shortly.

Balloon Launch

Just launched a new balloon payload this morning. As I write, it's headed for Point Arguello at 16,000 feet. More info here later. Above is what the payload looked like the other day during testing.

http://aprs.fi/?call=N1VG-11

The payload is a custom board with an OpenTracker+ RT series tracker, temperature and barometric pressure sensor, SRB MX146LV transmitter, two CR123A batteries, a USB interface for configuration, and a Prolific GPS receiver (not the one pictured here). It's all sealed in 2" heat shrink tubing. The temperature just reached 1C, hopefully it'll stay warm enough.

Standalone MON08 Device Programmer

Abraham Lincoln once said, "Give me six hours to chop down a tree and I will spend the first four sharpening the axe." In that spirit, I spend a lot of time building and refining the tools I use. So far, I've never regretted a minute of that effort, regardless of how much of a pain it was at the time.

My packing bench automation system is probably the best example of that, and I'll devote a post to it some other time, after I've added a few more of the features I've got on my list. But here's what I've been working on for a good portion of the past week:

It's a prototype of a standalone device programmer for Freescale HC08 microcontrollers, like those used in the OpenTracker+ and Tracker2. It's shown here with anMC908JL16 processor for the OT1+, which is presently the only thing it's set up to work with.

The hardware required to connect to an HC08 is actually very simple. I built my first programmer (way back before the OpenTracker 1) with parts I found in my junk box. I later upgraded to a board I bought from an outfit in the Czech Republic, and eventually to a USB pod from P&E Micro, of which I now have roughly a double handful thanks to package deals on development kits, freebies from Freescale, seminar handouts, and so on.

But all of those have required the use of P&E's programming software. Fortunately it's available for free, but they don't make it easy to find, and more importantly, they don't want you using it for automated production programming. For that, you'll need one of their $500 or $900 gadgets, or a nicer ($1200 + programming algorithms) system from one of their competitors.

I've never bothered, because with some creative use of a keyboard and mouse scripting tool I've been able to reduce the programming process to a single keystroke. Programming takes 30 or 40 seconds, much of which is avoidable overhead caused by P&E's software. It's a good job for a temp, and when the kids are out of school for the summer I can put them to work building up a stockpile of programmed MCUs.

Still, it's far from perfect. It could be much faster, and on occasion it'll choke and require some attention from a trained operator to get going again. More importantly, it requires a PC and it isn't something I can easily send off to a contract manufacturer. I'm making a major effort right now to reduce all of the post-assembly programming and testing operations to automated, standalone processes that can be easily run by anyone with minimal training - i.e., put the board in the programming fixture, press a button, and get a pass/fail result and maybe a test result printout on receipt tape.

Since I really need several of these things, and the $500 units aren't exactly what I want anyway, I decided to spend some time doing it myself. It's meant a few days at my workbench muttering and cursing - the programming process requires having the target processor boot a built-in program in ROM, then communicating with that program to load another program into RAM (which I had to write), starting that second program, and then communicating with it to actually do the erasing, programming, and verifying. And the one I/O pin you're guaranteed to have access to is not connected to any serial hardware, so it's all bit-banged. That tiny program, roughly 200 bytes, required several hours of coding and debugging. But the worst is over, and it's up and running now.

The unit shown above programs and verifies an OT1+ MCU in roughly 8 seconds. Pop the MCU in the socket, hit the button, and wait for the 'done' message. Lather, rinse, and repeat. P&E's "high speed" algorithm takes 20 seconds just to do the program and verify operation, not counting algorithm loading and user interface overhead. I haven't put any real effort into speeding up the process yet, but I think I can cut it down to 4 or 5 seconds without much trouble.

The code is still immature and doesn't elegantly handle error conditions (it just stops and displays a message, with no automatic retries or anything) but I've already added one useful feature I haven't seen elsewhere - it automatically detects when you've removed the target MCU, so it can clear the 'done' message and avoid any possible confusion when the operator gets distracted and forgets whether the chip in the socket is really done or if they just haven't pressed the button yet.

Total cash outlay for this prototype was roughly $10, including the perfboard (I hate FR-2, but the FR-4 perfboards were $30 and weren't the right size), button, ribbon cable, and connectors. Everything else I already had on hand. The green PCB is an AW-PROTO board, one of several dozen I had made for in-house prototyping of circuits build around the MC9S08AW series MCUs. I've got a big pile of those 16x2 backlit LCD modules, probably from when Electronic Goldmine or someone had a clearance sale. I actually got it mounted upside down, but I decided it doesn't really matter which way the board faces.

When the device is more mature, I may offer it as a commercial product. Might not be worth the effort required to document and support it, though. But in any case, I ought to be able to distribute a few to my overseas resellers to handle re-flashing of corrupted OT1+ and Tracker2 processors, and I'm looking forward to integrating it with the new automated OT2m test fixture that's in the works now.

OT2m Version 2.0

Pictured above is the first hand-assembled OT2m prototype with the new version 2.0 PCB. It's working well, but I think I'm going to make one or two small tweaks before it enters production.

The most obvious difference between version 2.0 and version 1.0 is that the demodulator is a CML Micro MX614 instead of the NJM2211 from NJR. Getting consistently good performance from the 2211 has been a pain. The switch to the MX614 is going to mean a cost increase of at least a few bucks, but I think it'll be worth it for the improved RX performance and decreased testing and tuning burden.

Less obvious is the addition of ESD suppressors on all external connections. I have yet to attack it with my ESD zapper, but it should be considerably more resistant to static discharge than the previous version. I won't guarantee that it'll survive a nuclear EMP, but it should tolerate some rough handling. The ESD suppressors also introduce some capacitance that should help improve RFI immunity, though that's never really been a problem with the 1.0 board and its existing inductive filtering.

The power supply section's be rearranged a bit and has proper reverse-bias protection now, that also protects the VN920 solid state relay - correcting an oversight in the last version that resulted in a couple of accidental magic smoke releases. D11 is undersized in this picture because I forgot to order the proper part.

The solder jumper SJ1 is there to bypass the reverse bias protection. This is in case you want to power the unit through the high-current pads and still want the supply voltage measurement to work.

What you can't see under that pretty black solder mask is that the board routing has been completely redone, mostly by hand. Eagle PCB's new follow-me router makes it much easier to lay out traces manually and resulted in a better arrangement of components, especially in the sensitive audio input section. The most critical traces are 14 mils wide there (version 1.0 was mostly 8 mil traces) and only a few of the shorter traces are under 10 mils anywhere.

This batch of boards was also made with twice as much copper - 2 oz per square foot, versus 1 oz for the version 1.0 production boards. This means more power handling capability in the solid state relay section in particular. The prototypes were done with a lead-free HASL finish, but I've had the production boards quoted with electroless nickel / immersion gold like the OT1+ boards.

The only other real change in this version is that the (never used) FRAM expansion has been removed, and those four I/O lines have been rerouted to the MON08 header at the front of the board. This should make it easier to wire up a keypad to go with an LCD display if I can ever find the time to finish the coding for the user interface.

Absolutely no firmware changes are required for the new board. Transmit audio is still generated by the processor, not the modem IC so it's still capable of 300 baud or PSK31 output. There's also some extra filtering on the audio output.

Decode performance is quite satisfactory. With the WA8LMF Track 2 test, it decodes 987 packets. The best I've heard reported for any other TNC is 970 for the uTNT. My KPC-3 scored 967. The highest ever recorded, to my knowledge, was 991 for an early Tracker2 connected to the output of the same KPC-3's TCM3105 chip. I'd have considered the TCM3105 for the new T2 board, but they've been discontinued for years.

It looks like the OT2m is going to be out of stock for a little while. The existing stock is enough for maybe two weeks at this rate, and it's going to take at least twice that long to finish testing the new board, make some minor tweaks, source all of the new parts, and get production started - which means new pick and place programming and a new solder stencil. I think six to eight weeks is more realistic.

I'm also going to have to have more enclosures produced, which doesn't usually take that long, but I've been a little unhappy with the consistency of the last batch or two from my current supplier. I've got a small pile of case pieces that just won't fit with the others. It wastes parts, and wastes time when you get an out-of-spec cover or end panel and have to disassemble it again.