Monday, April 23, 2012

Sneaky Sneaky... PnkBstrK.sys's hidden code.

As you might recall from my last post I'm now in the process of determining what the IOCTLs do. There was however one thing that was really bugging me. I didn't allude to this yet because I figured I was doing something stupid and just didn't understand how the driver's code was being mapped into memory by Windows. It turns out PnkBstrK.sys is doing something a little bit sneaky. Before I get into showing what they are doing,  I want to describe the problem.

When attempting to determine what the IOCTLs are actually doing I was noticing the first IOCTL that was "attempted" was calling a function which after doing some oddness, was jumping into some memory location that wasn't showing up in IDA. The first IOCTL that is seen by our DeviceControlDispatchHandler function is 0x2261c0.
First function that is called from the 0x2261c0 IOCTL.
 This function clears out some addresses and moves the value 0x3f onto the stack. Then jumps into some unknown address.
A jmp into an unknown memory address.
This is where I was stuck. I had no idea where this memory location was coming from. So I figured they were jumping into a non .text section. If you aren't familiar with the various sections of a PE file I suggest reading the PECOFF document from Microsoft. So in IDA you can look at the various segments by hitting "Shift+F7" or View->Open Subview->Segments. Here's basically what I saw:
PnkBstrK.sys segments
You'll notice none of those addresses are within range of our 'unknown' jmp address. Ok so now what? I honestly had no idea. When debugging the driver and that ioctl is called, it jmps to the unknown address but magically a valid code block is there. But how? I can't see any of the data in the segments and I certainly can't see any data in the .text segment. I called shenanigans.

I totally reset my vmware image thinking that some how during installation it was doing something to create this page in memory without me catching it in time. My first suspicion was that code was being called before the DriverEntry method. I searched all over Microsoft documentation to see if there was any other way of calling a driver besides the DriverEntry function. While I found out there is, it's only if you rename the DriverEntry function to something else (which this driver is not doing).

So I decided to look at something else. I loaded up PEiD which is a tool for looking at the segments. My thought process here was that they were doing something to trick IDA Pro. Here's what PEiD reports:
PEiD section output
OK so, basically the same thing. So I went back to WinDBG to see if there were any other hints. You may remember from a long time ago, one of the methods I use in RE'ing (because I suck at it) is to use surrounding data as possible hints to what the code is doing. In this case I am looking at surrounding data to find hints as to where the code came from. So here's what I see at that address in the data output (instead of looking at the disassembly) of our "unknown" address:
The data at our unknown address. Note the VeriSign certificate information
OK so that is a pretty good hint. So going back to IDA I searched for the string VeriSign (alt+T to search for text) and guess what. Absolutely nothing. So I had one last thought. Maybe it's not really contained in a valid segment at all, maybe it's contained in the binary and they're doing a hardcoded jmp? So I want to look at the PECOFF structure. For that I use 010Editor with the PECOFF template. I load the file, open the template and run the template against PnkBstrK.sys. I notice the following bits of data:
Overlay? What the hell is that?
So there's this 'overlay' section, and the data?
There you are! You sneaky bastard!
So in the EXE template I looked at how 'overlay' data is generated and I found they simply check:

