New 32-bit Detection Method Added

[aeo]

I've been looking into this as well. I can unlock lua with some hwbps but this method is public and at high risk of blizzard attention. I've been looking at using asmjit to build a fake stack frame for my call to execute buffer . Right now I use the old handle exception for my registered function addresses and use a executebuffer callback to process my lua instead of a patch or hwbp unlock . This is great except my call is outside the text section. I have used blackbone library to successfully generate a call to execute buffer but I cannot get a jmp to work. I'm using x64.

Basically I have tired to find a call rax instruction mov the execute buffer address to rax after moving all args to the rcx Rdx r8 regs and jmp to the call rax address however this results in a crash I make it to the execute buffer function as I've debugged it with cheatengine but I crash later on due to stack currupton I'd assume .

typedef int(*MyFn)();
        a->mov(asmjit::host::rcx, (DWORD_PTR)buffer);
        a->mov(asmjit::host::rdx, (DWORD_PTR)buffer);
        a->mov(asmjit::host::r8, 0);
        a->mov(asmjit::host::r13, executeBufferAddress); move my function address into r13
        a->jmp(((DWORD_PTR)GetModuleHandle(NULL) + 0x7B6BDD)); // this is a call r13 address
        MyFn fn = (MyFn)(a->make());
        fn();

09130000 - 48 89 4C 24 08        - mov [rsp+08],rcx
09130005 - 48 89 54 24 10        - mov [rsp+10],rdx
0913000A - 4C 89 44 24 18        - mov [rsp+18],r8
0913000F - 4C 89 4C 24 20        - mov [rsp+20],r9
09130014 - 48 83 EC 38           - sub rsp,38
09130018 - 48 C7 C1 58469C3C     - mov rcx,3C9C4658 : ["CastSpellByID(136)"]
0913001F - 48 C7 C2 58469C3C     - mov rdx,3C9C4658 : ["CastSpellByID(136)"]
09130026 - 49 C7 C0 00000000     - mov r8,00000000
0913002D - 48 B8 20CDE03F01000000 -mov rax,Wow-64.exe+3CD20
09130037 - FF D0                 - call eax
09130039 - 48 83 C4 38           - add rsp,38
0913003D - 48 8B 4C 24 08        - mov rcx,[rsp+08]
09130042 - 48 8B 54 24 10        - mov rdx,[rsp+10]
09130047 - 4C 8B 44 24 18        - mov r8,[rsp+18]
0913004C - 4C 8B 4C 24 20        - mov r9,[rsp+20]
09130051 - C3                    - ret

1. 
   
   Edit:added working asm call to Executebuffer.

[lolp1]

I felt (probably incorrectly) pretty "safe" because i do not share my bot code with anyone so i thought it would be unlikely that I would get detected.

Assuming you're not doing anything crazy or copying a popular public hack, I'd say that it is still unlikely.

I can think of several ways to defeat this "check" but the fact that Blizzard has resorted to checking the stack is making me consider returning to OOP which is where i started.

I don't think that is needed, if you are private and want to be safer I would probably still inject my app into WoW and use direct memory(aka not using popular func ptrs) over using any RPM stuff since it is so.. so.. soooooooo slow.

This feels like a departure on blizzards part from past practices.

In what way? They have used stack traces for years now. Actually, even 10 years ago on diablo 2 I remember some of my friends tools has protection against stack traces.. I think it's been something to be aware of and even used sometimes for pretty much the entire existence of their post-warden anti-cheats.

If you don't understand enough about anti-cheats to stay protected, I would simply recommend staying away from the use of Lua (and other conventional botting functions for that matter - ie. click to move.) It's not really needed if you're bothered to put in some extra work and seems to always be Blizzard's target when banning people.

I am probably wrong, but I really do not think it is that hard to call something like FrameScript::ExecuteBuffer in a private setting with out getting banned.

[Filint]

If you're in process and willing to register functions and unlock Lua (there are many different ways of doing this) then you can completely avoid using executebuffer and have a clean stack while executing arbitrary Lua. But, this can't really be generalised to anything other than executing Lua in wow. I think the more interesting discussion here is how to avoid/defeat stack checks. Its pretty simple in theory but when it comes to actually implementing it I found it to be quite tricky.

[lolp1]

If you're in process and willing to register functions and unlock Lua (there are many different ways of doing this) then you can completely avoid using executebuffer and have a clean stack while executing arbitrary Lua. But, this can't really be generalised to anything other than executing Lua in wow. I think the more interesting discussion here is how to avoid/defeat stack checks. Its pretty simple in theory but when it comes to actually implementing it I found it to be quite tricky.

Blizzhackers ? View topic - warden thread

1) Fake stack frames
2) Push a legitimate return address for a function, set a debug breakpoint on that addres, and jump to the function instead of calling it.
3) Debug breakpoint on the return address in the stack.

[aeo]

For me he tradeoff is performance. I don't have a warden scan hook to hide a direct patch. Hwbps on anything that is able to unlock all lua is slow. I can do it by hwbp a few key functions but it's still not as fast as needed for my machine at least. I think my final problem is I'm not very familiar with the x64 stack so I'm running into a lot of crashes but heh that's learning

[-Ryuk-]

Out of interest where do most people hook now?

I found a function that is called fairly often GetTickCount = 0xB825CA(not rebased;6.2.320779), just be aware that this is called for lots of threads not just the main one, so you need to filter it.

[DarkLinux]

Lots of vtables you can hook I'm hooking a vtable and faking the return address on the stack + hooking it just b4 it returns. I would say its one for the more safer ways. Dont like the return hook as I hate to modify any memory. And I'm still playing around with the stack, who knows how far up they will read and if they blindly do so.

[lolp1]

Lots of vtables you can hook I'm hooking a vtable and faking the return address on the stack + hooking it just b4 it returns. I would say its one for the more safer ways. Dont like the return hook as I hate to modify any memory. And I'm still playing around with the stack, who knows how far up they will read and if they blindly do so.

You might not know but you can certainly make a reasonable guess, no? I would say it is more likely it will not be too far up due to their accuracy standards in making detection's.

[-Ryuk-]

I can confirm that this is now running again and detouring lua_load(0xB63A1 rebased). I don't know if they changed how they checked if it was invalid, but since many people got hit by a ban last night I would assume that they now check the stack a little bit further than before.

Be careful