Anti End Task, not WM_Close?

[user]

To prevent WM_Close, I use

Code:

procedure TForm1.FormCloseQuery(Sender: TObject; var CanClose: Boolean);
begin
CanClose := false
end;

Try to click End Task with TaskManager, after several seconds, there will be an end task dialog then the app can be killed. How to prevent this? I just want to prevent End Task.

[Dezipaitor]

Call getsystemmetrics with SM_SHUTTINGDOWN and set CanClose to true in such a case.

BTW: Your app is not user friendly. However, in the end the user will always be able to close your application. It just takes a little more effort.

[user]

Zitat:

Zitat von Dezipaitor (Beitrag 1071668)

Call getsystemmetrics with SM_SHUTTINGDOWN and set CanClose to true in such a case.

BTW: Your app is not user friendly. However, in the end the user will always be able to close your application. It just takes a little more effort.

I'll try "getsystemmetrics with SM_SHUTTINGDOWN". Yeah I just want to prevent end task. I know there are many ways to kill an app. No I'm not making virus! :)


edited :

Code:

SM_BASE = WM_USER +  1736 ;
SM_SHUTTINGDOWN = SM_BASE +2;

procedure TForm1.FormCloseQuery(Sender: TObject; var CanClose: Boolean);
begin
CanClose:=false;
if (GetSystemMetrics (SM_SHUTTINGDOWN) <> 0) then
CanClose:=false;
end;

The code is right?

[rollstuhlfahrer]

Zitat:

Zitat von user (Beitrag 1071669)

edited :

Code:

SM_BASE = WM_USER +  1736 ;
SM_SHUTTINGDOWN = SM_BASE +2;

procedure TForm1.FormCloseQuery(Sender: TObject; var CanClose: Boolean);
begin
CanClose:=false;
if (GetSystemMetrics (SM_SHUTTINGDOWN) <> 0) then
CanClose:=false;
end;

The code is right?

Can't be right. You don't set CanClose to true in any case. It has to be

Delphi-Quellcode:

if (GetSystemMetrics (SM_SHUTTINGDOWN) <> 0) then
CanClose := true;

Bernhard

[user]

Zitat:

Zitat von rollstuhlfahrer (Beitrag 1071678)

Can't be right. You don't set CanClose to true in any case. It has to be

Delphi-Quellcode:

if (GetSystemMetrics (SM_SHUTTINGDOWN) <> 0) then
CanClose := true;

Bernhard

Still not working. I also change the value of SM_SHUTTINGDOWN to 2000 (referenced from MSDN). I am using 7 32 bit.

[Luckie]

And what's the use of it? If I want to end your application I just will call ProcessTerminate and that's it. Even a normal user cab do this. He just has to switch to the process panel of the taskmanager. Users ain't silly.

[user]

Zitat:

Zitat von Luckie (Beitrag 1071682)

And what's the use of it? If I want to end your application I just will call ProcessTerminate and that's it. Even a normal user cab do this. He just has to switch to the process panel of the taskmanager. Users ain't silly.

I already hook TerminateProcess.

[rollstuhlfahrer]

Why hook ProcessTerminate? - You just need to hook OpenProcess.
But why do you do so? - Just create a process with Admin-Account and don't let the user get Admin-Rights and your process acts like it should, cause a Non-Admin can't terminate Processes from an Admin-Account. Or create a service.

Bernhard

[user]

Zitat:

Zitat von rollstuhlfahrer (Beitrag 1071684)

Why hook ProcessTerminate? - You just need to hook OpenProcess.
But why do you do so? - Just create a process with Admin-Account and don't let the user get Admin-Rights and your process acts like it should, cause a Non-Admin can't terminate Processes from an Admin-Account. Or create a service.

Bernhard

Yes, hooking XxOpenProcess maybe better than hooking XxProcessTerminate. I'll implement that later. No, user can use my app in Admin-Account. My problem is user can kill my app from end task.

[rollstuhlfahrer]

