Monday, September 10, 2012

I'm in ur memoryz scannin' yur kodez.

So I've been slowly working on hacking my pnkbstrk.sys tracer script. It's going pretty well, much better than I thought it would have. In this post I'm going to explain how I built my script along with some of the 'interesting' things I've seen the driver do.

Basically I'm tracing the functions I think are important. Out of the five or so that I created breakpoints for, only three really displayed anything of interest so far. One function that calls KeTickCount I could have *sworn* would be called for doing some anti-debugging checks in kernel mode never ended up being called. I guess it is something that is triggered either randomly, or by a PB admin? Anyways, the three which were interesting were; MD5Update, strlen and memcpy. To see them all check out the latest '' in my auto_ghast github repo. (At least when github comes back up...)

In the mean time here is the pykd code next to the ida function and windbg result of MD5Update.
MD5Update bp + ida + windbg result
You should be able to guess how I got the various addresses by looking at the IDA function call and the pykd code. But just to make sure, I'll explain. First we need to get the RVA of where we will set the initial breakpoint. At first I buggered it up and set my bp at the function entry, which when looking up the address of values by using the offset + ebp, I got the totally wrong address. I needed to set the breakpoint after the function prolog. In this case ee00c373. You'll notice my RVA is 0x6373, this is due to subtracting from the base address, in IDA that would be ee006000 (so ee00c373-ee006000 = 0x6373). But the code will automatically determine the base address by looking up the PnkBstrK.sys driver information when it's loaded. This makes it so there is no need to re-calculate every time the driver is reloaded (which happens to be every time the game is started).

The first value that's retrieved is the length which we dereference ebp+0x10 to get the value. This ends up being 69 bytes. The second value is the buffer address. Which in IDA you can see as being called arg_buf. This is at ebp+0x0c, for this we don't have a value, but yet another address. So we run loadBytes at the address of arg_buf with our length value and print it out. As you can see in the windbg results this happens to be that mysterious MD5 sum I saw a long time ago. The rest is printing out the MD5Context structure which, if you look at the code you'll see how I extract the various members of the structure.

