RE: RE: [DUG]: Software Expiry Codes - OnGuard
I am looking into a product called SlockPK, which locks software using Private Key technology, it's a Delphi component and comes with a cert builder for the end registrations. Has anyone else looked at this component and could provide any feedback as to how effective it is? http://www.crypto-central.com/slock/index.html Jason -Original Message- From: Max Nilson [mailto:[EMAIL PROTECTED]] Sent: Thursday, 22 February 2001 4:47 p.m. To: Multiple recipients of list delphi Subject: RE: [DUG]: Software Expiry Codes - OnGuard David Brennan asked; Does anyone know enough about RSA to tell me if this is correct? It would be really nice if I was wrong and RSA was difficult to solve in both directions ways. As far as I am aware from the RSA mathematics you are dealing with a symetrical algorithm, where it doesn't matter which of the two keys are used, its the security of the one you mark as 'private' that matters. What you in essence want to do is use the public key to decrypt something that you have encrypted with the private key. This is exactly what you do when you are sending a message that you not only want to be recieved by only one known person (so you encrypt using their public key) but can be verified by them as only being from you (so you also encypt with you private key first). Then they use their private key to decrypt your message, which they can decrypt with your public key proving that only you could have generated the message in the first place. I believe that PGP has this sort of stuff build in, but its been a while since I read the sources. That leaves the first problem - someone hacking the executable. In some ways I am less worried about this because it will prevent our support patches from working, leaves tangible evidence and I think it is less likely to have a widespread effect. Nonetheless I will still take on board some of Max's suggestions and see how diabolical I can make the password checking routines. The main issue is that once a simple checker is cracked a small know diff can be created that will usually be able to be applied to all subsequent versions, as unless you know that someone has cracked your code, you don't know to change the relevant code. You often find that applications that use this sort of half assed security have a 'war' with the crackers where every version has altered code, and then the crackers recrack the change for the new version, so the programmers create a new verion that the cracker crack and so on... So have fun with some sneeky code, and but remebver to factor the potential loss in software sales vs. your programming time. Sending 100 hours to save $1000 is not a good bet usally. Cheers, Max. --- New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED] Website: http://www.delphi.org.nz To UnSub, send email to: [EMAIL PROTECTED] with body of "unsubscribe delphi" --- New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED] Website: http://www.delphi.org.nz To UnSub, send email to: [EMAIL PROTECTED] with body of "unsubscribe delphi"
RE: [DUG]: Software Expiry Codes - OnGuard
David Brennan asked; Does anyone know enough about RSA to tell me if this is correct? It would be really nice if I was wrong and RSA was difficult to solve in both directions ways. As far as I am aware from the RSA mathematics you are dealing with a symetrical algorithm, where it doesn't matter which of the two keys are used, its the security of the one you mark as 'private' that matters. What you in essence want to do is use the public key to decrypt something that you have encrypted with the private key. This is exactly what you do when you are sending a message that you not only want to be recieved by only one known person (so you encrypt using their public key) but can be verified by them as only being from you (so you also encypt with you private key first). Then they use their private key to decrypt your message, which they can decrypt with your public key proving that only you could have generated the message in the first place. I believe that PGP has this sort of stuff build in, but its been a while since I read the sources. That leaves the first problem - someone hacking the executable. In some ways I am less worried about this because it will prevent our support patches from working, leaves tangible evidence and I think it is less likely to have a widespread effect. Nonetheless I will still take on board some of Max's suggestions and see how diabolical I can make the password checking routines. The main issue is that once a simple checker is cracked a small know diff can be created that will usually be able to be applied to all subsequent versions, as unless you know that someone has cracked your code, you don't know to change the relevant code. You often find that applications that use this sort of half assed security have a 'war' with the crackers where every version has altered code, and then the crackers recrack the change for the new version, so the programmers create a new verion that the cracker crack and so on... So have fun with some sneeky code, and but remebver to factor the potential loss in software sales vs. your programming time. Sending 100 hours to save $1000 is not a good bet usally. Cheers, Max. --- New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED] Website: http://www.delphi.org.nz To UnSub, send email to: [EMAIL PROTECTED] with body of "unsubscribe delphi"
RE: [DUG]: Software Expiry Codes - OnGuard
David Brennan asked about what is essentially copy protection: Has anyone considered this issue before? Is there a way of encrypting the keys in the executable so that they are harder to obtain or does Delphi make it hard enough as it is? Or is there a better tool than OnGuard out there? We have hashed this over on the list before and there are a bunch of issues that alwats get raised I'll summarise for you now: 1. A good hacker can defeat virtually any copy protection system given enough time. 2. The number of good hackers that can be bothered hacking your product will vary inversly on the product of the popularity and cost of the product. 3. Anything that makes it harder, to take longer and compilicates a hackers job will discourage more of the less talented and raise the bar to the hack. 4. Any popular off the self copy protection probably already has a generic hack or key generator available. 5. Any non popular copy protection may not be very good protection at all. So as you can see this is an area fraught with issues. Ultimately you have to ask your self are you selling the product, or are you selling the product PLUS your support services. Any reputable business is not going to copy your product willy nilly because they are going to find themselves FUBARed for support when you find out. And any sufficiently complicated product will require support during its lifetime. But no matter what you do, don't make it hard for your users as that will only encourage them to find another vendor later on. Cheers, Max. --- New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED] Website: http://www.delphi.org.nz To UnSub, send email to: [EMAIL PROTECTED] with body of "unsubscribe delphi"
RE: [DUG]: Software Expiry Codes - OnGuard
If you are encrypting keys then it seems to me that you are also including in some form, the code that will encrypt and decrypt them in your application.At what point can a hacker discover the code in your application that enables them to decrypt your keys? -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of David BrennanSent: Wednesday, 21 February 2001 09:26To: Multiple recipients of list delphiSubject: [DUG]: Software Expiry Codes - OnGuard Hi, I am about to implement security codes which verify the user/site is allowed to run my software. I am envisaging that each site will be given a code and each code will be built using the site/company name and an expiry date. Thus the code won't work if the site name is different, nor will it work after the expiry date (naturally it also won't work for a different product). OnGuard from TurboPower provides exactly these features. As far as I can see it works as follows: You embed a unique and private product key in the application. The user enters the code they obtained for their product. The application checks the code by building a new code from the product key, site name, expiry dateand checks it against the code the user entered. If they match then everything is OK. My problem with this is that the product keys need to be embedded in the application. With these keys and their own copy of OnGuard a user/hacker could build their own valid codes for any site name or expiry date. I don't know how hard it would be for a hacker to extract the keys from an application (the recommended approach for embedding them would appear to be constants of type TKey which is a 16 bytebinaryvalue) but I suspect it wouldn't be too hard. Has anyone considered this issue before? Is there a way of encrypting the keys in the executable so that they areharder to obtain or doesDelphimake it hard enough as it is?Or is there a better tool than OnGuard out there? Thanks for your help. David Brennan.DB Solutions Ltd.
Re: [DUG]: Software Expiry Codes - OnGuard
David Brennan asked about what is essentially copy protection: Has anyone considered this issue before? Is there a way of encrypting the keys in the executable so that they are harder to obtain or does Delphi make it hard enough as it is? Or is there a better tool than OnGuard out there? We have hashed this over on the list before and there are a bunch of issues that alwats get raised I'll summarise for you now: I figured it would be one of those topics which rises periodically. Unfortunately I did check before I posted and it doesn't seem to have been discussed in the last six months since I joined DUG nor can I find any information in the archive at http://www.mail-archive.com/delphi@delphi.org.nz/ So as you can see this is an area fraught with issues. Ultimately you have to ask your self are you selling the product, or are you selling the product PLUS your support services. Any reputable business is not going to copy your product willy nilly because they are going to find themselves FUBARed for support when you find out. And any sufficiently complicated product will require support during its lifetime. Our situation is a little unusual in that we are in effect loaning the software to sites (for free) so long as they agree to continue purchasing other products (non computer related) from our primary customer (who funded the project). So if they stop buying the other products then we want access to the software to stop. In the majority of cases this will be easy because most sites will probably access the software on our server through terminal services. A small but important minority will have their own copy at their own site, probably in Australia and these are the sites I need to protect us against. Unfortunately we already have one case of a company in Australia who is using a much earlier version of our software without permission and due to a combination of poor contract wording, poor software copy protection and our past blind optimism we can't do a thing about it. With-holding support doesn't seem to be enough to stop them (despite our nightly praying that the data devils will strike and corrupt their database ;-). Perhaps I should be more precise in my questions: 1. Does anyone know of a good reason why I shouldn't use Turbopowers OnGuard? eg because it is a poor tool; or because there is a better tool? 2. Has anyone gone down this path before and decided to encrypt the keys in the .exe as part of copy protection? If so how?! Thanks again, David Brennan. DB Solutions Ltd. --- New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED] Website: http://www.delphi.org.nz To UnSub, send email to: [EMAIL PROTECTED] with body of "unsubscribe delphi"
RE: [DUG]: Software Expiry Codes - OnGuard
David wrote: My problem with this is that the product keys need to be embedded in the application. With these keys and their own copy of OnGuard a user/hacker could build their own valid codes for any site name or expiry date. I don't know how hard it would be for a hacker to extract the keys from an application (the recommended approach for embedding them would appear to be constants of type TKey which is a 16 byte binary value) but I suspect it wouldn't be too hard. You may want to go one step further and use Shrinker to shrink- and-encrypt the finished app. No security scheme is perfect (e.g. there are hacks to unShrink code too, and an in-memory debug/disassemble renders your logic transparent), but one extra layer of obfuscation is worth having, as is the side-benefit of a smaller EXE. I haven't found any issues in years of using Shrinker with some products. That aside, you may wish to take pains to assemble your key from diverse bits and pieces, not one single structure (especially if it has predictable content in some way). "Just in time" delivery of the key is nice, but still prone to disassembly at the moment of use, if they can find a way to hook into that. Like I say (and which Max repeats in his far more thorough outline), no scheme can promise utter security... cheers, peter Peter Hyde, WebCentre Ltd SPIS Ltd, Christchurch, New Zealand * Web automation for online periodicals: http://TurboPress.com * TurboNote+: http://TurboPress.com/tbnote.htm -- easy, small, handy onscreen sticky notes --- New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED] Website: http://www.delphi.org.nz To UnSub, send email to: [EMAIL PROTECTED] with body of "unsubscribe delphi"
RE: [DUG]: Software Expiry Codes - OnGuard
Takes them about 3 hours to crack any app I have seen (and put on the internet). Dave. -Original Message-From: Patrick Dunford [mailto:[EMAIL PROTECTED]]Sent: Wednesday, 21 February 2001 10:00To: Multiple recipients of list delphiSubject: RE: [DUG]: Software Expiry Codes - OnGuard If you are encrypting keys then it seems to me that you are also including in some form, the code that will encrypt and decrypt them in your application.At what point can a hacker discover the code in your application that enables them to decrypt your keys? -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of David BrennanSent: Wednesday, 21 February 2001 09:26To: Multiple recipients of list delphiSubject: [DUG]: Software Expiry Codes - OnGuard Hi, I am about to implement security codes which verify the user/site is allowed to run my software. I am envisaging that each site will be given a code and each code will be built using the site/company name and an expiry date. Thus the code won't work if the site name is different, nor will it work after the expiry date (naturally it also won't work for a different product). OnGuard from TurboPower provides exactly these features. As far as I can see it works as follows: You embed a unique and private product key in the application. The user enters the code they obtained for their product. The application checks the code by building a new code from the product key, site name, expiry dateand checks it against the code the user entered. If they match then everything is OK. My problem with this is that the product keys need to be embedded in the application. With these keys and their own copy of OnGuard a user/hacker could build their own valid codes for any site name or expiry date. I don't know how hard it would be for a hacker to extract the keys from an application (the recommended approach for embedding them would appear to be constants of type TKey which is a 16 bytebinaryvalue) but I suspect it wouldn't be too hard. Has anyone considered this issue before? Is there a way of encrypting the keys in the executable so that they areharder to obtain or doesDelphimake it hard enough as it is?Or is there a better tool than OnGuard out there? Thanks for your help. David Brennan.DB Solutions Ltd.
Re: [DUG]: Software Expiry Codes - OnGuard
David Brennan said Perhaps I should be more precise in my questions: 1. Does anyone know of a good reason why I shouldn't use Turbopowers OnGuard? eg because it is a poor tool; or because there is a better tool? 2. Has anyone gone down this path before and decided to encrypt the keys in the .exe as part of copy protection? If so how?! David, I protect my app by site exactly as your earlier message specified ie by site code and expiry date. The method that I use in the .exe is load the alpha site code and the expiry date into an array of bytes do some systematic manipulation at byte level return a character by character unlock code fron the resulting Byte array. This has proved quite adequate for my needs. Mark --- New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED] Website: http://www.delphi.org.nz To UnSub, send email to: [EMAIL PROTECTED] with body of "unsubscribe delphi"
RE: [DUG]: Software Expiry Codes - OnGuard
Peter Hyde commented: Like I say (and which Max repeats in his far more thorough outline), no scheme can promise utter security... Indeed, but treating this as an intellectual challenge it should be possible to throw some serious spanners in the works of anyone who wants to crack the application. The two main routes that all hacks take are to either alter the binary executable so that the security checking code is neutered, or to reverse engineer the algorithm for the security code generation and from there create new codes as needed. The first attack of a modified executable is fun to play with. The best case I ever had to crack for the copy protection for an Mac game that had some startup code that check summed itself to find the encryption key to unlock chunks of the executable. But even this level of paranoia was easily defeatable with an nice debugging monitor and a few minutes spent relocating the code and executing it to find the key in question. So the best idea that I have seen involve several different checking code procedures that fire at different times. You need to separate these in the code so that they are not all easily locatable one after the other, and you need to have one or two that are used very often so that the hacker will think that they have found the troublesome routines. The other checks need to fire only at long intervals so that they can detect changes in the code when the hacker has passed the hacked product onto others. Then you can disable, cripple, or otherwise have the application stop working in some subtle and annoying way. Intermittent crashes and data corruption are better than telling the user that you know what they are up to. Especially if you can trick then into asking for support so that you can find out who they are. The second attack of unpicking the security code is best tackled by having all the code that does that stuff exhibiting some annoying behaviour. But this I mean it should: 1. Make heavy use of recursion. 2. Include a complex state machine. 3. Be implemented in an interpreted language. 4. Include message passing, exceptions and interrupts during processing. 5. And for extra spice use cooperative threads or coroutines. One good solution I can image in a virtual machine implementing a small forth derived language. Only a serious loony would send the time to reverse engineer a complex pile of recursive forth that manipulated a state engine. I know this, because I once gave up on a nasty virtual machine that implemented some kind of p-code. You quickly established that there was a central dispatch loop in the assembler that used a jump table to call more virtual code that jumped back into the central dispatch code. The only attack would have been to write a decompiler for the p-code, and this was more effort than it was worth for the game in question. So there are some ideas, and they would be fun to implement as well, and as long as you combine the two sorts of protection you'll be safe for 99.9% of the people out there. Cheers, Max. --- New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED] Website: http://www.delphi.org.nz To UnSub, send email to: [EMAIL PROTECTED] with body of "unsubscribe delphi"
RE: [DUG]: Software Expiry Codes - OnGuard
Max wrote: So there are some ideas, and they would be fun to implement as well, and as long as you combine the two sorts of protection you'll be safe for 99.9% of the people out there. Actually, I'd say closer to 99.999% if you did both things as thoroughly as Max suggested (and had the time to ensure all your logic was truly debugged and wasn't going to come back and bite bona fide users g) But you can never really cover the 1 in 10,000 who is truly dedicated. On the other hand, if your product has fewer than 10,000 users, it may not matter g. cheers, peter Peter Hyde, WebCentre Ltd SPIS Ltd, Christchurch, New Zealand * Web automation for online periodicals: http://TurboPress.com * TurboNote+: http://TurboPress.com/tbnote.htm -- easy, small, handy onscreen sticky notes --- New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED] Website: http://www.delphi.org.nz To UnSub, send email to: [EMAIL PROTECTED] with body of "unsubscribe delphi"
RE: [DUG]: Software Expiry Codes - OnGuard
The following page offers a good overview of some of the issues involved in protecting Delphi applications: http://www.inner-smile.com/nocrack.htm The rest of the site is a treasure trove of links, BTW. Martin == Work: +64-4-917 1828 Fax: +64-4-473 2407 Home: +64-4-589 4899 "We are aware that our corkage charges are high, but if you bring your own glasses, wine bucket, ice, dishcloth and your own waiter, we are prepared to negotiate a discount." --- New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED] Website: http://www.delphi.org.nz To UnSub, send email to: [EMAIL PROTECTED] with body of "unsubscribe delphi"
