ring0 = lame.
encryption = temporary setback, which will harm end users in the long run.
10000 checks with different auto-generated algos is about the only _really_ effective thing.
Posted on 2003-08-15 08:17:47 by f0dder

ring0 = lame.
encryption = temporary setback, which will harm end users in the long run.
10000 checks with different auto-generated algos is about the only _really_ effective thing.


thanks f0dder!
I belive this shoul'd save my time in the future :stupid:
Posted on 2003-08-15 19:26:03 by S.T.A.S.


encryption = temporary setback, which will harm end users in the long run.


how would the one-time pad system not work ? (aside from a previously-licensed
copy being passed around the net).
Posted on 2003-08-24 22:14:30 by abc123

(aside from a previously-licensed copy being passed around the net).
That is the flaw, and that is what happens presently.
Posted on 2003-08-24 22:39:37 by bitRAKE
in reality, just make a non-full demo with stripped and crippled functions, and do not even allow users to download the full version of the exe, rather give each buyer the non-crippled version, etc. etc.

i dont think it is very often that "crackers" add and inject functions into crippled exes, for unless they had great motivation to do so, it would be quite a waste of time.

Anyhow, these are some anti-debugging techs. i had found on another article...and they do appear to be quite interesting.

1.) IsDebuggerPresent() API

really easy to use...but really isn't efficient IMO, lots of debuggers bypass this

here's what MSDN says:

The IsDebuggerPresent function determines whether the calling process is being debugged.


BOOL IsDebuggerPresent(void);

Parameters
This function has no parameters.
Return Values
If the current process is running in the context of a debugger, the return value is nonzero.

If the current process is not running in the context of a debugger, the return value is zero.


however, this API isn't supported under win95, so :<


Another technique takes the use of the FS register, and it was published in some v*ral magazines :rolleyes:, which i wont mention here.



mov ecx,fs:[20h]
jecxz no_debugger_found

;we're being debugged :|





oh well, these really dont serve a real efficent purpose if you're preventing your applications to not become another link on some warez site, IMHO the *only* and real effective technique is crippling your demo, period.


Best Regards,

Drocon
Posted on 2003-08-24 22:52:27 by Drocon
Posted on 2003-08-25 03:05:36 by wizzra

just want to give you some resources:

http://www.anticrack.de
http://daemon.anticrack.de



wizzra =)

May i also suggest (CrackProof Your Software - Pavol Cerven-) A very nice book for anti-cracking methods.

CuTedEvil
Posted on 2003-08-25 06:13:11 by CuTedEvil
"CrackProof Your Software" is being laughed at in "professional circles". I think the general comment is something aline "It's a bunch of ripped old tricks wich have been known for a long time, along with some pretty bad explations".
Posted on 2003-08-25 09:23:23 by f0dder
f0dder, those in the "professional circles" would recommend what reading material?
Posted on 2003-08-25 10:35:40 by bitRAKE
fravia's old site - even though there's a lot of shit and very fem gems, a lot of materials are outdated, etc., there's still okay stuff there. Fravia's (well, tseph's) messageboard, even though it's full of pretentious elitists and asslicking wannabes - there's still some threads there every now and then. Anticrack.de. http://www.reteam.org/ . Various smaller sites. disassemblies - study both the latest&greatest protections, and the "tools from the darkside". If you want to protect, that's the only way forward. And most people should give up before beginning.
Posted on 2003-08-25 11:00:02 by f0dder
f0dder,
You are part of ret right? :grin:
Posted on 2003-08-25 11:08:20 by roticv
more or less (so yeah, it was a shameless plug). I have had so much real-life stuff going on lately that I haven't had much time for any coding, RE, or whatever, though.
Posted on 2003-08-25 11:11:29 by f0dder