You are browsing the archive for Reversing.

Kernel hacking tool you might have never heard of – XueTR/PCHunter

April 20, 2018 in Reversing, Tips & Tricks

It is a good habit to keep your eyes open and monitor the updates to your favorite tools. I do it ‘religiously’ and comb the internet for the updates every once in a while. I know that some of these tools are never executed on my host machine, but they deliver an extremely unique and valuable interpretation of the system internals that I can act upon so I always want to have the latest, the best.

You definitely used Sysinternals tools, including the Process Explorer, and the Rootkit Revealer. You might have heard, or used GMER.  Same for the RKU. Same for the Kernel Detective.

At least three of these tools were amazingly popular in the first decade of this century as they allowed to poke around things that other tools could only dream of. They were really ahead of a curve as they allowed to access the system in a nearly forensically-sound manner, unhook kernel and user mode hooks, scan the whole memory for badness and overall, really help to deal with a lot of nasty code from those days… One couldn’t imagine a manual system repair of a system infected with a rootkit w/o one of these tools…

Now it’s 2018, and Windows 10 is out there.

What tools can we use?

Most of the aforementioned tools are kaput.

There is some light though…

Enter Process Hacker
– a  much better tool than Process Explorer.
I love Process Hacker and am really happy that it works on Win 10 pretty well.

While the official build is 2.39 and is 2 years old, there is a ‘nightly’ build you can always try to play with:

The last build, as of this post writing, is 3.0.1424 and is from 18/April/2018.

Yay! Go and get it!

Now… the one I want to talk about though is XueTR/PCHunter.

I bet you never heard of it.

I have recently discovered that the author released a new version (in March 2018). The current version is 1.53 and according to the blog post it was tested with Win10 (16299).

Mind you. This is after 5 years of a hiatus on his blog, so this is great news that the author picked up and updated the tool.

Now… before we begin – please note that the free version of PcHunter works on 32- and 64- bit Windows 10, and can’t be used commercially. This is explained in the About tab:

With that out of the way, we can explore the main interface.

When you execute the main 64-bit .exe (PCHunter64.exe) you will be presented with this UI:

The interface is (not a surprise) similar to GMER/RKU and to Kernel Detective.

There is a bunch of tabs we can browse through and which explore the Windows 10 internals in details:

  • List of processes
  • Kernel Modules
  • Kernel ‘Stuff’
    • Notify routines (e.g. these that notify the driver about a new process being created)
    • Filter
    • DPC Timer
    • Worker thread
    • Hal
    • Wdf
    • File System
    • System Debug
    • Object Hijack
    • Direct IO
    • GDT
  • Ring0 Hooks (including IRP+inline)
    • SSDT
    • ShadowSSDT
    • FSD
    • Keyboard
    • I804prt
    • Mouse
    • Partmgr
    • Disk
    • Atapi
    • Acpi
    • Scsi
    • Kernel Hook
    • Object Type
    • IDT
  • Ring3 Hooks
    • Message Hooks
    • Process Hook
    • KernelCallbackTable
  • Network
    • Port
    • Tcpip
    • Nsiproxy
    • Tdx
    • Ndis Handler
    • IE Plugin
    • IE Shell
    • SPI
    • Hosts file
  • Registry (browser)
  • File (system browser)
  • Startup Info
    • Startup
    • Services
    • Scheduled task
  • Other
    • File Association
    • IFEO (Image File Execution Options)
    • IME/TIP
    • Firewall Rule
    • User Name
    • Other (additional tools)
  • Examination (forensic-like report)
  • Setting
  • About

I am not going to include more screenshots. Download. Test. Make up your mind.

I think the tool is pretty cool and worth at least checking.

Curious case of the conhost.exe and condrv.sys

April 1, 2018 in Puzzles, Reversing


After I posted the question to Twitter, Alex Ionescu (god of NT kernel internals, for those who don’t know) suggested that it could be an export by ordinal from the ntoskrnl.exe. It was not the case in this scenario, but it’s a very good direction for investigation and I didn’t think of it when I encountered the issue.

Following on that lead I dug deeper. Further inspection of the condrv.sys driver confirmed that at least 2 functions from ntoskrnl.exe are imported by the ordinal (0x0001, and 0x0002):

->Import Table
 1. ImageImportDescriptor:
 OriginalFirstThunk: 0x0000A1AC
 TimeDateStamp: 0x00000000 (GMT: Thu Jan 01 00:00:00 1970)
 ForwarderChain: 0x00000000
 Name: 0x0000AA04 ("ntoskrnl.exe")
 FirstThunk: 0x00002088

Ordinal/Hint API name
 ------------ ---------------------------------------
 0x00FF "ExReleasePushLockExclusiveEx"

 0x0002  <------- import by ordinal
 0x05C1 "ObCloseHandle"
 0x067F "PsGetProcessImageFileName"
 0x0001  <------- import by ordinal

so Alex’s explanation points us in a right direction, except the issue is the import table of condrv.sys, not the export table of ntoskrnl.exe; IDA somehow assumes the names of the ‘guessed’ service functions based on the ordinals and does it wrongly – this is what causes confusion and ends up with us staring at an incorrect disassembly.

Old Post

A few months back I came up with an idea to find out how the conhost.exe process is spawn by the OS to co-exist with pretty much every single console applications on the system.

I theorized that if I find out how it is spawn, I may be able to possibly influence this process and make it behave differently from the expected (wishful thinking that perhaps I could find a way to run this process anytime I want and hijack it for e.g. process hollowing or sth along these lines).

After looking at the code of the AllocConsole function (which is a prime suspect here as it allocates consoles after all), I eventually landed in the code that calls NtDeviceIoControlFile with the IOCTL 0x500037.

Quick google search followed and I re-visited an excellent posts from FireEye:

where the very same conhost.exe spawning mechanism is also described, although briefly.

So, there is a way to launch a conhost.exe process bypassing all the WinExec/ShellExecute/ShellExecuteEx/CreateProcess/CreateProcessInternal/etc. API layer. Still, there is no easy way to obtain the handle to that process so the malware that would try to use it would still need to find that process and hijack it. It looks like OS designers took the malicious bit into account and made it a bit harder for the coders to abuse it.

The reason for this post is not the mechanism itself, but the curious issue I encountered while analysing the condrv.sys driver. It is the driver that actually receives the IOCTL 0x500037 and processes it, calling the ZwCreateUserProcess routine in the end, at least, this is my working hypothesis at the moment.

Why hypothesis?

When you analyze the the driver w/o symbols, the system routine the driver calls to launch conhost.exe is not ZwCreateUserProcess, but ExAcquireRundownProtection. A very strange choice. It is only applying the .pdb file to IDA will allow to map that call to ZwCreateUserProcess. Could it be an intentional way to obfuscate the calls? Or, am I missing something? I will admit my kernel mode analysis skills are really rusty.

Ideas, anyone?

This is what I see inside the condrv.sys without symbols (see that 2nd functions):

and with symbols: