Path: news.mitre.org!blanket.mitre.org!news.tufts.edu!cam-news-feed5.bbnplanet.com!cam-news-hub1.bbnplanet.com!news.bbnplanet.com!news.idt.net!news-peer-east.sprintlink.net!news.sprintlink.net!Sprint!sunqbc.risq.qc.ca!atl.bellsouth.net!uunet!in5.uu.net!ozemail!news.mel.aone.net.au!newsfeed-in.aone.net.au!news.mira.net.au!news.iinet.net.au!not-for-mail From: daveb@iinet.net.au (David R Brooks) Newsgroups: comp.security.misc Subject: Re: anti-cracking methods wanted Date: Sat, 13 Dec 1997 00:10:35 GMT Organization: iiNet Technologies Lines: 74 Message-ID: <3491ce8c.50507208@news.m.iinet.net.au> References: <34914B75.3843@hotmail.com> NNTP-Posting-Host: reggae-06-69.nv.iinet.net.au Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Newsreader: Forte Agent 1.5/32.451 Auntie Crack wrote: :I am looking for ideas or methods on fighting cracks - where :a person modifies the program to (typically) make it run without :paying for it. : :Some will suggest that I focus on the people who will pay and :that is a fair comment. But let's face it. There is a science :to fighting crackers and it is high time we pursued it. : :I must be a newbie at it because my product was cracked in one :day. My mistake (I believe) boiled down to using an if() statement :which could easily be modified to always return true. : :I am looking for suggestions from people who know more than I, :or direction to places where I can learn more. : It's extraordinarily difficult to defend against a truly determined hacker. Indeed, I suspect it may be provably impossible (in the mathematical sense), in that the CPU must necessarily have available to it sufficient information to run the program. That implies the hacker has that information also. All you can do is try to build in a long & tortuous path, and cover it well. As the police once told me when I asked their advice about choosing a gun-safe: "with any lock or safe, all you are buying is time. A determined theif, with time to spare, _will_ get in." I put this to proof, as a private exercise some years ago, with a sertain product that was boosted as well-nigh un-hackable. Several portions of the code were encrypted, each under a different key. The decryption module was itself encrypted, using a different algorithm. There were booby-traps a-plenty, such as 1. Use the INT-1 and INT-3 vectors to perform essential jumps. This hampers use of a debugger. 2. Set the timer before starting critical code: if it interrupts before the code completes, kill everything. 3. Push a lot of space onto the stack, create your local workspace, then pop the junk off. This leaves a void under SP for interrupts etc. But anyone pushing _all_ registers (eg a debugger) will likely destroy the local space. There were two glaring weaknesses, which I exploited (had they not been there, cracking wouldn't have been impossible, but it would have taken longer): 1. The encrypted sections were defined by a standard data structure, which included the block loaction and the key. Find those structures, and you know what needs decrypting. 2. There was no trap in the decryption routine to ensure it was only called by "authorised" code. I attacked it by patching a call into free memory, and executing that. This fooled the timer, since the crypto routine ran at full speed. One problem with encryption systems is that the file cannot (without extraordinary precautions) be loaded as an .EXE, since the relocation will scramble the encryption. Some authors include several copies of the security code. The additional protection is illusory, as one has only to look for simplar code blocks. A very useful hacker's tool is a piece of program which is given a target file and a sample of code from it. The program then does a correlation of the two: just look for peaks in the correlation function to find likely copies of the same code (the addresses are different , so correlation is not 100%). You need to defend against an attacker who knows the details of the CPU thoroughly, including how to exploit such things as the '386 debugging hardware. -- Dave Brooks PGP public key: finger daveb@opera.iinet.net.au servers daveb@iinet.net.au fingerprint 20 8F 95 22 96 D6 1C 0B 3D 4D C3 D4 50 A1 C4 34 What's all this? see http://www.iinet.net.au/~daveb/crypto.html