Windows 7 API Hooking

February 25th, 2009

Just wanted to give a heads up to anyone who utilizes API hooking heavily and wants their code to be compatible with Windows 7. Assuming things stay the way they are (which they probably will, this is the first time I’ve seen this before, so its not standard ‘beta build’ practice — checked with Vista and XP) then you will need to modify some of your API hooks.

Kernel32.dll now just ‘wraps’ a lot of APIs and the implementation is actually stored in KernelBase.dll.  This means if you want your code to work properly you’ll have to do this (example given with CreateProcessInternalW — unrelated code removed):

// Hook CreateProcessInternalW in KernelBase if it exists, or in Kernel32 otherwise.
// Needed because API moved to KernelBase in Windows 7.
// TODO: Implement alternative using NTDLL hooks. Priority: 2
FARPROC pCreateProcessInternalW = (hKernelBase) ? (GetProcAddress(hKernelBase,
“CreateProcessInternalW”)) : (GetProcAddress(hKernel32,”CreateProcessInternalW”));
CreateProcessInternalW_Trampoline = reinterpret_cast<tCreateProcessInternalW>(pCreateProcessInternalW);

// Perform the actual API hooking if the pointers are valid
if (pCreateProcessInternalW)
Patcher::Get()->AddPatch(&reinterpret_cast<PVOID&>(CreateProcessInternalW_Trampoline),
reinterpret_cast<PBYTE>(CreateProcessInternalW_Hook),”CreateProcessInternalW”);

So basically, most of your code can stay the same, it’s just the retrieval of the API pointer that needs to be updated. Whether you’re using GPA, EAT, whatever, you’ll need to check for KernelBase.dll first. Tested and working on XP through Windows 7. Please note I have NOT verified that IAT hooking will work without modifications, but I’m assuming it should.

If you end up testing IAT hooking in Windows 7 please let me know how you go. Also, I haven’t compiled a list yet of all redirected functions, I will if I get the time, otherwise just test your code with CreateProcessInternalW.

Cypher Programming, Reverse Engineering, Windows , , , , ,

WoW Alpha Client and PDB

February 23rd, 2009

The following is the alpha WoW client (just the main exe) and accompanying PDB file that was leaked before WoW was even released. This is what is primarily responsible for the swift development of bots, hacks, and emulators for WoW. The reason I’m posting it is that I’ve had a fair few requests for it so I figured I may as well post it here because it’s a pain to get your hands on (not impossible, but ‘difficult’). Yes it is very old, but it is still useful to this date. Lots of the function prototypes, structures, etc are still fairly accurate and what actually has changed can usually be filled in fairly quickly.

Anyway, here it is:

WoW Alpha

If the link goes down it’s probably because Blizzard filed a complaint and had it taken down. If that’s the case I’ll try and find somewhere more appropriate to host it. Also, you can always contact me directly and I’ll send you a link.

Hopefully this will help any prospective WoW hackers. (Its surprising how few people know/remember this exists and how useful it is.)

Cypher Games, Reverse Engineering, World of Warcaft , , , , ,

Analysis of Conficker

February 21st, 2009

SRI have done a very comprehensive and indepth analysis of Conficker including the latest variant boasting fun new features.

Great read, I highly recommend it if stuff like this interests you (malware development, windows internals, reversing malware, etc):

Click here for epix (and the analysis)

Cypher Programming, Reverse Engineering, Security, Windows , , , ,

Object Creation. How and where.

February 21st, 2009

This seems to be something that confuses a lot of newbies so I’m going to take the time to explain it properly here.

‘Inspiration’: Example

First off. PE Files. Although we can ignore most of the details of the PE file format for the purposes of this there are still some basics that are important. A PE file has ’sections’. One of those sections is ‘.text’, this is typically where code is stored. Another we need to know about is ‘.data’, this is typically where global variables are stored. The last we need to know about is ‘.rdata’, this is typically where global constants, hardcoded strings, floating point constants, etc are stored.

Nitpicker’s Corner: I said “typically” because packers often abuse intricacies of the PE file format which are irrelevant for this discussion in order to avoid the use of these standard sections and confuses disassemblers and debuggers. I am dealing ONLY with regular PE files created by regular compilers such as MSVC++, Intel, etc.

Second. The stack and the heap. The stack is a LIFO (Last In First Out) data structure typically used for things like passing parameters to functions, temporarily saving or “pushing” values stored in registers to be restored or “popped” back later, storing local variables, saving function return addresses, etc. All threads typically have their own ’stack’ to manage. The heap is a ‘pool’ of dynamically allocated memory typically used to store objects which are dynamically allocated at runtime because there size or other details cannot be known at run time. For more info on either of these subjects please consult any book on computer science, or wikipedia.

Nitpicker’s Corner: I am referring only to the stack/heap structures/concepts in terms of their relevance to this discussion and only the implementations which I have outlined. I am aware that the “stack” is also a common data type.

The following is a “typical” C++ application.

