Silly's Interact Thread of Doom

[Sillyboy72]

If nothing else, my thread has a cool title, right? ;-)

I really am quite pleased that I can now read memory to detect bobber splash action in my fishy bot, but naturally... now I want more ubery Time to get in process and do some Interact().

This will me my thread to catalog my learnings for future n00bs.

First, I have been reading the forums on how to pull this off, and this block of code comes up:

//get the adress of the call for vmt 36 (Interact)
uint VMT36 = wow.ReadUInt((wow.ReadUInt(obj) + (36 * 4)));

wow.Asm.AddLine("fs mov eax, [0x2C]");
wow.Asm.AddLine("mov eax, [eax]");
wow.Asm.AddLine("add eax, 8");
wow.Asm.AddLine("mov dword [eax], {0}", ObjectManager.s_curMgr);
wow.Asm.AddLine("mov ecx, {0}", obj);
wow.Asm.AddLine("call {0}", VMT36); //read pointer to Interact method
wow.Asm.AddLine("retn");

I figure I should be able to vaguely read that, and as I do... I am gonna tell you what I think it says. That way, you can tell me if I am retarded. and maybe future n00bs can read this for understanding as well.

First, it took some mad google skillz to figure out what the hells FS is... apparently it just always points to the TIB for the current thread. Who knew? (bolded so I can some back to it later...)

So, reading that assembly, the way a 1st grader reads MacBeth...
fs mov eax, [0x2c]

I am gonna boldly assume we are not doing a hard deref at 0x2c... so that "fs" must be relevant Freaky syntax. I guess i would have expected
mov eax, fs
add eax, 0x2c
or maybe
mov eax, fs:[0x2c]
but hey... I don't write the stuff, I barely even read it.

So anyway, the googlez says that 0x2c is the offset from TIB to the thread local storage. Sounds good. So we deref that to get the start of TLS into eax.
mov eax, [eax]

So, onto...
add eax, 8
beats me. I mean, sure... 8 away from start of TLS sounds hot. no idea what is there

Let's ignore that and move on...
mov dword [eax], CurrentObjectManagerAddress
Well, alright... wherever eax is pointing (8 away from start of TLS)... we are gonna jam the address of our current object manager. sounds nice. I guess?

Then...
mov ecx, TheObjectAddress
No real comment needed...

Then it's on... like donkey kong...
call VMT36Address
call that dirty skank. We should be able to infer some stuff about that function... me thinks. will come back to that.

retn;
done.

So, apparently this function expects the address of our object to be in ECX. Let's chaulk this up to the non-surprising column, as in c++ land the "this" pointer is typically in ecx. Correct?

Then we get to the two pieces most perplexing the Silly:

1. What's with jamming the object manager address into TLS+8?
2. Back to my bolded "current thread" madness... my threads TLS doesn't have a darn thing in it. Does it? Wouldn't i have to force this code to run on one of wowz threads?

Now that I see it written, am I answer my own question? Is the point... that the call to Interact is going to expect *my* TLS+8 to point to my object manager, so we jam it in there?

That'd be hot. Any commentary appreciated... while I try to figure out how to actually get this code into wow's process

[luciferc]

I like you.

It seems its all good make sure u got the right offsets and Current obj manager and make sure the BASEADDR is Correct if you ever have problems.

*Hint never call by Baseaddr make a func like _interactWithGuid/Name* since Baseaddrs can change

Also make sure that you Suspsend the Wow Thread while calling it or Hook that func like End*** i forgot.

I personally just suspsend wow's main thread then resume it.

wow.InjectAndExecute(codecave); is how you execute

"Codecave" is a uint which is a Assigned Block of Memory Allocated to your ASM injections. (Its a BlackMagic Func)

Something like

            uint codeCave = wow.AllocateMemory();

Fully done its like

uint codeCave = wow.AllocateMemory();
Process.EnterDebugMode();

//ASM LINES
//ASM LINES
//ASM LINES
//ASM LINES


//I only suspend/resume b/c sometimes the functions were called at the same time and it would crash wow but other wise you should be fine with just a fish bot i belive

suspendThread(); //My Func that Suspsends wow's Thread
wow.Asm.InjectAndExecute(codeCave);
resumeThread();//My func that Resumes Wow's thread

wow.Asm.Clear(); //Clear that shit so we can use wow again to do asm stuff.
wow.FreeMemory(codeCave);//Don't Forget to Bring a towel ... to clean up your shit

[Sillyboy72]

Quick question:

Given some function (c++ / microsoft visual studio) :

