Dan Griffin's Blog

Comments on security, PKI, smart cards, cryptography, and entrepreneurship.

Now all of the project landing pages for the Samples 2009 group on CodePlex have nice “inline” screenshots. That way, if you’re looking for reusable XAML, you know what you can get from these projects. Here are the five project URLs:

Permalink | Comments (0)

Because it’s done! Check out its CodePlex project site for updated demo binaries, source code, and the whitepaper.

Permalink | Comments (0)

… has been checked into its CodePlex site. Also new are built binaries for the IP Geocoding sensor driver, so you don’t have to download the Windows 7 DDK, and an updated dev spec draft with screenshots.

Especially notable in the final version is its use of the Virtual Earth 3D control. Install the driver and run LLJ on an internet-connected Win 7 machine - it’s pretty cool.

Permalink | Comments (0)

The above has now been posted to its CodePlex page. Feedback is welcome, either via this blog or via the CodePlex Discussions forum for this project.

Permalink | Comments (0)

In researching and developing the Laptop LoJack prototype (see blog thread and Codeplex page), I encountered a few gotchas. For posterity:

First, some kudos. The Windows 7 Location Platform sensor driver model uses the User Mode Driver Framework (UMDF). Like any technology, UMDF has a learning curve, and I wasn’t totally over it before I started this project (I’d experimented with some of it previously). That said, UMDF is one of the most important Windows technologies of the past several years: anything that doesn’t have to be in the kernel, shouldn’t be. That’s important for: reliability, security, and time-to-market for IHVs and ISVs who may now be able to avoid the extra cost of kernel-mode development.

The Win 7 Beta DDK (which I believe is unfortunately only available to premium MSDN subscribers right now) includes a sample sensor driver. The second kudos goes to the Microsoft location platform team for the documentation that they included with that driver code, specifically on how to customize it (i.e., how to take the sample and turn it into something real). If every product team at Microsoft included that kind of documentation with their samples (assuming they actually provide those, of course) the company’s dominance would be assured for many years to come …

Second point: as I described in the previous post on this topic, I customized the sample sensor to turn it into the IP geocoding sensor required for Laptop LoJack. I then used the devcon.exe tool (from the DDK, but looks like you can download it separately too) to install the driver. First mistake: I didn’t realize that the WDF helper dlls (e.g., WdfCoInstaller01009.dll), from the DDK redist sub-directory, were required in order for the installation to succeed. Frankly, the error message from devcon.exe is useless. Second mistake: I grabbed the wrong WDF dlls, thinking that I wanted the *_chk versions, since I was installing chk driver binaries.

You can avoid both of those mistakes by noticing which install helper binaries are referenced by the driver INF produced by build.exe.

Third point: Inf2Cat.exe is another useful DDK tool. If your building a driver (even UMDF) that’s going to actually be deployed somewhere, then you should be signing it to avoid the nasty prompt. But building your own CAT file is a pain, which is why Inf2Cat.exe is quite useful. However, remember that the CAT file needs to reference all of the files that are referenced by the INF. Thus, like devcon.exe, Inf2Cat.exe also needs to be able to find the WDF helper dlls. A build script would be the way to go here: copy the necessary files to a temporary location in order to build the CAT, then clean up duplicate files.

Fifth point: once the sensor driver is installed, it needs to be enabled via the Location Platform control panel applet. You can find that by typing “location” into the search field on the Start menu. The Laptop LoJack scenario would actually call for this sensor to be enabled by default, since it’s expected to be a managed laptop and the user shouldn’t be able to disable the sensor in this case. Hopefully, this is just a regkey that we can set via the installer. In fact, there’s a second problem here, which is that, even after the sensor is enabled, there’s a separate prompt asking the user for permission to expose data from that sensor. That strikes me as overkill, even for an un-managed deployment scenario. Again, hopefully there’s a registry override.

Sixth point: once I got this far, my driver still wouldn’t load with the test program (included with Laptop LoJack code; it’s just an adaptation of a Location Platform sample included with the SDK). I had an easy guess why, though. I had disabled these two “GPS sensor type” location properties,

SENSOR_DATA_TYPE_ALTITUDE_SEALEVEL_METERS
SENSOR_DATA_TYPE_ERROR_RADIUS_METERS

