[C++][Source] How to get started

[Flowerew]

It seems to me everything people post on this forum is C# code and alot of the new people think "ok, so I have to learn C#". Since I love C++ and I would like to see alot more C++ code in here I want to share some code with you I wrote to show the basic things you need to get your bot started. I don't claim to write the best/cleanest/<insert your word here> code in the world, but I tried to get close If you're not familiar with C++ try to get one of the books recommended in the http://www.mmowned.com/forums/wow-me...ookthread.html

What's included
- Simple injector class to inject a dll into another process and load it
- Very simple EndScene hook method via VTable
- ClientConnection, CGCurMgr_C and CGObject_C included to show where it all begins

The solution (VS200 contains two projects: the injector and the dll. I really tried to just include the essential stuff for both to not scare off beginners which may think "wtf is this beast?" when they are told look at project xyz to learn from. I think it comes down to about 150-200 effective lines of code.

What this sample code actually does
- Injects SampleDll.dll into your running World of Warcraft
- Prints the current object list to your debug output (so a debugger like Olly must be attached)
- Replaces the function address of EndScene in the vtable of IDirect3DDevice9 with our own function
- Unloads the dll from the target process after you pressed a key and thereby restores the vtable entry

What this sample code does NOT
- It won't teach you C++
- It won't teach you ASM
- It won't teach you uberl33t haxX0r skills

This code is for beginners only and just a sample for a fundament. Actually it's not even a bot yet because it does nothing but printing the object list, though it won't take much to make it one.

Source Code (read the comments block in SampleBot.cpp/SampleDll.cpp first)

I hope you like it. Best regards, PferdOne aka Flowerew

Edit: The offsets used in this sample are for WoW v3.3.0a (11159)

[Viano]

Thanks a lot. I just managed to hook few functions in other applications and this will help.

+Rep +Rep

[YetiHunter]

Can someone tell me where i can find those debug outputs? I have ollydbg attached to the WoW process but i'm unable to find the output. I'm sure my problem is caused by my incompetence but would be grateful for help .
Great job on the sample program btw.

[Flowerew]

In Olly click View > Log or just Alt+L

[YetiHunter]

In Olly click View > Log or just Alt+L

thanks alot =)

[madmange]

Im going from c# to c++ with my small mem-projects and stuff like this help's alot +Rep

[romanshade]

Excellent stuff, thanks for providing this.

I'm having some trouble with this ... I have confirmed I am running the appropriate version of WoW as posted in your opening post ... coupled with matching the offsets.

In the block below, lib_base_addr is always zero ... I added the GetLastError check to try and determine the cause ... the returned error is "The Handle is Invalid".

Apparently the GetExitCodeThread is throwing an error and lib_base_addr gets no value.

Thoughts?

Thanks!

 // call LoadLibraryW from the remote process
    thread = CreateRemoteThread(process, NULL, 0,
                                reinterpret_cast<LPTHREAD_START_ROUTINE>(load_lib),
                                dll_name_addr, 0, NULL);

    if (thread == NULL) {
      VirtualFreeEx(process, dll_name_addr, 0, MEM_RELEASE);
      OutputDebugString(TEXT("CreateRemoteThread failed\n"));
      return 0;
    }

    DWORD lib_base_addr;
    WaitForSingleObject(thread, INFINITE);
    GetExitCodeThread(thread, &lib_base_addr);

    // free space reserved for the dll name in the remote process
    VirtualFreeEx(process, dll_name_addr, 0, MEM_RELEASE);

    if(lib_base_addr == 0) 
	{
		void *buf;
		FormatMessage(FORMAT_MESSAGE_ALLOCATE_BUFFER | FORMAT_MESSAGE_FROM_SYSTEM | FORMAT_MESSAGE_IGNORE_INSERTS, NULL, GetLastError(), 0, (LPTSTR) & buf, 0, NULL);
		MessageBox(NULL, (LPTSTR) buf, NULL, MB_OK | MB_ICONINFORMATION);
		wprintf_s(TEXT("Epic Fail\r\n"));
		OutputDebugString(TEXT("Failed to load DLL\n"));
		return 0;
    }

[Flowerew]

...
In the block below, lib_base_addr is always zero ... I added the GetLastError check to try and determine the cause ... the returned error is "The Handle is Invalid".

Apparently the GetExitCodeThread is throwing an error and lib_base_addr gets no value.

Thoughts?
...

