[Source]Anti-Debugging

Originally Posted by Gordon`

@Void: you can read with ReadProcessMemory the whole DOS + PE-Header of every exe/dll. In the PE-Header are all informations you need - IAT/EAT, Relocations, etc..

But can't you simply circumvent that by destroy the PE header file of your injected module as soon as it's in the memory stream?

Originally Posted by Gordon`

As far as I remember CreateRemoteThread calls CreateThread in the remote process.

Also a system-wide hook on Nt/Zw APIs requires to be on ring0, the kernel mode. You would need to write a driver for all common operating systems (XP, XP x64, Vista, Vista x64, 7, 7 x64). Also on x64 operating systems you need a signed driver (which can be bypassed, but I wanted to mention it).

Every little mistake on kernel mode/ring0 gives you a bluescreen and can destroy your system. Be careful if you want to write a driver. WDK/DDK helps you.

@Void: you can read with ReadProcessMemory the whole DOS + PE-Header of every exe/dll. In the PE-Header are all informations you need - IAT/EAT, Relocations, etc..

With the 64-bit unsigned driver thing, there are two quite simple solutions.

First is to run a command through the command line in admin mode, and it's done. (bceddit if I remember correctly)

Second is to self sign the driver. Again, you'll be able to install this driver without problems.

Originally Posted by Void

Thanks Deezy, I'm definitely going to read over this later on in this project, anti DLL injection is going to come after anti debugging.

@Wes, how would I know if CreateRemoteThread is being used to inject DLLs? I mean, if I check if it's creating a thread at the LoadLibrary function, an extremely easy way to bypass this would be to write a jump or call somewhere in allocated memory space and start the thread there. |:

You can safely assume 90% of the people that try to inject a dll are scriptkiddies/end users of public hacks, therefor using whatever is publicly available to inject dlls, most of them using CreateRemoteThread.

Originally Posted by Hell_Demon

Yeah I agree, from what I could gather, most of the public hacks for "Combat Arms" at least are just using a CreateRemoteThread method without destroying headers or basically running any anti-detection method. Pretty sure if Nexon weren't such a bunch of lazy asses they could have easily just checked known modules with all modules in the process at the time. Would you even need to catch the "CreateRemoteThread" with something like that? Or could you just do a scan at any point of all loaded modules and check them against a list of "safe" modules?

Originally Posted by J-Deezy

they are not the ones checking for "hacks" (the game).. Hackshield is.. And they didn't code it.. Of course they could try to to some themselves.. but they are delevoping a game, not an anti hack. And if they paid for hackshield, they are going to use it. ;o

And almost every online game that get's hacked uses CreateRemoteThread because one guy creates a basic pub hack using it, and everyone copies it.. Just like Wes (HD) said.

Edit: I remember a few weeks ago i saw few others methods on injection with SetWindowsHookEx somewhere... But it's all about "blocking" the API. And also without API's.

Originally Posted by Brinuz

Yes, but it should also be possible for them to implement a simple thing like what I said into your own game that just randomly checks the loaded modules. I guess that could provide more ways to exploit it if it had to be given access to all the modules... I dunno much about the internal cog-work that goes on in memory streams and such and permissions and stuff. I know literally nothing about ASM or how memory works etc so I'm probably not the best person to be discussing such in-depth stuff with, but I find it interesting.

About the CreateRemoteThread method. There is probably a reason that anti-cheat company's don't put simple DLLInjection detection techniques in their protection, and I would pinpoint it at packers such as Themida, which destroy import tables. Themida therefore prbly loads each DLL independently instead of letting the windows loader do it. Therefore unless the packer could be given a list of every DLL used in the game it is prbly best to get rid of that protection mechanism entirely, but this is just a theory.

I don't know enough about Themida or Anti-cheats to know this. So don't take what I said too seriously.

Also: http://www.bluenotch.com/files/Shewm...-Injection.pdf - A good document on DLL Injection defense techniques.

Originally Posted by J-Deezy

It's the loader (aka. injector) that uses CreateRemoteThread. Once a library has been loaded into its target process, it no longer needs to use CreateRemoteThread, because it is already in the address space it wants to create the thread in. CreateThread will work just fine. And if you were to hook CreateThread, well, there's a whole heap of sorting out you now need to do.

And if we inject with CreateRemoteThread before a completed anti-hacking system has loaded (which would take a few seconds), it won't have detected us!

Originally Posted by why06

Thing is, both Nexon don't want to completely blocked DLL Injection. Nexon wants to allow legitimate tools to run, such as video recorders (like fraps), special interfaces (like Xfire) and other legitimate stuff (like benchmarking tools).

You may also want to leave that possible for your end customers... (It's all about user experience)

Originally Posted by freedompeace

I can understand it just fine...

It's also already clearly explained...

--"

learn to detect trolls please

Holy snap, crap load of replies, thanks guys.

But I'm still focusing on anti debugging at the moment. /yea

[Source]Anti-Debugging

Post a Reply

Similar Threads

Tags for this Thread