Nitpicker’s Corner: Typical in the sense in which objects are created  in multiple fashions ane the application uses fairly standard C++ concepts.

Nitpicker’s Corner: Application is obviously not thread-safe due to lack of serialization on global objects.

#include <iostream>
#include <string>

std::string MyGlobalString(”Foobar”);
std::string* pMyOtherGlobalString = new std::string(”Foobar2″);

std::string& GetStaticString()
{
static std::string MyStaticString(”Foobar3″);
return MyStaticString;
}

void MyStringSub()
{
std::string MyStackString(”Foobar4″):
std::string* pMyHeapString(”Foobar5″);
// Do something here
}

int main()
{
std::cout << MyGlobalString << *pMyOtherGlobalString
<< GetStaticString() << std::endl;
return 0;
}

Now the question is, which objects are stored where?

MyGlobalString will typically be stored in the ‘.data’ section becaues it is a global object.

pMyGlobalString will typically be stored in the heap, but a pointer to it will be kept in the ‘.data’ section, again because it is a global object.

MyStaticString will typically be stored in the ‘.data’ section because it is also a ‘global’ object. Whats that you say? Its not a global? Well by defining it ’static’ we technically are defining it as ‘global’. Static objects are created when the program first runs and not destroyed until the program quits, they are effectively globals as far as the compiler is concerned, the only differences are at the higher language level. The differences at the lower level are negligible.

MyStackString will be stored on the stack because it is local to a function.

pMyHeapString will be stored in the heap but the pointer to it will be stored in the stack because it is local to a function.

What is interesting though is where all the strings like “Foobar1″, “Foobar2″ etc are stored. They are NOT stored in the ‘.data’ section with our string objects. Hardcoded C-style strings will typically be stored and referenced through the ‘.rdata’ section. This is because std::string objects are created at runtime but the underlying c-style string needs to be stored somewhere. This “somewhere” is usually ‘.rdata’ because the section is designed for constants and will typically be paged as read-only when in memory. Our hard-coded strings never need to be changed so this is the perfect spot to put them.

Cypher Programming, Reverse Engineering, Windows , , ,

Some (Not That) Old But Easy to Update Code

February 18th, 2009

I realize I havn’t done that WoW post yet so to make up for it in the meantime here’s some code to play with that is very simple to update or port.

Download

While I’m not exactly sure what build of WoW that is for (too lazy to open it and check), I THINK that it’s for 3.0.3. At any rate, easy to look and see. All the offsets should be simple to update. At any rate, that’s just something to muck with until I get a full post done. (One guess as to what the post is going to be about :P)

Credits: Kynox, Greyman, BoogieMan, all of GD, anyone else I’ve forgotten to mention.

Cypher Uncategorized

WTB Standardized Email Encryption. PST

February 15th, 2009

Today I received an email from an undisclosed relative who works for an undisclosed company. Suffice to say that the relative works for a very large Australian company. In the footer of the email was the following message (identifiable information removed):

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender immediately.

This email has been scanned by the MessageLabs Email Security System for the presence of computer viruses.

Pretty much every company I’ve dealt with that I can think of has one of these retarded footers in their emails. Normally I just ignore them but today I’m grumpy so I’m going to complain about it.

To start with, the first sentence basically screams FOR THE LOVE OF GOD WE NEED STANDARDIZED EMAIL ENCRYPTION! Seriously. How long has it been since the introduction of S/MIME and PGP? Surely every modern email client supports encryption of some form or another, and surely if something were standardized all the products that didn’t would be fixed pretty quickly if they valued their customer base. Right? I mean, do you really think that a message saying “oh noes, if you got this on accident please delete it” is going to do anything if an unscrupulous individual receives a message that wasn’t intended for them? No. Its just plain pointless.

Second, even if the contents of the email aren’t sensitive enough to warrant full blown encryption signing is surely something that should be encouraged given the amount of identity theft that is going on at the moment. Is the corporate world really so behind the times that they think a little message in the footer is good enough protection?

I’m sure some people will be protesting that email encryption is unnecessary and annoying but think of it this way. If you were dealing with a law firm, your accountant, your bank, or some other corporation that has access to some of your very sensitive data (which I might add the company that the aforementioned relative works for does) wouldn’t you feel safer knowing that only you and the other party you’re dealing with could read your emails and that if they accidentally emailed the wrong person that there would be no compromise of security? Heck, I think if you explained to people WHY they had to go through the process they would appreciate it and be more likely to want to deal with the company in the future because they know that the security of personal data is a priority.

Then of course we have the “this message has been scanned by X anti-virus product” footers. Has it not occurred to the makers of these products that a worm could just copy that message verbatim into any infected emails it sends out? Teaching people to think “oh there’s a totally unverifiable piece of text here that says the email is virus free so I’m sure it’s safe to trust” is stupid. Whilst I realize it’s free advertising it’s also irresponsible. If the AV companies really cared about their customers they wouldn’t be teaching them such idiotic lessons. ALWAYS scan emails for malware, and even when emails are “clean” be wary of strangers bearing gifts because AV software is far far far from perfect.