So yeah, that's MD5Update all nicely traced :). Next up was strlen. In this particular run, it basically strlen's the same weird md5 value we see in MD5Update.
strlen doin it's thang
Yeah, pretty obvious. Saving the best for last, we have memcpy. This was the most interesting as I saw it basically incrementing through 0x1000 bytes at a time, doing a memcpy *directly* from userland addresses into a kernel address (pretty sure that's a big no-no but whatever), where, I'm sure it's doing some analysis/checks. Check it out:
memcpy, now things are starting to get interesting...
So yeah I think tracing to see what it does with these blobs of memory after it memcpy's will reveal some very interesting things about PnkBstrK.sys.  Until next time!

Thursday, August 23, 2012


Wow crap, I've been slacking. Sorry about that. At the same time, I sort of haven't because I'm happy to release my really really alpha auto ghast tool. This is basically a framework that I will end up building out to trace punkbuster and any other driver I need to analyze. I plan on doing a more formal write up later but I figured some people who are semi-familiar with pykd will appreciate some of the stuff I'm working on :>.  Basically the idea is to have a method to set breakpoints with callbacks where I can record various registers, values, structures or whatever else I need over the course of running through the driver. In particular for pnkbstrk.sys I want to record all IOCTLs along with various IRP information. You can sort of see what I'm doing in my '' script which I walk through later in this post.

I've also included a built winxp sys driver which is actually just the generic WinDDK ioctl sample driver + exe. If you use the ioctlapp.exe it will install/load the sioctl.sys driver and call it with 4 different IOCTLs. My auto ghast tool was built by repeatedly running/testing with this.

Anyways, here's auto ghast in action recording a single breakpoint:
auto ghast automatically setting breakpoints/recording data
What's nice is all I need to do is set a breakpoint on driver load then run !py and it does the following:

  1. It steps into the DriverEntry function
  2. Grabs the DriverObject ptr and creates a custom 'driver' object that we can use in the program.
  3. By calling driver.get_driver_by_address(esp) it will extract the pointer and give us access to the drivers properties
  4. Prints out the base/end/entry addresses
  5. Runs through the entire DriverEntry function
  6. Extracts the IRP_MJ_DEVICE_CONTROL address (driver.get_device_control_address())
  7. Creates a custom breakpoint object that I've designed. Set's up various information to record for the breakpoint when it's callback handler is called
  8. Sets the breakpoint
  9. Runs the program

What's nice about having a custom recorder is that we can extract/work with various registers, memory addresses or whatever we want for each time the breakpoint is hit. I'll fix up the documentation of it later but please consider this VERY ALPHA!

Finally, thanks to a blog post about pykdtrace which allowed me to figure out that I needed to return DEBUG_STATUS_GO from my debug handler (was banging my head!) to get the dang thing to continue to run.

Check out my ghast git repo for the code!

Thursday, July 26, 2012

Introducing GHAST & Finding PnkBstrK.sys when "lm" fails

So I'm pretty sick of doing stuff manually in WinDBG. Now that I have a decent understanding of how to use pykd (well, mostly anyways...) I'm going to start writing and releasing various scripts that help me automate some of my analysis. I figured I'd make a github git repo for all this code, which I've dubbed GHAST; Game Hacking Adventures Scripts & Tools.

One problem I've been having is that PnkBstrK.sys doesn't show up in the 'lm' output. Not exactly sure why this is but at first I suspected it was removing itself from the PsLoadedModuleList doubly linked list. This is a common rootkit behaviour and I pretty much consider PnkBstrK.sys to be a rootkit at this point. To confirm whether this was true, I wrote a pykd script to walk the PsLoadedModuleList and print out the name, entry point and base address of all modules. Turns out PnkBstrK.sys hasn't removed itself, but for some reason WinDBG isn't listing it.
PnkBstrK.sys in the PsLoadedModuleList, but not 'lm' output.
Now that I have at least the base address and driver entry point, I can start to automate setting breakpoints and dumping out argument values. My goal is to be able to trace and record all of my 'interesting' functions that I've RE'd from my static analysis. I'm halfway done but the above issue is affecting pykd as well so I needed an alternative way to find the base/entry addresses. The above code can be found here. Hopefully now I can get my other script to work. Anyways, keep your eye on my github repo as I'll update whenever I finish any scripts.

Tuesday, July 17, 2012

Constant Love

If you've been following my journey thus far, you may remember a while back when I first started I identified third party libraries in use in the target I was RE'ing due to the values of constants. Well today is my lucky day it appears. Well, technically yesterday, but whatever. While poking through some more functions in IDA I noticed a very long string of instructions that appeared to be doing some sort of hashing/crypto. I deduced this due to the fact that there were a lot of shr, shl, or, and, and not instructions in a pretty specific pattern.
Hmm, this looks crypto'y
I took a few of the above constants; 28955B88h 173848AAh 242070DBh 3E423112h and threw them in to Google to see what I could find. 
We have a winner! :>
After seeing the reference to MD5 I quickly remembered my GUID related post where I found two values that appeared to be the stringified versions of two md5 hashes. I highly suspect this function is used to generate that GUID. I'm still doing static analysis at this point, my next post will probably clarify what is going on by setting bp's in the debugger while it runs. So we have md5, awesome. No one codes their own MD5, so I bet myself that I could find the source they used... For that I headed over to koders code search. I selected C from the language and converted the hex value (28955B88h) to it's decimal form which is 606105819d.

md5.c from RSA. Can't get any more obvious than that. By finding the direct source, I was able to re-label four functions that are the assembly versions of the C code. Here are snippits of the asm alongside the C source:
So we now have four of the md5 functions accounted for and labeled. But continuing my search, I also noticed another function with some pretty unique looking values. Using the same technique above, I took the 9D2C5680h and 0EFC60000h values and koders searched them. To my surprise it turned out to be the Mersenne Twister algorithm, also known as rand() in some languages :>. So now I have two more functions re-labeled to sgenrand(seed) and genrand().
rand()? Why thank you, don't mind if I do!
Overall, a pretty successful find, took longer to write this post than it did to get everything discovered and re-labeled, but hey that's the price you pay for documentation!

Sunday, July 15, 2012

Scripts, Tools and the IDT.

So from my last post I had a few people reach out to me about fixing up dumped modules. Unfortunately, I subscribe heavily to the NIH attitude and ended up writing my own quick python module using the pefile module (note you can pip install pefile as well). All my script really does is set the PointerToRawData to the VirutalAddress value and writes out the changes to a new file (prefixed by new_).

import os
import sys
import glob
import argparse
import pefile

def dump_directory(path):
    for filename in glob.glob(path+os.sep+"*.sys"):

def dump_file(filename):
        print "Fixing up: %s"%filename
            pe = pefile.PE(filename)
            for section in pe.sections:
                print "Updating: %s PointerToRawData 0x%x to"\
                      " VirtualAddress: 0x%x"%(section.Name,
                # Update the section.PointerToRawData to be equal to
                # the VirtualAddress/
                section.PointerToRawData = section.VirtualAddress
            # write the changes
            print "new_%s written to disk."%filename
        except pefile.PEFormatError, msg:
            print "Error %s file is not a PE file? msg: %s"%(filename, msg)
def main():
    parser = argparse.ArgumentParser(
        description='Fixes up the VirtualAddress of drivers dumped from memory.')
                        help='Directory with *.sys driver files.')
                        help='Single file to fix up.')
    args = parser.parse_args()
    if is not None:
    elif args.file is not None:
