Create setup with s/n - c#

I have a Vb.Net/C# 2010 project that I'd like to distribute as a setup file. During installation, it should ask the user for a serial number. Any suggestions as to how to do this?

Here is a question on DaniWeb, more an idea rather than an actual way to implement it: http://www.daniweb.com/forums/thread336128.html
Written in VB.NET, this person made a package of code that randomly generates CD keys. It might help with random generation in your project. He stated that he would try to get C# code up some time, but I don't know if he has or will. Here's the link: http://www.codeproject.com/KB/security/cdkeys.aspx
This thread has a couple of links to MSDN articles and some interesting ideas on the topic: http://www.vbforums.com/showthread.php?t=472626
As far as I can tell, if you sincerely want to implement a serial key system, you would:
1) Need to randomly generate keys and store them somewhere.
2) Check the available keys every time a user enters one, therefore requiring online access.
3) You might even have to use paid libraries, as it's difficult to do this alone.
4) Give the user some kind of offline "key-storage" technique, such as Autodesk products do. This means that they fill out the registration and then save a file to their hard drive with their registration information, so they can send it to you later, when they have an internet connection. Be warned, however, that these offline activation systems are very easily exploited.
I'm sorry I can't be of more help, I have researched this topic, but have never successfully accomplished it!
Good luck!

Either code everything yourself or i would say use an Installation Builder tool like Install Shield from Flexera Software which provide such facilities. Even Microsoft suggest it.. however its not free.

Related

How to protect .Net exe from Decompiling/Cracking

I am really sad because a few days ago we launched our software developed in .Net 4.0 (Desktop application). After 3 days, its crack was available on the internet. We tried to protect the software from this but somehow people got away cracking it.
Here is the scenario:
When the application launches the first time it communicates with the web server and checks the credentials passed by the user. If the credentials are correct, the software saves the values in the Registry, sends the MachineID back to the server and stores it in the database.
Now, the hacker has replaced the Server communication with a "return true;" statement (I checked that with Telrik JustDecompile). and he has uploaded the cracked software on the internet.
Now, following are my questions:
1- How to make sure that .Net application will not get cracked ?
2- The hacker now knows my code since he has done the modification. What steps should i take ?
3- I read on the internet about - obfuscators . But the hacker knows my code what should i do ?
4- Any other pro tips that i can use to avoid getting the software cracked ?
5- I am not sure but can these reflector softwares also decompile the App.Config with sensitive data ?
1- How to make sure that .Net application will not get cracked ?
If a computer can run your code + The hacker can run his own code at a higher privilege level than you, there is nothing that can 100% prevent your app from being cracked. Even if they just have access to the executable but not the target platform they still can step through and mimic what the target platform would do and figure out how the protection is being done.
2- The hacker now knows my code since he has done the modification. What steps should i take ?
Totally rewrite the authentication portion so they have to start from scratch but they will get it again, it is just a matter of how long.
3- I read on the internet about - obfuscators . But the hacker knows my code what should i do ?
The jinni is out of the bottle now that they have the non-obfuscated code. There is not much you can do unless you drastically re-write the software so they have to start from scratch. A obfuscateor will not prevent a determined attacker, they only thing that can prevent it is keeping the binary out of their hands.
4- Any other Pro tips that i can use to avoid getting the software cracked ?
The only copy protection I have seen to remotely delay for any period of time is what Ubisoft did with Assassin's Creed: Brotherhood. They encrypted ther levels with the game disk and it had to download the decryption key from the internet as it was needed (This is the keeping the binary out of their hands approach). But that did not work forever, eventually the hackers did get those levels decrypted and it was fully cracked. This approach is just what I saw take the longest time to get around without legal involvement (See point 2 at the bottom)
5- I am not sure but can these reflector softwares also decompile the App.Config with sensitive data ?
All the reflector software needs to do is look for the section that loads App.config and read what the defaults are. There is no secure place to store information on a computer you do not have full control over. If it is on the computer, it can be read. If it can be read, it can be reverse engineered.
The only real solution I can see to prevent piracy is one of two options.
The person never gets your app, it is streamed from a server under your control and they never get to see the binary. The only thing you send them is the information they need to drive the UI. This is the approach that all MMO's work on. People can reverse engineer what you are sending to the UI and mimic the logic that is going on on your servers but they will never be able to outright see what it is doing and if your software is complex enough it may not be feeseable for the attacker to recreate the server side code. The downside to this approach is you will need to host servers for your users to connect to, this will be a reoccurring cost you will need a way to re-coup. Often this method is called a "Rich Client" or "Thin Client" depending on how much processing is done client side and how much processing is done server side. See Chapter 22 of "Microsoft Application Architecture Guide, 2nd Edition". Specifically I am describing what is shown in figure 4 and 5
The seccond option is whoever you sell your software too have them sign a legal contract not to distribute the software (not a EULA, a actual contract that must be physically signed by the client). In that contract have large fines be applied to the person who leaks the software, then riddle your program with fingerprints that are unique to the person who buys the software so that when the program is leaked you can see who did it. (This is the method the vendor Hex-Rays use for their disassembler IDA. A quick google search could not turn up any cracked versions newer than 6.1, they are on 6.3). This method will not stop piracy, but it may discourage the copy to be leaked in the first place. This also lets you recover some lost costs associated with the program being leaked in the first place. One issue is that you will need to put a lot of fingerprints and they will need to be subtle, if a attacker can get two copies of the program and can compare the files between the two he will be able to tell what is the identifying information and just put whatever they want in so they can't tell who they got it from. The only way to do this is put a lot of red-herrings in that can't just be stripped out or randomized, also make the identifying code non-critical to running the software, if they don't have to work to crack it they are more likely to leave it in.
Update: After revisiting this answer to link to it for another question I thought of a easy way of implementing the #2 solution.
All you need to do is run your code through an obfuscateor and let it rename your classes for every person you sell your software to (I would still make them sign a license agreement, not just click a EULA so you can enforce the next part). You then make a database of the obfuscation mapping, when you see a leaked copy on the internet you just need to find one class anywhere in the project, look it up in your database, and you will know who leaked it and know who you need to go after for legal damages.
1: you can't. You can obfuscate, but the only way of preventing this is: don't give anyone the exe. Look how much games companies spend on this; they haven't solved it either.
2: obfuscation would help a little, although it is an arms race between obfuscators and de-obfuscators
3: too late to go back and undo that, but the obfuscation will slow them down a bit in future
5: app.config is usually very readable; you not much you can do here; encrypting will only slow them down a bit if the keys are in your app and therefore obtainable
As others have said there really isn't anything you can do against a determined cracker if they have access to your code. Obfuscation will provide some protection against a lazy cracker. Dotfuscator is built into VS you can give it a try. Keep in mind that there is a real cost to obfuscation. It will make it very difficult to debug issues from stack traces that your (paying) customers send you.
The best answer is one you will have to accept. You can't. Just focus on giving your users a great user experience, and make licensing very easy. The possibility that your application can be cracked does not mean that choosing to build a desktop application was a bad idea. Pirates will be pirates and honest customers will be honest customers.
Apparently there is enough commercial or intellectual value cracking your app that someone with reasonable skills tried it almost right away.
The only way you will win that war is to use commercial software protection packages.
If you try to implement copy protection yourself, you will be an easy target to hack again.
If you write a business application you would not also write the database engine that stores the data. You should also not write the crack prevention code for your application. That is not what solves your customer's problem, and it takes a tremendous skill set to do it right.
What you can do, in addition to the code obfuscation is, adding a mechanism of code decryption based on hardwareID, have in mind the following scenario, the send their HwID to your server, you identify the copy/owner/installation number/etc with that HwID, and you reply with a decription key BASED in that HwID for THAT specific binary (with the fingerprints mentioned before), so the hacking would be harder, since for fully functionality they need valid access to your server, otherwise they can't use the software.
Cheers,

