Protection against piracy

Hello and Merry Christmas !
I have created a shareware application and i want to protect it against piracy.
I know there is Armadillo (http://www.siliconrealms.com) but it costs 300$ for Win32 only.
I plan to protect my software in a way and if i get enough sales then i will buy Armadillo.

I was thinking of using Triple DES encryption and a secret phrase #1 in order to generate a user key based on user name and machine name. Then the user sends the user key to me and i decrypt the user key and get the user name and machine name.
Then i encrypt again the user name and machine name by using Triple DES encryption and a secret phrase #2 and generate a registration key and send it to the user.

The user enters the registration key and at the start of the application,saving the project and at various points of the application i test if the registration key is valid. To do so i encrypt the user name and machine name using the secret phrase #2 and check if it matches the registration key.

The problem is that that the secret phrase #1 and secret phrase #2 has to be located in the source code. I will obfuscate ofcourse the code
but if a cracker finds the secret phrase it will be possible to create a key generator..

Also in order to make a trial version that works only 30 days i do the following:
The first time the application is run i create a registry key "First Run Date".
Each time the application exits i update a registry key called "Last Run Date".
If Current Computer Date <"First Run Date" -> Exit
If Current Computer Date <"Last Run Date" -> Exit
If Current Computer Date > "First Run Date"+30 days -> Exit.

What do you think of these ?
Is there any free protection system against piracy available ?

Thanks !
Alex

I am not sure if it would work since some one could possibly change the registry settings and thus void the protection.

i would encrypt ofcourse the registry settings with Triple DES and a secret phrase #3.
if a user changes the registry settings the setting would be corrupt and the application will not run.

I wouldn't bother with any of that. The fact of the matter is most web users are honest folk. A simple nag screen or reduced functionality will make people buy the program. People who are going to pirate your wares will do so regardless of encryption strength. The secret of getting good sales versus pirated sales is a good price and great service.

Take Pinnacle Game Profiler. This is a piece of software that many people use, yet its pirated very little. Sure its easy to find a pirated copy but the fact that its a reasonable price and has great support means that the author doesn't worry about piracy a huge amount.

"most web users are honest folk".. i doubt it just remember how many mp3 and movies are pirated .. web users are the common members of the society in the whole world , not just us or europe. so it would be better to , try at least , to protect a commercial application.

what do you think of the protection scheme i wrote above ?

The key is, to corrupt any software protection is not just reversing/imitating its encryption methods, but it is much more easy, to simply modify its functionality, in assembly programming level. That is, what called in common language, reverse engineering, where you can recall the machine code (compiled exe) to a better but readable format. There, a software protection cracker guy, can modify a Jump code to simply pass/skip the decrypt and/or result generators, to make always a True result, there the application will always think "hmm, license keys are ok".

To avoid this, there are dongle keys, that is hard to imitate (yet its not impossible to imitate, but for 'cheap' ware theres no cracker group will create such an emulated dongle), because it may takes too long to doing it. I have heard about some methods, just like the software contains some machine code sequences, that are encrypted (so its impossible to skip the dongle, because the app cannot be run). There i also heard about methods, the dongle just simply contains some parts of the code, so the application will not able to run (simply crashing) without to including the proper dongle content, that is some parts of the program itself.

I'd guess that 90% of the people here using VB6 are using a pirated copy. No joke.

Despite the free Express Editions I'd guess that 50% of those using a VS.Net "pay" Edition are pirated too. The number might only be lower because the .Net versions haven't been around long enough for widespread cracking and distribution and that the Express Editions take some pressure off.

With those kinds of numbers for programming tools what can you expect of the Great Unwashed who might use your software?

My Software Is Being Pirated

Regarding licensing, I'd suggest you take a look at ActiveLock. It's a bit VB6 but it does the job of providing a way to create time-limited demos, plus there's a wizard that will generate .Net code for you.

Regarding code protection, obfuscation will not stop a determined person who knows .Net from cracking your app. I'd strongly suggest Protector which makes a cracker's job much more difficult. Down side of protector is that it's quite pricey.

This topic comes up at least once a month and my response is always the same: stop treating your legitimate customers like criminals!

Below is my rant from the last thread about this. There are many threads about this issue.

Quote:

---

Originally Posted by kasracer

These kinds of questions have been poised many times in this forum. My opinions are very user-experience-centric.

Quote:

---

Originally Posted by GaryMazzone

What software anyone using to perform obfuscation of your code before sale?

---

None. .Net's design makes applications easy to disassemble. What does obfuscation do? It hides the meanings behind your code (i.e. variable renaming) and also creates method overloads to hide the purpose of your methods. Some even go as far as encryption but in the end it doesn't matter.

You'll make it a little harder for the occasionally cracker but beyond that it's ineffective. You can still follow the process flow from obfuscated code. Since encrypted assemblies can't run by themselves with the framework they have to be decrypted at some point making them vulnerable. It would also have the decryption key embedded within itself (otherwise how could it decrypt itself?).

Obfuscation is a waste of money in my opinion. You developed in .Net so you knew the risks before hand. Trying to use a rapid development focused framework for a native application is never a good idea.

Quote:

---

Originally Posted by GaryMazzone

Also anything to prevent piracy?

---

No. Think about it this way: Joe wants to pirate a copy of your software. Do you think he is going to

1. Attempt to copy a CD
2. Attempt to install someone else's copy
3. Find it at a typical software pirating website.

If you guessed 3 then you're correct. No matter what software protection scheme(s) you employ on your software, 99.9% of pirates will be completely unaffected because they downloaded the copy someone else broke.

The biggest problem I have with software companies is when they treat their customers like criminals. I'm very against any type of DRM and copy-protection on all types of software and media as it only punishes the legitimate user and does absolutely nothing to the pirate.

Quote:

---

Originally Posted by GaryMazzone

Allow timed demo of application?

---

I have no qualms with this. Keep on keepin' on :thumb:

---

In the end, the pirated version of any application is better than the original because they remove the annoying aspects of the original. Don't end up like this.

Quote:

---

Originally Posted by ntg

Regarding code protection, obfuscation will not stop a determined person who knows .Net from cracking your app. I'd strongly suggest Protector which makes a cracker's job much more difficult. Down side of protector is that it's quite pricey.

---

Protector is also quote worthless. It only takes one software cracker to crack your application and it's done. It'll be on the net and anyone can download that copy.

Protector is really for upper management. It'll stop the little guy but not the pirate who makes it available to the little guy.

the problem is what happens if the user changes the registry and
brings it to the state when the application was first installed. then the user
can run the application for another 30 days .
any help on that ?

Quote:

---

Originally Posted by alexandros

the problem is what happens if the user changes the registry and
brings it to the state when the application was first installed. then the user
can run the application for another 30 days .
any help on that ?

---

Unfortunately there isn't a whole lot you can do about that. You could possibly use your server to create a custom executable that is set to expire at a specific date / time but then it can be re-downloaded.

All applications suffer from this same shortcoming, however. MS Office and Adobe products can be reset. An OS format and reinstall always fixes this as well so you won't be able to prevent this entirely.

There is no way to protect any piece of software from being pirated. The best you can hope for is to make it as difficult as possible to pirate.

Quote:

---

Originally Posted by Kasracer

Protector is also quote worthless. It only takes one software cracker to crack your application and it's done. It'll be on the net and anyone can download that copy.

---

Quote:

---

Originally Posted by Hack

There is no way to protect any piece of software from being pirated. The best you can hope for is to make it as difficult as possible to pirate.

---

That's my point as well guys. Applications are always crackable but I don't see any particular reason in making them easily crackable.

Quote:

---

Originally Posted by Kasracer

Protector is really for upper management. It'll stop the little guy but not the pirate who makes it available to the little guy.

---

I won't agree there. Besides the trivial matter of trying to make an application more difficult to pirate, with pure IL there's always the downside of anyone being able to use tools like Reflector to get the complete source code. It all depends on your application's worth and your target audience, but I can't see anything wrong with making an effort to protect your intellectual property, whatever its value. Of course there's always the shared/open source pay-for-services-and-customizations mentality but I think that's not what we're talking about here.

Quote:

---

Originally Posted by ntg

That's my point as well guys. Applications are always crackable but I don't see any particular reason in making them easily crackable.

---

I'm not saying make it easily crackable. I'm saying make is a great user experience and don't worry about the pirates because there is nothing you can do.

Quote:

---

Originally Posted by ntg

I won't agree there. Besides the trivial matter of trying to make an application more difficult to pirate, with pure IL there's always the downside of anyone being able to use tools like Reflector to get the complete source code. It all depends on your application's worth and your target audience, but I can't see anything wrong with making an effort to protect your intellectual property, whatever its value. Of course there's always the shared/open source pay-for-services-and-customizations mentality but I think that's not what we're talking about here.

---

I'll have to disagree with you there. If you're developing using the .Net framework then you're (or at least should be) aware with how it works. If you're developing in .Net and you want it impossible to get your original source code... well that's like buying and using a car but expecting it to float on water; it's not meant to do that so it'll never work as well as a real boat.

If you use Salamander's native compiler then you lose out on the security and managed code benefits (such as processor optimization). If you use their encryption then you not only make your application's launch slower but your source code is still available (otherwise JIT wouldn't be able to compile it) the attacker would just need to get the executable after decryption or decrypt it themselves.

I can understand wanting to protect your source code but to attempt to do so with a language that's not meant to do so is a bad decision. Use the platform for what it's meant for, not what you want it to be.

I appreciate what you're saying and all I can say is that we have different view points. To use your car example, an analogy that fits my state of mind is that the car key lock doesn't have anything to do with the car's purpose to drive you from A to B but still you need to have it in place otherwise someone might easily steal it. Still, even with the lock, a good thief can steal it anyway but you wouldn't use that as an argument to do away with the lock altogether.

Having said that, I still think that the level of protection you apply to your application depends on its audience. If, for example, you've developed the .Net equivalent of WinRar I would say that a simple obfuscation in order to make the algorithms look incomprehensible would suffice. Indeed there wouldn't be any point in taking additional measures for such a popular application since it's going to get cracked very quickly and (like you said) one should focus on providing real application value.

On the other hand, if you're developing for a vertical market and you target a few (or even one) customers, leaving your application open so that anyone can easily make the decompile-recompile round trip is not good practice. My focus is banking which means very few customers and few, large scale applications. I know from experience that someone once tried to see what happens inside one of our libraries with the full intent of "patching" it. This might not necessarily mean that the application, or parts of it, would somehow also be made available to our competition but I'd rather not chance that so I use protector routinely (no experience with salamander native compiler). It's true that since it can still be JITed then it can also be cracked but our attack surface and exposure are so much smaller simply because the application is not out there i.

It also occurs to me that our different view points may have something to do with our possibly different backgrounds. My experience in Greece is that people typically treat software as something that can be routinely copied and examined. License agreements are things that appear in a dialog box where you just click on Next to get it out of the way.

Quote:

---

Originally Posted by ntg

On the other hand, if you're developing for a vertical market and you target a few (or even one) customers, leaving your application open so that anyone can easily make the decompile-recompile round trip is not good practice. My focus is banking which means very few customers and few, large scale applications. I know from experience that someone once tried to see what happens inside one of our libraries with the full intent of "patching" it. This might not necessarily mean that the application, or parts of it, would somehow also be made available to our competition but I'd rather not chance that so I use protector routinely (no experience with salamander native compiler). It's true that since it can still be JITed then it can also be cracked but our attack surface and exposure are so much smaller simply because the application is not out there i.

---

I would argue that you're using the wrong technology then. .Net is for RAD which typically ends up being a fast interface between the client and the database. Banking software software especially for many clients doesn't really make sense, in my mind, to develop with any kind of RAD framework. It just sounds to me like you're trying to take the easiest route then shoehorn some protection onto it. There is a reason very few .Net applications become commercialized (even Microsoft makes lite use of it in their commercial products; as far as I know they don't ship any major components written in .Net).

Regardless of your solution you should always work towards abstracting things away from the client as much as possible anyway. Critical items such as data access should always be handled via web services or other, similar technologies. A client should never, definitively, decide what gets updated and what doesn't but instead request that the server updates what it sends. I think we can both agree on that but what I'm trying to get at is that typically your client application is stupid with a real focus on the server side for much of the brains. Maybe it's because I don't have much experience in the banking sector but I just can't think of any features or code that you could create that would be "protection-worthy" especially since most of the business logic wouldn't exist in the client application anyway.

Quote:

---

Originally Posted by ntg

It also occurs to me that our different view points may have something to do with our possibly different backgrounds. My experience in Greece is that people typically treat software as something that can be routinely copied and examined. License agreements are things that appear in a dialog box where you just click on Next to get it out of the way.

---

While I grew up in America that's typically the same attitude. No one cares about licensing agreements (EULA's are hard to hold up in court anyway) and everyone I know pirates software. My viewpoints came from frustration as the end-user with the way many companies do business.

