How does a bot technically and specifically work?

[C_O_R_E]

Hey guys,

I'm quite busy with university and trying to get in touch with bot programming, reverse engineering and hooks. University and part-time job at there keeps me busy but spending my remaining time in the week for 'interests'


I have to begin somewhere and decided to get a start at bot programming.
A question popped out regarding to bot programming and can't explain it, how
it should work.


When my bot works with addresses, many factors exists like memory randomization, architecture, varies from end-host to end-host.
there might be some more factors and some will probably pop out if I spend more time but anyway, you got it, right?


The addresses changes at every restart, the solution is calculating the base pointer, which always points to the right address.


Does this base pointer in the stack frame varies from user to user?
- I would say yes, because stack-based memory allocation varies from user to user.

My idea is to obtain the address the game client is running on. So, its just relative jump to the address, isnt it?


How does a bot programmer managing the address calculation for his clients?


Please be technically specific as possible

[florian0]

In general, a program is deterministic. Same input, Same output. For compiled languages on a singlethreaded application: same codeflow. Therefore mostlikely same stack-allocation.
JITs can really ruin your day on this one . If your code spreads work on multiple threads, codeflow changes.

In a compiled application, the stack allocation is likely to be the same, but there is a more reliable technique than calculating addresses and hoping. You have to step up from a Memory-Point-of-View to "Purpose"-Point-of-View. Consider, how the memory is being used.

Somewhere inside your executable is a function that creates your object of interest.
It is easier to simply detour here. Once the original code is executed, it takes a sidestep into your own code where you can simply write down the address of the allocated object. Then return back to the original func like nothing ever happened.

Once you got a deeper understanding on how your data is used, how it is changing, reacting to changes and linked together, things will get a lot easier. Maybe, you'll be able to reuse the games functions for modifing the data (e.g. use an item in the inventory).

[C_O_R_E]

@
I think detour-functions are meant to be the same as hooks, right?'cause it sounds like the same thing.
For a couple of weeks ago, I wrote some hooks for linux small programs and works
like the way you described it.
Anyway, I think I got the point and indirectly answers my question.
All you say is, a bot programmer assumes where the object might be addressed by determining the base pointer. Right?
ASLR makes it hard to do so, a countermeasure from my side would be to start the game within a "sandbox environment" - Might be also a problem, when this "environment" also gets randomized in memory space.


Modyifing the game itself by using detour functions, isn't it architecture depended?
Like my hooks worked in a way with X86 instructions. So, the hack would only work
with X86 instruction set (Intel).


Lets make an example:

cmp     [esp+10h], 0
jz      short loc_696969

Lets assume the code above is a X86 instruction obtained from a game function.
My program operates now as a detour function, instead of jumping to
696969 my program is getting loaded into the stack frame, right?
Is it possible to operate out of my programs own stack frame into the game stack frame?

Logically, I should have access to the game locals/objects. So this would also explain how anantivirus program works, 'cause it observes such a operation like that.
Detecting programs which are operating out of the own frame makes it rlly to a point of interest.


Thanks alot for you effort!

[florian0]

Yes, detouring is the same as hooking.

Since you're realing with plain assembly code, it is indeed architecture depended. An x86 hook will only work on x86-compatible processors, an x64-hook will only work on x64-compatible processors. (Even if x64 and x86 assembly mnemonics are pretty much the same).

Hooking requires injecting code somehow. Doesn't matter if you inject an entire dll or use a remote thread to allocate memory and copy your code over.
When the original code enters your detour/hook, the stackframe does not change at all. Its still the same program.

Lets say you wanna hook that example code.

cmp     [esp+10h], 0
jz      short loc_696969

The memory of interest is that value in esp+10

jmp <your code>
jz      short loc_696969

We override the cmp-instruction with a jmp to your code.

your_code:
mov g_ImporantVariableValue, [esp+10h];
jmp <original_code>

Now your code does a simple copy of that value into a global variable that you allocated somehow before.

The jmp to the original code will, for this example, return to the jz instruction.

Sadly, its not that easy in real life, because the jmp-instruction often requires more bytes than the original instruction had. In this case, you have to preserve the original code in your custom code before returning to the original code.

[Ares]

#moved