[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: 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]: Deleting records
John Have a look at the TupdateSql component, which can be used by a Tquery via its UpdateObject property. It is ideally suited to post updates for read-only datasets (i.e. where querying more than one table as in your case). HTH Martin -Original Message- From: John Christenhusz [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 20, 2001 12:46 To: Multiple recipients of list delphi Subject:[DUG]: Deleting records G'day folks, I want to delete certain records from multiple linked tables. The criteria (defined in sFILTER) is e.g. "ClientType = 2" What I did is, I created the following SQL and delete records in a loop. The thing is, that the loop seems to work quite well, it counts down (indicated by the recordCount value, but: - it deletes not all the records with the specified criteria, and - it also deletes a few records outside of the specified criteria, - sometimes it runs through the loop and after all it did not delete any records at all, but while running in the loop they seem to disappear otherwise it wouldn't come out of the loop. "WS SMTP relay" made the following annotations on 02/21/01 11:44:47 -- [INFO] -- Content Manager: [MMSSOV] This e-mail message and any attachments are confidential to Sovereign Limited and subsidiaries and subject to legal privilege. If you have received this e-mail in error, please advise the sender immediately and destroy the message and any attachments. If you are not the intended recipient you are notified that any use, distribution, amendment, copying or any action taken or omitted to be taken in reliance of this message or attachments is prohibited. == --- 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"
