Hello,

I was wondering if there is any way to prevent hooking a given API???
Is this how some applications are able to prevent being dumped or is it done some other way???
Thx,

Regards,
YAA
Posted on 2002-09-19 14:01:43 by yaa
I have no idea, but I might try something like this

.data

dllName db "user32.dll",0
procName db "GetMessageA",0

.code
invoke GetModuleHandle, dllName
invoke GetProcAddress, eax, procName
cmp dword ptr [GetMessageA+1], eax
je @f


...or something. I guess it would check if your imports have been patched but I don't know if it would thwart API hooks.
Posted on 2002-09-19 15:52:26 by iblis
There are different ways to hook api's, but if they are actually patched, there's only one thing that one can do - check to see if the code is modified. The problem is that if someone patches the api, they don't have to patch the api entrance .... there are many places to patch an api to hook it.

Furthermore, there are other ways to hook api's than to patch the api itself. Protecting against all ways is rather hard, since you're fighting an enemy you don't really know where is.

Which leads to: app's that can't be dumped. This is not to do with protection against api hooking, but to do with encryption/packing/wrapping. If the app is encrypted, and decrypts bits at a time, and re-encrypts decrypted sections, there's no way to dump all of the image at one go. One would have to manually decrypt the whole thing, and this may not be possible, depending on how the app is written.

Two things to stop dumping: encryption and checksums. Together, they make dumping a pain in the ...

Fake
Posted on 2002-09-19 15:57:18 by Fake51
If the app is encrypted, and decrypts bits at a time, and re-encrypts decrypted sections, there's no way to dump all of the image at one go. One would have to manually decrypt the whole thing, and this may not be possible, depending on how the app is written.
I believe this would not be too hard to beat, as the code that does the decryption will always be in a decrypted state, which means that it would be easy to copy the algo, then memory map the app and run the algo against it.

yaa,
this type of subject has been covered many times in this forum, as we are on shaky ground when discussing it (because of the forum rules), i would suggest that you do a search for those previous threads, that way you don't risk this thread being censored :)
Posted on 2002-09-19 17:20:36 by sluggy
Is this how some applications are able to prevent being dumped
DumpShield

To prevent dumping it hooks ReadProcessMemory.
Works under w9x only.

The code given by iblis should look like this:

.data

dllName db "user32.dll", 0
procName db "GetMessageA", 0

.code
start:
invoke GetModuleHandle, addr dllName
mov ecx, eax
invoke GetProcAddress, ecx, addr procName

mov ecx, dword ptr GetMessageA + 2
mov ecx, [ecx]
cmp ecx, eax
je @f


It let you only check if IAT (import address table) in your module was patched,
and real GetMessageA address is not match.
But it will not work if export table of module that exports API being hooked was patched also.
AFAIK, there is no way to prevent hooking a given API from ring3.
You can only do some check if it was hooked.
Take a look at this thread. There are many useful link about API hooking.
Hook question for advanced coders
Thought there is no info about preventing hooking there,
but if you know how to hook, it can help you to manage how to prevent it.
Posted on 2002-09-20 02:42:30 by Four-F

I believe this would not be too hard to beat, as the code that does the decryption will always be in a decrypted state, which means that it would be easy to copy the algo, then memory map the app and run the algo against it.


Everything depends on the circumstances. As all shareware programmers should know (but most don't) the best algorithm will do you jacksh*t if you don't implement it correctly. Your decrypt algo should rely on other parts of the app being encrypted. That way, if all previous sections are decrypted, you won't be able to decrypt the last. It can be done by using an encrypted area to decrypt another. The decrypt algo in itself should not be enough to decrypt every part of the app.

In passing: someone determined to dump the thing won't be stopped. It will still be possible to dump the thing, grabbing a section at a time. To work against this, use checksums on encrypted parts of the app.

Fake
Posted on 2002-09-20 03:57:54 by Fake51

DumpShield

To prevent dumping it hooks ReadProcessMemory.
Works under w9x only.



Dumpshield won't keep off dumping of your app. If someone is trying to dump, there are other ways than using using a dumper that uses readprocessmemory. Plus, the 9x dependancy makes it sorta useless.

Fake
Posted on 2002-09-20 04:00:13 by Fake51
I am inclined to agree with Fake here, compression/encryption is a pain to deal with, particularly when its combined with a CRC or length checking algo somewhere later in the code.

Passing around stuff in memory mapped files between DLL calls adds to the joys of dumping code as there is nothing intuitive about finding global access variables that come from nowhere.

Changing how a DLL or EXE acts if the CRC or length is wrong is easy to do but no joy to modify and while nothing is unbreakable, it sure takes the fun out of an easy dump/hack/patch.

Regards,

hutch@movsd.com
Posted on 2002-09-20 04:22:19 by hutch--
there are other ways than using using a dumper that uses readprocessmemory. Plus, the 9x dependancy makes it sorta useless.


Of cource you are right. That only simple example for yaa how it can be done.
At least it protects from dumping with most famous ProcDump under w9x.
Posted on 2002-09-20 06:21:29 by Four-F
Is there any way to protect an app from being dumped when using one of those other ways Fake is talking about?


Regards,
YAA
Posted on 2002-09-20 14:20:16 by yaa
Exactly what do u mean?

Fake
Posted on 2002-09-21 12:57:50 by Fake51
I was just wondering if there is anyway for an application to protect itself from being dumped when someone is employing one of the other methods you were talking about. By the way, what are these other methods?

Regards,
YAA
Posted on 2002-09-22 14:28:09 by yaa
yaa:


Did you heard about polymorphism and metamorphism ?
These techniques could be the strongest form of code protection a commercial application may involve against cracking/RE.
Implementing them is difficult but I suppose you can easily find some "all done" on the web...

PS : I bet Anti-Hooks procedures will be totally inefficient for what you want to do.
Posted on 2002-09-22 18:48:01 by Axial
Well, one typical way is to manually dump an app, using a ring-0 debugger. They don't rely on readprocessmemory, so checking if that's hooked, or hooking it yourself would be utterly useless. In that case, you could try to check for instances of soft-ice or trw, but that will do you little good (look elsewhere on the board for reasons, I believe they have been stated a few times).

Through process hooking, another app could gain access to your app's process space, and might then be able to read it, without making use of readprocessmemory. It might be dirty, but they probably wouldn't care.

Anyway, I'm probably stretching things a bit with board policy, so I'll refrain from going further into the issue. I'll just repeat the main point: Although you can protect yourself against different ways of memory dumping, you'll soon end up doing a lot of work, that will probably be a wasted effort. Instead of trying to prevent people from dumping an app, make sure that their dump is useless.

Fake
Posted on 2002-09-23 02:47:46 by Fake51