Why do you need a not-closable Application?

Bernhard

[Luckie]

If I want to kill your application and you will not allow ist, I just pull the plug after the administrator has removed your application from auto run. Or can you prevent the user from pulling the plug with your application?

[Assarbad]

Man, just write a service if you need something the user cannot close. Even if the user closes the "client" part (e.g. a visible GUI), the service will continue to run. Let's assume for a second that you succeed in achieving your goal of an application that cannot be closed. No application is bug-free. Once the user encounters a bug and your application prevents the user from closing it, you'll have a bunch of angry users. Besides, with a hook such as the one you describe it's likely that you introduce more potential issues into the user's session ... i.e. affecting other processes as well.

I think you should elaborate on the problem you're trying to solve, because so far it indeed sounds iffy. So let's hear ... ;)

[user]

I am making a security application for a policy. This app block unlisted/unwanted program from running (Admin/Guest Account). I hook in ring3, right now I have not implemented my app as a service/ring0, it's just a normal GUI app. I use ESET in my pc, Eset's GUI can be killed easily but eset's service is "self restarting" service. But.. I have not implemented yet my app as service. Making a service will consume more my time, maybe later I will working on it. So I just want to ask, is there any simple way to block End Task for GUI app?

[Luckie]

It will be easier to implement a service rather than a application that can not be killed. Plus it would be the preferred way by Microsoft because that's why they introduced services. Hooks will strain the system. And if they are not properly implemented the application may influence other applications from running properly.

[rollstuhlfahrer]

So, why do the users need administrative privileges? - You don't need any administrative privileges if you just use the computer and don't administrate it.

On top of that, Windows comes with a Software Policy Kit which allows you to block unwanted Programs by name and Hash. Your program can't do it in an better way. Those policies even apply to administrative accounts, if wanted.

Bernhard

[Assarbad]

Zitat:

Zitat von user (Beitrag 1071729)

I am making a security application for a policy. This app block unlisted/unwanted program from running (Admin/Guest Account).

Well, in this case it's neither secure nor is it the right approach. Sorry to say :zwinker:

Zitat:

Zitat von user (Beitrag 1071729)

I hook in ring3, right now I have not implemented my app as a service/ring0, it's just a normal GUI app.

Well, write a driver. If you can live with the prerequisites of Windows XP SP2 or Windows 2000 SP4+SRP+FltMgr and higher, you can easily use one of the mini-filter samples from the WDK. Mini-filters are rather easy to implement, compared with classic FSFDs.

Zitat:

Zitat von user (Beitrag 1071729)

I use ESET in my pc, Eset's GUI can be killed easily but eset's service is "self restarting" service.

Well, there is usually something like a failure action. But again, "self-restarting" and "invincible" processes suck!

Zitat:

Zitat von user (Beitrag 1071729)

So I just want to ask, is there any simple way to block End Task for GUI app?

Nope.

Zitat:

Zitat von rollstuhlfahrer (Beitrag 1071836)

On top of that, Windows comes with a Software Policy Kit which allows you to block unwanted Programs by name and Hash. Your program can't do it in an better way. Those policies even apply to administrative accounts, if wanted.

This should be Vista or higher, though?! The old approach was pretty unsecure and relied on particular means being used to execute a program. If a more subtle method was used one could circumvent the restriction. Done so myself as admin.

But otherwise I can recommend TrustNoExe, though it may not work on x64 or Vista and higher (due to signing policies).

Small note concerning TrustNoExe: the guy used a SSDT hook to see when images get loaded. Whenever something that was not allowed was about to be loaded, he'd exchange the section (aka MMF) handle with one of his own usermode executable. This way his executable could retrieve its "own" location (actually the one of the attempted execution) and display a nice message to the user. Simple but effective.

[rollstuhlfahrer]

Zitat:

Zitat von Assarbad (Beitrag 1071843)

Zitat:

Zitat von rollstuhlfahrer (Beitrag 1071836)

