{"id":4719,"date":"2018-04-01T00:03:13","date_gmt":"2018-04-01T00:03:13","guid":{"rendered":"http:\/\/www.hexacorn.com\/blog\/?p=4719"},"modified":"2018-04-02T00:12:15","modified_gmt":"2018-04-02T00:12:15","slug":"curious-case-of-the-conhost-exe-and-condrv-sys","status":"publish","type":"post","link":"https:\/\/www.hexacorn.com\/blog\/2018\/04\/01\/curious-case-of-the-conhost-exe-and-condrv-sys\/","title":{"rendered":"Curious case of the conhost.exe and condrv.sys"},"content":{"rendered":"

Update<\/strong><\/p>\n

After I posted the question to Twitter, Alex Ionescu<\/a> (god of NT kernel internals, for those who don’t know) suggested<\/a> 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.<\/p>\n

\"\"<\/a><\/p>\n

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):<\/p>\n

->Import Table\r\n 1. ImageImportDescriptor:\r\n OriginalFirstThunk: 0x0000A1AC\r\n TimeDateStamp: 0x00000000 (GMT: Thu Jan 01 00:00:00 1970)\r\n ForwarderChain: 0x00000000\r\n Name: 0x0000AA04 (\"ntoskrnl.exe\")\r\n FirstThunk: 0x00002088\r\n\r\nOrdinal\/Hint API name\r\n ------------ ---------------------------------------\r\n 0x00FF \"ExReleasePushLockExclusiveEx\"\r\n\r\n\r\n 0x0002  <------- import by ordinal\r\n 0x05C1 \"ObCloseHandle\"\r\n 0x067F \"PsGetProcessImageFileName\"\r\n 0x0001  <------- import by ordinal<\/pre>\n
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.<\/p>\n
Old Post<\/strong><\/p>\n
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.<\/p>\n
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).<\/p>\n
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.<\/p>\n
Quick google search followed and I re-visited an excellent posts from FireEye:<\/p>\n