Strangely enough, I'm seeing medium/large scale .Net banking solutions (developed by vendors and in-house by banks) all the time - in fact nowadays it's either that or Java in the area of my experience which is EFT. What I'm seeing suggests that .Net is definitely not something for RAD only.

Regarding the parts of an application worthy of protection, we make heavy use of server-side components almost all the time. I normally wouldn't really bother with a client application unless it's something really special - however clients also get protected as part of the build process.

Quote:

---

Originally Posted by Kasracer

My viewpoints came from frustration as the end-user with the way many companies do business.

---

I never had an end-user get frustrated because I obfuscated/protected an application or library, except from that instance I pointed in my previous post.

Quote:

---

Originally Posted by ntg

What I'm seeing suggests that .Net is definitely not something for RAD only.

---

.Net is meant for RAD. I can understand creating an in-house solution in .Net as that was what it was made for but commercial applications? That just doesn't sit right with me. You can use it for whatever you want; I just feel there are some things it shouldn't be used for.

Quote:

---

Originally Posted by ntg

I never had an end-user get frustrated because I obfuscated/protected an application or library, except from that instance I pointed in my previous post.

---

You were discussing piracy and with piracy comes crazy, anti-user protection schemes which is where my viewpoint comes from. I wasn't specifically saying obfuscation or encryption upsets users (though I could see why an obfuscated or encrypted library could upset developers trying to extend the existing solution).

