A Long Story And Short Security Tip For Mobile Developers
I’ve been working on a project that involves developing a custom power on password for Pocket PC. To do this, you build a DLL as a control panel applet and point a registry key at it so that the device will use your DLL instead of the default password applet when it’s powered on (or booted). There are also a few APIs you need to hook into, but I can’t find the whitepaper so you’ll have to trust me.
Anyway, this particular password doesn’t use a text input, so the only way to unlock the OS under the covers is to perform the right series of operations (which is greatly simplified at this point), after which the password DLL will call the underlying APIs to unlock the device. This is actually a neat way to lock the device down—just have your applet never call those underlying APIs to unlock the device and you can limit the user's actions to whatever's in your DLL.
During the dev process, I managed to lock the device with a password I couldn’t recreate from the password applet UI. To get around this, I connected the device via ActiveSync, which let me type in the password by hand. I then used ceregedit to turn off the power on password (there’s a documented key somewhere on MSDN), which disabled the power on password. A soft reboot took out the password protection.
However—and I didn’t understand why at the time—my applet had been copied into the StartUp folder, meaning that it would always be started when the device booted. Since the applet would never be able to be closed (it would never get a successful response from the underlying password APIs) I was in a bind. Fortunately, it was just acting like any other app—after all, it wasn’t given the instructions to guard the front door (since power on password had been turned off). As a result I was still able to use the device because the Start menu and shell were all working, except that I had this annoying dialog I couldn’t minimize, and it didn’t show up as an app you could kill via the Memory pane on the control panel.
So then I tried to delete it from the StartUp folder, but since the module was actively loaded, I couldn’t do anything. At this point I copied down jshell.exe, which is a neat little tool that lets you view and kill processes. From the jshell command line I ran “gi mod” to determine the module that had the DLL (actually, a .CPL) loaded, and was able to track down the process, which can be killed with “kp 22” where 22 was the process ID. After that, I was able to delete the password applet from the StartUp directory.
The moral of this story—if there is one—is to be careful about how you secure devices. For example, if you’re going to lock down a device by using a power on password that never yields (where the login screen is actually the whole app) then don’t give the end users the password or else they can get around the system.
The tools I referred to here are available as part of the Mobile Application Development Toolkit at http://msdn.microsoft.com/mobility/thekit/.