From: Tim Jowers (timjowers_at_yahoo.com)
Date: 19 Feb 2004 14:02:18 -0800
"Kirk Ferdmann" <firstname.lastname@example.org> wrote in message news:<ydKdnbQaW72pWrTd4p2dnA@comcast.com>...
> "Tim Jowers" <email@example.com> wrote in message
> > Has anyone seen or made an autologon program for Windows that can be
> > run from the scheduler or another program?
> > I've three several approaches and wonder if anyone can assert or deny
> > any. I am running these from a Service.
> > 1. Send the username and password to the "SAS Window" - the name of
> > the logon window from EnumWindows. Sending ctrl-alt-del to get the
> > window works and sending to the one to lock the workstation work fine
> > but trying keybd_event, SendInput, and PostMessage do nothing with SAS
> > Window AFAICT. This seems to be the approach used by VNC so I wonder
> > what I am missing.
> The key point: messages are local to a desktop. You can't send a message to
> a window on a different desktop. You probably can attach (see
> SetThreadDesktop) to the winlogon desktop from the service that runs under
> local system account (I never tried to so). You need to so before you send
> the message. This looks like a hack to me though. I'd say there is no
> guarantee that it will work in the future.
> > 2. Tried used LogonUser, OpenWindowStation, SetProcessWindowStation,
> > etc. and CreateProcessAsUser on explorer.exe but this does not log the
> > user in. Works fine if a user is alreadylogged in though.
> It does log the user on, but winlogon/GINA do more then just that: they
> modify the default desktop DACL, start userinit, switch to the default
> desktop, etc.
> > 3. Read up on Gina DLL and downloaded an OS one from xpasystems but
> > did not see that their Geni replacement DLL would provide what I
> > needed. Do I really have to redo the Windows security to get this to
> > work? Do I need to make a stub or do I have to make a complete Gina
> > DLL?
> GINA would be a recommended way to extend the existing security
> infrastructure. I guess you can get away with GINA stub in this case:
> 1. cache the WLX table
> 2. communicate from your service to the DLL using some IPC (DCOM, RPC, MMF,
> 3. issue your own type of SAS from the stub
> 4. handle your own SAS without forwarding it to the original GINA
> 5. for all other calls just forward the call to the original GINA
I was able to post the characters. I'll look into Gina.dll if things
develop but for now wanted to steer from something that could
potentially lock up the whole system. (Due to buggy code 8-]
HDESK old_desktop = GetThreadDesktop(GetCurrentThreadId());
// Switch into the Winlogon desktop
// Winlogon uses hotkeys to trap Ctrl-Alt-Del...
// HWND w=FindWindow("SAS window class","SAS window");
SendMessage(HWND_BROADCAST, WM_HOTKEY, 0, MAKELONG(MOD_ALT |
// evil forever loop follows?
while( NULL != (w=FindWindow(NULL,"Welcome to Windows")) )
SendMessage(w, WM_HOTKEY, 0, MAKELONG(MOD_ALT | MOD_CONTROL,
// Alt-P for password edit
keybd_event( VK_MENU, 0, 0, NULL );
keybd_event( VkKeyScan('p'), 1, 0, NULL );
keybd_event( VkKeyScan('p'), 1, KEYEVENTF_KEYUP, NULL );
keybd_event( VK_MENU, 0, KEYEVENTF_KEYUP, NULL );
Sleep( 50 ); // maybe not needed
// Enter the password
char password = "not4u2no";
for( int c=0; c<strlen(password); c++ )
keybd_event( VkKeyScan(password[c]), 1, 0, NULL );
keybd_event( VkKeyScan(password[c]), 1, KEYEVENTF_KEYUP, NULL );
// Send the enter key and do the default (logon)
keybd_event( VK_RETURN, 0, 0, NULL );
keybd_event( VK_RETURN, KEYEVENTF_KEYUP, 0, NULL );
// Switch back to our original desktop
if (old_desktop != NULL)
Yeeha! Even works with lockut to unlock. My impression is Windows just
does the right thing... if I'm allowed to run interactively then I can