On top of that, Windows comes with a Software Policy Kit which allows you to block unwanted Programs by name and Hash. Your program can't do it in an better way. Those policies even apply to administrative accounts, if wanted.

This should be Vista or higher, though?! The old approach was pretty unsecure and relied on particular means being used to execute a program. If a more subtle method was used one could circumvent the restriction. Done so myself as admin.

I just know that in Windows XP there was something like that. Tried it only once and i thought it works. I never had the idea to circumvent the blocking-policy.

Bernhard

[Assarbad]

Zitat:

Zitat von rollstuhlfahrer (Beitrag 1071846)

I never had the idea to circumvent the blocking-policy.

I know I know: I'm paranoid. But just because you're not paranoid doesn't mean they aren't after you :zwinker:

As an admin I considered it my duty to make the machines luser-proof. However, for XP MS offered (until recently, I think it was withdrawn) something like a kiosk mode. I.e. you could lock down an XP quite thoroughly. Would have to ask in the forum whether someone still has a copy around. I don't even recall the name of the tool, but it got "advertised" on heise.de.

[rollstuhlfahrer]

Zitat:

Zitat von Assarbad (Beitrag 1071850)

I know I know: I'm paranoid. But just because you're not paranoid doesn't mean they aren't after you :zwinker:

Don't we all are a bit paranoid? - If you want security you have to test it, not just think it will work.

Zitat:

Zitat von Assarbad (Beitrag 1071850)

However, for XP MS offered (until recently, I think it was withdrawn) something like a kiosk mode. I.e. you could lock down an XP quite thoroughly. Would have to ask in the forum whether someone still has a copy around. I don't even recall the name of the tool, but it got "advertised" on heise.de.

Do you think of the "Shared Computer Toolkit"? - I have got a copy.

Bernhard

[Assarbad]

Zitat:

Zitat von rollstuhlfahrer (Beitrag 1071856)

Do you think of the "Shared Computer Toolkit"? - I have got a copy.

That could well be it (new name seems to be SteadyState). I don't need it, but the OP might appreciate to get his hands on a copy. Let's see when he returns to this topic ;)

[fkerber]

Hi,

do you mean this one:
http://www.microsoft.com/presspass/n...ToolkitFS.mspx

Bye,
Frederic

[rollstuhlfahrer]

Yes, meant this one.

Bernhard

[user]

Zitat:

Zitat von rollstuhlfahrer

So, why do the users need administrative privileges?

Zitat:

Zitat von Assarbad

Well, in this case it's neither secure nor is it the right approach. Sorry to say

Policy from that place. I can't say any reason about this because I just make the program. I am not the boss :p

I guess by writing service, my problem easier to solve. Thanks for the mini-filter.

Zitat:

Zitat von Assarbad

but the OP might appreciate to get his hands on a copy

Ehmmm... no thanks :) , I can't use product from other.

Zitat:

Zitat von Assarbad

Nope.

That's the answers! :-D

I am still trying to block End Task, if I found the way, I'll post to this board :wink:

[rollstuhlfahrer]

Then search for all ways how to terminate a process and block them. The easiest way to do so is to block OpenProcess for all matters (and to handle OnCloseQuery). To let Windows shutdown, Windows is issuing a broadcast message on WM_ENDSESSION. After this message (and the check, that this message came from Windows and not from anybody else issuing WM_ENDSESSION to your window) your program needs to be terminatable.

Bernhard

ADD: Which implies: If someone hooks GetSystemMetrics, and tells your program after issuing the WM_ENDSESSION-Message to your window, your process becomes terminateable even if Windows does not really shut down.

[Assarbad]

Zitat:

Zitat von user (Beitrag 1071897)

Policy from that place. I can't say any reason about this because I just make the program. I am not the boss :p

I guess by writing service, my problem easier to solve. Thanks for the mini-filter.

A mini-filter is going to make it even harder than some UM hooks, but if the users have admin privileges, nothing will keep them from circumventing any of those measures, given they have the necessary know-how.