Tuesday, June 16, 2009

Windows Mobile Local Authentication PlugIn

The Local Authentication Plugin (LAP) is a way to identify the user of a mobile phone, while applications need special rights to access features or perform actions. Basically user is prompted for authentication through a password that he previously configure on his mobile. The default LAP provided by Microsoft (see below), is a single PIN password, but you can implement your own if you need.

LAP Implementation
A LAP is a signed DLL share the following entry points :
  • InitLAP : Call by the system to initialise the LAP while loaded.
  • DeinitLAP : Call while LAP is unloaded
  • VerifyUserStart : Call to start the GUI of the LAP
  • VerifyUser : Call to validate the user, with or without a GUI. This functions returns while the user has been authenticated successfully or fails. Multiple calls to this function can be done by the system. Options parameter specifies how the user have to be validated.
    • VU_NO_UI : while the system needs to validate the user, without displaying a window to the user.
  • VerifyUserStop : Call to destroy the GUI and clean up.
  • VerifyUserToTop : Call to bring to top the LAP Window.
  • LAPCreateEnrollmentConfigDialog : Used to display configuration window to configure the pass-phrase of the LAP

To implement your own LAP you can start from scratch or use the sample LAP provided with the Windows Mobile SDK :
  • for pocket PC : %ProgramFiles%\Windows Mobile 6 SDK\Samples\PocketPC\CPP\win32\LAP
  • for smart phone : %ProgramFiles%\Windows Mobile 6 SDK\Samples\Smartphone\CPP\win32\LAP
LAP Installation
The Local Authentication Subsystem (LASS) is in charge of the management of the LAP display and user validation.
To define a new LAP, add a new key in the registry :

To select the current active LAP set the

LAP Configuration
The LAP Configuration should be done by the user through the Enrollment window accessible form the Parameter Menu using the Lock icon. In this window the user should be able to change its pass-phrase (or other if the LAP is not based on pass-phrase authentication).
For security reason this pass-phrase should not be saved in the registry as a clear string, but should be encrypted using a custom algorithm or the Windows MobileCryptoAPI.

Validate a User in your application
To check if user has been authenticated on the device you have two possibilities :
  • ValidateUser is a blocking call to the LASS service, and give a way to provide parameters to the LAP, like an AE Key (specific security policy id), options (like VU_NO_UI to check the user without prompting any Window). Functions will return only after user authentication.
HWND hMyWindow;

DWORD LastError;
GUID AEKeyForFoo = ...;
if (VerifyUser(&AEKeyForFoo,"App A",hMyWindow,
VU_UNTIL_SUCCESS,0)) // Call into LASS;
// This will
CallSecureFunction() // call into active LAP
// and show LAP-specific UI
// display your own UI

  • SHDeviceLockAndPrompt is a non blocking call, but will require user authentication for any activity on the device.

- Nicolas

Tuesday, June 9, 2009

CERegEditor : an alternative to Remote Registry Editor

Found a great atlternative to the Remote Registry Editor, without the requirement of the installation of a Visual Studio Smart Device component. Useful for non developper's guys...
One of my favorite feature is the registry comparison, between two snapshots.
Check out this cool application here.
- Nicolas

Easy way to componentize modules

Since Windows CE 4.2, Mike Hall is maintaining a power toy application helping to componentize your applications, drivers to integrate them inside your catalog views. This application is now available under the MSDN Code Gallery.

Big thanks to Mike for this CEFileWiz application helping beginners for an easy and quick understanding of the requirements for a componentized module.
- Nicolas

Wednesday, June 3, 2009

Get Ready for Windows Mobile 6.5

Microsoft announced last month the Windows Mobile 6.5 Release, and provide today an access to the Windows Mobile 6.5 Tool Kit to get your softwares ready for new coming mobile devices runnning this version of the operating system.

- Nicolas

Tuesday, June 2, 2009

WES 2009, Virtual PC and Windows PE [Updated]

When experiencing Windows Embedded Standard, you need an x86 device to boot the OS. The first solution is to use a spare computer and deploy the Runtime image to the hard drive at every OS re-generation. Except if you are a skew driver fan, but mounting and unmounting the hard-drive to push the new binaries on the target, is quite painful after two or three manipulations. So another solution could be to use the current hard drive of your development computer, and reserve a partition for WES. In this case no screw driver is required, as the partition is visible directly under the OS of you development computer. The only restriction, in this case, is too reboot the development machine to get the WES OS booted. But this solution is also painful, as booting the development OS can take a while, and all development tools have to be reloaded. The ultimate solution is to use an x86 virtualizer, like Virtual PC or other. When using the virtualizer, the way to reboot the WES OS is by launching the virtualizer software.

Use a Virtual PC :
First you need to create a new virtual machine and a hard drive, you can find all the details in the Virtual PC blog.
Then you have to prepare the hard drive to receive the WES files. And for this, you have to create a partition.... and at this point you are locked, except if you have in your drawer, an old booting floppy disk and a floppy disk reader...
Microsoft is providing for IT's a Windows Automated Installation Kit, available for free from their website. This kit provides cool applications, called WinPE, and ways to easily have a booting CD-ROM iso that can be customised to integrate all the applications that can be useful to deploy an OS, like Windows XP, Vista, and WES.

Prepare your booting CD-ROM :
After downloading and installing the AIK package, launch Startup Menu->Microsoft Windows AIK->Windows PE Tools Command Prompt.
1) Initial Folder Creation
copype x86 [Destination_Folder_Path]

2) Add custom Files
Copy required custom files to the ISO folder in \ISO. Like bootsect.exe available in "Windows AIK\Tools\PETools\x86".

3) Build the customized ISO
oscdimg -n -b[path to etfsboot.com file]\efsboot.com [path to the ISO folder] [path and name of the iso to generate]

Boot the ISO :
When the iso image is generated, then you have to boot it under Virutual PC, by launching the Configuration done previously and going to the CD menu. Then attach the iso file, and Virutal PC should boot on the virutal CD-ROM drive.

Partitions creations :
When WinPE 2.0 boot up, it initialize a shell from where you can launch batch scripts or single comands. >e gonna use diskpart to create, format partition.

1) List the available disks :
list disk

2) Select the disk
select disk 0

3) Clean Up the disk

4) Create a partition
create partition primary size=XXXXX

5) Assigne a letter to the partition
assign letter=C

6) Format the partition
format fs=ntfs quick

7) Activate the partition to be bootable by the Virutal PC BIOS

8) Exit diskpart

Then you have to store the boot sector on the partition, diskpart provided with WinPE 2.0 store by default the Vista boot sector, that is not compatible with WES 2009.
9) Prepare boot sector
bootsect /NT52 C:
Note : bootsect.exe can be found in the AIK installation folder and pushed into the CD-ROM Iso

Push files to the target :
The hard drive is now ready to receive the WES runtime files, and the easy way to push those files from the development machine to the virtual hard drive is using the network and the sharing capabilities of Windows.
Share the folder used for the generation of the WES image on the development computer, and use netuse from the Virtual PC to access it.
Then use xcopy to get the files onto the virtual hard drive.

Conclusion :
Using the Virtual PC is fairly easy to get and experiment WES.

- Nicolas