Re: Clever ways to hide a compare
- From: "hutch--" <spamtrap@xxxxxxxxxx>
- Date: Sun, 25 Sep 2005 04:47:26 +0000 (UTC)
I have yet to see a technique tha causes as much grief as the "maze of
garbage" approach in terms of the amount of work that needs to be done
to get around it. The weaknes with any concentrated evaluation is that
once it is found, its easy to break. Do a compare somewhere that
branches after the compare and you are dead meat. Change the opcode for
JE to JNE and you have usually defeated that protection scheme and
fortunately most of these have disappeared.
Use global scope variables and they are nor sequentially tracable so
you can write something to it in one location ad use it somewhere else
with no obvious connection. Enabling bits of code on the basis of
correct keys can be done well and be very hard to find, distributing
string data through an app is no joy to find and if you want to give
them nightmares, try using basic dynamic string for constructing
various bits of string data.
Shove the result through an decent EXE compressor that does not have
automatic expansion like UPX and you defeat simple patches and people
tweaking bits with a hex editor.
Looking for the single simple big hit is a surefire way to get you
software broken easily but distribute it all over te place and you
increase the workload to defeat it by some powers if you do it
properly. With enough time, any system will be broken, particularly if
its a sought after app but the more work it is, the longer it will take
to be broken and idiosyncracy works well for you here.
Regards,
hutch at movsd dot com
.
- References:
- Clever ways to hide a compare
- From: jonathon
- Re: Clever ways to hide a compare
- From: David J. Craig
- Clever ways to hide a compare
- Prev by Date: Re: accessing device memory
- Next by Date: Re: Clever ways to hide a compare
- Previous by thread: Re: Clever ways to hide a compare
- Next by thread: Re: Clever ways to hide a compare
- Index(es):
Relevant Pages
|