[Help] HowTo use LUA func

[jojom]

Hello,
first, I apologize in advance for my very bad english, but I come here because I can see that this site seems very active so sorry if you have trouble to understand me :confused:
I am currently doing a cheat for the version 3.3.5a 12340 (tphack, flyhack, speedhack, realmlist changer, walk on water, ...). I know coding in c/c++ and I'm able to write / read simple things in memory but I need some help in using LUA functions.

For some reasons, i need to use the "/reload" command into the chat. So i searched some lua func and i found :
lua_SendChatMessage with the offset : 0050D170 // for 3.3.5a 12340

So I launched my OllyDbg and I researched this offset :



And after... I don't realy understand, i know simple assembler instructions but i don't know where to start :confused:

So if you could help me to understand and interact in c++ (in preference, but i can understand autoit and c#) with this function it would be great

[lanman92]

That's not the function you want. Use FrameScript_Execute. There is a lot of information in this section about it. Just make sure you run it from the main thread.

[jojom]

Right, after several searches I noticed that "FrameScript_execute" was also called "Lua_DoString", so i found Lua_DoString = 0x00819210, // 3.3.5a 12340 .

As you said lanman92, there is a lot of information about "Lua_DoString", I found source code in c# here for exemple (Lua Do String) or here (they are very similar ).

But I have some difficulties to translate c# to c++, so if someone could help me to understand it, it would be very nice

and is it forced to use blackmagic dll?

thank you

[J0llyGr33n]

How i'm doing it:

public void LuaDoString(string command)
        {
            int nSize = command.Length + 0x100;
            uint codeCave = process.AllocateMemory(nSize);
            uint moduleBase = (uint)process.MainModule.BaseAddress;

            process.WriteASCIIString(codeCave, command);

            process.Asm.Clear();

            String[] asm = new String[] 
            {
                "mov eax, " + codeCave,
                "push 0",
                "push eax",
              
                "push eax",
                "mov eax, " + (moduleBase + Offsets.Endscene.Lua_DoStringAddress),
                
                "call eax",
                "add esp, 0xC",
                "retn",    
            };

            vLib.InjectAndExecute(asm);
            process.FreeMemory(codeCave);
        }

seems to be pretty straight forward.

[Viano]

Yes but why doing this? Inject. Hook. Win.

[Empted]

seems to be pretty straight forward.

This will cause crashes i guess and not that rare you think. And seems like you don't update thread's TLS.
Just make a simple detour. So you pause process, modify memory page properties for writing, not just executing and reading, write jmp to your codecave at the start of some frequently called function (some d3d func or even WoW's like RenderWorld to start with) and in that codecave you simply call anything you want and then restore original 5 bytes of the function then jmp back. This is probably the most explicit and close to your code way of calling function in main thread, though not the best.

[jojom]

seems to be pretty straight forward.

yes in c# but not in c++ :/

[flo8464]

yes in c# but not in c++ :/

It's easier in C++ than in C#, because C++ is a nativly compiled language and C# not.
The code snippet is horrible, it has a tendency to leak memory (C# people seem to leak more resources than people using a language without garbage collector ...) and it won't work as lua function have to be called inside WoW's main thread context, but Black Magic will create a new thread to execute the code. Even if that chat functions are an exeption and do not rely on thread-specific data, you'll encounter threading problems like race conditions.

Just inject a DLL and hook some function only called by the main thread (Prefer Endscene oder GlxSwapBuffers, depending on which 3d-API you use to run WoW, as it ensures that you have a consistent state) ad do your stuff there.

The only alternative to code injection is adjusting the main threads context (Didn't use Windows for over 3 years, but it should be SetThreadContext/GetThreadContext) which is VERY hackish.