since I only have data for latitude and longitude. Turns out those are required. I re-enabled them, and just return hard-coded values for now, and the driver works fine. A better way to handle that? A future version of the driver could take the returned lat & long values and look-up the altitude for that location. Error radius is still problematic, though, since as I mentioned in a previous post, IP geolocation is really a best-guess with regional granularity. I’m guessing it could be off by several hundred miles, unless you live in a city in the northern hemisphere.

Seventh point: I mentioned one potential improvement above in doing a reverse look-up on your altitude. Additional potential improvements:

  1. The current IP geocoding web-lookup code, since it screen-scrapes Live maps, is fragile. Maybe someone has a better idea. However, what it currently does is convenient for two reasons. (A) we don’t have to do a separate “what’s my public IP address” look-up, since that’s implicit. And (B), the string matching logic for the Live page is pretty simple, even in native C. Still, I’d love to improve on this.
  2. There’s currently no caching of latitude and longitude data. That’s partly because the sensor driver makes separate queries for those two items, and I’m not yet confident enough in my knowledge of the UMDF sensor architecture to make a caching recommendation. However, because the relevance of the data is really just city to city, as previously stated, caching the data for an hour or more should be fine (even if you’re in a jet!).
Permalink | Comments (3)

The Laptop LoJack sample will be hosted on Codeplex, here. Actually, I’m having problems connecting to their TFS server this morning, so the initial code will be available later in the day.

What does the sample do? It currently consists of two components. The first is a Windows 7 location sensor driver (based on the User-Mode Driver Framework - no kernel-mode code here). The driver uses your public IP address to determine latitude and longitude coordinates.

What does that mean? It means that this project turns your laptop into a GPS, without having to buy an actual GPS - pretty cool! Not only that, but the GPS capability is exposed in the new “proper, platform-compliant” way, so that any Win 7 applications that are location-aware can use it.

Big disclaimer, though: unless you live in a major city, the granularity is regional at best. Why is that? The trick I use to obtain the coordinates is simple: local search on Microsoft Live Maps. That is, when you connect to the default URL for Live Maps, the returned page includes script goop that supports local search. That goop includes default lat & long for wherever the server thinks you are, based on your IP address. (As an aside, there’s another clue that the server is doing a reverse look-up on you, even before you run an actual search: when the default map loads, notice how it’s centered on your region!)

That process of mapping an IP address to a physical location, known as IP geocoding, is imprecise. In fact, it’s only the big technology providers like Google/Microsoft/Yahoo that can afford to maintain the most up-to-date IP geocoding databases; their incentive to do so is competition for search traffic. Once the Laptop LoJack code is live, I’m hoping to get additional user feedback on how accurate your location data is.

So, the sensor driver for Laptop LoJack is screen-scraping its coordinates from Live Maps. This is not an ideal implementation. For example, if Live changes the names, or even just whitespacing, in the script embedded in that default page, the screen-scraping code will break. Plus, since the sensor is UMDF, I really didn’t want to use the .NET framework in-proc, even though loading and robustly parsing the page might be easier that way in the long run (instead, I used WinHttp and some of the string library routines in the CRT).

That said, the code works, and the concept is cool. Next steps? We need to design and implement a cool (WPF-based) viewer application for the location data. We also need to provide a (WiX-based) MSI for this, because installing the UMDF driver by hand is painful. Stay tuned …

Permalink | Comments (1)

A new sample code project idea has been proposed as part of this series. In summary, the idea is to create a client agent for laptops that periodically phones home with its geographical location. There’d also be management application for viewing the client data, ideally a map showing flags representing each machine.

The client data would be obtained using the Windows 7 Location Platform API. Of course, given that hardly any laptops come equipped with a GPS, we need to write a plug-in that produces that data some other way in order to make the sample more generally accessible. The current proposal is to do this by calling out to one of the various websites that will map the client’s IP address to a geographical region and return a default latitude and longitude for that region.

While I think that would make for a pretty cool sample, there are a couple of drawbacks. First, this being a Windows client demo, the management application needs to be some really sexy WPF. So we need to not spend too much of our budget on the agent and the location sensor plug-in.

Second, I haven’t been able track down a reliable source of IP geocoding that’s packaged as a convenient web interface. Instead, we’d have to screen scrape it, which makes the demo fragile and could shorten its shelf life.

Feedback would be welcome here. Would this make a cool sample despite the potential drawbacks? Is there a better approach?

Permalink | Comments (0)