Quote:
Originally Posted by asgborges
i dun care with your opinion...!!! WTH
whats wrong with u guys?!
i don wanna make a perfect code or whatever... i just trying to make ppl "think" by urselves in other way instead to only changes addresses or pointers...
and im SHARING this half that i know!!!
* do you mind if i wanna a free world?!
|
i posted in this thread because someone wanted to know how to make your code vc++ compatible, so i looked through the code and pointed out potential flaws that might lead to exceptions (especially in vc++), so that he can change his code accordingly to make it run. since you stated that you don't know about vc++, i added some vc++ inline asm specific stuff which i also had my problems with before i didn't know how vc++ handles inline asm (which it really does not handle very well). you stated this code was c++ compatible, but at least the inline asm part - might not - be vc++ compatible. so why not let someone correct it for some specific compiler.
then, for whatever reason, you went crazy on my post.
also your param passing to the remote thread IS a potential danger on any compiler. if you pass a buffer with an actual size lower than the size you read from it, there might always happen bad things. yaya, you wanna write a general function to pass more params, but still, if you code it like this in this special case, it IS a bad flaw, it doesn't matter what you COULD actually do if you DON'T do it (ok, you only read 256 bytes, which is probably not going to raise an exception, but still it is no proper programming).
just the same with your frame based exception handling in the remote code. yaya, if you did this and that you would be able to make it run (actually i doubt you would be able to make it run), but if you DON'T do it, and leave the code as it is, it IS another bad flaw. what does it help you if you raise an exception in the remote code and raise another exception because of broken exception handling.
and yes, your post is about remote code injection, still i made a little side note that dll injection is the way to go. what should i do? should i create a new thread telling everybody that dll injection is the way to go (which it obviously is)?
ya, your just setting a target in your code, it's a few lines to code a remote code injection. sure you can do it like this. but setting targets isnt the only thing your gonna do. at some point you will realize the advantages of dll injection, maybe not for now. i bet you that at some point you will get sick of resolving dynamic pointers and explicitly calling readprocessmemory to read anything.
hell, i wasnt even criticizing your method, actually i was just trying to help with the statement and again you went crazy. better change to dll injection now instead of later when you realize what i'm saying. i doubt anybody wants to call createremotethread and readprocessmemory a few hundred times per minute if you can do all this via direct memory reads and direct calls from a dll.
and again as for detectability remote code injection vs. dll injection...
first of all, even if you dont hide your dll, they cant ban you just for injecting a dll. if they did, everybody who has malware like userland rootkits that inject dlls into processes (and dont hide it) or some other shit on his system would get banned (there are also "good behaving" programs that inject dlls too). so they can actually only ban already known dlls.
what's bad about dll injection + hiding?
1) your threads will run in the target process
2) your dll still resides in the target process memory
about 1)
yaya, you can't completely hide a thread even with a rootkit because if you unlink it at the lowest possible level, windows won't give it execution time, so your thread will be paused forever. but still, you cant ban for finding threads that dont belong to the program, it can be something else than a bot.
about 2)
you can still strip unneeded information (like some headers, all import dll and name strings, etc.) or crypt some parts of it, which would make it really hard to identify a dll since such scanners would usually scan on page boundaries, but what, if there is no valid header?. since memory scanning the whole address space would use up a lot of system resources, this probably isnt really done too much anyways.
anyways, if i was a program and checked what was going on in my process, i would be a lot more suspicious, if some other program called readprocessmemory or createremotethread in my context a few hundred times per minute than if a dll was injected. what else than a bot would do something like this that often?
and im pretty sure that next generation anti cheat methods are going to be a combination of methods from blizz warden (dynamic download of the module or shell code) and 3rd party kernel level anti cheat tools that involve kernel level rootkit methods (i dont know whether this is allowed by law, but i think they can at least adjust their eula so that they may do it), which would make it even harder to access the process with api functions after the program has started. you wont have this problem with injected dlls that much since you wont be using such apis after the dll has been loaded (which should be done before the program runs its first instruction anyways). and hiding your process from a well coded kernel level anti cheat tool that knows what its doing, is like impossible as several programs on the net prove (over swapcontext etc.). so identifying a process over a hidden dll would be much easier.
so the statement that code injection was safer than dll injection is just not true, even more, if the anti cheat tool maximizes its possibilites, although both methods can be detected somehow.
maximum security would surely be to disable the anti cheat tool completely, which might take a lot of time of debugging depending on the tool, but if your looking for a general solution, hidden dll injection and switching from hooking game code to constant polling should be the way to go.
why do most (all?) professional bots that cost money come with a dll and maybe even a kmd anyway? why are they surviving for so long, although the game coders know it exists and can even debug its code if they purchase it (the imagination of the game coders purchasing a bot for their own game is pretty funny anyway, dont you think) or get their hands on it somehow else? probably not because its the wrong way to go..
Also by giving incorrect paramters to functions, or forgetting some parameters you might go outside the bounds of some containters/arrays (some functions use registers to pass some parameters) and there is a whole other lot of issues you can run into, it is so much fun 
)