if __name__ == '__main__':

If you are curious about the recommendations I got. @skier_t recommended his tool rreat. The tool from @iMHLv2 was a pretty interesting looking framework/toolset for memory analysis of malware called volatility. I'll definitely play around with their tools more, but for now i'mma write my own junk :>.

So besides fixing up the image once dumped, I've also been working on looking at the various functions of the driver after it's loaded. I came across two very curious blocks of code. At first, IDA didn't flag them as being functions.
IDA listing just the code as is
But by selecting the start of the function and hitting P, IDA will define it for us.
woo, we have functions! :>
You'll notice in the above code the two comments I added. If you are not familiar with the SIDT and LIDT x86 operands, well they are for storing and loading the Interrupt Descriptor Table. I suggest reading materials (both from phrack) if you want to learn more about the IDT and how they are used for hooking. "Handling Interrupt Descriptor Table for fun and profit" article by kad for a deep technical dive into the IDT and the IDT hooking article by mxatone and ivanlef0u for a more 'windowsy' look.

Anyways, it appears that the above disassembly stores the IDT values in memory, does a modification (*notice the mov eax, dword_EE01033C...) then reloads the modified version back into the idt register. When doing run-time analysis I didn't see anything at that address except nulls, so i'm not really sure what the point of it is yet. Keep in mind i'm pretty new to this whole IDT business as well. I tried setting a breakpoint on the two functions which modify the IDT and I can't seem them being called at any point yet. I think I will need to do more work in this area to get a better understanding of it all.

One thing I did notice however is that I'd like an automated way of inspecting the various interrupt entries. If you love python and you use windbg, you should really take a look at pykd, it's pretty damn awesome. After a few minutes of poking through it's samples I found an old (non-working) script which read the IDT entries. I had to rewrite most of the sample script to run in the latest version, but it works now. It's pretty simple in that it just loops through the IDT entries, extracts the dispatch address, dispatch code and the symbol name and displays it. Here's the code:

from pykd import *
import sys

