Software Protection Survey
-
i must be missing something... as i see it, CRC is equivalent to a hash :
hash_or_crc = fn(fileBytes). if you app has to calculate it, a crack can bypass it. -c
"Do you mind if I smoke?" "Madam, I don't care if you burn." -Oscar Wilde Smaller Animals Software, Inc.
Chris Losinger wrote: i must be missing something... Yes. Go to Google and search for "one way hash". MD5 is a commonly used one way hash. This is all related to the wonderful world of Cryptography. "A hash function is an algorithm that takes a variable-length string as the input and produces a fixed-length binary value (hash) as the output. The tricky part is to make this process irreversible, that is, finding a string that produces a given hash value should be very hard (hence the word "one-way"). It should also be hard to find two arbitrary strings that produce the same hash value." have fun. Neville Franks, Author of ED for Windows. www.getsoft.com
-
I have worries about OS support:
- I can't actually think of any way to stop an executable file from being read or written. The OS has to provide low level access to the disk in some way (e.g. for defragging and checking the disk), so even if the high level prevents access to the exe, you can still get to it at a lower level.
- If the OS supports protection, then breaking everyone's protection is easy because you just break the OS code. Does anyone know a good OS manufacturer?
- If it also relies on some hardware device (such as a dongle), I've already listed the problems with this in an earlier post.
- How are developers going to compile programs? If the OS has a "switch off protection - development in progress" mode, then that's pretty straightforward for anyone to use.
The two ends of this problem are:
- software can always be changed
- hardware is damned inconvenient to ship
So, it seems to me that most software products (excluding the really expensive stuff) need a cheap and simple but effective software protection solution. (PS does anyone know why using HTML list causes the post to go bold?) Russell Robinson (russellr@rootsoftware.com) Author of TTMaker (Advanced Timetabling Software) http://www.rootsoftware.com
Russell Robinson wrote: I can't actually think of any way to stop an executable file from being read or written. the same way they'll make it impossible to read or write video and audio files: through a combination of software and compliant hardware. Russell Robinson wrote: How are developers going to compile programs? ahh... there's the true evil of DRM, and why every US citizen reading this should be sending letters to their congress people telling them to defeat the latest round of copyright nonsense. i am playing devil's advocate here. i don't want the OS to do anything like this. but, if the media people have their way, OSes will be required, by law, to prevent access and copying of copyrighted material - programs included. the only real way to do that is to combine software and smart hardware. then we're all screwed. -c
"Do you mind if I smoke?" "Madam, I don't care if you burn." -Oscar Wilde Smaller Animals Software, Inc.
-
Chris Losinger wrote: i must be missing something... Yes. Go to Google and search for "one way hash". MD5 is a commonly used one way hash. This is all related to the wonderful world of Cryptography. "A hash function is an algorithm that takes a variable-length string as the input and produces a fixed-length binary value (hash) as the output. The tricky part is to make this process irreversible, that is, finding a string that produces a given hash value should be very hard (hence the word "one-way"). It should also be hard to find two arbitrary strings that produce the same hash value." have fun. Neville Franks, Author of ED for Windows. www.getsoft.com
i know all about the "wonderful world of Cryptography". what i don't know is what you think a person should do with this one-way hash that makes it any different than just using it as an expensive CRC. calc the CRC of the EXE, stamp the EXE with it, recalc at runtime and compare against the stamped version (s/CRC/MD5/) -c
"Do you mind if I smoke?" "Madam, I don't care if you burn." -Oscar Wilde Smaller Animals Software, Inc.
-
i know all about the "wonderful world of Cryptography". what i don't know is what you think a person should do with this one-way hash that makes it any different than just using it as an expensive CRC. calc the CRC of the EXE, stamp the EXE with it, recalc at runtime and compare against the stamped version (s/CRC/MD5/) -c
"Do you mind if I smoke?" "Madam, I don't care if you burn." -Oscar Wilde Smaller Animals Software, Inc.
The difference is that hacker can patch out your protection code then calculate a new CRC and put it into the .EXE. Then when your code checks the CRC it says "all ok" and the app works normally. With a one way hash like MD5 it isn't possible for the hacker to calculate the new MD5 because they don't know the key. So when your app checks it, it fails. Neville Franks, Author of ED for Windows. www.getsoft.com
-
The difference is that hacker can patch out your protection code then calculate a new CRC and put it into the .EXE. Then when your code checks the CRC it says "all ok" and the app works normally. With a one way hash like MD5 it isn't possible for the hacker to calculate the new MD5 because they don't know the key. So when your app checks it, it fails. Neville Franks, Author of ED for Windows. www.getsoft.com
Neville Franks wrote: So when your app checks it, it fails. ok. so how does the app check it????? sheesh. actually, forget it. i don't want to know -c
"Do you mind if I smoke?" "Madam, I don't care if you burn." -Oscar Wilde Smaller Animals Software, Inc.
-
Hardware protection is really good stuff. No argument from me. But it does have some drawbacks: 1. Can be inconvenient to the user when he/she buys 5 or 10 products that each require a dongle-like object. 2. Can be expensive - for each sale you have an extra expense. 3. Probably overkill for most software systems. 4. Inconvenient to the provider and the user - the user must wait until the physical dongle has been delivered to them. With more and more software being delivered electronically, this kind of defeats the whole concept. So, I think there's still room for a good software-only system. Hopefully, the survey will tell us (and everyone - we'll publish the results). Russell Robinson (russellr@rootsoftware.com) Author of TTMaker (Advanced Timetabling Software) http://www.rootsoftware.com
Russell Robinson wrote: 1. Can be inconvenient to the user when he/she buys 5 or 10 products that each require a dongle-like object. Not necessarily true. Only in case of multiple vendors. But yes, this can lead to a christmas tree in your LPT port. :) Russell Robinson wrote: 2. Can be expensive - for each sale you have an extra expense. Yeah, very expensive. Here in Brazil, about US$ 43 each key. Russell Robinson wrote: 4. Inconvenient to the provider and the user - the user must wait until the physical dongle has been delivered to them. With more and more software being delivered electronically, this kind of defeats the whole concept. Worst than that, I have to mantain about 10 keys hanging around just in the case I sell more than I predicted. Not only the user has to wait for the key, I (the software provider) have to wait for the keys and buy them in advance for the software I did not sell yet. Again, I think that a software-only protection can achieve about the same level of protection that a hardware key if a network server acts like the dongle. Conceptualy, if the protection scheme is really strong, the protocol can be LPT, USB or TCP/IP, it really doesn't matter. But I am yet to see it implemented. Crivo Automated Credit Assessment
-
Neville Franks wrote: So when your app checks it, it fails. ok. so how does the app check it????? sheesh. actually, forget it. i don't want to know -c
"Do you mind if I smoke?" "Madam, I don't care if you burn." -Oscar Wilde Smaller Animals Software, Inc.
Chris Losinger wrote: ok. so how does the app check it????? sheesh. It runs the hash verifier function over the .exe and compares the result with what it is supposed to be. ie. The hash value embedded in the .exe Neville Franks, Author of ED for Windows. www.getsoft.com
-
Chris Losinger wrote: ok. so how does the app check it????? sheesh. It runs the hash verifier function over the .exe and compares the result with what it is supposed to be. ie. The hash value embedded in the .exe Neville Franks, Author of ED for Windows. www.getsoft.com
just replace
bool VerifyHash() {... return ok;}
with
bool VerifyHash() {... return true;}
breaking it is identical to a breaking a CRC check. -c
"Do you mind if I smoke?" "Madam, I don't care if you burn." -Oscar Wilde Smaller Animals Software, Inc.
-
just replace
bool VerifyHash() {... return ok;}
with
bool VerifyHash() {... return true;}
breaking it is identical to a breaking a CRC check. -c
"Do you mind if I smoke?" "Madam, I don't care if you burn." -Oscar Wilde Smaller Animals Software, Inc.
Correct, assuming they can find this and find every occurence of it. The trick is to check this at random times and in multiple places. I can check it on the nth start of my app n minutes after it started, on day 23 etc. etc. I can run it from some obscure thread instead of or as well as the main app thread. If there is something wrong just flag the fact and don't handle it till some time later. This is all about smoke and mirrors and deception. By all means have simple checks that make them think they've cracked it, but be realy devious with other well hidden and disguised code. At then end of the day it is all a game we play. Neville Franks, Author of ED for Windows. www.getsoft.com
-
Chris Losinger wrote: Russell Robinson wrote: I can't actually think of any way to stop an executable file from being read or written. the same way they'll make it impossible to read or write video and audio files: through a combination of software and compliant hardware. Like DVDs region restrictions. I don't own a DVD player, but I believe it's easy to get one that plays any DVD. Yes, I suppose it could happen, but it really would require a sea-change in the law in democratic countries. No-one would build a computer that provided hardware enforcement unless everyone *had* to. Imagine all US companies being forced to build computers that way....that would create a good market for Taiwanese computers; even if it had to be a black market. My guess is it's very unlikely.....And if we can come up with adequate software protection, there won't be a need for hardware protection. Russell Robinson (russellr@rootsoftware.com) Author of TTMaker (Advanced Timetabling Software) http://www.rootsoftware.com
but, it's exactly what congress is trying to do. -c
"Do you mind if I smoke?" "Madam, I don't care if you burn." -Oscar Wilde Smaller Animals Software, Inc.
-
Russell Robinson wrote: I can't actually think of any way to stop an executable file from being read or written. the same way they'll make it impossible to read or write video and audio files: through a combination of software and compliant hardware. Russell Robinson wrote: How are developers going to compile programs? ahh... there's the true evil of DRM, and why every US citizen reading this should be sending letters to their congress people telling them to defeat the latest round of copyright nonsense. i am playing devil's advocate here. i don't want the OS to do anything like this. but, if the media people have their way, OSes will be required, by law, to prevent access and copying of copyrighted material - programs included. the only real way to do that is to combine software and smart hardware. then we're all screwed. -c
"Do you mind if I smoke?" "Madam, I don't care if you burn." -Oscar Wilde Smaller Animals Software, Inc.
Chris Losinger wrote: Russell Robinson wrote: I can't actually think of any way to stop an executable file from being read or written. the same way they'll make it impossible to read or write video and audio files: through a combination of software and compliant hardware. Like DVDs region restrictions. I don't own a DVD player, but I believe it's easy to get one that plays any DVD. Yes, I suppose it could happen, but it really would require a sea-change in the law in democratic countries. No-one would build a computer that provided hardware enforcement unless everyone *had* to. Imagine all US companies being forced to build computers that way....that would create a good market for Taiwanese computers; even if it had to be a black market. My guess is it's very unlikely.....And if we can come up with adequate software protection, there won't be a need for hardware protection. Russell Robinson (russellr@rootsoftware.com) Author of TTMaker (Advanced Timetabling Software) http://www.rootsoftware.com
-
Correct, assuming they can find this and find every occurence of it. The trick is to check this at random times and in multiple places. I can check it on the nth start of my app n minutes after it started, on day 23 etc. etc. I can run it from some obscure thread instead of or as well as the main app thread. If there is something wrong just flag the fact and don't handle it till some time later. This is all about smoke and mirrors and deception. By all means have simple checks that make them think they've cracked it, but be realy devious with other well hidden and disguised code. At then end of the day it is all a game we play. Neville Franks, Author of ED for Windows. www.getsoft.com
yup -c
"Do you mind if I smoke?" "Madam, I don't care if you burn." -Oscar Wilde Smaller Animals Software, Inc.
-
but, it's exactly what congress is trying to do. -c
"Do you mind if I smoke?" "Madam, I don't care if you burn." -Oscar Wilde Smaller Animals Software, Inc.
Some in congress. Also, Microsoft and IBM are against it. And it Microsoft, which was recently convicted of rather nasty activity, can get away scot-free, then I'm not too worried about the congress bill(s) getting very far. You've got an election in the US soon (couple of years) haven't you? Russell Robinson (russellr@rootsoftware.com) Author of TTMaker (Advanced Timetabling Software) http://www.rootsoftware.com
-
Some in congress. Also, Microsoft and IBM are against it. And it Microsoft, which was recently convicted of rather nasty activity, can get away scot-free, then I'm not too worried about the congress bill(s) getting very far. You've got an election in the US soon (couple of years) haven't you? Russell Robinson (russellr@rootsoftware.com) Author of TTMaker (Advanced Timetabling Software) http://www.rootsoftware.com
Russell Robinson wrote: You've got an election in the US soon (couple of years) haven't you? this year (not for president, but for a fraction of congress) -c
"Do you mind if I smoke?" "Madam, I don't care if you burn." -Oscar Wilde Smaller Animals Software, Inc.
-
Russell Robinson wrote: You've got an election in the US soon (couple of years) haven't you? this year (not for president, but for a fraction of congress) -c
"Do you mind if I smoke?" "Madam, I don't care if you burn." -Oscar Wilde Smaller Animals Software, Inc.
I guess I'm an optimist in most things. It took nearly 5000 years (or maybe 35000 years) to create the concept of a Liberal Democratic Society. Clearly, they are the most prosperous of societies on Earth and many people have died either creating them or defending them. Our only real threat (apart from global annihilation through terrorism and/or war) is the really rich people who want to have absolute power too. I guess that's what you're talking about Chris: a couple of rich industries wanting to control our societies and take away freedoms. I think Liberal Democratic Societies are more resilient to those attacks than we might believe. However, it's people like yourself, who are passionate about the issue, that keep us on our toes and help to defend the freedoms we already have. I'm so inspired now :). Being an Aussie, can I write to congress or is a waste of time? Cheers. Russell Robinson (russellr@rootsoftware.com) Author of TTMaker (Advanced Timetabling Software) http://www.rootsoftware.com
-
I guess I'm an optimist in most things. It took nearly 5000 years (or maybe 35000 years) to create the concept of a Liberal Democratic Society. Clearly, they are the most prosperous of societies on Earth and many people have died either creating them or defending them. Our only real threat (apart from global annihilation through terrorism and/or war) is the really rich people who want to have absolute power too. I guess that's what you're talking about Chris: a couple of rich industries wanting to control our societies and take away freedoms. I think Liberal Democratic Societies are more resilient to those attacks than we might believe. However, it's people like yourself, who are passionate about the issue, that keep us on our toes and help to defend the freedoms we already have. I'm so inspired now :). Being an Aussie, can I write to congress or is a waste of time? Cheers. Russell Robinson (russellr@rootsoftware.com) Author of TTMaker (Advanced Timetabling Software) http://www.rootsoftware.com
Russell Robinson wrote: I'm so inspired now . Being an Aussie, can I write to congress or is a waste of time? :) you should get ready to fight this battle in the Aussie govt.. if this becomes a US law, it will probably spread (things seem to work out that way, unfortunately). -c
"Do you mind if I smoke?" "Madam, I don't care if you burn." -Oscar Wilde Smaller Animals Software, Inc.
-
Paul Ingles wrote: Protection routines have to be interwoven with the rest of your application. A simple check like "If isRegistered Then EnableWindow Else DisableWindow" is easy to remove, since you can either change the parameter for enablewindow to true, and its enabled even with a wrong code, or, change the comparison so it checks the generated code, with the generated code etc. Absolutely right. Paul Ingles wrote: Of course, if it was this simple then there would be masses of great protections. Some are better than others, but its really no substitute for creating one yourself. I'm not saying it is simple. I'm just saying it's possible. In fact, Paul, with respect, your second sentence contradicts your first one. If it isn't simple, why would you try to create one yourself? Everyone is basically saying "you can't sell a protection product that everyone can use without it being easily broken". I think this is based on these assumptions:
- a Software Protection System will have a single interface that can be targeted by crackers
- you can't spread the protection throughout your product
- coming up with your own solution will always be better
On this last point, what about cryptography? The best cryptographic systems are open source. Everyone gets to see how they work. But they are still difficult/impossible to break. We're still thinking about the source code issue, and we may well provide the source as part of our offering. In other words, we'll take the challenge that a cracker might say "I'll break it if I know how it works". Our system overcomes the first two assumptions. You *won't* have a single interface that can be targeted. You *will* be able to spread the protection throughout your product. I really like the idea of a collaborative area where we can test and discuss ideas. This will definitely be part of our offering. I'm simply asking whether developers would like a system that incorporates the good ideas, the ones that work, into a product they can purchase. Russell Robinson (russellr@rootsoftware.com) Author of TTMaker (Advanced Timetabling Software) http://www.rootsoftware.com
I still think the best way that protections can be produced is by doing them yourself, the problem is that it does require thought on the part of the developer. Not only that, but quite specialist thought. I accept the point about not providing a single interface, however, assuming that crackers do ever reverse code that implements your routines, there will effectively be code fingerprints. Things that would identify it as being an X Protection routine, for example, certain system calls that were used to identify hardware etc. By knowing that it could be a protection implementing your code, it might be possible to glean some light from other attacked applications to help its cracking. I totally agree about the point with Cryptography being a good benchmark. A good sign of security is that the data would remain secure, even if the method that it was protected with was made public. This is even more valid with .NET since the disassembler can produce fairly readable code, certainly more so than straight assembly that most disassemblers churn out -- making it easier for crackers to disassemble IL code and follow it. This is where the suggestion about a distributed protection come in. Since part of the code is stored on a server, it can't be modified. The problem with a .NET based solution is that people could be unwilling to be permanently connected to the Internet to use an application, also it would require absolutely mission critical webhosting -- since if you sell an application and your site dies for whatever reason, and people can't use your application that's been purchased then they're going to be pretty annoyed :) Assuming some important part of the code is implemented as a webservice, thus only licensed users will be able to have vital structures correctly initialised, it would then be necessary to ensure that they are authenticated properly and that nobody sniffing on network traffic could intercept messages and either impersonate the end-user, or work out how the webservice works. I might start doing a little thought into this and post an article over the weekend about my thoughts, set out possible plans for authentication, securing the communication and how it could then be called from an App. As for the collaborative environment glad to hear you like it, could be an idea for CodeProject, people could create projects, and then post articles like now, post comments like now, forums around that particular project etc. I suppose a bit like SourceForge :-) Paul
-
benjymous wrote: Also using a farmed out copy protection system, really depends on how it works. The best form of protection is to distribute the piracy checks throughout the whole codebase, thus making it very dificult for the cracker to know that they've all been removed. Something like that would have to be found and overcome on a per-title basis, even if the cracker knows what basic system is being used. Absolutely one of the keys (no pun intended) to achieving a better outcome. Also don't check the second the app starts, but some random time later, every nth use, or whatever. Lots of twists to make it more difficult. By using a range of techniques you can accomplish a lot. Neville Franks, Author of ED for Windows. www.getsoft.com
Totally agree, another good way of doing things is to make it more difficult to follow the disassembly of code when its statically dumped (i.e. using a disassembler) or dynamically (through a debugger like the fabled SoftIce). I've never tried it myself but you could always set it off by failing a check, that triggers a new thread that maybe waits a set amount of time, this then sends a message to the main application saying that there's been a problem of some sort and that it needs to close. This same message handling routine ought to then be used by other trapping code, and the error numbers ought to be in some way mangled/decrypted so that the users can't easily see what code causes the app to generate that particular message. I.e. if they notice that error code 39 is a registration check error, then they'll check through the code to find where the message creation function is called with a parameter of 39. This could be further complicated if you wanted to I guess, by making things as complicated as possible it gets more frustrating and the more likely people will give up. Of course, if its an incredibly desireable application, and the cracker is skilled then you're probably unlikely to sway them away from removing the protection. Paul
-
I still think the best way that protections can be produced is by doing them yourself, the problem is that it does require thought on the part of the developer. Not only that, but quite specialist thought. I accept the point about not providing a single interface, however, assuming that crackers do ever reverse code that implements your routines, there will effectively be code fingerprints. Things that would identify it as being an X Protection routine, for example, certain system calls that were used to identify hardware etc. By knowing that it could be a protection implementing your code, it might be possible to glean some light from other attacked applications to help its cracking. I totally agree about the point with Cryptography being a good benchmark. A good sign of security is that the data would remain secure, even if the method that it was protected with was made public. This is even more valid with .NET since the disassembler can produce fairly readable code, certainly more so than straight assembly that most disassemblers churn out -- making it easier for crackers to disassemble IL code and follow it. This is where the suggestion about a distributed protection come in. Since part of the code is stored on a server, it can't be modified. The problem with a .NET based solution is that people could be unwilling to be permanently connected to the Internet to use an application, also it would require absolutely mission critical webhosting -- since if you sell an application and your site dies for whatever reason, and people can't use your application that's been purchased then they're going to be pretty annoyed :) Assuming some important part of the code is implemented as a webservice, thus only licensed users will be able to have vital structures correctly initialised, it would then be necessary to ensure that they are authenticated properly and that nobody sniffing on network traffic could intercept messages and either impersonate the end-user, or work out how the webservice works. I might start doing a little thought into this and post an article over the weekend about my thoughts, set out possible plans for authentication, securing the communication and how it could then be called from an App. As for the collaborative environment glad to hear you like it, could be an idea for CodeProject, people could create projects, and then post articles like now, post comments like now, forums around that particular project etc. I suppose a bit like SourceForge :-) Paul
Paul Ingles wrote: I still think the best way that protections can be produced is by doing them yourself, the problem is that it does require thought on the part of the developer. Not only that, but quite specialist thought. That's the issue. Why don't we all write our own C++ compilers? Because it's quicker and easier to buy someone else's; one that's proven, etc. Paul Ingles wrote: I accept the point about not providing a single interface, however, assuming that crackers do ever reverse code that implements your routines, there will effectively be code fingerprints. Things that would identify it as being an X Protection routine, for example, certain system calls that were used to identify hardware etc. By knowing that it could be a protection implementing your code, it might be possible to glean some light from other attacked applications to help its cracking. Yes, that's the main "electronic warfare" we're entering into. My system addresses this very issue. Again, it won't be completely uncrackable, but the idea is to make it sooooo hard, and sooooo time-consuming, and different in every product where it is used. The distributed stuff is fine (with the problems you've mentioned) for apps that must work with the net. But what about most apps that don't require the net to operate? That's the first place I'll be focussing on. Paul Ingles wrote: I might start doing a little thought into this and post an article over the weekend about my thoughts, set out possible plans for authentication, securing the communication and how it could then be called from an App. I look forward to hearing your thoughts. Russell Robinson (russellr@rootsoftware.com) Author of TTMaker (Advanced Timetabling Software) http://www.rootsoftware.com
-
Paul Ingles wrote: I still think the best way that protections can be produced is by doing them yourself, the problem is that it does require thought on the part of the developer. Not only that, but quite specialist thought. That's the issue. Why don't we all write our own C++ compilers? Because it's quicker and easier to buy someone else's; one that's proven, etc. Paul Ingles wrote: I accept the point about not providing a single interface, however, assuming that crackers do ever reverse code that implements your routines, there will effectively be code fingerprints. Things that would identify it as being an X Protection routine, for example, certain system calls that were used to identify hardware etc. By knowing that it could be a protection implementing your code, it might be possible to glean some light from other attacked applications to help its cracking. Yes, that's the main "electronic warfare" we're entering into. My system addresses this very issue. Again, it won't be completely uncrackable, but the idea is to make it sooooo hard, and sooooo time-consuming, and different in every product where it is used. The distributed stuff is fine (with the problems you've mentioned) for apps that must work with the net. But what about most apps that don't require the net to operate? That's the first place I'll be focussing on. Paul Ingles wrote: I might start doing a little thought into this and post an article over the weekend about my thoughts, set out possible plans for authentication, securing the communication and how it could then be called from an App. I look forward to hearing your thoughts. Russell Robinson (russellr@rootsoftware.com) Author of TTMaker (Advanced Timetabling Software) http://www.rootsoftware.com
Russell Robinson wrote: That's the issue. Why don't we all write our own C++ compilers? Because it's quicker and easier to buy someone else's; one that's proven, etc. Ok, point accepted. However, I think people ought to realise that there's probably a cost to pay for doing this. As for proven, there are many many existing commercial protections funded by some mighty large corporations -- Flexlm and Macrovision -- and these have been broken. Of course, as you mentioned before, your solution would be different per app so the generic crack wouldn't be quite so straightforward. Going back to your questionnaire I would think most people would want actual source code, and this could then be modified/suited to an application with further guidance etc. Kind of a protection consultancy as it were. Russell Robinson wrote: The distributed stuff is fine (with the problems you've mentioned) for apps that must work with the net. But what about most apps that don't require the net to operate? Totally true, and my first thoughts on the subject of distributed protections (which I've been toying with in my head on my train journeys commuting) are that they're probably more secure than a standard protection because there's nothing to disassemble, it would require a kind of brute force investigative approach of trying things out (from a cracker point-of-view), but with significant downsides. As for it not needing the net, this is true, but think of how many applications now include auto update features, its kind of a step up from that :-) (albeit a fairly large one), if the licensing is required to be strong then it may be worth it. In the end it comes down to an economic decision, it may not be worth the time and effort developing it yourself and you just accept it. You could co-develop a system which affords you a greater level of protection and flexibility, or you go the whole hog and become a protectionist guru :-) It'd be interesting to see the system you come up with, whether you'll be willing to divulge anything here is another matter :) (and understandable too), but it'd still be interesting to see the end result. Do you have plans for release schedules yet? When initial versions may be available for testing? Also, have you considered putting anti-debugging code in? I've probably missed this somewhere but what's the target language for this? C++?