LOCKDOWN PROGRAM

The easiest thing to do is to have real passwords and the screen saver password turned on by a policy.  If you have a program that decides the box needs to be protected, just activate the screen saver.

although this does sound easier, i will not be able to have a window telling the user how long they have to wait (and more importantly that this lockdown program was made by me!)

i was surfing and i found this program made by some guy that ignores mouse events, it was quite a nice program which shows the position of the mouse, and "captured" it if it was moved close to a picture of a cat on the form. u then had to right click, to get the cat to release the mouse.

im thinking that it cant be that hard to get the OS to ignore every event

do u know how to do this?

btw i will try to find this program again (he was giving out the source code aswell) and ill post a link here if i find it

In the callbacks for the various events you hook, the normal procedure is to call CallNextHookEx() to pass the event along after you're done with it.  Not calling CallNextHookEx keeps the event from being processed normally.  For Windows messages, you use WH_CALLWNDPROC to get the messages before anyone else.

Hi,
This is not a good idea.
Having computers shutdown etc whilst in the midst of things is a recipe for disaster. Train users to logout etc. NEVER force a disconnection because you never know what they may be processing  - your pay check.

cookre:

ok i will give this a try and see how it turns out (i really like the sound of this, nice and easy)

parkerig:

hmmm u deffinately have a point, but im not trying to shut them down, just effect a "pause" for a certain amount of time

consider a high-security app.

if the user can try password after password, it will only be a matter of time before the correct password is found and the security is severly comprimised

but with my app:

if the user gets the password wrong 3 times in a row, the high-security app makes a call to my lockdown dll, which makes the puter completly non-responsive until the high-security app has decided enough time has passed, makes another call and my lockdown dll removes the system-wide lock.

what the user is doing at the time, and how much warning the user gets depends completly on the high-security app. if used correctly, my lockdown app can be very useful.

futhermore, if they are processing something, it can still continue during the lockdown, only there can be no user interaction with the computer.

no luck... it dosnt work.

i set all three hooks to use one hook proc which looks like

LRESULT CALLBACK HookProc(int nCode, WPARAM wParam, LPARAM lParam)
{
    return 0;
}

but the system did not get locked down.

i was not sure if it was working or not until i changed it to log every HookProc event and then i got a 500kb log file so its deffinately working.

im thinking that this is only going to affect applications that use hooks. other apps will work fine because windows will notifiy them from their WndProc

i need to call something like ReleaseCapture on the event but i dont know how to do this

Hi,
Try
http://www.planet-source-code.com
Search for
(1) Screen saver
(2) Keyboard lockdown
(3) Disable CTRL-ALT-DEL

I'm sure there will be enough code to get exactly what you want.

Ian

CTRL-ALT-DEL is no longer trappable on Windows.

Suma, did you also hook with WH_CALLWNDPROC to block messages?

4 sho :)

but i did hook them all into 1 HookProc. i cant see how that would matter but maybe it does.

the mouse was movable, the keyboard was working, and the windows were responding.... i.e. nothing worked


pakerig:

i went to that site and did the searches:

(1) download a matrix screen saver - i liked the first movie but the revolutions sucked :P
(2) absolutely nothing
(3) some code that i had already tried from another place and didnt work

new approach:

there is a function that lets u set the position of the mouse (im not sure what it is but i know it exists)
(1) for every mouse event, set the position of the mouse to (0,0) or some place off the screen

(2) for every keyboard event, create a new array and set every variable in it to 0, call SetKeyboardState with the new array

(3) what should i do for every WndProc event and will (1) and (2) work??

You're right, not calling CallNextHookEx just blocks other hook, and when CallWndProc returns, the message is passed on.

However, I wonder what would happen if CallWndProc never returned, but was terminated instead?  To wit, the WH_CALLWNDPROC hook is set in a child thread by the main program.  When it gets something to be blocked, it sets a flag being monitored by the spawning thread which, in turn, kills the child thread which can then never return.  A new thread is then spawned to set the hook again.  Now you wouldn't be able to block every message since the box would probably lock up from never being able to keep up with all the messages that are sent, but judicious blocking just might work.  

One fly in that ointment, however, is what the long term effect of never returning from all thos CallWndProcs would have on the OS.  I suspect the box would eventually run out of RAM or handles from all of the OS threads waiting for returns.


Perhaps just opening your own desktop and keeping focus there would suffice.

rather then keeping the focus on the desktop, i would like to keep the focus on a window which i will be creating.

what do u think about:

1) making my window appear as maximized (i.e. over the whole screen)

2) on every WH_CALLWNDPROC event, repaint my window

would this work?

everything so far works (i havnt yet tried the repaint the window thing)

