Ramblings++

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.)

Games, Reverse Engineering, World of Warcaft alpha, hack, pdb, reversing, world of warcraft, wow

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)

Programming, Reverse Engineering, Security, Windows conficker, malware, reversing, Security, Windows

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.

Programming, Reverse Engineering, Windows c++, Programming, reversing, Windows

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.

Reverse Engineering, Windows cloaker, reversing, Windows

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?

Games, World of Warcaft reversing, world of warcraft

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

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.

Reverse Engineering, Windows reversing, rootkit, Windows

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.

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!

Reverse Engineering, Windows reversing, rootkit, Windows

Hey, just wanted to post a screenshot from the usermode rootkit I’m working on showing off the first ‘proper’ feature of the x86 build. Hiding processes.

Sorry about the low quality screenshot (JPEGs suck but PNGs are huge). If you want a higher res screenshot please this link.

Hoping to get the code ported to x64 builds of Windows when the x86 builds are stable. All the code is in usermode so it shouldn’t be too difficult.

Reverse Engineering, Windows reversing, rootkit, Windows

Hey, as requested I’m gonna post the info needed to use WoW’s console in a hack. Because I’m a little short on time I’m just going to post the bare minimum, but at the end of the post I’ll point out some of the other functions that may be of interest in case you want to go hunting for them.