if __name__ == "__main__":
    if isKernelDebugging():
        dprintln( "check interrupt handlers...\n" ) 
        idtr = reg( "idtr" )
        nt = loadModule( "nt" )
        ErrorCount = 0
        dprintln("idtr is: %08x"%idtr)
        for i in xrange(0, 255):
            idtEntry = nt.typedVar("_KIDTENTRY", idtr+i*8)
            if idtEntry.Selector == 8:
                offset = ( idtEntry.ExtendedOffset * 0x10000 ) + idtEntry.Offset
                InterruptHandler = offset
                kinterrupt = nt.typedVar("_KINTERRUPT",InterruptHandler)
                if InterruptHandler != 0x00:
                        dprintln("IDT [%02x] InterruptHandler: 0x%08x "\
                                 "DispatchAddress: 0x%08x "\
                                 "KINTERRUPT.DispatchCode 0x%08x"\
                                 " (symbol: %s)"%(i,InterruptHandler,
                    except Exception, msg:
                        dprintln("IDT [%02x] empty"%i)
        dprintln( "we are not debugging the kernel..." )

And here's some output from it being run from WinDBG: pykd script, dumpin' some interrupt tables baby!
I think I'm going to become very well acquainted with pykd, because well, doing this kind of stuff manually kinda sucks.

Tuesday, July 10, 2012

Dumping PnkBstrK.sys Part 2: Fixing it up!

You may remember from my last post that I was able to dump PnkBstrK.sys from memory but it "looked weird". As in the addresses, even after I rebased the image in IDA to make them look right, were showing up incorrectly. After a bit of work I've figured out  not only why but also how to get a module/driver/dll that was dumped from memory to "look right" in IDA.

You may remember from the PECOFF specification that the sections of a PE file have some meta-data associated with them. In particular the IMAGE_SECTION_HEADER. This section has the name, the VirtualSize, address of the section in the image as well as the address of where it will be when the image loads, also known as the VirtualAddress. This is the important part. Because what is on disk versus what is loaded into memory is quite different due to section alignment. Here's what the files look like side-by-side in 010editor.
The difference between the file from disk (left) and the one dumped from memory (right)
 You'll notice in the above image there's a large section of null bytes that doesn't exist in the file from disk. This is due to the value of the VirtualAddress section of the PE file for each section. It basically is aligned at 0x1000 so it injects a bunch of null bytes by the loader. If you attempt to load the file as is into IDA Pro you'll get something that looks like the below image.
The file that was dumped from memory, rebased, but the DriverEntry is totally wrong.
 When I first loaded it, the DriverEntry point was totally off. That's because IDA Pro is reading the PointerToRawData value of the PE file metadata struct and assuming that the entry point is where it says it is: at 0x400 in the case of the .text section. This of course is wrong because the dump from memory was aligned differently (adding about 0xc00 of null bytes). With that mystery finally solved (after much head banging, I assure you.) I fixed the PointerToRawData values for each section in 010editor.
Fixing the values for each section for (updating PointerToRawData values)
I then attempted to reload the dumped driver into IDA for analysis again. At first I tried to rebase on load (again selecting the "Manual Load" and "Load resources" check boxes) but that turned out to be incorrect as well, as you can see below.
Looks "ok" but some offsets are pointing to the wrong place!
This was annoying as I wasn't really sure how to fix this problem. After mucking around for a while in IDA Pro's rebasing abilities (Edit ->  Segments -> Rebase program...) I found if I unchecked the 'Rebase the whole program' I'd get a proper load with all offsets pointing to the right part of the PE file.

 After all that, I finally got the driver dumped from memory to look like the one extracted from the disk.
The image with all sections correctly resolved and displayed.
And that's pretty much it! Now I know how to dump drivers directly from memory and fix them up to be able to analyze with IDA Pro easier. Hope this saves someone the headache!

Tuesday, June 26, 2012

Dumping PnkBstrK.sys

So I finally had a few hours to sit down and muck around in driver land tonight. I learned a few useful things about WinDBG which I kind of which I had known before. This reminds me I should probably read WinDBG A-to-Z from back to front (or front to back, sheash I've been in Japan too long) at some point.

Once again I started from the beginning and traced through the first IOCTL coming in. I tried to look for any sort of patterns but again my boredum got the best of me and I kind of gave up. One thing I know is that it is occuring in some sort of loop. I set a break point on the below address because it jumped back to this point a number of times in the code.
.reloc:EE05BB4E                 lodsb

For those who aren't aware, lodsb basically will take a byte out of ds:esi and store it in al (because we're doing a Load Store Byte). It then increments or decrements esi depending on the df (Direction Flag). By looking at the following code, sure enough eax appears to be a register of importance. One thing I realized I *should* have done, and probably will do once I get some more free time is to totally disregard all the stupid register operations that are going on in this loop and concentrate on one important factor.

When do the values of registers get *written* to locations in memory? This is a very important operation because this is what will give away what it is doing. I need to see if it's writing to the driver itself? (self modification) or writing to some objects in memory, or doing something else crazy. So this is really where I should have concentrated my efforts better. Instead I was 'getting a feel for it' also known as 'not having a fucking clue what I'm doing'.

So I set a breakpoint at the lodsb operation in the .reloc section to print out what exactly esi was pointing to. After a few bagillion operations I got a nice table of what byte it was pulling from esi and storing in al.
The command I ran was:
bp ee05e11d ".printf \"esi: %08x ds:esi: %08x\r\n\",esi,by(@esi); g"

This basically sets a break point and tells it to call the printf function displaying both what esi is, and the low-order byte that esi points to (note the 'by()' function). Then it tells it to continue running. So I got this enormous table which, is pretty friggen useless to me. While I'm sure if I had time I could script something up to recreate exactly what it is doing, I still hadn't looked at what it's doing with the value once it got into the al register.

So even though I am pretty tired of looking at this loop I will need to go back to it and look for any when registers are dereferenced or direct memory locations are referenced for mov or write operations. So I can see what it's modifying. This shouldn't be too hard I think, because from what I could tell it wasn't modifying the loop itself, just other parts of the driver.

So to do something a bit different I decided that maybe I should just dump the driver's memory while it's running during various IOCTLs and see if I can see any major changes. After a bit of searching I found out you can dump arbitrary memory by using the .writemem command. This takes addresses/ranges and will spit out the resultant bytes to a file. In my case I ran:
.writemem c:\temp\pnkbstrk_dump_ioctl1.sys 0xEE050000 0xEE073FF6 a few times with varying filename parameter values. The 0xee05000 is of course the base address and 0xee073ff6 is the end of the file.
i'm in ur memory, dumpin' ur codes.
So now I have three new driver files to look at. Oddly enough they look very different from the one from on disk and I'm not entirely sure why, but there's enough similarity in them to lead me to believe it's just what is in memory, so whatever. For example when the first IOCTL is called the DriverEntry function looks waaaaaaaaaay different then the one I'm working with in IDA (pulled from disk). Even though, I think, none of the self modification code has been called yet? If someone could explain how the hell this happened I'd appreciate it :>.

Anyways, the most striking difference I found is the relocation table/fix up code that I RE'd a while back. You may remember it was a series of 1000xxxx values that get rewritten to include the real address. Anyways here's what they look like side by side after the first IOCTL has been called.
yehp, symbol names.
The other thing I noticed was another area around this section of the driver that contained a very curious ID. So curious that I think it might be my GUID, the one that EvenBalance/PunkBuster use to global shit ban people. This is the first time I've seen it so I'm totally jumping to conclusions on that. Anyways, since that *may* give away who the hell I am, i'mma muck with it in the image below:
My guid? Maybe? Notice the BFP4F in the middle of it...
It's a 69 byte long string with BFP4F in the middle of it. The first section (before the BFP4F string) is 24 bytes, the second section (after the BFP4F) is 40 bytes. Both sections are stringified hex strings, as in a string representation of the hex bytes. So yeah, maybe two 32 byte md5 hashes with a BFP4F thrown in the middle to split them up? I dunno... yet!

Thursday, June 7, 2012

Tedious Boring Work (Obfuscation 1, Me 0)

I really do want to be posting more, and exploring more and learning more. But right now I'm stuck in state of tedium. The past few attempts at looking at PnkBstrK.sys have left me pretty bored. Right now the majority of the code is doing some sort of silly obfuscation and is just fixing up addresses and data. After the first IOCTL is sent to the driver, the IOCTL instructs the driver to fix up some table of addresses. In IDA we can see this table of pointers in it's base address form.
A table of pointers that are to be 'rebased' during execution
 You can see from my comments in the above code that various registers contain the address of the driver in memory, which in a below function are used to recalculate the table and update it to point to where the driver is loaded for the current execution run. This table, when all is said it is updated to look like:

ee05b844 ee05e046
ee05b848 ee05c997
ee05b84c ee05d719
ee05b850 ee05bc4d
ee05b854 ee05f5f1
ee05bad0 ee05c842
ee05bad4 ee05c049
ee05bad8 ee05f3e4
ee05badc ee05eff3
ee05bae0 ee05cc3c

While that part of the code is easy to understand, what isn't easy is the next part.
The rest appears to just be doing arithmetic to change various addresses both in the stack and in the registers. It's so boring and tedious that I find it hard to walk through more than a few functions at a time before I give up and go do something else.

I guess, that *would* be the entire point of obfuscation :>. However, I don't plan on giving up, but forgive me this might take a bit longer because, well, it's boring as shit. Someday when I have more free time (right now i'm clocking in about 1-2 hours a week looking at this) I'll sit down and run through the entire process to see if there are any patterns I can extract on what it is doing from a more high level view point.

Friday, May 25, 2012

Manually Loading Segments in IDA

It's been a while since I posted. Mainly because I took a two week trip back to America and totally forgot to copy over IDA. Now that I'm back and my jetlag has subsided a bit, I'd like to post a real quick update on how to get IDA to load that 'hidden' data from PnkBstrK.sys. While the '.reloc' section wasn't marked in the PE, the hidden data, according to IDA is simply the .reloc section. Apparently, to get it to load you need to do a Manual Load when you first do your analysis. If someone knows how to get IDA to re-analyze the file and not lose your comments/symbols that you've added I'm all ears.

Since I couldn't figure out how to do that, I decided to just reload the file and manually add in my comments again. When you first load a new file you have a number of options to chose from.
Make sure to select 'Load resources' and 'Manual Load'
After selecting the Manual load and Load resources check boxes go ahead and click OK. You'll then be asked if you want to specify a new base image (rebase). Since my VM image is locked with the driver loading at EE118000, I decided to set the base image to that so I don't have to do any math when I'm comparing addresses.
Setting a base address to my VM image's driver location.
Finally, the part we really need, is to have IDA ask us which segments we want to add for analysis. You'll notice here that the last one is what we need, the '.reloc' section. Why this isn't done by default I'm not exactly sure, but after loading this you'll be able to see all that extra hidden code that PnkBstrK.sys has. This will make our analysis much easier in the end. 
IDA asking us which segments to load.
As you can see in the final image, our new IDA window on the left shows the jmp address as going to a valid location.

Left: Valid analysis with .reloc address, Right: Old version jumping to unknown address
That's pretty much it, now I can properly trace all the calls to the code outside of the .text/.data sections that PnkBstrK does.

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!