Correct me

You need to retrieve the modulehandle because you need the address of the module to add the offset of the variable you need inside it to it.

The module handle is the starting (base) offset of that module in the calling processes context(think of it as memory for now): cShell.dll is a module loaded Engine.exe's process.

You stored the base address of CShell and now you add the offset of the variable you need to it. You need the address of CShell because the variable you need is in there.



I'll comment the lines one by one for you.

This is as you know a function, don't be thrown off by the __cdecl thingy, it just tells windows what to expect form the caller (This means: caller fixes the stack)

We just discussed this one.

This checks if dwCShell (the one that receives the module handle) is not NULL, if it is it means that the module is not loaded into memory, and thus we cannot use it

We already did the first line, and the second line is almost the same, apart from the fact that it's a multi level pointer.

The __asm statement tells your compiler that you're going to input some ASM code into your code.

The push instruction pushes the push to console command onto the stack. Windows functions take their variables of the stack to use.

The call instruction tells windows/processor to call the address that you've stored in CONoff, CONoff if I'm correct points to some in-game console function. I'm sure you know what that is. In most games you can put such a console up with the '`' key(so you know what I'm talking about)

add esp, 4 is a mandatory because you just told windows with __cdecl that you're going to fix the stack. Adding 4 to the esp register fixes the stack


And that's basically what this code does. It shoves commands to the in-game command function that Nexon has removed from the GUI (you can't bring it up with the '`' key in CA or Warrock)

-SCHiM

Thank you very much.

+rep and thanked

thanks SCHiM for the explanation, i know i learned something from it