Easy update assistance

We are writing simple architectured software in C# 3.5.
What I was searching for is for easy updating framework/application...
We don't have COM components, Servicdes to install or whatever, so basically what we need is xcopy stuff form one Server side directory to the client. So what the program should do is like a workflow:
Check some location \Server\Updates for manifest.xml
Check the local setup verison
Download all available DLLs (doesn't necessary all need for complete application, so kind of patch stuff) and substitude them with "old" ones.
I'm aware of ClickOnce, of App publishing, also our setup generator supports autoamtic updates (even if noone yet used it, and I don't want to use to not strongly couple ourselfs with that technology).
Do you know some app or technology, that I'm not aware (actually listed in question) which could better fit our needs. ?
Thank you in advance.
So, after the comment, the answer:
I would look at this SO post.
I looked wyWuild and the AutomaticUpdater controler some time ago. It really looked great.
EDIT
I just remembered that I chose to use AppLife Update in the end. It's more expensive but the features are extremely good

Protect the source code on delivery to client

I've recently learnt that the company that will handle the installation of one of our core products have previously tried to reverse engineer suppliers' work in evil purposes. Due to this I want to learn more about how to protect our work and so far I have thought of the following:
1) Obviously to use an obfuscator. Question is which one.
2) Encrypt config files as much as possible (especially endpoint information).
3) Move as much of the logic as possible to the web service.
4) Use SSL for data transfers.
The project is written in C#/WPF and connects to a set of web services hosted on a IIS 7. We package our deliveries with WIX, does WIX have anything to provide?
I understand that in the end all binaries can be hacked and that as a minor company we should probably concentrate on writing code instead of protecting it. But these minor steps will at lease make it harder.
What else can be done? Does the community have any more advices regarding this? Links to internal/external resources would be much appreciated.
Here are your options:
Don't give them the program, they've already abused their power
Have them enter into a license agreement wherein:
They can reverse engineer the program or even see the source code within the confines defined by your legal team
They can't do anything without inviting a world of legal hurt
Release the code as open source. You'd be surprised, if the "forbidden fruit" isn't forbidden they may just get bored and leave it alone.
Move the proprietary computation to your own servers, essentially making your program into a thin client.
Reverse engineer some of their tools. Enter into a cold-war of sorts.
Stock up on patents, and when you see your own code out in the wild sue the company into oblivion for violating your patent.
Pay the mob to run your "friends" out of town
Send them a basket of muffins with a note that says "PlZ st0p wit teh H4x"
Dress up as the ghost of professional integrity, visit each of the employees in their homes and teach them lessons about ethics and morality.
Buy out the company, fire all of the employees.
As much an agreement with #Chris as anything.
Hire an attorney and draw up the appropriate license terms.
Every so often contact the offending company and ask if they have something similar to your software for sale. In the event they say yes, get a demo. If it bears any resemblence to yours, sue them into oblivion. One of the early stages in a lawsuit of this type is discovery. At which point you'll know whether they copied your code or not.
Presto, problem solved.
Point is, the only real solution is to use the legal system.
Actually I think that your 4 points cover what you can do (realistically) very well. The only thing I would add is the appropriate clause in your licence.
If someone wants to steal, they will steal.
Edit: oh, RE Obfuscator as much as I hate to recommend Red Gate after their reflector treatment, their Smart Assembly is very good.

