[Narvikz]

What I have read above is mostly bullshit to be honest.

You want to stick to the same language as the game you're programming for and (preferably) the same compiler even.

This will help avoid any incompabilities that could happen if done otherwise.

So, CS:GO for example, is coded in C++ and compiled using the Microsoft C++ Compiler, by sticking with it you're making it so much easier for your work, since the calling conventions basically are the same which makes it much easier to hook stuff without having to deal with naked hooks and shitty inline function prologues and epilogues.

Really, there's no reason AT ALL to be using inline asm in 2016, please...

It's REALLY REALLY easy to hook shit like that.

Just hook _stdcall as _stdcall by replacing the first 5 bytes (or 6-7-8, whatever, depending on instructions placed there) with JMP + address, start your hook by the instructions that were replaced and end your hook by a JMP back to the place you hooked, no inline ASM, no nothing.

Same thing for _thiscall but now with _fastcall with ecx and edx pointers and arguments right to left once again after that.

In the end it would be WAY harder to use a C# module for this since the process wouldn't even be able to run the module without some hard work around it, even if you did it hooking stuff would be a pain in the ass really and there's really no benefit to it.

Now, Java? Wtf? Really?

[Narvikz]

Did you just post on the wrong thread ? ... ?

Who is talking about CSGO ? What if OP just want to hack a browser-game ?
Who ever wrote ASM on this thread ?

I don't support C# but I can bet there is open-source projects to hook process functions with it.

Don't blame Java, you and I said it : He have to stick to the language of the game.
But we don't even know the target game in the first place !

Because I was giving an example man, rule of thumb if you're going internal (which you should be, really) you stick to language and preferably compiler of the game you're targetting to minimize compability issues.