void __declspec(naked) myasmfunc(DWORD obj)
{
    __asm {
        // bunch of asm here
    }
}

How come something like :
memcpy(myBuffer, myasmfunc, length);

doesn't copy the opcodes into myBuffer?

am I just hitting some sort of madness around reading from a code section? need to do weird VirtualProtect magic or something?

(I was gonna use this to inject the asm into wow.exe via WriteProcessMemory...)

The compiler is eff'ing with me

Wrote this C...
BYTE *pWTF = (BYTE*) myasmfunc;

Looked at the disasm...
// 00413959 C7 85 C8 FE FF FF 16 13 41 00 mov dword ptr [ebp-138h],offset myasmfunc (411316h)

But like, myasmfunc... actually lives at 0x00412850, not 0x411316.

So, I got look at the code around 0x411316...

00411307 E9 F4 3B 00 00 jmp _RTC_GetErrorFunc (414F00h)
0041130C E9 BF 11 00 00 jmp CatchFish (4124D0h)
00411311 E9 DA 28 00 00 jmp LookupPrivilegeValueW (413BF0h)
00411316 E9 35 15 00 00 jmp myasmfunc (412850h)
0041131B E9 E0 04 00 00 jmp memcpy (411800h)

Good gravy, there is a freaky jump table!

Hrm, okay... so, if we read 1 byte (opcode) + 4 bytes (offset) from the jump table... we can get really close to my stupid function.

"really close", cuz ... apparently the relative jump is from the NEXT instruction, not the current. freaky. who knew?

I'll just add 5 bytes, don't tell anyone.

[kynox]

The jump table is the result of compiling with "Incremental Linking". Turn that off and you're good to go.

[Sillyboy72]

LOL. This thread is like a documentation of my incompetence

So... the original code I stole, was fasm/c# madness... that was emitted at run time. I thought I was all awesomeness, and didn't need that crap, since I was livin' large in the c++ world... and had the uber __declspec(naked)

But, here's the thing. Once compiled, the bytes are static. But, umm... there are dynamic things going on. So, clearly, i should have done less drugs in middle school.

The things is I can only vaguely read asm, let along write it... and I needed to convert fasm to masm. Not only that... if I wanted to continue down this (increasingly retarded) path, I would need to write some literal values, and go back and patch them later. I think

__asm {
		push ebx
		mov eax, dword ptr FS:[0x2c] 		
		mov eax, [eax]
		add eax, 8
		mov [eax], 0xDEADBEE1  // patch with Mgr
		mov ecx, 0xDEADBEE2   // patch with the object
		call cs:0xDEADBEE3	  //  patch with VMT36
		retn
    }

Ya, okay... so I am blatantly guessing on the call instruction with that cs:literal madness. Is that correct? seems call without a colon in there somewhere required a label or somethin'.

So, when I actually want to inject this crap, I do all the magic above (jmp table, etc). Then go searching for 0xDEADBEE1, replace it w/ the address of the current object manager in WoW's space. Jam the object adress into 0xDEADBEE2, and jam the location of VMT36 into 0xDEADBEE3.

(Okay fine, 1 and 3 could be done once not every time, but whatever).

Am I on drugs?

The jump table is the result of compiling with "Incremental Linking". Turn that off and you're good to go.

Holy Shnikies! That's worked! thx.


Much sadness.

This application has encountered a critical error:

ERROR #132 (0x85100084) Fatal Exception
Program: C:\Users\Public\Games\World of Warcraft\WoW.exe
Exception: 0xC0000005 (ACCESS_VIOLATION) at 001B:0AC60000

The instruction at "0x0AC60000" referenced memory at "0x0AC60000".
The memory could not be "written".

Code: 16 bytes starting at (EIP = 0AC60000)

0AC60000: 55 8B EC 81 EC C0 00 00 00 53 56 57 8D BD 40 FF U........SVW..@.


So, here is where we got. I am doing as I suggested above... hard coding deadbee1-3... and patching them before writing process memory. To me, everything looks pretty okey-dokey. VirtualAlloc comes back with 0xAC60000, which is where I WriteProcessMemory.

If I attach a debugger to wow, indeed my memory looks as expected.

However, I can't explain the error above.

Note that its crashing on that first opcode 55...
push ebp
Double You Tee Eff?

You may ask why I am pushing stuff on the stack... Well, I'm not... auto generated stuffz is. While I had tried nekked for awhile, its currently matching the correct signature for a CreateRemoteThread call:
DWORD __stdcall MyInteractAsm(PVOID *UnUsedCuzItScaresMe)

Suppose, I will switch back to the lean and naked version and see if that helps. I am skeptical.