what are the different componenets needed to produce and sell an application in C#?

I need some help with my knowledge of .NET !
ive always created applications using C#(for fun), i also have knowledge in C, however i have some unanswered question and ive been searching for days!
once i create my form and my application is running fine, do i need to add a class of any sort to programeName.cs file? and why (i breifly know why but i need to understand exactly why, and when is it a must) ?
when im finished with the application design and my previous question is answered; what do i need to do to sell the application? do i just burn a CD with the .exe in it?? :S
i guess my question would be, what are the different componenets needed to produce and sell an application? is it really as simple as just creating a windows application form that works??
Cheers
Your question is really about two things:
Technical completion
Distribution
You don't need to do anything special, short of perhaps building in release mode rather than debug mode, to have a product ready to ship. You can do extra things, but don't need to. If you want to package it up in an installer application such as an MSI then you can, which makes distributing and installing easier for end users. Alternatively, depending on your audience, zipping it and telling users to xcopy it might be sufficient.
In terms of distribution - burning cds is out. Use the internet. If you're really solving a paint point for customers, and there is legit need for your app then customers will come. How do you get traffic to your site? Blog about it, (ideally in advance), find a few important blogs in the same vertical, with good readerships, and insert yourself into them. Add insightful comments, and post a topic expanding on it in your blog, and link to it. Build SEO, get inbound links etc.
If you application is running fine then you shouldn't need to add anymore code. Now, you might want to create an installer package. This is preferable to just have the plain executable as it will aid in creating Start menu shortcuts and so forth. However, if your app is very simple, you may just want an exe; it really depends but people usually create an installer. You can create a simple one within Visual Studio.
As far as selling, there are some other things like building a web site and using some sort of payment vendor. A lot depends on your specific needs and goals.

Design considerations when implementing/distributing updates for application

I have already designed an applications that is nothing more than a simple WinForm with one or two classes to handle data and collection.
Fairly often I find myself refactoring parts of it or adding new features to it, not huge features but small additions to its functionality.
The question I have is what would be the best way to provide an updated program to the user after they have initially downloaded it.
I have thought of a few different options already:
Upload a new version with improvements on CodePlex
Host the application on my personal website but change the file with the latest version
Implement some sort of system that will work in a way similar to add-ons to add the functionality.
Is there a way to provide an updated application without the user having to essentially replace their current version by deleting it and replacing it with a newly downloaded one? Although the CodePlex idea seems worthwhile I wasn't sure if there was a better or easier way.
Thank you for your time.
This is what ClickOnce was designed for.
I've used it regularly in a corporate setting,but it would also be appropriate for an Internet deployment scenario. You may want to invest in a certificate so you can sign your code if this is a commercial product.
Added
Here's a shorter article with a lot of screen shots.
http://www.15seconds.com/issue/041229.htm
(Still looking for more good links).
Added - final addition
Wikipedia sums it up succinctly.
http://en.wikipedia.org/wiki/ClickOnce

Categories