Re: undestroyable process

Grzegorz,

It could be achieved on higher level using SetWindowsHookEx() API. I've
seen working code hooking OpenProcess this way, preventing obtaining
handle to particular process and returning NULL for it.


Are you sure you haven't confused SetWindowsHookEx() with user-mode IAT
or
disassembly-style hooking???? Since when Windows hooks spy upon API
calls???

Furthermore, SetWindowsHookEx() is meant to monitor only those events
that are somehow related to window management (done by win32k.sys ),
but creation and termination of processes is a pure kernel stuff, which
is managed by ntoskrnl.exe. Therefore, Windows hook procedure is not
going to get invoked as a result of a call to some kernel-related API
function, although it may get invoked as a result of calling
some window management API functions (for example, DestroyWindow())

I'm not sure if you are joking or not right now, but injecting a dll
into other processes is definitely not solution of any kind, it's just
hacking and cracking.

Not at all......

And to inject a dll he would need to run an executable that injects the code, so your objections to b)point would still apply.

Well, my objection to point (b) applies to *ANY* attempt of creating
executable section, including injection of DLL into the fogeign
process, as well as loading it into your own one.

Yes, but what the OP was suggesting the admins are not very advanced
(otherwise as we all tried to convince him, his approach will inevitably
fail), so the purpose of this is to hide his file from the human eye,
moving away from places where admins could manually look, like most
obvious registry entries, etc.

At this point let's ask ourselves a reasonable question - who the heck
the OP is to hide processes, registry entries, create processes that
cannot be terminated by Admins,etc,etc,etc???????? After all, we are
not going to help him with writing a rootkit, are we????

Anton Bassov


Grzegorz Wróbel wrote:
anton bassov wrote:
a) Hooking TerminateProcess() and in your hook procedure check if
process id is of your application.

It can be done, but I don't think the OP is able to handle things like
that - first of all he has to learn basic Windows concepts, so that
hooking SSDT does not seem to be the task he is able to handle

I didn't actually mean altering System Service Descriptor Table. It
could be achieved on higher level using SetWindowsHookEx() API. I've
seen working code hooking OpenProcess this way, preventing obtaining
handle to particular process and returning NULL for it. Result is error
message and process is unkillable unless you obtain handle to it using
for example native equivalent of OpenProcess() API. So what I meant
would be extending this technique to hook TerminateProcess instead and
display some "human friendly information".

b) If you concern that someone could disallow to start your application
at all, you would have to run it using some obscure method. I'm aware of
about 15 different possible startup methods, many unknown by most people

And they still are not going to work if the job of prevention is
handled properly.

Yes, but what the OP was suggesting the admins are not very advanced
(otherwise as we all tried to convince him, his approach will inevitably
fail), so the purpose of this is to hide his file from the human eye,
moving away from places where admins could manually look, like most
obvious registry entries, etc.


can create remote thread for some other process or you can write your
program as dll and attach it to some running critical system

I would say this is the optimal solution in the OP's situation - he
will eventually learn some basic Windows concepts while trying to
inject a DLL into some system process

I'm not sure if you are joking or not right now, but injecting a dll
into other processes is definitely not solution of any kind, it's just
hacking and cracking. And to inject a dll he would need to run an
executable that injects the code, so your objections to b)point would
still apply.


--
Grzegorz Wróbel
http://www.4neurons.com/
677265676F727940346E6575726F6E732E636F6D

.

Relevant Pages

  • Re: RUNDLL32.EXE
    ... 0x66800000 0x155000 Windows Shell Common Dll ... 0x75FA0000 0xA000 BSD Socket API for Windows ... 0x794D0000 0x15000 Microsoft WinSock Extension APIs ...
    (comp.security.firewalls)
  • Re: newbe about API
    ... Emne: Re: newbe about API ... > I found all these API-CALL strings are finally compiled to ... more than that...and Windows simply takes this to an extreme that this ... DLL, when a weak point is found (which, with Microsoft, is something ...
    (alt.lang.asm)
  • Skype codec
    ... user32.dll Windows XP USER API Client DLL ... LINKINFO.dll Windows Volume Tracking ... SETUPAPI.dll Windows Setup API ... MSVFW32.dll Microsoft Video for Windows DLL ...
    (microsoft.public.win32.programmer.mmedia)
  • Can C# Call This DLL?
    ... I need to call a Win32 DLL. ... The API supports both Windows and Linux, ... I'm only concerned with Windows. ... (void * Memblock, ...
    (microsoft.public.vc.language)
  • Can C# Call This DLL?
    ... I need to call a Win32 DLL. ... The API supports both Windows and Linux, ... I'm only concerned with Windows. ... (void * Memblock, ...
    (microsoft.public.dotnet.languages.csharp)
Loading