(sorry for my very bad english)

Hello!

I need hide a process (don't show it in Task Manager)
in Win2000, NT and XP.

This code work in Win95/98 using a semi-documented(?) function:

*****************************************************
.data
kernel32 db 'kernel32.dll', 0
sFunc db 'RegisterServiceProcess', 0

.data?
RSP dd ?

.code
...
invoke GetModuleHandle, ADDR kernel32
or eax, eax
jz lblError

; we must get the address
; of semi-documented function.
invoke GetProcAddress, eax, ADDR sFunc
or eax, eax
jz lblError
mov , eax
push 1 ; hide
push 0 ; 0 = this process
call RSP ; call it

lblError:
...

*****************************************************

In Win2000/NT is posible???

Thanks in Advance.
Posted on 2004-04-20 20:09:48 by Avrin
Posted on 2004-04-20 20:30:02 by smurf
OK! Thanks for old news! ;)
Posted on 2004-04-20 20:52:19 by Avrin
Hi, avrin

In Windows NT/2k/XP/2k3, the only safe way
is using device drivers.

Until now, its not possible to hide processes
from Klister utility. It displays all the processes
because it reads the internal windows scheduler
list of threads.

Klister v0.4

Regards,
Opcode
Posted on 2004-04-22 06:41:21 by Opcode
RegisterServiceProcess works only in Win 9x
Posted on 2004-04-22 12:25:19 by Vortex
Without even pausing to question why you wish to hide processes from the task manager, may I suggest that you look into a method which nobody has mentioned in this thread yet - injecting the process to be hidden into a remote thread in another process !!! You choose a target process that is known to exist (something like explorer.exe), inject self into target, make a call to begin remote execution, and then terminate original process - no need to hide it because it's now DEAD.
The clone of the original process has modified its own entrypoint to some code which fixes up the import table with respect to its new address space (a reloc stub), and then hands control to a given procedure.. your injected process shares the same Process ID (PID) as the process into which it has been injected - which opens a few possibilities in terms of doing things like subverting local security where security is based on PID's of trusted processes (many software firewalls, for example)..
This method works on 98, me, 2k and xp.

PS - this "klister utility" - does it operate on PID's or on TID's - and are you sure?
I'd wager without having seen this utility that in the interests of efficiency it examines PID's only, associating each PID with the name of the executable which created it, but not spending as much time examining the possibly numerous Thread IDs for a given Process...
Posted on 2004-04-22 22:59:58 by Homer
Windows scheduling is thread based, not process based.
The scheduler uses 3 lists to control threads:



_KiDispatcherReadyListHead
_KiWaitInListHead
_KiWaitOutListHead


The tree lists are circular-linked lists of KTHREAD structures.
Each KTHREAD has a pointer to the owner process, or
the EPROCESS structure. All these structures are in
the kernel memory area.

The version 0.3 of klister uses the PID to identify the
processes, but after the launch of the PHIDE utility that
change the PID of theses structures, now the version
0.4 looks only for the address of each EPROCESS
structure, which is unique.

There are some "process injection detector" projects
in the security community, based on looking for the
objects from the original process, by inspecting the
internal handle table of the process.
If you inject some process into another, these table
is not changed, so it is a easy job to detect.
Using the PsSetCreateThreadNotifyRoutine in
the kernel is useful.
Anyway, process injection is easy detectable in
user-mode, because windows kernel creates
too many internal structures to trace each
process. Device-drivers are a better approach.

Regards,
Opcode
Posted on 2004-04-23 06:23:00 by Opcode
@Opcode: the link to Klister did not work for me here. Could you please post it in the forum? :)
Posted on 2004-04-23 15:22:45 by QvasiModo
Afternoon, Avrin.

Why do you wish to hide your process from the task manager?

5...

Cheers,
Scronty
Posted on 2004-04-23 22:48:47 by Scronty
I would certainly like to know too. Nice that this shady topic has brought ought klister though, that utility might be of quite some use when dealing with evil code.
Posted on 2004-04-23 23:08:38 by f0dder
Afternoon, Avrin.

4...

Cheers,
Scronty
Posted on 2004-04-24 10:33:03 by Scronty
Posted on 2004-04-24 11:01:41 by Criminal2

@Opcode: the link to Klister did not work for me here. Could you please post it in the forum? :)


Klister v.0.4 is attached.

Regards,
Opcode
Posted on 2004-04-26 05:57:21 by Opcode
Afternoon, Avrin.

3...

Cheers,
Scronty
Posted on 2004-04-26 07:47:31 by Scronty
To Scronty,
Hiding a process is in it self not *forbidden* code. The aims to what they might be used for can be. We run a login agent in the internet cafe, that hides itself from the users to we don't have to worry about the time counter on the individual machine.

This is only one example, manny more can be aplied within a work enviroment. Anyway, if *forbidden* code is coded by an individual and he then has to use it - and by me - he'll be held responsible for it. I don't think this form will be. Anyway, hiding a process...

Avrin, if you return to this post before Scronty reaches Zero, please just give him a good reason...

Regards,
Black iCE
Posted on 2004-04-26 21:25:26 by Black iCE
There are uses, but most of them will be malicious. If you don't want the user to terminate your timecounter, run it as a service with higher privileges than the regular login user.

I'd like to hear avrin's reason for hiding a process, too.
Posted on 2004-04-27 03:19:23 by f0dder