Hi all,
As some of you might know with Windows XP you can use the windowskey+L to lock the workstation.
Unfortunately this doesn't work on Windows 2000.
So i wrote a small program which catches this sequence and locks the workstation. This program should run in the background and Lock the computer when <winkey>+<L> is pressed.
I know it's nothing special, but i still have a problem with it.
This is the dll i have written for it. The dll gets injected into explorer and then uses GetAsyncKeyState to see if the combination of keys is pressed. (I know, process injection isn't legal here, but thats not the issue, and i'm not going to post code of how to do this).
The problem with this approach is that it is difficult to let the program respond immediately. Most of the times you have to press the combination a couple of times before the station gets locked.
To my knowledge there are 2 other ways of making such a program:
- using a keyboardfilter driver to catch the sequence. Biggest issue here is locking the station from kernelland (i'm not too familiar with kernelland).
- using a global keyboardhook. I don't want to do this since the program would be seen as a possible keylogger, and it would be far too easy for someone to alter the program and use it as a keylogger (even without sourcecode).
So my question, what can i do to optimize above code, and which approach would be best for this matter?
Thanks in advance!
As some of you might know with Windows XP you can use the windowskey+L to lock the workstation.
Unfortunately this doesn't work on Windows 2000.
So i wrote a small program which catches this sequence and locks the workstation. This program should run in the background and Lock the computer when <winkey>+<L> is pressed.
I know it's nothing special, but i still have a problem with it.
.586
.model flat,stdcall
option casemap:none
include \masm32\include\windows.inc
include \masm32\include\kernel32.inc
include \masm32\include\user32.inc
includelib \masm32\lib\kernel32.lib
includelib \masm32\lib\user32.lib
;WindowsLock PROTO
.CODE
;~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
LibMain PROC h:DWORD,r:DWORD,u:DWORD
mov eax,1
ret
LibMain ENDP
;~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
;~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
;The WindowsLock procedure
;~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
;~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
WindowsLock PROC
endless:
push 500
call Sleep
push 5Bh ;Left windowskey
call GetAsyncKeyState
push eax
push 4Ch ; L-key
call GetAsyncKeyState
push eax
push 5Ch ;right windowskey
call GetAsyncKeyState
pop ecx
pop ebx
cmp ecx,-32767
jnz endless
cmp ebx,-32767
jz lockstation
cmp eax,-32767
jz lockstation
jmp endless
lockstation:
call LockWorkStation
jmp endless
ret
WindowsLock ENDP
;-------------------------------------------------------
end LibMain
This is the dll i have written for it. The dll gets injected into explorer and then uses GetAsyncKeyState to see if the combination of keys is pressed. (I know, process injection isn't legal here, but thats not the issue, and i'm not going to post code of how to do this).
The problem with this approach is that it is difficult to let the program respond immediately. Most of the times you have to press the combination a couple of times before the station gets locked.
To my knowledge there are 2 other ways of making such a program:
- using a keyboardfilter driver to catch the sequence. Biggest issue here is locking the station from kernelland (i'm not too familiar with kernelland).
- using a global keyboardhook. I don't want to do this since the program would be seen as a possible keylogger, and it would be far too easy for someone to alter the program and use it as a keylogger (even without sourcecode).
So my question, what can i do to optimize above code, and which approach would be best for this matter?
Thanks in advance!
IsWinL_pressed proc
invoke Sleep,0
invoke Sleep,200
invoke GetAsyncKeyState,5Bh ; Left Windows
push eax
invoke GetAsyncKeyState,5Ch ; Right Windows
push eax
invoke GetAsyncKeyState,4Ch ; key "L"
pop edx
pop ecx
or edx,ecx
or edx,1
and eax,edx
ret
IsWinL_pressed endp
WindowsLock PROC
WaitForRelease:
call IsWinL_pressed
jnz WaitForRelease
WaitForPress:
call IsWinL_pressed
jz WaitForPress
lockstation:
;print "locking"
jmp WaitForRelease
ret
WindowsLock ENDP
This one seems a bit better in its response.
Constant polling :(
:oops:
main proc
local msg:MSG
invoke RegisterHotKey,0,0,MOD_WIN,VK_L
again:
invoke GetMessage,addr msg,0,0,0
.if msg.message==786
call LockWindowStat
.endif
;jmp again
ret
main endp
main proc
local msg:MSG
invoke RegisterHotKey,0,0,MOD_WIN,VK_L
again:
invoke GetMessage,addr msg,0,0,0
.if msg.message==786
call LockWindowStat
.endif
;jmp again
ret
main endp
This is perfect. I didn't knew it was that easy to register hotkeys. Thanks a lot!!
Oh, duh - why didn't I think of that? :oops:
By the way, is it possible to register Win+L hotkey on XP, where it's already defined? Iirc I tried replacing Win+E like that but failed.
By the way, is it possible to register Win+L hotkey on XP, where it's already defined? Iirc I tried replacing Win+E like that but failed.
According to MSDN you cannot register a hotkey which is already in use by another hotkey.
Hotkeys are registered directly in the kernel (traced RegisterHotKey), so the only way i can think of is by writing a keyboard filter driver which catches these keys and changes its output.
on www.sysinternals.com there is a good example including source on how to do this. the program is called Ctrl2cap.
Hotkeys are registered directly in the kernel (traced RegisterHotKey), so the only way i can think of is by writing a keyboard filter driver which catches these keys and changes its output.
on www.sysinternals.com there is a good example including source on how to do this. the program is called Ctrl2cap.
Hotkeys are registered directly in the kernel (traced RegisterHotKey)
Nice, pretty efficient then :)
so the only way i can think of is by writing a keyboard filter driver which catches these keys and changes its output.
A bit overkill probably, but probably the way to go if you NEED to be sure it's YOUR app getting a key, for security reasons or whatever.
A bit overkill probably, but probably the way to go if you NEED to be sure it's YOUR app getting a key, for security reasons or whatever.
Or if you want to change the hotkeys which are already created by default in Windows XP :D
My guess is that winlogon.exe is registering these hotkeys, so if you would inject code into winlogon.exe which would pick up the handle and closes the hotkey, you might be able to do it in userland as well.
My guess is that winlogon.exe is registering these hotkeys, so if you would inject code into winlogon.exe which would pick up the handle and closes the hotkey, you might be able to do it in userland as well.
foo foo!
Especially the ctrl-alt-del sequence is handled specially for security reasons, and people shouldn't go about injecting code into winlogon.exe.
Now, who has a bad mind???
I was still thinking about <winkey>+<E>, the <ctrl>+<alt>+<del> combination is something i didn't even think about :lol:
But if you use a keyboard filter you won't even need to hook the special key sequence, so that would be even more dangerous regarding security.
Luckely this is only theory, and no code is posted, so no-one should find this info useful enough to hack windows ;)
I was still thinking about <winkey>+<E>, the <ctrl>+<alt>+<del> combination is something i didn't even think about :lol:
But if you use a keyboard filter you won't even need to hook the special key sequence, so that would be even more dangerous regarding security.
Luckely this is only theory, and no code is posted, so no-one should find this info useful enough to hack windows ;)
Now, who has a bad mind???
Iirc slight paranoia us a requirement for the moderator team :P
Luckely this is only theory, and no code is posted, so no-one should find this info useful enough to hack windows ;)
Otherwise that code would certainly have been edited out :)