[listito]

Hello guys, i'm reversing a software which is listing all processes without calling process32next() and it's in usermode, is there really any other way to do it?

[rkhunter]

ntdll!NtQuerySystemInformatiom, SystemProcessInformation class
http://msdn.microsoft.com/en-us/library ... s.85).aspx

[EP_X0FF]

Hello guys, i'm reversing a software which is listing all processes without calling process32next() and it's in usermode, is there really any other way to do it?

PSAPI, http://msdn.microsoft.com/en-us/library ... s.85).aspx
Documented and supported way, in fact based internally on the same Native API calls.

[listito]

thanks guys, very interesting how the most of api's exported by ntdll.dll got the Zw prefix instead of Nt hehe :)

the program was calling enumprocess from psapi

[Alex]

You may wonder why Table B-1 provides two columns for ntdll.dll and
ntoskrnl.exe, respectively, labeled ntdll.Nt*, ntdll.Zw*, ntoskrnl.Nt*, and
ntoskrnl.Zw*. The reason is that both modules export two sets of related Native
API symbols. One of them comprises all names involving the Nt prefix, as listed in
the leftmost column of Table B-1. The other set contains similar names, but with Nt
replaced by Zw. Disassembly of ntdll.dll shows that each pair of symbols refers to
exactly the same code. This may appear to be a waste of memory. However, if you
disassemble ntoskrnl.exe, you will find that the Nt* symbols point to real code and
the Zw* variants refer to INT 2Eh stubs such as the one shown in Example 2-1. This
means that the Zw* function set is routed through the user-to-kernel-mode gate, and
the Nt* symbols point directly to the code that is executed after the mode transition.
Two more things in Table B-1 should be noted. First, the function NtCurrentTeb()
doesn’t have a Zw* counterpart. This is not a big problem because the Nt* and Zw*
functions exported by ntdll.dll are the same anyway. Second, ntoskrnl.exe doesn’t
consistently export Nt/Zw function pairs. Some of them come in either Nt* or Zw*
versions only.

The Windows 2000 Native API
Kernel API Functions (Table B-1)

[Brock]

PSAPI / ToolHelp / BruteForcing PIDs with NtOpenProcess/OpenProcess with GetModuleFileNameEx / PEB access to LDR_MODULE / NtQueryVirtualMemory with class of SectionNameInformation on ImageBase of executable (also contained in PEB), NtQuerySystemInformation to get threads and process list etc. CSRSS also contains PIDs of processes which *register* with it, this can be traversed as well.

PSAPI and ToolHelp just wrap these methods when it all boils down to it, primarily native calls (NtQuerySystemInformation / NtQueryVirtualMemory with section name of image and usermode PEB module name in linked-lists)

Many ways to enumerate processes :lol: