 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / .NET Framework / New Users / December 2004Copy protection for a .NET application
I'm planning to develop a .NET application using C#, in order to sell it as a shareware and/or as a full package, so I'll need a good way to protect it against piracy. I know some ways to protect it (activation, serial keys, etc.), but my concern is: how can any copy protection mechanism work when you can always disassemble it and read the source code? Even if I use a native C++ DLL for my copy protection, the point where it's called from the C# code can always be found. Any good tips about this? Thanks Massimo Use a good obfuscator. It will atleast make it tough to disassenble. I have benn using one from wiseowl and it seems to work pretty good. Naveen Kohli http://www.netomatix.com > I'm planning to develop a .NET application using C#, in order to sell it > as a shareware and/or as a full package, so I'll need a good way to [quoted text clipped - 8 lines] > > Massimo > I'm planning to develop a .NET application using C#, in order to sell it as > a shareware and/or as a full package, so I'll need a good way to protect it [quoted text clipped - 4 lines] > C# code can always be found. > Any good tips about this? Yes - don't worry. Obfuscate your code if you particularly want to, but I wouldn't bother going any further than that unless you're *really* sure that: a) There'll be lots of demand for pirate copies b) There'll be technically competent people who are willing to spend time decompiling your obfuscated code  SignatureJon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet If replying to the group, please do not mail me too You can check into obfuscating. But depending on the obfuscator, that might not buy you much. Getting thru obfuscated code can be simple: http://www.atrevido.net/blog/PermaLink.aspx?guid=8315fa01-0286-47ce-a20b-fcc15eb297c3 The real way is to use a tool that does a lot more than just simple naming obfuscation (say, type obfuscation as well, call obfuscation), encrypts your assembly, and then, write really messed up code for the critical part. For instance, you might try some tricks to fake your stack trace, use multiple threads, etc. in the "serial checking" part. Also remember, if there's demand, people will get through and crack your app. Even MS Window's activation has been cracked (and the Windows programmers are extremely intelligent). SignatureMichael Giagnocavo MVP www.atrevido.net > I'm planning to develop a .NET application using C#, in order to sell it > as a shareware and/or as a full package, so I'll need a good way to [quoted text clipped - 8 lines] > > Massimo Very true. Just some random thoughts. I got to the point where all the fancy stuff is a waste of time if your protecting against code modification or round-tripping. You can use threads, jumps, or Egyptian carrier pigeons to confuse, but it normally all comes down to one single "if" statement to continue. This is one way to even get around RSA...just walk around it. You can obfuscate to help keep logic and secrets hidden so they ~can't generate external key gens or repro your license stuff, but if they will mod the code, then none of that really matters. So your really protecting again those that don't/can't mod the code - the others you can't really stop (not even with smartcards, strong names, etc.). Most of your protections will be in a single constructor, so not too hard to drill in on that. In this case obfuscation still helps a bit as it makes it harder to figure out where/what to mod the code(hopefully). Some obfuscators also help prevent ildasm to raise the bar even farther. SignatureWilliam Stacey, MVP http://mvp.support.microsoft.com > You can check into obfuscating. But depending on the obfuscator, that might > not buy you much. Getting thru obfuscated code can be simple: http://www.atrevido.net/blog/PermaLink.aspx?guid=8315fa01-0286-47ce-a20b-fcc15eb297c3 > The real way is to use a tool that does a lot more than just simple naming > obfuscation (say, type obfuscation as well, call obfuscation), encrypts your [quoted text clipped - 18 lines] > > > > Massimo > Very true. Just some random thoughts. I got to the point where all the > fancy [quoted text clipped - 3 lines] > confuse, but it normally all comes down to one single "if" statement to > continue. That's exactly my point of view on the subject. So, in a higly disassemblable environment such a .NET (or Java, for that matter), isn't there any way to really protect applications against piracy? Massimo > > Very true. Just some random thoughts. I got to the point where all the > > fancy [quoted text clipped - 7 lines] > So, in a higly disassemblable environment such a .NET (or Java, for that > matter), isn't there any way to really protect applications against piracy? Well, there's protection and there's protection. There's no foolproof way of protecting software whether it's Java or native code. You can make things harder by using an obfuscator, but if the code is going to run on a user's box, that user can (with appropriate skill) work out what it's doing. Usually, however, the concept behind a piece of software (which is plainly visible anyway) is more important than the implementation, IMO. SignatureJon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet If replying to the group, please do not mail me too You can skip MSIL and compile directly to machine code if you want. In fact, you can obfuscate and then compile to machine code for double protection. You don't have to release your program in MSIL. However, if you do go straight to machine code then you will loose the cross platform benefits of MSIL. That means you will have to complie separate assembiles for PC, MAC and so on. -Robby >> > Very true. Just some random thoughts. I got to the point where all the >> > fancy [quoted text clipped - 19 lines] > Usually, however, the concept behind a piece of software (which is > plainly visible anyway) is more important than the implementation, IMO. > You can skip MSIL and compile directly to machine code if you want. In > fact, you can obfuscate and then compile to machine code for double > protection. You don't have to release your program in MSIL. However, if > you do go straight to machine code then you will loose the cross platform > benefits of MSIL. That means you will have to complie separate assembiles > for PC, MAC and so on. Didn't know about this; how can I generate machine code? I was talking about a Windows application here. Massimo Use the NGEN utility that comes with the .Net Framework. Robby >> You can skip MSIL and compile directly to machine code if you want. In >> fact, you can obfuscate and then compile to machine code for double [quoted text clipped - 7 lines] > > Massimo > Use the NGEN utility that comes with the .Net Framework. The IL is still present in NGENed code. SignatureJon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet If replying to the group, please do not mail me too > > You can skip MSIL and compile directly to machine code if you want. In > > fact, you can obfuscate and then compile to machine code for double [quoted text clipped - 5 lines] > Didn't know about this; how can I generate machine code? I was talking about > a Windows application here. See http://www.pobox.com/~skeet/csharp/faq/#framework.required I can't say I'd recommend going that route though - while I haven't used the products in question, the .NET framework will clearly have gone through a lot more testing (especially if you include the "testing" which all of us are doing every time we run some .NET code) than the linkers. I'd certainly recommend that if you take that route, you do it early on and do as much of your development and testing using the product as possible, largely ignoring the normal framework. That may well end up costing a lot in terms of ease of development, of course... SignatureJon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet If replying to the group, please do not mail me too Using the NGEN utility is not ignoring the .Net Framework. It is a part of the .Net Framework. Machine code compiled assembiles still need the .Net Framework installed to run. You should not make grossly incorrect statements like that. Robby >> > You can skip MSIL and compile directly to machine code if you want. In >> > fact, you can obfuscate and then compile to machine code for double [quoted text clipped - 21 lines] > may well end up costing a lot in terms of ease of development, of > course... > Using the NGEN utility is not ignoring the .Net Framework. It is a part of > the .Net Framework. Machine code compiled assembiles still need the .Net > Framework installed to run. You should not make grossly incorrect > statements like that. I think you should be careful about the fact before accusing others of making grossly incorrect statements: 1) NGENed assemblies still require the original IL, so don't help in the slightest. 2) If you'd followed the link I provided, you'd see that the products I was referring to *don't* require the .NET framework to be installed - they include everything that's required. I wasn't talking about NGEN, as it doesn't accomplish the desired goal. Of course, if you don't believe me about the first point, you'd presumably be happy to send me an NGENed executable which you believe doesn't contain any IL. If you can do so, *then* I'll apologise for making a grossly incorrect statement. SignatureJon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet If replying to the group, please do not mail me too Well, I was talking about NGEN so your statements are incorrect. NGEN assemblies do not require you to distribute MSIL. Robby >> Using the NGEN utility is not ignoring the .Net Framework. It is a part >> of [quoted text clipped - 16 lines] > doesn't contain any IL. If you can do so, *then* I'll apologise for > making a grossly incorrect statement. > Well, I was talking about NGEN so your statements are incorrect. You may have been talking about NGEN, but you didn't specify that. My statements concerned the products I referred to, and were correct in that context. I answered a question from Massimo, and all my statements in that answer were correct. > NGEN assemblies do not require you to distribute MSIL. So I should expect an executable (compiled from C# source) in my inbox which doesn't have any IL in pretty soon, right? I'll be very surprised if you can produce one (using ngen). Just out of interest, I NGENed a small test executable, copied the native file out of the GAC, and tried to run it directly. No dice. You need the assembly containing the IL in order to get the framework to use the native image in the GAC. There *may* be ways of removing the IL from the original assembly after NGENing it, but in a way that fools the framework into using the image from GAC - but I haven't seen anyone writing about that, and you'd need fairly deep knowledge of exactly how the GAC works to try it out. (If the framework checks the hash of the assembly against the original, for instance, you're in trouble unless you can also change the hash that's stored in the native code file.) I'm off to bed now, but I'll be fascinated to see that executable (along with exact details of how you produced it) in the morning... SignatureJon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet If replying to the group, please do not mail me too Not sure if this product works well or not, but thought it looked interesting. Salamander .NET protector takes your code to produce native code like: 00000000 mov eax,dword ptr ds:[20004000h] 00000006 mov ecx,dword ptr [eax] 00000008 mov eax,dword ptr ds:[200046C0h] 0000000e call dword ptr [eax] 00000020 ret From this: IL_0000: ldstr "Hello World using C#!" IL_0005: call void [mscorlib]System.Console::WriteLine(string) IL_00a: ret Have not tried it, but sounds interesting. Anyone use it? SignatureWilliam Stacey, MVP http://mvp.support.microsoft.com > > Well, I was talking about NGEN so your statements are incorrect. > [quoted text clipped - 24 lines] > I'm off to bed now, but I'll be fascinated to see that executable > (along with exact details of how you produced it) in the morning... > Not sure if this product works well or not, but thought it looked > interesting. Salamander .NET protector takes your code to produce native [quoted text clipped - 11 lines] > > Have not tried it, but sounds interesting. Anyone use it? Interesting - seems to be a variant on the linker, basically - except using a "pseudo-native" code rather than real native code. I do wonder to what extent it's security through obscurity though - just a different format for what is still really MSIL. I'd need to know exactly what it was doing to say for sure, of course, and I'm not about to spend a huge heap of time or money on it... SignatureJon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet If replying to the group, please do not mail me too > I'm off to bed now, but I'll be fascinated to see that executable > (along with exact details of how you produced it) in the morning... Just for anyone following this thread - I haven't heard anything back. I have, however, tried playing around with ngen just for kicks. I took a normal, very simple C# application: using System; class Test { static void Main() { Console.WriteLine ("Hello"); } } I compiled and ran it, producing "Hello" as expected. With a binary hex editor, I then changed the "Hello" to "Hallo" - ran it, and got the obvious output. I then ran ngen on it, and edited the IL to "Hxllo" afterwards. Ran it again, and "Hxllo" was produced, showing that the normal assembly was still being used (as it couldn't have made it as far as the native code). Whether that was due to the string table from the normal assembly being used by the ngen code, or the framework realising that there was a change, I don't know - but it doesn't really matter, as it seems to disprove Robby's point, as far as I'm concerned. Still, I suppose it's always fun to be told I've made grossly incorrect statements ;) SignatureJon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet If replying to the group, please do not mail me too > Still, I suppose it's always fun to be told I've made grossly incorrect > statements ;) only if it is within the context of a conversation with self... :)) Did you compile for release or debug? Did you move the NGENed assembly to a different folder or .Net installed computer? --Robby >> I'm off to bed now, but I'll be fascinated to see that executable >> (along with exact details of how you produced it) in the morning... [quoted text clipped - 26 lines] > Still, I suppose it's always fun to be told I've made grossly incorrect > statements ;) > Did you compile for release or debug? Did you move the NGENed assembly to a > different folder or .Net installed computer? I just compiled with the defaults from the command line. Note that running NGEN doesn't change the assembly it's run on - it just adds the native image to the GAC's native images section. I don't see why moving the assembly itself around either within the same computer or to a different one would make any difference. (I'd need to run NGEN again on the other computer, of course.) However, as you're the one suggesting that NGEN is the way to go, you should be the one to tell us how we're supposed to get a program running without the original assembly. SignatureJon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet If replying to the group, please do not mail me too >> Did you compile for release or debug? Did you move the NGENed assembly >> to a [quoted text clipped - 11 lines] > should be the one to tell us how we're supposed to get a program > running without the original assembly. A NGENed assembly has a special non-accessible cache created where the machine code in stored. When you modify the IL assembly and re-execute it the .Net Framework stops pointing the the cache and uses the IL cache instead. This is why you see the changes made to the IL assembly instead of the cached machine code version. --Robby > A NGENed assembly has a special non-accessible cache created where the > machine code in stored. I don't know why you think it's non-accessible - I found it very easily. > When you modify the IL assembly and re-execute it > the .Net Framework stops pointing the the cache and uses the IL cache > instead. This is why you see the changes made to the IL assembly instead of > the cached machine code version. Exactly. The whole point was to demonstrate that. What that means is that you can't execute the native code without the original assembly, contrary to your previous assertions. You still haven't detailed exactly how you think you can use NGEN to foil people who wish to decompile the assembly. Maybe if you gave step- by-step instructions as to how you'd go about it, things would be clearer. SignatureJon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet If replying to the group, please do not mail me too Have you considered Protector from Remotesoft.com? It "completely stops MSIL disassembly and decompilation" Mike Marsh > Well, I was talking about NGEN so your statements are incorrect. NGEN > assemblies do not require you to distribute MSIL. [quoted text clipped - 21 lines] > > doesn't contain any IL. If you can do so, *then* I'll apologise for > > making a grossly incorrect statement. Hi, I'm working with C# now for the last months and just discovered that obfuscating is not enough. My sourcecode is not considered safe anymore because it can now be easily decoded with products like Remotesoft's software. How can I protect myself? An answer could be using the protector software from Remotesoftware but how sure can I be that this is also not breakable. What is the technique used by Protector and is it considered safe? Is it possible in anyway to link my assemblies into native code without having to include my IL code. Even obfuscating IL code is not really safe because the algorithm is 'easily' breakable. Anyone? > Have you considered Protector from Remotesoft.com? > It "completely stops MSIL disassembly and decompilation" [quoted text clipped - 25 lines] > > > doesn't contain any IL. If you can do so, *then* I'll apologise for > > > making a grossly incorrect statement. Marco van Nieuwenhoven <MarcovanNieuwenhoven@discussions.microsoft.com> wrote: > I'm working with C# now for the last months and just discovered that > obfuscating is not enough. My sourcecode is not considered safe anymore > because it can now be easily decoded with products like Remotesoft's software. But can it actually be *understood*? > How can I protect myself? An answer could be using the protector software > from Remotesoftware but how sure can I be that this is also not breakable. > What is the technique used by Protector and is it considered safe? You'd have to ask RemoteSoft. > Is it possible in anyway to link my assemblies into native code without > having to include my IL code. Even obfuscating IL code is not really safe > because the algorithm is 'easily' breakable. Yes - follow the links I posted before. However, people will still be able to decompile your code. It'll take a bit longer, but it's far from impossible. SignatureJon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet If replying to the group, please do not mail me too > Marco van Nieuwenhoven <MarcovanNieuwenhoven@discussions.microsoft.com> > wrote: [quoted text clipped - 3 lines] > > But can it actually be *understood*? I think the code can still be understood because the calls to the .net framework are still understood and there you can fiddle out the function of a function :-) When getting a message of a customer that a crash has occurred this will also cause you a problem as well. You will then not be able to understand what went wrong. > > How can I protect myself? An answer could be using the protector software > > from Remotesoftware but how sure can I be that this is also not breakable. > > What is the technique used by Protector and is it considered safe? > > You'd have to ask RemoteSoft. I don't think I will get a clean answer from them because this will give away a big hint on how to hack their tool. A disadvantage of their solution is also that the solution is: *BeginQuote* This method is not compatible across .NET Framework Service packs. For example EXE files created using .NET Framework Service Initial Release do not work with installations of Service Pack 2. Because many users may have different installations of the framework installed, this solution becomes useful only in very controlled environments - but usually in these environments protection is not strongly needed. *EndQuote* This is why I am looking for a solution which does not include the IL code inside an executable. This will make it more difficult to hack. x86 code is more difficult to read than IL (obfuscated or not) > > Is it possible in anyway to link my assemblies into native code without > > having to include my IL code. Even obfuscating IL code is not really safe [quoted text clipped - 3 lines] > able to decompile your code. It'll take a bit longer, but it's far from > impossible. I may be a fool but I could not find the reference you told me of. I could only find the qoute from below. This does confuse me. > There *may* be ways of removing the IL from the original assembly after > NGENing it, but in a way that fools the framework into using the image [quoted text clipped - 3 lines] > instance, you're in trouble unless you can also change the hash that's > stored in the native code file.) Marco van Nieuwenhoven <MarcovanNieuwenhoven@discussions.microsoft.com> wrote: > > > I'm working with C# now for the last months and just discovered that > > > obfuscating is not enough. My sourcecode is not considered safe anymore [quoted text clipped - 5 lines] > framework are still understood and there you can fiddle out the function of a > function :-) You can see what it does, but actual semantic meaning is a lot harder to understand without any reasonable names. Try decompiling any large obfuscated app and see how easy it is to understand. > When getting a message of a customer that a crash has occurred > this will also cause you a problem as well. You will then not be able to > understand what went wrong. Most obfuscators build a map so that you can get back from an obfuscated stack trace to a nicely named one (with the map). > > > How can I protect myself? An answer could be using the protector software > > > from Remotesoftware but how sure can I be that this is also not breakable. [quoted text clipped - 14 lines] > inside an executable. This will make it more difficult to hack. x86 code is > more difficult to read than IL (obfuscated or not) Yes, it's more difficult to read. Not impossible though. > > > Is it possible in anyway to link my assemblies into native code without > > > having to include my IL code. Even obfuscating IL code is not really safe [quoted text clipped - 6 lines] > I may be a fool but I could not find the reference you told me of. I could > only find the qoute from below. This does confuse me. The link was http://www.yoda.arachsys.com/csharp/faq/#framework.required - there are links there to linkers which produce native code. > > There *may* be ways of removing the IL from the original assembly after > > NGENing it, but in a way that fools the framework into using the image [quoted text clipped - 3 lines] > > instance, you're in trouble unless you can also change the hash that's > > stored in the native code file.) I'd ignore that if I were you - that was trying to understand how Robby thought you could use an NGENed image without the original assembly. I assume from his silence on the topic that he's now accepted that you can't do it... SignatureJon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet If replying to the group, please do not mail me too Are you talking hacking/cracking or getting the code posted at the code project? They are different. Actually, cracking is just as simple on x86 code as it is with IL. That is because crackers live in debuggers and asm anyway. From that perspective obfuscated IL is harder for them as you add obfuscation and is different then what they are used to. So you will be able hack any app that lives on a w/r medium. But can you understand it is the other another problem and the one you want to control as well as possible. I really like Xeno code. Is a fair price and works really well. With conservitive settings and control flow obfus, and ILDasm breaking turned on is great. Can not use std ILdasm to round trip, can not understand from Reflector or others and can not reverse it. Saying "can not" is misleading. As everything is possible - right? I mean you would eventually find your RSA private key with a brute force attack too. So how hard is it is the key. Even with a good obfuscator you have to balance protection level as if you do to much you start breaking things. You still need to test whole app again after obfuscation which is a big problem with the idea in general. SignatureWilliam Stacey, MVP http://mvp.support.microsoft.com > > Marco van Nieuwenhoven <MarcovanNieuwenhoven@discussions.microsoft.com> > > wrote: [quoted text clipped - 46 lines] > > instance, you're in trouble unless you can also change the hash that's > > stored in the native code file.) > Usually, however, the concept behind a piece of software (which is > plainly visible anyway) is more important than the implementation, IMO. I agree on this, but I'm not talking about protecting intellectual rights (i.e. algorithms), but the software itself, which can be easily copied. Massimo > > Usually, however, the concept behind a piece of software (which is > > plainly visible anyway) is more important than the implementation, IMO. > > I agree on this, but I'm not talking about protecting intellectual rights > (i.e. algorithms), but the software itself, which can be easily copied. And native code can fairly easily be copied too - look how much effort the games industry is constantly putting into making games as hard to crack as possible. SignatureJon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet If replying to the group, please do not mail me too >> > Usually, however, the concept behind a piece of software (which is >> > plainly visible anyway) is more important than the implementation, IMO. [quoted text clipped - 5 lines] > the games industry is constantly putting into making games as hard to > crack as possible. Yes, I know this, and in fact I'm quite unsure about native code safety, too. But IL is definitely *a lot* simpler to understand, when disassembled. Massimo > > And native code can fairly easily be copied too - look how much effort > > the games industry is constantly putting into making games as hard to > > crack as possible. > > Yes, I know this, and in fact I'm quite unsure about native code safety, > too. But IL is definitely *a lot* simpler to understand, when disassembled. Have you tried decompiling a real application of significant size, after it's been obfuscated? It takes a fair amount of skill and patience to understand it. SignatureJon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet If replying to the group, please do not mail me too Agreed. When using XenoCode with control flow obfus and IL cracking, I have not been able to decomiple a clean enouph version to start really reading. In some respect I guess, IL and obfuscation may be harder to crack then native code without obfuscation - assuming one knows how to look at (and change) both. SignatureWilliam Stacey, MVP http://mvp.support.microsoft.com > > > And native code can fairly easily be copied too - look how much effort > > > the games industry is constantly putting into making games as hard to [quoted text clipped - 6 lines] > after it's been obfuscated? It takes a fair amount of skill and > patience to understand it. It all depends on what the objective is. If it's to understand the working and architecture of an application, it should be exceedingly hard. If it's to simply find a single branch instruction, well... perhaps it's much easier. SignatureMichael Giagnocavo MVP www.atrevido.net > Agreed. When using XenoCode with control flow obfus and IL cracking, I > have [quoted text clipped - 16 lines] >> after it's been obfuscated? It takes a fair amount of skill and >> patience to understand it. Hi, all. Well, reading all the thread, there's a really good way to make a copy protection for a IL (or bytecode for Java) available. Besides obfuscation, which is good for many of the cases, the approach I'll tell you is for *real* paranoids. In protecting some piece of code from analysis requires that it is impossible to reach that piece of code from within the context of application, that is, run that code somewhere else. The best candidate, as far as I know, is smartcards with crypto co-processors. Have the smartcard generate a key pair for you and store the private key inside itself, never telling it even you. Then, put a piece of code in the smartcard and give it the access credidentals with only the public key that the card delivered you. Use a secure communication protocol between the smartcard and the computer, so that nobody will be able to intercept the data transmitted. When your program is running as shareware, it won't require the vital piece of code that needs to execute in the smartcard. But when it is licensed, you give your customer the card and the corresponding public key. So, when in licensed mode, the card executes the vital code, and returns only the required results meaningful only for that license or context. (The code inside the smartcard may be dependent on some data or other code in your application, but your application *must* be dependent on this code piece.) I used this approach on some projects, and proved well. You can check out possible cards supported by Windows CSP from Gemplus, Sclumberger and Orga. The capacity of cards range from 8 to 128 Kbytes, which is sufficient for many types of applications. As this is the hardest nut to crack, this is also very hard to code, so you decide if you want it or not... Salih > I'm planning to develop a .NET application using C#, in order to sell it as > a shareware and/or as a full package, so I'll need a good way to protect it [quoted text clipped - 8 lines] > > Massimo True. But it is no harder to branch around this then anything else if your talking patching (not simple keygens). If keeping secrets, then maybe a good way to go but seems to have all the draw backs of a dongle which I would never buy (again). SignatureWilliam Stacey, MVP http://mvp.support.microsoft.com > Hi, all. > [quoted text clipped - 47 lines] > > > > Massimo > your application *must* be dependent on this code piece. That's the failure point of your solution. Even in this case, there will be some point in the application where an IF statement will compare the value returned from the smart card to something else, and decide if the program is allowed to run. Find that statement, and you crack the program... Massimo > That's the failure point of your solution. Even in this case, there will be > some point in the application where an IF statement will compare the value > returned from the smart card to something else, and decide if the program is > allowed to run. Find that statement, and you crack the program... Well said. SignatureWilliam Stacey, MVP http://mvp.support.microsoft.com Well, I think I couldn't point out the case I was talking about. OK, for the sake of bravity, I'll state these axiomes: 1. Anything locked by a human being can be opened or broken by another human being. 2. Anything that runs on deterministic fashion (in a way that uses a limited set of commands like that of a CPU or IL) can be backtracked and reverse engineered. We can't do anything about the 1st axiome, as all programmers I know are human beings, so what we may try is, to make our code for copy protection less deterministic. With the help of obfuscators, we try to reach this goal. For further confusion to be put on intruder is, to put *some* other also deterministic in nature, but indeterministic in vision, a piece of code that is vital for the protected part of the program. I don't say, just do some hashing etc. and return the result to the program and compare with something else and unlock something or not. What I say is, run some part of the application *outside* the application context, Windows and CPU that the application is already running. Physically seperate these two parts of application. For example, using RPC, we do just this, have some code run on another computer. So that intruder can just trace the encrypted traffic between these two parts. Of course it is possible to analyse the main application and find out what that vital code is doing in that black box and write some other piece of code or just patch the application, so that it has the same piece of code running in the same context. But, here is the point: How much will it cost to achieve this goal? If I need supercomputers to find out the key pair generated (And don't forget, my suggestion states that private key is only known by the card itself. Not even by the programmer or personalizer) and a class 1000 (that is 1000 particles in 1 cubic meters of air) clean room and an electron scanning microscope to crack a program, well, it's better to buy it... Of course, if you increase the cost for breaking a system you also increase the cost for building that system... That's what I think. I never asserted that the solution I offered was impenetretable. It is just too expensive to impenetrate... Salih > > That's the failure point of your solution. Even in this case, there will > be [quoted text clipped - 4 lines] > > Well said. Thanks Salih. I think what we are saying is a bit different. You are 100% correct from the protection stand point. Trying to break a hidden algo on a card would be too hard. Good protect from that stand point. However, what we are saying is you can easily find where your program calls your "Card" method, returns, and does an IF test to see if we can continue. Now you can patch that and just "JUMP" around it. The hacker does not need to break RSA or hash or Smart card. All he has to do is set the Test to true and he totally went around all your protections. This is easier then you may think. You can't really protect against this kind of hack, but only make it harder to read and figure out your code, etc. A very good discussion of these methods are at: http://www.atrevido.net/blog/CategoryView.aspx?category=Code SignatureWilliam Stacey, MVP http://mvp.support.microsoft.com > Well, > [quoted text clipped - 51 lines] > > > > Well said. > Thanks Salih. I think what we are saying is a bit different. You are 100% > correct from the protection stand point. Trying to break a hidden algo on a [quoted text clipped - 8 lines] > these methods are at: > http://www.atrevido.net/blog/CategoryView.aspx?category=Code Not all protection depends on an IF statement. You can use a smartcard (hardlock) to crypt data, which can only be read by use of this crypto device. If you make part of your code depend on this crypto process then it's a very different from just making a bitflip in the exe to bypass an IF statement. We use Hardlocks to crypt certain DLLs. They have to be read through the hardlock, otherwise they're useless. There's a whole lot of wizardry going on to prevent people from getting at the uncrypted code. I'm not saying this is uncrackable (anything that can be run can be cracked), but it's a whole lot more difficult than replacing an IF statement. SignatureRinze van Huizen C-Services Holland b.v. With respect, it does not matter. It eventually has to come down to an if test somewhere in your main code. Otherwise you could never test if the hardlock method with valid or not. It does not matter what the "blackbox" is doing - you still have to test the return of the blackbox somewhere. If I am still in error, please post some code to review. Don't need the blackbox code, just the parts where you call the blackbox, return some value and not test it with an if. Would be interested to see that. tia SignatureWilliam Stacey, MVP http://mvp.support.microsoft.com > > Thanks Salih. I think what we are saying is a bit different. You are 100% > > correct from the protection stand point. Trying to break a hidden algo on a [quoted text clipped - 21 lines] > cracked), but it's a whole lot more difficult than replacing an IF > statement. > With respect, it does not matter. It eventually has to come down to an if > test somewhere in your main code. Otherwise you could never test if the [quoted text clipped - 3 lines] > blackbox code, just the parts where you call the blackbox, return some value > and not test it with an if. Would be interested to see that. tia With respect, it does matter. I see you don't understand the method. We have functional code wrapped up in a DLL. This DLL is then crypted through a hardlock (www.hardlock.com). You can also crypt the whole .exe if you want. This DLL can only be used if the hardlock is attached to the computer. It encrytion 'envelope' decrypts the parts it needs on the fly using the hardlock. The communication between the hardlock and the software is also scattered with random stuff to make it very difficult to catch what's real and what's not. All interaction with this hardlock is regulated by the encapsulating encryption. No intervention on my part is nescesary. As such, I don't need to check anything from a black box, since from my POV (code) there is no black box, that's the whole beauty of this solution. Check out the documentation on the site. This protection is very different from checking if that hardlock is attached, because that would be easy to circumvent in the way you're describing. SignatureRinze van Huizen C-Services Holland b.v. Thanks Rinze. Was not trying to be flippant with response. I assume your talking license management here. If something else, please expand. To have context here, lets assume we are talking license check as that is what site mainly talks about. And your right, we probably can't crack the device or internal structures. However, I still don't need to. Pretend we call an IsValid() method in the hardlock. It does and does its thing with checking keys, decrypting, xyz, etc. That is fine and good. But now, my main code at some point need to check some reply from the hardlock to see if that was valid or license failure. So my code my look like this (could be anything) private void MainForm_Load(object sender, System.EventArgs e) { bool valid = HardLock.IsValid(); // HardLock goes and does its magic. if ( ! valid ) MessageBox.Show("Thank you for using our software. Please obtain a valid license at xyz.com."); } So I can still bypass your HardLock all together with a mod to the code. I don't need to break the hardlock, I just need to change your code. The return value my not be a bool but something else. You can still do the same thing. Now if all your code is in the hardlock, then that is probably a different issue - but not sure we are talking about that. Truly interested in this, so please post some other example if I am in error. I did look at the site. The idea is good, but in the end it is a fancy dongle that people will not buy sw that requires a dongle/smartcard/smart usb device (at least a lot of people will not.) A good obfuscator and PKI would probably work as well to make it very difficult to crack your code without requiring the dongle. Now if we could load the whole program in the dongle and run it from there, that may be a little more interesting. Instead of distributing CDs or exe, you send out USB device with sw on it. Still a dongle however, and you still have the perception issue. Is your software that great that people will carry around this dongle with them. What if everyone did this, I would have 20 dongles sticking out of my machine (If I could even get that many usb ports.) As a user, chances are a non-dongle SW alternative starts looking more attractive as the dongle feels like one more thing to keep track of that I don't need. That said, for some high security applications, this may be the right choice. SignatureWilliam Stacey, MVP http://mvp.support.microsoft.com > > With respect, it does not matter. It eventually has to come down to an if > > test somewhere in your main code. Otherwise you could never test if the [quoted text clipped - 21 lines] > different from checking if that hardlock is attached, because that would > be easy to circumvent in the way you're describing. > Thanks Rinze. Was not trying to be flippant with response. I assume your > talking license management here. If something else, please expand. To [quoted text clipped - 21 lines] > > So I can still bypass your HardLock all together with a mod to the code. I think he was talking about encrypting a DLL using some key stored inside a dongle/smart card/whatever. That way, nobody could even access the code without the key, so no patching could actually crack this system. Howewer, a lot of copy protections from games take exactly this approach (enrypting the main executable using data stored in the CD-ROM subchannel), and no one of them has been cracked, but the games are still being copied... by distributing a copy of the decrypted executable along with them. Massimo You don't seem to understand the crypting process. quote: "Pretend we call an IsValid() method in the hardlock." That is where you go wrong, in my code I don't even have to check for the presence of the hardlock. The entire executable/dll is crypted with a 128bit encryption method. It needs the hardlock to first decrypt the code then run it. Code similar to what you showed is nowhere to be found in my software. I'll describe the process: 1. I create and compile program just like any other 2. attach the customers hardlock with a specific module address 3. attach our company specific crypt lock 4. run the compiled program through a crypt program that crypts the executable with the customers hardlock 5. burn it on CD and ship it and the hardlock to the customer Now the executable/dll has changed alot. Aside from the encryption, it is encapsulated in a software envelope that will automatically decrypt it when needed. The envelope doesn't simply check if the hardlock is available, it NEEDS it to be there to even be able to decrypt the machine code and run it. Think of PGP. PGP encrypt your program. Can you run it? No. Can you go in there, change 1 bit and have you then defeated the PGP encryption? No. You need to decrypt the program first before you can use it. The hardlock does this on the fly, but all the while it obfuscates it behaviour making it very hard for anyone with special software (like WinIce) to see what is going on. You can use it like you described, but that would defeat the purpose of having one simply because it can be broken like you showed. But proper use of the hardlock makes it very very hard to break. > Thanks Rinze. Was not trying to be flippant with response. I assume your > talking license management here. If something else, please expand. To have [quoted text clipped - 35 lines] > track of that I don't need. That said, for some high security applications, > this may be the right choice. SignatureRinze van Huizen C-Services Holland b.v. I gotta now. I see what they are doing. I would never spend time on it, but from a discussion standpoint, I still wonder how much better that is then encrypting the dll yourself and encrypting the key in the loader or something. I think under both (hardlock and self encrypted dll) you have some key used for decryption into memory and/or disk. Naturally, one could use "corddb myapp.exe" to find the plain key passed to Rijndael (et al) for decryption and just use that to manually decrypt the dlls. That is an additional step that takes most folks out-of-the-game. But your not really protecting from them. Your really protecting from the crackers that live inside debuggers and read asm like the morning paper just to publish a crack or keygen to their buddies on the INET. Still sounds interesting, but don't think majority would ever buy sw that requires dongles (as history shows us.) Also not sure how much better this is (in reality) then decrypting and loading your own dll in a loader? Just curious, now that we spent time on this, what kind of application are your protecting? Thanks for your patience and helping me understand. Cheers. SignatureWilliam Stacey, MVP http://mvp.support.microsoft.com > You don't seem to understand the crypting process. > [quoted text clipped - 69 lines] > > track of that I don't need. That said, for some high security applications, > > this may be the right choice. > I gotta now. I see what they are doing. I would never spend time on it, > but from a discussion standpoint, I still wonder how much better that is [quoted text clipped - 14 lines] > your protecting? Thanks for your patience and helping me understand. > Cheers. The problem with decrypting the code yourself is that you have a readily accessable decryption module in your software to decrypt the DLL. That would make it a breeze for any decent cracker to break your protection. We have engineering software for factories and such where very simply put they store every connection (power/signal lines etc) and instrument and what not in a database. It's a very expensive piece of software. One of our other leading products is software for calculating powercables to conform to the Dutch NEN norm. That ranges from wiring in your home to streetlighting. Our main concern in the early days was decompilation protection (VB4, easily decompiled to vb source). So we used the hardlock encryption to stop people getting at our math modules. These days it's a bit harder, but we still use it for licencing purposes so we can control how many copies can be started at one time, serverlocks are available so they can just plug it onto a Novell or Windows server for instance. Now I agree with you that for most software packages this solution is way to expensive. The hardlock itself costs about as much as the average game. But the same company also provides a software solution (http://www.ealaddin.com/HASPSL/default.asp) which may be much more interesting to more developers since it doesn't require a piece of hardware and this distribution via the web is so much easier. How secure that is, I can't say. But I do know the hardlock encryption is very tough to crack. In the end, any protection can be broken. I think our software is too specific to be interesting enough for any hacking group to spend it's efforts on, so we (our company that is) are reasonably safe. SignatureRinze van Huizen C-Services Holland b.v. > The problem with decrypting the code yourself is that you have a readily > accessable decryption module in your software to decrypt the DLL. That > would make it a breeze for any decent cracker to break your protection. True. But you have equal access to the either code in memory using a debugger. So it does raise the bar, but not too high for crackers. They use debugger anyway (after ildasm fails), so it is not much difference for them. > We have engineering software for factories and such where very simply > put they store every connection (power/signal lines etc) and instrument > and what not in a database. It's a very expensive piece of software. Sounds interesting. Hope yall do well with it. > Now I agree with you that for most software packages this solution is > way to expensive. The hardlock itself costs about as much as the average [quoted text clipped - 4 lines] > that is, I can't say. But I do know the hardlock encryption is very > tough to crack. Thanks for the link. Thanks for the talk. Cheers. SignatureWilliam Stacey, MVP http://mvp.support.microsoft.com >>The problem with decrypting the code yourself is that you have a readily >>accessable decryption module in your software to decrypt the DLL. That [quoted text clipped - 4 lines] > use debugger anyway (after ildasm fails), so it is not much difference for > them. Not really. The decrypting part is in the hardlock, unaccessable by debuggers :) From the tech docs I've read, they also employ anti-debugging techniques to prevent on the fly inspection of things going on. But as I said. Nothing is impossible to crack, it's just how much time and effort is one willing to spend. SignatureRinze van Huizen C-Services Holland b.v. I read the docs. They talk about things like "Protective Shields" and "Train Cars" a lot. But when you wade past the marketing fluff, it is an RSA key store plain and simple. It stores private keys and can take an encrypted string (encrypted with public key) and decrypt it. Here is the basic process from what I read: 1) Encrypt exe, or dll with 128-bit Rijndael using random Secret and IV and store. Done at developers station. 2) Encrypt the secret and IV with the public key. Save the cipher text and public key with the cipher dll from Step 1. 3) One and 2 are the "package". Other transforms and/or "magic" splitting/blocking/train-car may be done. 4) Create the wrapper/loader around the cipher "package" and distribute that. When app starts: 1) Loader *.exe that is called by user. 2) Loader first checks that the HardLock(HL) is present with a ping msg. If not, return failure. 3) Loader loads "package" and extracts cipher Secret and IV and sends to HL. 4) HL decrypts the string(s) using private RSA key stored in the lock. 5) HL returns *clear secret and IV to caller. This is the potential weak link in the procedure. 6) Loader decrypts "package" in memory using Rijndael keys. 7) Loader can call an entry point to start the app. 8) Loader may also use a timer thread to periodically check the HL is always there with some ping msg - or exit if not. 9) Loader has some magic to tell if a debugger is running. Not sure about validity of this statement or what is possible here. So basically it uses Rijndael and RSA key pairs to encrypt the Rijndael keys like you would do in normal digital envelope. But the RSA private key is stored in the lock. Like all crypto, it comes down to protecting the keys and to use the resulting clear text for only a very short time and remove it from memory. Here is where it comes back to the same problem we all have - protecting the clear text in memory. The driver api call to decrypt the rj keys *has to return clear text to init Rijndael with - just has to be done. If I can get the key, the HL is not much use anymore as I can run Rijndael myself with the known key and iv. The various "mixing" they also do would slow you down a bit more. The "crashing debugger" part is the most interesting I think. If they can do that in a fool proof way, then they really have something there. But they don't talk about the tech here other then marking points. I don't know enough about it to say either way. If they can't stop debuggers, then it would not be that much harder to crack then a sw only solution. Actually I have done all the same things in a sw-only license solution with digital envelopes and ran into same issues. It all comes down to protecting that darn key - the rest is not so important. Wonder if a USB sniffer would show the returned clear text rj keys? Cheers. SignatureWilliam Stacey, MVP http://mvp.support.microsoft.com > >>The problem with decrypting the code yourself is that you have a readily > >>accessable decryption module in your software to decrypt the DLL. That [quoted text clipped - 12 lines] > But as I said. Nothing is impossible to crack, it's just how much time > and effort is one willing to spend. Hello, William, Here are two questions for you: 1. you have definetely no access to th code that is encsrypted, because it is stored in a flash memory of the smartcard, which is also immune to physical investigation of data under Electron Scanning Microscope. 2. nobody, even the developer doesn't know the private key to encrypt and to run the code required. Remember, the code "doesn't" run on th CPU of the target machine, but on another place. So, 1. How can you attach a debugger to a process that doesn't run on the same context? 2. Hawill you reveal a private key, that's known by just one party. Hey, if you can answer thece questions with working snippets, please let me know... As a result I can just flush all the money in your bank there... By the way, the differences with CD way, that the games use: 1. With CD, you can read any data you want with a raw reader. 2. CD doesn't have a CPU in order to run some code on it... TIA, Salih BTW, I'm definite about the breaking into an RSA crypted executable located on another CPU... If anyone can do it, he/she's a billionnaire now... > I read the docs. They talk about things like "Protective Shields" and > "Train Cars" a lot. But when you wade past the marketing fluff, it is an [quoted text clipped - 64 lines] > > But as I said. Nothing is impossible to crack, it's just how much time > > and effort is one willing to spend. > 1. you have definetely no access to th code that is encsrypted, because it > is stored in a flash memory of the smartcard, which is also immune to > physical investigation of data under Electron Scanning Microscope. I may have missed it, but that was not what the docs said that I read. The code is not stored on the HL. Only the private keys are stored on the HL. The HL decrypts the secrets to return the text so it can decrypt the assembly. Then the assembly can run as normal in memory. > 2. nobody, even the developer doesn't know the private key to encrypt and to > run the code required. > Remember, the code "doesn't" run on th CPU of the target machine, but on > another place. Your .Net code running inside the little usb device? That would have some scalability issues I would think. SignatureWilliam Stacey, MVP http://mvp.support.microsoft.com Well, William, there are many devices around that work as the hrdware locks. That you may put on Parallel port (the earliest), serial port, USB, even I saw some using ISA or PCI expansion boards... Unlike EPROM's and EEPROM's of earlier, Flash RAM modules hold data electrically, which makes them immune to ESM... If you emit electrons or photons on such a device, you just erase what's written inside... :) And for the scalablility issue. I accept this is a fact. But, if you application needs to run as a server and needs scalability, there are really good alternative scenarios. My approach is just for desktop applications. Salih Goncu > > 1. you have definetely no access to th code that is encsrypted, because it > > is stored in a flash memory of the smartcard, which is also immune to [quoted text clipped - 13 lines] > Your .Net code running inside the little usb device? That would have some > scalability issues I would think. > like you would do in normal digital envelope. But the RSA private key is > stored in the lock. Like all crypto, it comes down to protecting the keys > and to use the resulting clear text for only a very short time and remove it > from memory. Here is where it comes back to the same problem we all have - > protecting the clear text in memory. The driver api call to decrypt the rj > keys *has to return clear text to init Rijndael with - just has to be done. AFAIK the hardlock itself decodes the encrypted part, it doesn't send the key to the computer. So the key is never visible. Ofcourse I don't have detailed insight into their methods, but if I had to develop something like that, I would also decrypt the exe in (random) chunks or on demand so that at no particular time the entire decrypted code is stored in memory. It probably isn't impossible to break, but it won't be as easy as you make it seem IMHO. SignatureRinze van Huizen C-Services Holland b.v. I think (using HL envelope method) just returns the AES key to allow the api to decrypt your local code in the wrapper. But have seen reference to both ways in the docs that are not very helpful to see what goes on. However, either way, clear data comes back from the HL. Either a clear encryption key, or the clear data itself. The dll(s) eventually has to be reconstituted completely in memory, so that will always be the weak spot for any encryption method. In this regard, it is not much different from downloading a decrypted dll from a remote server and loading it. In this case, the HL is the server. The difference is one uses Ethernet and one uses USB as the transfer media. SignatureWilliam Stacey, MVP http://mvp.support.microsoft.com > > like you would do in normal digital envelope. But the RSA private key is > > stored in the lock. Like all crypto, it comes down to protecting the keys [quoted text clipped - 13 lines] > It probably isn't impossible to break, but it won't be as easy as you > make it seem IMHO. Massimo schrieb: > Find that statement, and you crack the program... But if the assembly is signed it will fail to load when patched. Or has the framework already been hacked in a way that prevents signed assemblies from getting verified? Christian > > Find that statement, and you crack the program... > > But if the assembly is signed it will fail to load when patched. Or has > the framework already been hacked in a way that prevents signed > assemblies from getting verified? So when you patch the assembly, you don't sign it - or anything that relies on it. You remove anything which demands that the assembly is signed - it's not hard to do. SignatureJon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet If replying to the group, please do not mail me too True. Or you just resign it yourself if you want. A common misperseption is that SNs are a security enabler as apposed to a way to uniquely identify assemblies (which they are for.) A good doc by a MS guy is at: http://www.codeproject.com/dotnet/StrongNameExplained.asp Michael has some good text and SNReplace code here: http://www.atrevido.net/blog/CategoryView.aspx?category=Code Cheers. SignatureWilliam Stacey, MVP http://mvp.support.microsoft.com > > > Find that statement, and you crack the program... > > [quoted text clipped - 5 lines] > relies on it. You remove anything which demands that the assembly is > signed - it's not hard to do. Well, I think at last someone else told, what I intended... Do not use something like this: Sub Main() If DoSomethingOnCard = True Then ' Go on with program Else ' Drop to sharewaremode End if End sub What I offer is like this: Sub DoSomething Dim d as deciaml as CalculateOnCardTheDecimalValue() ' use d variable in the program here... end Sub So, if the card is not acailable, the value of "d" is wrong... (Maybe correct, but how can you know?) So, if the card is unavailable you can't be sure of the value of d here... If you can find out how d is calculated, well, you already are a candidate for nobel... (assuming d is calculated on the smartcard, through an application with RSA or PKI security. Please tell me a "cheap" way of calculating the value of d here... Note, if you are writing Windows XP of higher, it's definite that many people with many computing power and knowledge will attack you. If your program is an interest program for milk producers, well, write a good program and sell them all your customers. > True. Or you just resign it yourself if you want. A common misperseption > is that SNs are a security enabler as apposed to a way to uniquely identify [quoted text clipped - 14 lines] > > relies on it. You remove anything which demands that the assembly is > > signed - it's not hard to do. > Sub DoSomething > Dim d as deciaml as CalculateOnCardTheDecimalValue() [quoted text clipped - 3 lines] > So, if the card is not acailable, the value of "d" is wrong... (Maybe > correct, but how can you know?) Thanks. Not sure what your showing here Salih. Somewhere latter in your program, you need a test to figure out if d is good or bad. If d is a key, then you know d. What am I missing? TIA SignatureWilliam Stacey, MVP http://mvp.support.microsoft.com d is not the key. Assume that you're writing a program that calculates the interest values for some data... Assume that *only* the card *knows* how to calculate it. It is still possible to crack this program, but you must *know* how this interest is calculated. And assume that the algorithm that calculates this value is the main part of your program. So, your program running in Windows context doesn't know how to calculate this value for any variable. If you want any calculation on any variable, you use the smart card. BTW, smart cards are really smart with 33 MHz dedicated MPU's that do not deal with any UI but only raw calculations. I have heard of faster MPU's for smartcards but I myself didn't check them live yet... Is it clear enough? Salih > > Sub DoSomething > > Dim d as deciaml as CalculateOnCardTheDecimalValue() [quoted text clipped - 7 lines] > program, you need a test to figure out if d is good or bad. If d is a key, > then you know d. What am I missing? TIA Salih Goncu schrieb: > And assume that the algorithm that calculates this value is the main > part of your program. Bear in mind that the memory available on smart cards is very limited. I doubt that one will be able to put "the main part of your program" within a couple of kibibytes. Christian Believe me Christian, in most of the applications around, the code or algoritm that makes the application unique is so small... And 2K of ram is not so little... I remember I was able to use my spreadsheet program on my Sinclair ZX Spectrum (an 8 bit computer with just 8 K of ram)... :) If you don't have to deal with graphical UI, the memory requirements of applications are just fractions on the order of 10, with the GUI enabled application. Salih Goncu > Salih Goncu schrieb: > [quoted text clipped - 6 lines] > > Christian Salih Goncu schrieb: > Believe me Christian, in most of the applications around, the code or > algoritm that makes the application unique is so small... That's certainly not the case for our application. :) Christian It has an OS, the CLR, and a subset of the framework, and your program in 8K? SignatureWilliam Stacey, MVP http://mvp.support.microsoft.com > Believe me Christian, in most of the applications around, the code or > algoritm that makes the application unique is so small... And 2K of ram is [quoted text clipped - 17 lines] > > > > Christian Hey ! There are lots of tools available in the market which can encrypt the IL. One of the tool ships with Visual Studio 2003 too. Check with that tool. Hope this helps ! Thanks, Nikhilesh > I'm planning to develop a .NET application using C#, in order to sell it as > a shareware and/or as a full package, so I'll need a good way to protect it [quoted text clipped - 8 lines] > > Massimo Hello Massimo, .NET programs are always Open-Source, if you do not protect it with a third party tool. Have a look at programs like Anakrino and you see that all your code (obfuscated or not) is visible in source. Obfuscating has the only effect, that understanding your program needs much more time. If you want to protect it secure, you need an additional tool like Thinstall or others. These tools have the great disadvantage that your protected program is not longer a real .NET program for the environment. That means, it is, for example, not possible to change the security with the .NET Framework wizard, A ideal solution is not available! I think this must be realized by microsoft. I think it's a joke: Microsoft have many reason's against open-source and protect it's own software very well and create a developer suite without any effective copy protection. Bye Frank > I'm planning to develop a .NET application using C#, in order to sell it as > a shareware and/or as a full package, so I'll need a good way to protect it [quoted text clipped - 8 lines] > > Massimo > .NET programs are always Open-Source, if you do not protect it with a third > party tool. Either you don't understand Open Source, or you're wilfully ignoring whole rafts of implications of the phrase beyond being able to get (probably illegally, depending on the licence of the application) some source which you can compile. > Have a look at programs like Anakrino and you see that all your > code (obfuscated or not) is visible in source. Only if you don't put any comments in your code. What comes out of a decompiler is nothing like my code... Have you ever tried to understand a large and complex piece of software without any comments? Even without obfuscation, it's still a significantly difficult undertaking. > Obfuscating has the only effect, that understanding your program needs much > more time. So do all other solutions. If the code runs on someone's computer, ultimately that person can see the code in some form or other. > If you want to protect it secure, you need an additional tool > like Thinstall or others. If you think those give 100% security, you're deluding yourself. They make it another level harder, certainly. > These tools have the great disadvantage that your > protected program is not longer a real .NET program for the environment. [quoted text clipped - 7 lines] > protect it's own software very well and create a developer suite without any > effective copy protection. Yes, because the games industry is proof positive that native code is uncrackable, isn't it? SignatureJon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet If replying to the group, please do not mail me too Hello Jon, you are right. Open-Source means not only the available of the source code, but also a copy license (like GPL, LGPL or so on). In this case i only mean the easy available of the source code. It's included in the .NET application. If you use tools like Anakrino you get only the source code without comments, but it is much more than a reverse engeneering of the program code, which offers you only the assembly code of the program. I must sometimes take the code of a colleague (who left our company) in my company and add additional functions to this programs. Especially the older code has no or poor comments, but it's possible and much more easier than getting only the assembler code! I think there is a fault in your view. The goal is not a 100% security (this does not exist). The goal is to make code copy much more difficult. So the time for creating the program should less than the time for copy another program and understand the philosophy of the source code. This is the goal for copy protection of a program. And for copy protection i do not only mean safety for cracking program, but safety for avoiding changing source code or copy of a part of the program like an algorithm. Frank > > .NET programs are always Open-Source, i |
Enable EMail Alerts
Start New Thread
Reply to this Message