they can still open the taskmgr using CTRL+ALT+DEL but (and this is the funny part) they caint do nuttin wit it!!

microsoft went to ALL that effort so that nobody can block CTRL+ALT+DEL, and for what?? how exactly do u end a process if your mouse and keyboard is completly disabled!!

provided i get the window painting thing to work, this could be the first program ive ever made that is actually useful      :)

Doing that on EVERY time your CallWndProc is triggered might be a bit much - afterall, they get their message AFTER you (unless you use WH_CALLWNDPROCRET (which is what you may want to do)).  In any case, messages like mouse moves don't effect focus, so you needn't worry about them.

I have tried many things to do the same sort of things, one of which was to open the task manager hidden so, when the CTRL + ALT + DEL keys are pressed no taskmanager appears tell me what you think

well ive given it a bit of thought and:

if i can get a full-screen window which is *always on top* then my problem will be solved.

i have filtered my CallWndProc for WM_PAINT messages, but i need to filter it more so that it will be called ONLY if something wants to become the active window

then it woulc be a simple matter to fix it so that:

if the HWND is my HWND, then no action is taken

otherwise, my hwnd becomes the active window (repaints itself)

so how can improve the filter of CallWndProc?

WM_PAINT per se is OK since that doesn't cause a window to come to  the top.
WM_SETFOCUS and WM_ACTIVATE should definately get caught.

In your compiler's help index, bring up WM_ and look for likely candidates to catch.
(I'm being lazy right now 'cause I've been working outside most of the day and am ready to crash - back tomorrow night...)

ok thanks i was wondering why WM_PAINT didnt seem to do anything

well i filtered the CallWndProc to WM_SETFOCUS || WM_ACTIVATE, started the program, gave another window the focus, then gave the original window the focus, and that resulted in 500kB of logs.

i need some way to filter to ONLY when the window gets activated, otherwise im going to waste some serious processing power.

i will try also filtering nCode to HC_ACTION and see if this helps

- filtered nCode to HC_ACTION and absolutely nothing got logged

ahhh thats better... i had the wrong type of hook and was hooking the keyboard!!!!

i changed it to WH_CALLWNDPROCRET, resulting with the nCode filter working, and a mere 100kB log file.

im thinking that there must be a wParam filter or something that i dont know about

The description of each WM_ message includes, if applicable, whatever is in wParam and lParam.
Here's a link to the the first WM_ message in the MSDN.  The left frame lists all of the WM_ messages.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui/windowsuserinterface/userinput/keyboardinput/keyboardinputreference/keyboardinputmessages/wm_activate.asp?frame=true

ive managed everything using CBT hooking - it's the IDEAL way to do these things.

its about 11pm here, and i have to be up in the morning for school, so ill post again with the details some time tomorrow avo

later

ok heres the deal:

=======================================================================================

a hook CAN make the OS ignore events.

to make the OS ignore the event, make the HookProc return TRUE
to allow the OS to continue the event, make the HookProc return FALSE (however if another HookProc returns TRUE, the event will be ignored)

returning CallNextHookEx() is a more compact way of returning FALSE (it minimizes 2 lines of code into 1)

=======================================================================================

CBT hooks are very useful for hooking when a window becomes the active one

=======================================================================================

currently, i have an app that blocks all windows from becoming the active one, this works, however if i click on another app, my app loses "the focus" even though the other app does NOT gain "the focus". This makes it impossible to imput a password to "unlock" the computer.

i will be doing some more work on this soon (i can either create put an IF statment in my hook, or block all mouse events)... ill post here if i have any problems

=======================================================================================

dam... everything worked fine until i tried out the program on windows 2000, where it lost the power to block the taskmgr

any ideas how to overcome this?

It may be that the task manager is coming up in the logon desktop and not the default desktop.

Hi,
You can disable the task manager at the registry

http://www.winguides.com/registry/display.php/163/

Cheers
Ian

cookre: i am logged on when i run the program, if thats what u mean.

pakerig: no luck, i am planning to use this program on the computers at my school. i have a hack which enables me to load up any exe file, but unfortunately they have completly blocked registry editing :(

this program is not a service... i got bored with that because all the user has to do is unselect "allow this service to interact with the desktop" and no windows or anything can be created.

and seeingz as my program is about taking power away from the user, not giving them more, i do not want that weakness

is there another way to get that "always on top" window effect

All that enumerate stuff applies even outside of a service.  Your 'always on top' program probably was on top - in its desktop that was covered by the logon desktop.

oh i get it now... that explains why it works in XP and not in 2000 (in 2000 CTRL-ATL-DEL logs u off, but in XP it does not.

this makes my job a LOT harder.

is it possible to block the logon desktop (or any other desktop for that matter) covering the desktop which i have taken control over?