This Windows batch file will parse Subversion’s svn up output and show you what files were modified, but also what files should be added.

It looks for C++, C, H, PHP, Python, Java and then some. You can easily add your own to the list.

To use simply call localfiles.bat from any versionned directory. Anything you add to the command line will be passed along to svn up. Try these variations :

• localfiles.bat -u to see potential update conflicts.
• localfiles.bat c:\the\path\to\my\project\sources works, you can run the command from anywhere
• localfiles.bat --ignore-externals or any other Subversion command you can think of

In the sample output (below) you will see

• New Source Files are source that were added (localy) but never comitted.
• Modified Source Files are source that are under source control and were modified locally.
• Unversioned Source Files are source that probably should be under source control.
• Each file is listed, with (no source file) if it looks ok.

$ localfiles.bat C:\Users\Guillaume\src\Projects\aucun.selfserve

Gathering data...

======================================
 New sourcefiles
======================================
(none found)

======================================
 Modified sourcefiles
======================================
M       C:\Users\Guillaume\src\Projects\aucun.selfserve\GINA\SecurityHelper.cpp
M       C:\Users\Guillaume\src\Projects\aucun.selfserve\GINA\loggedout_dlg.cpp
M       C:\Users\Guillaume\src\Projects\aucun.selfserve\common\Trace.c
M       C:\Users\Guillaume\src\Projects\aucun.selfserve\GINA\GinaHook.c

======================================
 Unversioned files
======================================
?       C:\Users\Guillaume\src\Projects\aucun.selfserve\GINA\StaticPrompt.cpp
?       C:\Users\Guillaume\src\Projects\aucun.selfserve\shellie\shellie_p.c
?       C:\Users\Guillaume\src\Projects\aucun.selfserve\shellie\dlldata.c
?       C:\Users\Guillaume\src\Projects\aucun.selfserve\shellie\shellie_i.c
?       C:\Users\Guillaume\src\Projects\aucun.selfserve\shellie\shellie.h

Here is the file. I gave it a txt extension, in case you are behing a paranoïac corporate proxy.

Fortunately, I had set up LSASS to run under ntsd, which was connected to a remote Windbg.

To edit the registry of a remote machine running under a debugger :

1. Break into the debugger. This step will happen naturally in most snafu
2. Start a shell with the .! command
3. Fix the registry with the command line reg.exe tool. For example, to restore authentication packages type

   reg add HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v "Authentication packages" /t REG_MULTI_SZ /d msv1_0

4. Type exit to quit the shell (hit Enter enough times to get back to Windbg’s prompt)

Then use the g command to resume execution.

As a side note : The windows subsystem is fully loaded before LSASS.exe starts, or at least there is enough of it to launch CMD.exe and REG.exe.

• Every time you type CTRL-ATL-DEL, a new LogonUI process is launched.
• LogonUI will try to load any registered Credential Providers COM objects.
• You can run any process on the secure desktop

With that knowledge, it is easy to set up a debugging session for your Credential Provider, right on your development machine. Before I continue, be aware that it might affect the stability of your computer temporarily, as the following illustration shows.

To debug your credential provider, you will need this :

• A CredentialProvider that can be loaded by LogonUI
• Microsoft’s Debugging Tools for Windows
• Microsoft’s psexec tool (of Sysinternals fame)

I guess you could also use Visual Studio instead, ymmv. If it works, please drop us a line in the comments.

To start debugging, here is what you have to do:

1. Start a command shell on the Secure Desktop with this command:
   

   psexec -dsx cmd.exe

2. Build a debug version of your Credential Provider and register it.
3. Type CTRL-ALT-DEL to switch to the secure desktop. That will also launch LogonUI.exe
4. Hit Alt-Tab to switch to the command prompt you started at step 1
5. Change to the directory where your source code is
6. Debug LogonUI.exe and set the source path at once, with this command :
   

   windbg –pn logonui.exe –srcpath %CD%

That’s it. You might not be very familiar with windbg, so here are a few tips to get you started:

• When you attached to LogonUI at step 6, the process is stopped. You can enter commands to set breakpoints before resuming it.
• Verify that your Credential Provider is loaded with the lm command. Look for a string like this one:

  000007fe`f5e80000 000007fe`f5e9b000   SampleCredentialProvider   (private pdb symbols)

• Just to be sure, verify that a specific symbol is loaded with this command (you should get an address):
  

  x SampleCredentialProvider!CSampleProvider::SetUsageScenario

• Set a breakpoint to the same location with this command:
  

  bu SampleCredentialProvider!CSampleProvider::SetUsageScenario

• Resume LogonUI with the g command.