You need only check this to see that there are a lot of vendors out there that create .Net commercial applications.

Regarding extensibility, an obfuscated or protected library can be extended by end-users to the degree that the author allows it (by providing a good description of the library and how it does what if the library was meant to be extended in the first place). There's nothing that prevents you from extending a class that resides in an obfuscated/protected assembly. If you have problems extending such a library, then either the classes aren't well thought out or the documentation is not of good quality. In either case, in most countries that doesn't mean it's OK to disassemble to see what's inside.

Quote:

---

Originally Posted by ntg

You need only check this to see that there are a lot of vendors out there that create .Net commercial applications.

---

I understand vendors do it but it just doesn't feel right to me but I can't really argue beyond the basic reasons why I don't think it's a good idea. I think .Net really lends itself to open-source projects though. The website you linked to has custom solutions for enterprises which is the key usage of .Net.

Quote:

---

Originally Posted by ntg

Regarding extensibility, an obfuscated or protected library can be extended by end-users to the degree that the author allows it (by providing a good description of the library and how it does what if the library was meant to be extended in the first place). There's nothing that prevents you from extending a class that resides in an obfuscated/protected assembly. If you have problems extending such a library, then either the classes aren't well thought out or the documentation is not of good quality. In either case, in most countries that doesn't mean it's OK to disassemble to see what's inside.