Note: I’m assuming you already know how to enable and use WoW’s console. (Hint: ‘WoW.exe -console’, then use the ‘`’ key to bring it down. Just like in most other games.)

First off, registering console commands. The easiest way to find the function needed to do this is look for a known command in the binary. I chose ‘worldport’ because I’ve used it before, and found this:

.text:004073B3                 push    0               ; int
.text:004073B5                 push    0               ; int
.text:004073B7                 push    offset sub_406D70 ; int
.text:004073BC                 push    offset aWorldport ; “worldport”
.text:004073C1                 call    sub_6A0BD0

Now, from that we can easily see that sub_6A0BD0 is the function we are interested in because it takes both the command name and the associated function pointer (which you can verify by looking inside). Based on that the callback registration function prototype will be the following:

void __cdecl RegisterConsoleCommand(unsigned int Unk1 = 0, unsigned int Unk2 = 0, void* pCallback, const char* Command);

What you will notice though is that if you try to use your new command WoW will exit. Why is that? Well, if you go to the trouble of debugging it (Hint: start at ConsoleExec, called by the Lua subroutine by the same name) you will come across the following function:

.text:007CB3A0 sub_7CB3A0      proc near               ; CODE XREF: sub_69F470+B9p
.text:007CB3A0                                         ; sub_6A11A0+1Ap …
.text:007CB3A0
.text:007CB3A0 var_40          = byte ptr -40h
.text:007CB3A0 arg_0           = dword ptr  8
.text:007CB3A0
.text:007CB3A0                 push    ebp
.text:007CB3A1                 mov     ebp, esp
.text:007CB3A3                 mov     eax, dword_12EA640
.text:007CB3A8                 mov     ecx, dword_12EA644
.text:007CB3AE                 sub     esp, 40h
.text:007CB3B1                 test    eax, eax
.text:007CB3B3                 jz      short loc_7CB3B9
.text:007CB3B5                 test    ecx, ecx
.text:007CB3B7                 jnz     short loc_7CB3C9
.text:007CB3B9
.text:007CB3B9 loc_7CB3B9:                             ; CODE XREF: sub_7CB3A0+13j
.text:007CB3B9                 call    sub_7CB310      ; <”Unable to find .text section”, “.text”>
.text:007CB3BE                 mov     eax, dword_12EA640
.text:007CB3C3                 mov     ecx, dword_12EA644
.text:007CB3C9
.text:007CB3C9 loc_7CB3C9:                             ; CODE XREF: sub_7CB3A0+17j
.text:007CB3C9                 mov     edx, [ebp+arg_0]
.text:007CB3CC                 cmp     edx, eax
.text:007CB3CE                 jb      short loc_7CB3D4
.text:007CB3D0                 cmp     edx, ecx
.text:007CB3D2                 jb      short loc_7CB3F1
.text:007CB3D4
.text:007CB3D4 loc_7CB3D4:                             ; CODE XREF: sub_7CB3A0+2Ej
.text:007CB3D4                 push    edx
.text:007CB3D5                 push    offset aInvalidFunctio ; “Invalid function pointer: %p”
.text:007CB3DA                 lea     eax, [ebp+var_40]
.text:007CB3DD                 push    40h
.text:007CB3DF                 push    eax             ; char
.text:007CB3E0                 call    sub_6A6920
.text:007CB3E5                 lea     ecx, [ebp+var_40]
.text:007CB3E8                 push    ecx             ; char *
.text:007CB3E9                 call    sub_6A9E60
.text:007CB3EE ; —————————————————————————
.text:007CB3EE                 add     esp, 14h
.text:007CB3F1
.text:007CB3F1 loc_7CB3F1:                             ; CODE XREF: sub_7CB3A0+32j
.text:007CB3F1                 mov     esp, ebp
.text:007CB3F3                 pop     ebp
.text:007CB3F4                 retn
.text:007CB3F4 sub_7CB3A0      endp

Again, if you go to the trouble of reversing this function (which I’m not going to explain in detail because its beside the point of this post) you will see that it is looking at WoWs PE header, getting the start and end of WoW’s ‘.text’ segment (which is where all code is kept) and ensuring no function pointers are being registered outside that range. If a function pointer outside the valid range is found then WoW will quit.

What is the easiest way to get around this? Hook the function to just do a “return” at the start. If you want to just write a single byte to do the same (even easier), simply write ‘0xC3′ to the top of the function. Please keep in mind this is ignoring the presence of Warden. If you want to ensure you don’t get detected by Warden you will need to breakpoint whatever you’re hooking to ensure it’s not being scanned, or use a generic Warden bypass.

Now with that out of the way we move to printing output. Funnily enough we can backtrack to the exact same starting position as before:

.text:004073B3                 push    0               ; int
.text:004073B5                 push    0               ; int
.text:004073B7                 push    offset sub_406D70 ; int
.text:004073BC                 push    offset aWorldport ; “worldport”
.text:004073C1                 call    sub_6A0BD0

I checked worldport and happen to know that if you pass it invalid params it will print usage information to the console. Knowing that we can dive into worldport’s callback and we find this:

.text:00406DED                 push    4
.text:00406DEF                 push    offset aUsageWorldport ; “Usage: worldport <continentID> [x y z] “…
.text:00406DF4                 call    sub_69D850      ; <”.\ConsoleClient.cpp”, “[email protected]@”>
.text:00406DF9                 add     esp, 8

Again, very obvious what’s going on there.

void __cdecl ConsolePrint(unsigned int Unk1 = 0, const char* Output);

Using that you can easily write output to the console.

Well, that pretty much sums up the pure basics. If people are interested in some of the other console related stuff (changing the print colour, registering cvars, modifying/retrieving cvar values, what the parameters we’re ignoring are for, etc.) let me know. If you’d rather see something different like packet-based stuff, or even something non WoW related like my new usermode rootkit project or something else related to Windows reversing and internals feel free to suggest that too.

Extra Credit:

See if you can work out what the extra parameters I’ve marked as “Unk” (unknown) in each function are for. I’ll let you know if you’re right or wrong.

Games, Reverse Engineering, Windows, World of Warcaft Games, reversing, world of warcraft

Hey, before I write my next post (which will be WoW related) I was wondering what topic people would be more interested in. Console hooking was brought up, as was packet-based stuff (logging packets, spoofing packets, etc). So rather than just pick blindly I was wondering, what do you want to see?

Note: Obviously not limited to the two above they were just two random examples that had been brought up.

Games, Reverse Engineering, World of Warcaft poll, reversing, world of warcraft