You can now lock your workstation and try to unlock it. When LogonUI appears to freeze, ATL-TAB to the debugger. It should be waiting for you with the source file loaded, waiting for your instructions. Type g to resume. Complete the unlock procedure to end LogonUI.

To reattach to logon UI, you can quit windbg and launch it again, but it is easier to list the process with the .tlist command (LogonUI.exe will be the last in the list). Attach to it again with .attach 0n2331 (replace with your PID).

Happy debugging !

Image credits : http://www.123rf.com/photo_6015610_idiot-saws-branch.html

Microsoft new architecture is better, but the separation it enforces makes it hard to play tricks with the security policy. First, there are no shortcuts with Credential Providers. The documentation is formal :

CredentialProviders are not enforcement mechanisms. They are used to gather and serialize credentials. The Local Authority and Authentication Packages enforce security.

So we have to use an authentication package with the credential provider. Nothing that we didn’t see coming. I have played with authentication packages before, it just a matter of writing one.

Second, LogonUI will not kill another user’s session. I am able to get a credential provider tile on the unlock screen, logon with administrator credentials, but then I get this error message :

This computer is locked. Only the logged on user can unlock the computer.

Which makes some sense: why kill (or unlock) a user’s session if you can just start a new session next to it ? Unfortunatly, it does not help the most common use case my custom GINA users need to solve: many users need to access a single application running in a single session.

But I haven’t given up yet.

I tested on Windows 7 Ultimate 64bits, with or without fast user switching. If you ever able to unlock another user’s session, write a line in the comments. I would love to hear about it.

A custom Gina runs in Winlogon’s process. It runs under the SYSTEM account, in the TCB… In short it can do pretty much anything. But some things just can’t be done, no matter what rights you have.

Fortunately, there is an easy way to tell if a GINA can do what you need it to do, without having to write a single line of code.

The trick is to launch a cmd.exe shell (or whatever shell you prefer) on the Winlogon desktop. I used to work with EnumWinStaGui, but Microsoft’s own psexec (of Sysinternals fame) is easier to use.

To run a cmd shell on Winlogon desktop, do the following :

1. Logon with an account with administrator rights
2. Open a command prompt (elevated if you are on Vista or later)
3. Type this command :
   

   psexec –dsx cmd.exe

That’s it ! You will not see your shell, because it is running on the current desktop. To verify that it works, hit CTRL-ALT-DEL and your command prompt will be there. On Vista and later, it will be hidden under the full screen logon application (logonui.exe). Just ALT-TAB to it. That shell will keep running even if you log out, because it is not tied to the interactive session you used to start it. From that command line on the secure desktop, launch whatever command you need to confirm that what you want to do can be done.

For example, say you need to launch a process that will notify a web application just before the password is validated, maybe to start a timekeeping application. Can it be done ? Yes. On the command line running on the secure desktop, type this command :

start iexplore http://www.paralint.com/

It might not work. Maybe your proxy is not set up in the SYSTEM account ? Whatever the problem may be, you need to fix it. Writing a custom Gina is a waste of time if you can’t get past this step.

Tortoise SVN is a Explorer shell extension which calls a Windows executable, TortoiseProc.exe.

To use it from the command line, simply save this batch file somewhere in your path :

@echo off
start "" "C:\Program Files\TortoiseSVN\bin\TortoiseProc.exe"  /command:%1 /path:"%2"

Then simply call like this :

tortoise log http://src.pararlint.com/aucun/trunk

or like this

tortoise commit .

Tested on Windows with 32 and 64 bits version.

Credential Providers cannot make an authentication decision. They only collect credentials. The approach I took in “Aucun” is that the Gina actually makes the authentication decision. That will not work under the new Credential provider architecture.

When I started looking to port my Gina to a Credential Provider, I first though of saving the initial credentials (when the first user logs on), then check any other user’s credential in my own Credential Provider, and if all is good, replay the initial credentials.

That bothered on many grounds :

• There will be a unlock event logged to the initial user, although that user never unlocked the workstation
• I don’t like saving passwords, even to encrypted memory
• That architecture didn’t look like something that would last

Looking deeper into the Credential Provider interface, I saw that there is one decision a Credential Provider can make. It can select what Authentication Package will honor the logon request (or unlock request, in my case). That takes place in my (your) ICredentialProviderCredential::GetSerialisation, by setting the ulAuthenticationPackage field of the CREDENTIAL_PROVIDER_CREDENTIAL_SERIALIZATION structure.

So I believe the right way of doing this is to have two components :