---

You can reference and use a library that was obfuscated as long as the author made sure to not obfuscate the public interfaces. If they did obfuscate that then there will be issues. Even if the library wasn't meant to be used outside the application sometimes companies need to hook into that library and use it.

As for a protected assembly; how can you use those in a standard .Net application? I understand it when they encrypt the entire assembly and basically stick it inside of a native executable to decrypt and run it but how does that work for dynamic libraries?

Quote:

---

Originally Posted by Kasracer

As for a protected assembly; how can you use those in a standard .Net application? I understand it when they encrypt the entire assembly and basically stick it inside of a native executable to decrypt and run it but how does that work for dynamic libraries?

---

All members of a protected library appear exactly as they do if the library is unprotected. You can even use Reflector and ILDasm to see the class declarations, you just don't see any code.

Quote:

---

Originally Posted by ntg

All members of a protected library appear exactly as they do if the library is unprotected. You can even use Reflector and ILDasm to see the class declarations, you just don't see any code.

---

Thanks I'll have to look up how that works then. It was my understanding that executables were replaced with native versions that basically decrypted the main executable but I obviously don't know how it works for libraries.

I am planning to save an encrypted file in the Windows System Directory.
There i will store the date last run , date first used , license key etc.
The problem is that the user propably should have admin rights in order to
write in the System32 each time the application starts...
Should i use the application data directory ? Is that better ? The problem with the application data directory is that the encrypted file would be too obvious..
What do you think of that ?

Quote:

---

Originally Posted by alexandros

I am planning to save an encrypted file in the Windows System Directory.
There i will store the date last run , date first used , license key etc.
The problem is that the user propably should have admin rights in order to
write in the System32 each time the application starts...
Should i use the application data directory ? Is that better ? The problem with the application data directory is that the encrypted file would be too obvious..
What do you think of that ?

---

I wouldn't use the System directory; that should be reserved for anything that needs total system access.

I would store it in the application data directories. I don't see why that would be obvious though; there is a ton of stuff in there. Just make sure to put it in the all users application data so someone can't create a new user and start their trial again.