if(max < FileSize()) {
   BYTE Overlay[FileSize()-max];

That is all they are doing. PnkBstrK.sys isn't creating a section for it, they're just appending the data which will still get mapped into memory and then they are 'hardcoding' the jmp to the offset into this extra data area. Pretty sneaky.

It is almost like a magic trick, at first it seems like magic, then you realize you're just an idiot for not knowing how it worked to begin with.

NOW I can start to figure out what these IOCTLs do :>

Tuesday, April 17, 2012

Kernel Hacking Is Hard (KHIH)

Besides totally slacking on game hacking, I have taken the time to read four documents from Microsoft which I felt were important for gaining at least a bit of understanding of this driver craziness.
1. Architecture of the Kernel-Mode Driver Framework
2. Architecture of the Windows Driver Foundation
3. I/O Flow and Dispatching in WDF Drivers
4. Handling IRPs: What Every Driver Writer Needs to Know

Since I have a little (and I mean very little) understanding of drivers, I do have a bit of a suspicion that the PnkBstrK.sys driver is simply reading in custom IOCTLs and acting upon them. However, I wanted to confirm this. I did a bit of reverse engineering of the PnkBstrK.sys DriverEntry function. You'll notice in my IDA output I renamed a lot of things (and added comments) to make understanding what was going on a bit easier. Remember ';' for adding comments and right click -> rename for renaming labels/functions whatever.
PnkBstrK.sys DriverEntry function.
It's a pretty standard setup, loop over and set all IRP handlers to the same function. Except one, you'll notice at .text:10033FB (I renamed DeviceControlDispatchHandler) a function is moved into an offset into the DriverObject structure.  Initially when analyzing this, I missed that line and during debugging sessions always ended up going to the same stub dispatch function which did nothing. So what is this special handler? This is actually the dispatch handler that will handle the IRP_MJ_DEVICE_CONTROL "event" or whatever the hell they're called in kernel land. All of the other handlers don't do anything but accept the IRP and pass it on/finish it.

Later on, you'll notice a call to IoCreateDevice with the "\\device\pnkbstrk" as the device name. Further down in the code a symbolic name "\\DosDevices\\pnkbstrk_link" is also created which the user-mode applications will most likely call. However, I have yet to verify this.

Which is actually my biggest problem, trying to figure out how user-mode code calls into this driver. After searching around I found a really good forum post on how to gain a bit of additional information when debugging drivers. From that post I learned if you are actively debugging PnkBstrK.sys there's a way you can determine what IRP handlers are mapped to. In WinDBG you run "!drvobj PnkBstrK 7" which gives the following output:
PnkBstrK.sys IRP dispatch handlers
You'll notice they're all set to the same address, except one: [0e] IRP_MJ_DEVICE_CONTROL. This is what I believe the user-mode code calls to interact with this driver. So my next step(s) are to do a bit of analysis of this device control handler function. For that I turn back to IDA.

Here's what the device control handler function looks like by itself:
device control handler function with no comments/names.
So that's not really helpful. Again, taken from that above post he suggests including the IRP and IO_STACK_LOCATION structures into the IDA session. This ends up helping a lot. How do you add structures? It's pretty easy, click on the 'structures' tab of your IDA view and hit the 'Insert' key. Next click 'Add standard structure'. Then find the IRP structure (or _IRP).
Adding the IRP structure to IDA
Do the same for the IO_STACK_LOCATION structure and go back to the device control dispatch function at .text:10002fC0. Now we can change Irp+60h to [eax+IRP.Tail.Overlay.anonymous_1.anonymous_0] by selecting the 60h part and hitting 'T' and selecting the proper value. Not sure why it's that structure value, but whatever, that's what the dude from the forum said. Three lines below that you'll see a mov eax, [edx+0Ch]. This can be transformed to: IO_STACK_LOCATION.Parameters.DeviceIoControl.IoControlCode which looks a bit more reasonable to me. Here's what I've come up with for this segment of code after doing some initial analysis of it:
DeviceControlDispatchHandler with comments.
Of course, I've just started doing this reverse engineering so there are two things to keep in mind; I'm not done yet and I could totally be wrong. Trying to figure out what the Irp+60h value pointed to turned out to be challenging for me. I looked through the 'wdm.h' header file and found the _IRP definition but without looking up all it's members, I have no idea what the 0x60h offset points to. Again, the forum post I mention earlier helps clear that up, but I hadn't read it at that point. If you haven't already, I seriously suggest going back to read it.

*After* reading that post, I tried running the commands he mentioned to see what the structures look like from WinDBG, but it went horribly wrong. Mainly because I wasn't referencing the value correctly.
Attempting to display the IRP struct values using the wrong value.
Next I waited until ECX got set to the value of the IRP structure and tried again:
_IRP.Tail (0x40) + CurrentStackLocation (0x20) => 0x60 = IO_STACK_LOCATION (I think?)
So this looks 'better' but the 'memory read errors' throughout the structure references makes me think I might be wrong. OH WELL. I'm sure it'll all become clear the more I work with this stuff.

Of course, next up is reversing what the different IOCTLs actually do. That might take me some time, but I'll keep at it, don't you worry.

Wednesday, April 4, 2012

Punking PnkBstrK.sys

Man talk about being out of ones league! So I've been spending the last few days trying to brush up on how to reverse Windows Kernel drivers. First step was flipping through pages of Rootkits: Subverting the Windows Kernel to learn the basics of how kernel drivers work. I really have never looked this deep before. There is one problem with using that book as a reference, being you know, trashed by Lulzsec. So the links to example code and utilities no longer exist.

I thought it wouldn't be all that important and I could simply connect my kernel debugger, start a game and watch the driver being loaded (by setting "bp PnkBstrK!DriverEntry" in WinDbg). Boy was I wrong, I don't know if they're doing something special to hide themselves but I couldn't for the life of me break on the driver being loaded. At first I thought I was doing something wrong, so I set the debugger to break on any module load. This can be done by breaking in the current session and going to Debug -> Event Filters and enabling the on module load option.
How to break on module loads (provided they aren't f'ing with you)
So I did this, then hit '.reboot' and watched every driver load. You can get the driver name by using the '.lastevent' command on break.
Using .lastevent on driver load
So, I watched, every, stupid, friggen, driver load (there's a lot by the way). But I never saw PnkBstrK.sys load. What was really strange was I started up a game, then quit out then used Ctrl+Break to cause WinDbg to send a break. I then ran "lm" to see what modules were loaded. I started to see PnkBstrK under the Unloaded section. But.. I could never actually *catch* it loading.
Game loading the drivers, and showing pnkbstrk being 'unloaded'

So how the hell do I break into it? Well first off, I wanted to make sure it was actually being loaded and have 100% control over loading and unloading the driver. To do this the Rootkit book suggests using InstDrv.exe, which as far as I can tell doesn't really exist any more. So instead I found a new tool to help in loading and unloading. I found a tool called WinDriver from Jungo which has a helper tool called wdreg.exe which you can use to load/unload drivers.
Using wdreg to load PnkBstrK
By running the command "wdreg.exe -file PnkBstrK install" you can have the PnkBstrK.sys driver loaded and installed. Notice you don't pass the .sys and you are also required to use the full path (I copied it to the WinDriver directory). So I kept loading/unloading and *still* wasn't able to break. So I started searching around for other methods. Some forums suggested using WinDbg's "bu" command. This did not work. Next I visited openrce to see if they had any tips and found this. Which inevitably lead me to searching for and setting a breakpoint on IopLoadDriver. As an added bonus I found a tweet by stupid smart @Ivanlef0u which was the command I needed:
bp nt!IopLoadDriver+0x66a . Yeah that pasted big, but you know what? I don't care, it deserves that font size, because it friggen worked.
call'ing into PnkBstrK.sys FINALLY!
Now I can start to figure out their dinky little xor obfuscation and see what ioctrl's it uses with the various services... Yay!