1. An authentication package that implements the unlock policy (any user can unlock, depending on group membership).
2. A credential provider that collects credentials (and while you’re at it, the session you want to unlock) and instruct winlogon to forward them the “unlock” authentication package.

That architecture fixes all three points above. And as a bonus, I can greatly simplify my existing Gina by merely collecting the credentials and forward them to the same authentication package. No need to hook dialog procedures and sending magic, reversed engineered constants to winlogon. In short, instead of making the Credential Provider look like a Gina, I make the Gina behave like a Credential Provider.

Authentication packages are the same under Vista and XP, that’s a good thing. But to debug them, you need the scary kernel remote debugging tools. You also need to reboot every time you mess up. But I have a working authentication package from CVS NT code source, and another called YPAuth (YP means yellow pages, the old name of NIS). None of them support the unlock scenario, though…

Stay tuned !

The trick is to subtract 4 from the Capabilities in the registry. Not easy, but it can be done. The only thing is that it keeps coming back after every boot ! And it looks like the value cannot be edited under Vista. Here is how to fix it for good.

What has to be done (but doesn’t work)

Find the drive that shows up in the safely remove hardware icon in your registry. It will be somewhere under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\IDE\. My DVD drive was here :

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\IDE\CdRomHL-DT-ST_DVDRAM_GMA4082Nj_______________PM01____

There is a numerical an alphanumerical key under that with a DWORD Capabilities value.

It is a bit field. The bit 0010 (4 in decimal) is the REMOVABLE bit. Clear it by subtracting 4 from the value you have. The value I had was 6, so now I am down to 2.

If you try to do that, you will get an access denied. That’s ok, we will get around that. For now, right click on the key name and copy it (the key named 5&3392c8c4&0&0.0.0 in my example).

Same idea, that works manually under Vista

You need to have the TCB privileged enabled to modify that registry key. Running regedit as an administrator (or elevated, if you have UAC) will not work. You can fix the value with this command line :

psexec -s reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\IDE\CdRomHL-DT-ST_DVDRAM_GMA4082Nj_______________PM01____\5&3392c8c4&0&0.0.0" /v Capabilities /t REG_DWORD /d 2 /f

You will have to replace the key name with what you found in your registry. Running psexec -r regedit might work, but who wants to do that every time the computer boots ?

Permanent fix

I hardly ever run as an administrator, so putting the above command in a script was out of the question. The solution was to create a Task using Windows Task Scheduler. I set it to run at startup, under the SYSTEM account. Don’t forget the /f (force) flag, or else the job will appear to hang, waiting a confirmation from you.

Create a new task. In the “General” tab, click Change User or Group and enter “SYSTEM” . Trigger on startup and enter the same command as above, but without psexec -s. Your task is running reg.exe, with everything right of that (in the command line, earlier) as optional arguments.

Good luck and HTH !

I found a detailed explanation of the MSCASH format. Here is how you make your own MSCASH hashes to do close to reality benchmarks of your favourite password cracking tool.

The format is MD4(MD4(password) + username). password and username are in Unicode. In the explanation linked above, we have the classical "user" and "password" combination. Using notepad, type your password. Save the file using Unicode format. The first two bytes of the file will be FF and EF, a flag called the byte order mark (BOM). Delete them using an hexadecimal editor. It should look like this :

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00000000  70 00 61 00 73 00 73 00 77 00 6F 00 72 00 64 00  p.a.s.s.w.o.r.d.

Now calculate the first hash with openssl, with a binary output :

openssl dgst -md4 -binary password.unicode.txt > md4.password

Type and save your user name in Unicode format, remove the BOM, and concatenate the Unicode user name to the first hash.

copy /b md4.password + user.unicode.txt md4.password.user

The file should look like this (the first 16 bytes is the md4 hash of the password) :

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00000000  88 46 F7 EA EE 8F B1 17 AD 06 BD D8 30 B7 58 6C  ˆF÷êî.±...½Ø0·Xl
00000010  75 00 73 00 65 00 72 00                          u.s.e.r.

Now just hash that last file, again with openssl :

openssl dgst -md4 md4.password.user
MD4(md4.password.user)= 2d9f0b052932ad18b87f315641921cda

You can now use that MSCASH hash for your benchmarks. I hope you find it usefull. I might write a program in C to automate this, If I see good traffic on this post. Spread the word !

• Vista Home Premium and Vista Business support (same binary works on XP and Vista)
• Better error handling on platforms that don’t support IUserNotification
• Option to specify pop-up delay in seconds (/d 5 or /d 5000 will give you 5 seconds)

I updated the main project page. There are a couple of typos and the email link is gone. I will fix that sometimes this week. Click on the bitmap here or on the project page to download.

Enjoy !