Sigh, that’s my rant for the day.

Note: If you don’t understand the title of the post it’s because it’s using WoW jargon. ‘WTB’ = ‘Wanting to Buy’, ‘PST’ = ‘Please send tell’ or in other words ‘Please contact me for details’.

Cypher Security , , , , ,

Module Cloaker

February 13th, 2009

Slight delay on the WoW related post I’m sorry (personal reasons). But in the meantime I figured I may as well post something else which I had already finished.

This is the source code to my module cloaker. The idea is to attempt to hide the presence of a DLL in an exe. My implementation is designed for use in a usermode rootkit (which is my current project) but it is half-way to being complete for use in anti-anti-cheat code (you will need to fix the weaknesses described in the comments along with a bunch of other stuff — also, by complete I mean ‘complete as possible’, there are some things you just can’t disguise at this level).

Documentation, credits, etc. is all in the source code (sorry but I’m too lazy to copy/paste it here :p):

Download

32-bit only, but a 64-bit version will most likely be coming in the not-too-distant future when I port my usermode rootkit code to x64.

Would love to hear suggestions/criticisms/etc.

Update: Sorry. Fixed link. I forgot to include a header the first time.

Update 2: Just wanted to point out, sorry for the retarded namespace name, its just to avoid collisions.

Cypher Reverse Engineering, Windows , ,

Another Quick Poll

February 11th, 2009

Another WoW related post coming late today (or late tomorrow at the latest I hope). So let me know, what do you want to see this time?

Cypher Games, World of Warcaft ,

File Hiding

February 9th, 2009

I’ve just implemented the first beta of the file hiding feature for my rootkit. As usual, I’ve attached a screenshot:

Usermode Rootkit File Stealth

As you can see, any files with the prefix “__PJB_F” are hidden from view. I’ve implemented it by hooking NtQueryDirectoryFile. Tested and working on both Vista and XP with only minor bugs (which should be smoothed out soon). Once I’ve smoothed out most of the bugs in the project I’m hoping to release portions of the source so if you’re waiting on that then stay tuned, I’ll have more information in the near future.

P.S. WoW related post incoming in the next few days probably.

Cypher Reverse Engineering, Windows , ,

Selective Infection

February 7th, 2009

Hey, thought I’d post another progress update on my usermode rootkit project. Mostly it’s bug fixes and stability fixes (no more crashes! yay!). But I’ve also added three new things.

1. Process hiding by name. If the process name starts with “__PJB_H_” it will be cloaked.

2. Selective infection. If the process name starts with “__PJB_S_” it will not be infected and hence will be able to see the system in an uncloaked state.

3. Module stealth. Rather than hook APIs to hide my modules in the processes I inject into I’m manually unlinking it from the linked lists, then nulling out the entire LDR_MODULE structure, and also nulling out the entire PE header.

I’ve attached a screenshot to show off the latest features. To make it easier I’ve put colour coded boxes around what I want to draw attention to.

Latest Rootkit Revision

Purple: My test applications to hide from the system. Just CMD and Wordpad. (I blocked out my username on CMD because I used my full name, whoops. :P)

Blue: The rootkit bootstrapper and the DLL that is injected into processes to do all the dirty work.

Yellow: Process Explorer. Kinda like Task Manager on crack. I used that rather than taskmgr for two reasons. First and foremost is that it’s a lot more powerful and so much more useful when testing my code. Second is that taskmgr won’t open multiple windows unless you hack it to do so. The copy on the left is the ‘clean’ one, the one on the right is the ‘regular’ (infected) one. Sorry, they’re backwards to the placement on the desktop, didn’t notice until now and I’m too lazy to take a new screenshot. You will see that the clean process can see the two test apps yet the infected process can not.

Red: As stated above, the copy of Process Explorer with the window on the left can see our test processes because it has been ignored by the rootkit, the regular copy on the other hand is unaware of the presence of the two processes.

Orange: Both copies of Process Explorer have Explorer.exe highlighted. Because API hooks are not being used and the module is cloaking itself upon being injected the module is invisible even to the ‘clean’ copy of Process Explorer. If I were to disable module cloaking __PJB_x86.dll would appear at the top of both those lists. If I were to modify the cloaking to a less stealthy variant (ie using API hooks), although it would normally mean the clean process would be able to see the module and the infected one wouldn’t it isn’t hard to manually traverse the list and look for the module manually so I decided to go for a more ‘permanent’ but also more stealthy approach.

Whats next? A few extra hooks to increase the security of the process hiding, then I’m moving on to hiding files. I’ve decided rather than doing x64 support incrementally I’ll just finish 80-95% of the x86 code first so I can port most of it across at once.

Update: Whoops, forgot the screenshot. Fixed!

Cypher Reverse Engineering, Windows , ,