Software Protection Survey
-
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++?
-
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++?
Paul Ingles wrote: mighty large corporations -- Flexlm and Macrovision -- and these have been broken. Sure, but as is often the case, mighty corporation doesn't always equate to good software. Paul Ingles wrote: 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. I'll give you a little hint of where we're going with this... Our product is not going to be a straight binary library that you plug in and use. That will be a small part of our offering I suspect (mainly to protect our product from theft!) The aim is that you'll buy our product and then spend less than a day adding the security to your system. We also plan to have a "lite" version that you can plug in in about 10 minutes, but with, obviously, less security. So, the developer is completely in control at all times. And, of course, part of our product is to put in serious anti-debugging, anti-cracking code. Given the responses to the survey, it looks as though C++ is the target. VB has some interest, but we're likely to look at that down the track. Java has almost no interest. As for schedules, it's looking like late May for Beta testing. Russell Robinson (russellr@rootsoftware.com) Author of TTMaker (Advanced Timetabling Software) http://www.rootsoftware.com
-
Paul Ingles wrote: mighty large corporations -- Flexlm and Macrovision -- and these have been broken. Sure, but as is often the case, mighty corporation doesn't always equate to good software. Paul Ingles wrote: 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. I'll give you a little hint of where we're going with this... Our product is not going to be a straight binary library that you plug in and use. That will be a small part of our offering I suspect (mainly to protect our product from theft!) The aim is that you'll buy our product and then spend less than a day adding the security to your system. We also plan to have a "lite" version that you can plug in in about 10 minutes, but with, obviously, less security. So, the developer is completely in control at all times. And, of course, part of our product is to put in serious anti-debugging, anti-cracking code. Given the responses to the survey, it looks as though C++ is the target. VB has some interest, but we're likely to look at that down the track. Java has almost no interest. As for schedules, it's looking like late May for Beta testing. Russell Robinson (russellr@rootsoftware.com) Author of TTMaker (Advanced Timetabling Software) http://www.rootsoftware.com
Russell Robinson wrote: Sure, but as is often the case, mighty corporation doesn't always equate to good software. Totally true! Although the larger financial backing is not always a bad thing. Some of the best protections were written by individuals. The best site I ever found was Fravia's (not sure about its current status, but you can find most of the essays written by people by searching for fravia on google). There were some very good ideas, and these were then set as crackme's for some of the best reversers, so if it was difficult to reverse then its a pretty good thing to implement! Although almost all the code is Assembly, but I would imagine you could probably implement reasonably similar stuff in C++, although for the more advanced protections there were suggestions of creating VxD's that would then have lower-level access to hardware. The only thing I'd warn about the anti-debugging stuff is that it may not be worth the hassle of doing it. There are quite a few modified versions of the popular debuggers (predominantly SoftIce) that aids it in being avoided in detection. Should be good to see how a new protection works, specifically one with a different approach to all the current ones. I've got a good hour on the train tomorrow morning so should be able to get some good thinking done :-)