Re: DLL Injection Detection
A dll is a module. So the task must look like enumerating a process modules. The task could be performed several ways, and to begin with something I would suggest to create a toolhelp32 snapshot and enumerate process modules. That would be the very first spoon.
Re: DLL Injection Detection
OK I'll be sure to do that. Anyone else want to chime in, maybe with some ideas on how I can accomplish my task?
Re: DLL Injection Detection
if you really want to prevent DLL injection.
- set your program security descriptor
- prevent apps from getting your process handle.
- scan for dll modules (without winapi) nt internals
- re-fix import table
this is how far any pro game security goes.
cannot give you specific details on how todo that, good luck
Re: DLL Injection Detection
Well, I mainly just want to know if a DLL has been injected, not necessarily PREVENT them from being injected. Because if a DLL HAS been injected, I want to alert the server admin that cheats have been detected, or I want to kick/ban them from the server. So I don't necessarily need to prevent it, I just need to know if it's happening.
Re: DLL Injection Detection
One point to remember: an injected dll is not necessarily a cheat tool. For example: contemporary dictionary applications inject global hook dlls into processes. Last year I made the one for one well-known respectable dictionary. :)
Re: DLL Injection Detection
Quote:
Originally Posted by
Igor Vartanov
One point to remember: an injected dll is not necessarily a cheat tool. For example: contemporary dictionary applications inject global hook dlls into processes. Last year I made the one for one well-known respectable dictionary. :)
That may be true, but in my case most if not all injected DLLs will be cheats. And if there is any that aren't, I should be able to distinguish them depending on their name or some other way. But as far as I know there is no legit reason for there to be injected DLLs into this specific game.
Re: DLL Injection Detection
What you are trying to do is swim against the stream, that is the problem all game developers
have since day 1.
cj-wijtmans post is maybe the best advice, not using any win api calls (any function you call for detection could be hooked already).
It's maybe a good idea to use EncodePointer and DecodePointer at startup of your application.
Just scanning for injected dll's can be done by using toolhelp32 as Igor Vartanov already mentioned, but again, several applications inject dlls into other processes for any reason, so it's probably not a good idea to bust an user because of those results.
Re: DLL Injection Detection
Quote:
Originally Posted by
pobri19
But as far as I know there is no legit reason for there to be injected DLLs into this specific game.
As far as I know, a global hook dll is injected into each and every windowed process that runs along with the hooking process... Okay, I'm gonna stop bothering you with my suggestions, have a good hunt. ;)
Re: DLL Injection Detection
Quote:
Originally Posted by
Igor Vartanov
As far as I know, a global hook dll is injected into each and every windowed process that runs along with the hooking process... Okay, I'm gonna stop bothering you with my suggestions, have a good hunt. ;)
My bad hehe, but that won't necessarily be a problem if I can get the names of the injected dlls. I could probably have a blacklist of known cheats or something, and run the names against the blacklist, or possibly attempt to see what the injected modules are trying to do, and if they're doing something suspect (like trying to hook OpenGL) I will know if it's being used for cheating. Anyways, sorry if I came across wrong, but what I just stated was what I was trying to get across =)
Re: DLL Injection Detection
better to check DLL's for CRC hash
Re: DLL Injection Detection
Igor Vartanov
A dll is a module. So the task must look like enumerating a process modules. The task could be performed several ways, and to begin with something I would suggest to create a toolhelp32 snapshot and enumerate process modules. That would be the very first spoon.
can you give me c# source code how to detect because i want to close my application when dll inject into my process.........help me to give c# source code.i remain thankfull to you
Re: DLL Injection Detection
Quote:
Originally Posted by
Qasim Qadri
can you give me c# source code how to detect because i want to close my application when dll inject into my process.........help me to give c# source code.
But why do you ask about a c# code in a C++ and WinAPI Forum?
Re: DLL Injection Detection
because i know c# and i make dll injector my self in c# now i want to detect.i did alots searching but tired to find solution.may be i not have much experience.i ask queston c# forum.i not get answer yet..may be i dnt know why they not provide me.i ask microsoft forum and stackflow.i just want when dll is injected in my process any event fire runtime or wat .dat i can detect it.then i will close my application. i hope codeguru team member will help me.
Re: DLL Injection Detection
Fact: You have no realistic means to stop all methods of client side "hacking". At best you can raise the bar and make it harder for the novice hacker or you can stop a couple common generic hacking tools dead in their tracks (or at least detect their use server side). There are simply put way too many ways you can:
- inject dll's into code
- inject code that isn't even in a dll
- execute code that influences a running program without even ever running any code in the addres space of your game.
Fact 2: It takes considerably more effort AND expertise to devise ways against a hack than it is to make a hack. If you aren't experienced at how "hacking a game" works in practice, you have zero chance of achieving anything.
Fact 3: Nomatter how good you are, there are a lot of hackers out there that are either a lot smarter than you, or a lot more creative than you, or a lot more devious/evil than your are.
Fact 4: A hacker will go to extremes in effort for even minimal gains. They will gladly spend weeks/months of effort on their cheat apps. Either because the minimal gains are significant enough to make a difference, or even just because it's a challenge to succeed at what they do. Even if you have a lot of paying customers, you cannot possibly match every hacker with an appropriately matching investment in time/effort/money to stop them.
----
Listing all the DLL's is easy enough. This is achieved with EnumProcessModules(). This returns handles, you can know which dll it is with GetModuleName or GetModuleBaseName. note that a LOT of dll's can get loaded in your application process space for a wide assortment of reasons, these can be perfectly legitimate and blocking them could be anything from mildly annoying to the user, to potentially harmfull (as in preventing the PC from operation properly and even destroying data and preventing it from booting anymore).
Listing all the memory that is marked as executable is also easy enough. Just use VirtualQueryEx to walk over the entire memory range and obtain the Access flag to see if it's executable.
You can then match this up with the loaded modules (dll's) and pick out any sections of code that are marked executable but aren't part of a DLL's image. This could be suspect, but it's also used in legitimate ways by for example JIT compilers, scripts, and even some Windows DLL's use this for code-overrides on specific hardware, or for obfuscating some security related code.
-----
What you can do are:
1) for local games. don't bother, the player is only hurting himself by using cheats. Cheat prevention is only a real issue for online/multiplayer games.
1) Don't send ANY data to the client that it can't know about (such as sending it information about what opponents are doing). This was abused in a cheat for a RTS game. The clients got information about buildings opponents were doing, so a cheat could be devised that basically removed the "fog of war" and you could perfectly see at all time what your opponent was doing and building.
In a "patch" this was fixed, but they were still sending information about how much resources everyone had gathered. By watching changes to the resources a cheat could infer what buildings/units were being built.
2) Don't allow the client to send/submit any information that isn't verifiable on the server.
If a user has X resources. and 2 seconds later he has Y. Then the server should have a means to verify that the transition from X to Y was indeed possible. The simplest way to do that is of course to do all resource management server side, but that isn't always fully feasible.
3) Even with the above 2 in place there's still plenty ways to cheat.
Autotargetters in FPS games. Any sort of automated play could be an issue. Detecting those is harder, this boils down to detecting 'unhuman' behavioural playing patterns.
GL. you have a very ungrateful job ahead of you. But it has it's rewards :)
Re: DLL Injection Detection
Quote:
But as far as I know there is no legit reason for there to be injected DLLs into this specific game.
Wrong, there are a ton of reasons for this to be legit.
Stuff like Ventrillo/mumble uses this for their push-to-talk button among others (global key hook). Videodrivers use this to enable/disable certain features on demand (again key hook). I've seen anti-virus software install Window hooks. Software to help people with disabilities hook all kinds of API functions in "legitimate" ways to either do voice-narating, or zoom/scale text, or display text on a braille device.
I could go on. The list of software that needs to do soem form of hooking/injecting is HUGE.
Quote:
if I can get the names of the injected dlls. I could probably have a blacklist of known cheats
Plenty "generic" cheats have built in obfuscation. Such as renaming the dll (even each run), even modifying the dll, or building "custom/randomized" versions for each of their paying customers.
Quote:
or possibly attempt to see what the injected modules are trying to do, and if they're doing something suspect (like trying to hook OpenGL) I will know if it's being used for cheating.
You have no realistic way to detect they are hooking API functions other than detecting one of several common tricks which no self respecting hacker would use.
You have no realistic way to check "what a module is trying to do", other than some basic heuristic testing. Even an experienced programmer will need a good bit of time to figure out what a chunk of assembly code is doing. And it's easy to obfuscate code so that you can't just watch at the entire code in a debugger. (A lot of cheats run on custom VM's, and all you ever see is the basic VM runtime loop).
With all due respects to the people on codeguru, and I know some are awesome.
Like I said in previous if you haven't got experience with the actual hacking process itself... you have no chance of stopping a hacker, you probably don't even have much notion of some of the tools these guys have at their disposal to do their evilness.
Re: DLL Injection Detection
You're probably right OReubens and that's also why I haven't bought any game for many years now. Multiplayer games are just full of cheaters or people that spend so many hours in it it's just not fun when you just have time to enter a few hours a week.
I whish there were more game companies that focused on making a good single player game, free of all the unwanted crap such as Steam, Punkbuster and you name it. The possibility to play against a friend over internet or local network would give extra points though. I miss the Quake evenings with snacks and a few beers we had at the company ages ago. :cry:
Re: DLL Injection Detection
EnumProcessModules() it require to check again and again..my code checking again and again dll exist or not....i want efficient method like wen somebody inject then any event fire or watever i can easy detect instead of listing of dlls then block by checking ...i
Re: DLL Injection Detection
i dnt think its efficient method to checking again and again by using process module name and enumprocessModule....i want efficient ways wen dll is injected and event fire .so my process will not disturb by checking again and again.Below code checking again and again.i dnt think its efficent..i want it will detect as event fire.LoadAssembly event handler not work because dll is injected in process memory.i dnt knowe what should i do...i need ur help.
while (true)
{
Thread.Sleep(500);
Process proc1 = Process.GetCurrentProcess();
for (int i = 0; i < proc1.Modules.Count; i++)
{
proc1.Modules[i].ModuleName.ToString();
}
// if count greater then current dll then APPLICATION WILL ESIST
if (proc1.Modules.Count > CurrentProcessModule.Count)
{
Application.Exit();
}
}
Re: DLL Injection Detection
A dll can be loaded before your program even starts executing, so you will need the EnumProcessModules anyway.
If you want to be notified of dll's being loaded and unloaded:
LdrRegisterDllNotification and it's companion 'unregister' are what you could use.
However... this only tracks actual DLL loads (LoadLibrary and LoadLibraryEx calls) done through the process space itself.
You could also hook LoadLibrary yourself (be VERY careful here, it's quite easy to get obscure bugs this way).
It won't help for injected code. Cheats can circumvent the API's themselves. It also won't help for out-of-process cheats nor will it help against rootkits (which are the thing the advanced cheat programs use these days).
Re: DLL Injection Detection
Quote:
Originally Posted by
S_M_A
You're probably right OReubens and that's also why I haven't bought any game for many years now. Multiplayer games are just full of cheaters or people that spend so many hours in it it's just not fun when you just have time to enter a few hours a week.
Quite a few games have an "always online" feature ONLY as a means to stop piracy or to force-feed or advertise additional (paying) services.
As to games that are really server based, true, a lot of them get their competition out of "playing more than others". You can't really avoid this, someone that has more time simply will be better even if just because of the fact they get more practice.
Then again, there are quite a few games that restrict how much a player can do each day either by having a fixed number of turns per day or a fixed number of time you can play or even getting a fixed amount of "action points" per day and you spend different amounts of those on various actions. Those games are rare though. Game makers tend to want their players to play MORE not less :)
Re: DLL Injection Detection
Quote:
Originally Posted by
Qasim Qadri
i want it will detect as event fire.LoadAssembly event handler not work because dll is injected in process memory.
// if count greater then current dll then APPLICATION WILL ESIST
If you are going to block/terminate your app whenever a dll gets loaded... your customers will REALLY hate you for that. (or you're simply not going to have a lot of customers).
Like I said before, there are tons of legitimate reasons why a DLL gets loaded into your application after it started running. Even calling some windows API functions loads additional DLL's (and this has become even more obvious with the way Win8 has taken things. Lots more stuff now is delay loaded to keep the initial footprint of your app as low as possible).
Re: DLL Injection Detection
Quote:
Originally Posted by
OReubens
A dll can be loaded before your program even starts executing, so you will need the EnumProcessModules anyway.
If you want to be notified of dll's being loaded and unloaded:
LdrRegisterDllNotification and it's companion 'unregister' are what you could use.
However... this only tracks actual DLL loads (LoadLibrary and LoadLibraryEx calls) done through the process space itself.
You could also hook LoadLibrary yourself (be VERY careful here, it's quite easy to get obscure bugs this way).
It won't help for injected code. Cheats can circumvent the API's themselves. It also won't help for out-of-process cheats nor will it help against rootkits (which are the thing the advanced cheat programs use these days).
can u give me source code Example.because i dnt have much experience.i can better understand from source code in c#..i wait for source code.