I did try using VirtualProtectEx with PAGE_EXECUTE_READWRITE, to no avail.

Theories appreciated

I did try using VirtualProtectEx with PAGE_EXECUTE_READWRITE, to no avail.

Theories appreciated

Here is a theory, dumbass. Try checking return codes from api's

Didn't realize the last param to VirtualProtectEx was required. Now I think I crashing farther in, which is way better

[Nesox]

It's liek n0t good to forget the most important thing,u need to update ure remote-thread/thread with g_clientconnection & offset, unless you call it from wows main thread or from a EndScene hook or if you hijack wows main thread ..

EDIT: Quoting ureself only has one meaning, "ure crazy!" :twisted:

EDITEDIT: can you create labels with fasm? ie.

wow.Asm.AddLine("loopStart:");
wow.Asm.AddLine("jmp loopStart");

[Sillyboy72]

Holy. Crap. It worked! :devildance:

Fixed my virtualprotect screwup, massaged the patching a bit, went back to the nekked flavor, and I will be damned if I didn't see the fishy loot box popup!

Turned on "auto loot" in the UI, and poof. fishes in bags! w00t!

So, in sum total it was pretty much this:

void __declspec(naked) MyInteractAsm()
{
    __asm {
		mov eax, dword ptr FS:[0x2c] 		
		mov eax, [eax]
		add eax, 8
		mov dword ptr [eax],  0xDEADBEE1  // patch with Mgr
		mov ecx, 0xDEADBEE2    // patch with the object
		mov eax, 0xDEADBEE3	   // patch with VMT36
		call eax  
		retn
    }
}

Plus this:

void Interact(DWORD obj)
{
	DWORD vtable = ReadDword(obj);
	DWORD VMT36 = ReadDword(vtable + 36 * 4); 

	BYTE MyBytes[0x100];
	memcpy(MyBytes, MyInteractAsm, sizeof(MyBytes));
	
	DWORD db = 0xDEADBEE1;
	PatchMem(MyBytes, sizeof(MyBytes), &db, sizeof(db), &Mgr);
	db = 0xDEADBEE2;
	PatchMem(MyBytes, 0x50, &db, sizeof(db), &obj);
	db = 0xDEADBEE3;
	PatchMem(MyBytes, sizeof(MyBytes), &db, sizeof(db), &VMT36);

	void *pv = VirtualAllocEx( hProcess, 0, sizeof(MyBytes), MEM_COMMIT, PAGE_READWRITE );	
	DWORD old;
	VirtualProtectEx(hProcess, pv, sizeof(MyBytes), PAGE_EXECUTE_READWRITE, &old);
	WriteProcessMemory(hProcess, pv, MyBytes, sizeof(MyBytes), NULL);	
	
	HANDLE hThread = CreateRemoteThread(hProcess, NULL, 0, (LPTHREAD_START_ROUTINE) (BYTE*)pv, NULL, NULL, NULL);
	WaitForSingleObject(hThread, INFINITE);
	CloseHandle(hThread);
	VirtualFreeEx(hProcess, pv, sizeof(MyBytes), MEM_RELEASE);
}

And she was GTG. Rock on peeps, thanks for the helpies (though, I was mostly talking to myself tonight... i would get nowhere without stealing from the forums )


So. How do I cast my lure in process?

[Nesox]

So. How do I cast my lure in process?

you could go with the noobish approach and send 2 keymessages or you could
call some lua function think it's protected tho so you would need to unprotect it

[Sillyboy72]

Well, I mean... i already have a perfectly working fishbot... as long as you have your fishin' skill in slot '8', if you know what i mean

I want to fish while surfin' the web... so... no more "sendkeys" madness (though, i dunno maybe that doesn't actually require any window focus... still trying to learn to not suxor )

Searching for CastSpellByName gets me this hot string in IDA: "Usage: CastSpellByName(name [, target])" ... but daaaamn.

Let's not forget how retarded I am at reading assembly. for me to figure how to call that bad boy would be a miracle. (and even then, I guess it wouldn't work unless I figure out the protection madness).

<whimper>

[hypnodok]

SillyBoy72 is one weird fellow.
Reminds of that Angelina Jolie-guy (kinda) :O
PS: You dont actually require window-focus to send keys (PostMessage ftw).

[Nesox]

or you can use SendMessage the call for CastSpellById is 0x00773400 find all the calls with olly that uses that call and you shoud be able to write some asm for it

[kynox]

As much as i hate double/triple/quadruple posters, you've earned an exception in my books. You're learning very well from your mistakes!

Bravo, this forum needs more people like you