Last time I gave some specific guidance on Dynamic objects, OAuth and HttpWebRequest versus WebClient. This time, I’ve got a hodge podge of different topics for you!
NB: Code presented here is of example quality only. Please don’t cut and paste this code into your solution. Proper error handling, logging and graceful failures are not included.
Remote Debugging (Dev)
You may want to have a remote debugging session with a slate. Since most slates have Windows 7 Home Premium installed, Visual Studio might tell you that it is “not supported on this version of Windows”. To get around this, execute msvsmon using the /noauth and /anyuser flags. Warning: Do this behind a firewall only! “/noauth” means no authentication!
Registry Access (Design, Dev)
You can read and write the registry from a SLOOB, but not all hives are available. If you need to persist or read information out of the registry, the WshShell object hanging off the Windows Script Host (WScript) be used to accomplish this task. Remember, COM Interop requires elevated trust. Here is a code example …
using (dynamic WShell = AutomationFactory.CreateObject("WScript.Shell"))
var reg = WShell.RegRead(@"HKCU\Software\Foo\Bar");
MessageBox.Show("The GUID you wrote is: " + reg);
Unique Device ID & Hiding the Keys (Design)
There is no Unique Device ID for a Windows 7 slate PC. This is a well known issue. Every time Intel tries to solve the problem, they get such bad press that they have to do ridiculous tap dances or they back off completely. It’s best to try and avoid this issue completely. If the need is to roll your own Digital Rights Management, don’t! Use an existing DRM technology like PlayReady. If it does not need to survive an OS re-install, you can use the above approach to write a GUID into the Registry and be done with it.
If you must have a Unique Device ID and you cannot design around it, you can consider using several elements of the hardware through COM Interop using WMI. This is quasi-unique at best and might change over time if hardware is replaced. I advise against it, but here is some code for the truly desperate:
using (dynamic loc = AutomationFactory.CreateObject("WbemScripting.SWbemLocator"))
loc.Security_.ImpersonationLevel = 3;
loc.Security_.AuthenticationLevel = 4;
dynamic IService = loc.ConnectServer(".", @"root\cimv2");
dynamic query = IService.ExecQuery("select * from Win32_Processor");
var procid = query.ItemIndex(0).ProcessorId;
query = IService.ExecQuery("select * from Win32_BaseBoard");
var serial = query.ItemIndex(0).SerialNumber;
Gotcha: Some manufacturers will not put Serial Numbers or ID on their devices, so make sure you take a good cross section of different hardware elements in order to put together your unique representation (i.e. combine IDs and Serial Numbers from 4 or 5 different pieces of hardware and expect some to be null).
There is no access to the DPAPI from a SLOOB. There is no way to completely protect a key without asking either the user or a web service for a secret. This will change in Silverlight 5 as P/Invoke will be available to access the DPAPI.
Gotcha: If you store an authentication token and a key on the Windows 7 slate PC, there is the potential for the user to be impersonated if the PC is compromised. The implications of potential user impersonation should be thought through before an authentication token is stored locally.
That it for the series. I hope you enjoyed it! The Windows 7 slate PCs are cool devices and fun to design and develop for. If you have one, check out the Flickr app!