First of all did you create the required environment variable WOWDIR which should point to your wow directory (that's where the dll will be put)? Further Injector::FindProcessIdByPeName is case-sensitive so if you're looking for "Wow.exe" and your wow executable looks like this "WoW.exe" it won't find it. Here are some things you should check:
- Injector::FindProcessIdByPeName, does it return a valid process id?
- in Injector::LoadDll, check if the handle OpenProcess returns is valid
- and so on ...

You don't have to output errors yourself, cause I added a fair amount of error-checking myself. Just make sure a debugger is attached, which should be default when running an application in debug mode via F5 in VS and you should see where it fails.

You can also talk to me on IRC: #mmowned @ quakenet

[Cypher]

Excellent stuff, thanks for providing this.

I'm having some trouble with this ... I have confirmed I am running the appropriate version of WoW as posted in your opening post ... coupled with matching the offsets.

In the block below, lib_base_addr is always zero ... I added the GetLastError check to try and determine the cause ... the returned error is "The Handle is Invalid".

Apparently the GetExitCodeThread is throwing an error and lib_base_addr gets no value.

Thoughts?

Thanks!

 // call LoadLibraryW from the remote process
    thread = CreateRemoteThread(process, NULL, 0,
                                reinterpret_cast<LPTHREAD_START_ROUTINE>(load_lib),
                                dll_name_addr, 0, NULL);

    if (thread == NULL) {
      VirtualFreeEx(process, dll_name_addr, 0, MEM_RELEASE);
      OutputDebugString(TEXT("CreateRemoteThread failed\n"));
      return 0;
    }

    DWORD lib_base_addr;
    WaitForSingleObject(thread, INFINITE);
    GetExitCodeThread(thread, &lib_base_addr);

    // free space reserved for the dll name in the remote process
    VirtualFreeEx(process, dll_name_addr, 0, MEM_RELEASE);

    if(lib_base_addr == 0) 
	{
		void *buf;
		FormatMessage(FORMAT_MESSAGE_ALLOCATE_BUFFER | FORMAT_MESSAGE_FROM_SYSTEM | FORMAT_MESSAGE_IGNORE_INSERTS, NULL, GetLastError(), 0, (LPTSTR) & buf, 0, NULL);
		MessageBox(NULL, (LPTSTR) buf, NULL, MB_OK | MB_ICONINFORMATION);
		wprintf_s(TEXT("Epic Fail\r\n"));
		OutputDebugString(TEXT("Failed to load DLL\n"));
		return 0;
    }

More C++ Idioms/Resource Acquisition Is Initialization - Wikibooks, collection of open-content textbooks

[Flowerew]

More C++ Idioms/Resource Acquisition Is Initialization - Wikibooks, collection of open-content textbooks

I think you're referring to: "Resources acquired in a function scope should be released before leaving the scope..", but this whole code block is in a __try{...} __finally{...} block.

[Cypher]

I think you're referring to: "Resources acquired in a function scope should be released before leaving the scope..", but this whole code block is in a __try{...} __finally{...} block.

I was referring to Romanshade's code, it's C++, and C++ does not have a 'finally' construct, nor does it have GC. It uses RAII as it's resource management idiom/technique.

[Flowerew]

I was referring to Romanshade's code, it's C++, and C++ does not have a 'finally' construct, nor does it have GC. It uses RAII as it's resource management idiom/technique.

Well it's ultimately my code from the sample (except, for the FormatMessage, MessageBox, wprintf_s stuff).

Yes try-finally Statement (C++) is no C++ itself but this is what the MSDN has to say about it:

The try-finally statement is a Microsoft extension to the C and C++ languages that enables 32-bit target applications to guarantee execution of cleanup code when execution of a block of code is interrupted. Cleanup consists of such tasks as deallocating memory, closing files, and releasing file handles.

And I used that to close handles (to cleanup).

The article you posted says its intend is:
- To guarantee release of resource(s) at the end of a scope
- To provide basic exception safety guarantee

...so my guess was, you complained about handles which wouldn't be closed if one only sees the code romanshade posted. Since you only posted the link and it looked like a suggestion to look up on RAII...that's what I based my last post/guess on.

If you think anything is wrong with this approach I would love to hear/read feedback from you, since what I've seen from you is quality work and I appreciate any comments from you.

[Cypher]

Well it's ultimately my code from the sample (except, for the FormatMessage, MessageBox, wprintf_s stuff).

Yes try-finally Statement (C++) is no C++ itself but this is what the MSDN has to say about it:

And I used that to close handles (to cleanup).

The article you posted says its intend is:
- To guarantee release of resource(s) at the end of a scope
- To provide basic exception safety guarantee

...so my guess was, you complained about handles which wouldn't be closed if one only sees the code romanshade posted. Since you only posted the link and it looked like a suggestion to look up on RAII...that's what I based my last post/guess on.

If you think anything is wrong with this approach I would love to hear/read feedback from you, since what I've seen from you is quality work and I appreciate any comments from you.

try/finally is not C++, and those extensions you're talking about don't gel well with C++ objects. It's primarily designed for C code, as when using SEH you can't use objects with destructors.

Example:
__try
{
std::string MyString;
// do something with string
}
__finally
{
}

That will not compile.

RAII is how it's supposed to be done in C++, try/finally is a hack designed for C code, is not portable across compilers, etc. Basically, it's just 100% the WRONG way to do it in C++. C, yeah, I can see that being useful. But in C++ it's not only unnecessary, it's wrong.

[wanyancan]

Did anyone make the same thing using Darawk's ManualMap? Any success?
I've tried but crashed..

[Cypher]

Did anyone make the same thing using Darawk's ManualMap? Any success?
I've tried but crashed..

Standard answer:
Add TLS support, it will fix the crash.

Extended answer:
1. If you're manually mapping, you need to understand both the implementation AND the implications, otherwise you'll waste hours on pointless shit.
2. Why the **** do you even need to manual map? It's only useful for public cheats.
3. More here, if and when I feel like expanding. Busy atm, but at least your problem is now fixed.