myAutoLogon

  • Thread starter Thread starter Tim Jowers
  • Start date Start date
T

Tim Jowers

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.

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.

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?

Thanks for advice,
TimJowers
 
Tim Jowers said:
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.
Click to expand...

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.
Click to expand...

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?
Click to expand...

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,
etc.)
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

-Kirk
 
Kirk Ferdmann said:
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.


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.


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,
etc.)
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

-Kirk
Click to expand...

Thanks Kirk,

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
if (!SelectDesktop("Winlogon"))
{
return FALSE;
}

// 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 |
MOD_CONTROL, VK_DELETE));
HWND w=NULL;
// evil forever loop follows?
while( NULL != (w=FindWindow(NULL,"Welcome to Windows")) )
SendMessage(w, WM_HOTKEY, 0, MAKELONG(MOD_ALT | MOD_CONTROL,
VK_DELETE));

// 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)
SelectHDESK(old_desktop);
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
post.
Cheers,
TimJowers
 
Back
Top