I am a web developer that is very conscious of security and try and make my web applications as secure as possible.
How ever I have started writing my own windows applications in C# and when it comes testing the security of my C# application, I am really only a novice.
Just wondering if anyone has any good tutorials/readme's on how to hack your own windows application and writing secure code.
The books by Michael Howard are a good starting point;
19 Deadly Sins of software security (with examples in several
languages)
Writing Secure Code
There's loads of links and interesting articles from Michael Howard's blog here
There's an interesting powerpoint presentation from Microsoft about threat assessment, risks and ASP here.
Apart from all the obvious answers to prevent buffer overflows, code injection, session highjacking et. al. you should find somebody else to check your code/software because you can only think about ways to hack your software that you know how to prevent. Only because you can’t find a way to hack your own software that doesn’t mean that nobody else can.
This is something that is very difficult for you to do, and I think that you are approaching the problem from the wrong angle. If you are writing an application of any size then attempting to deal with security at the end, by looking for specific ways of breaking your own software, is almost impossible.
This is for a number of reasons. You already think about your software in a certain way. You think of specific ways of interacting with it, and you know how to get the best from it. You don't think about it in terms of ways to exploit it, and this is a hard thing to do with software that you are intimately familiar with.
Another problem is that the task by this point is too big to deal with. Any problems that you do find may open up any number of other problems. A system wide security check is nowhere near granular enough.
What you should be doing is thinking about security while you write the software. Learn the best practices, and consider each method and class that you write from a security perspective. This goes hand in hand with unit testing, try to consider what inputs could make this specific part of my program break. and then deal with them at that level.
After that I think its a matter of responding quickly to any security concerns that you are made aware of.
Small things that I have come across through my own experience.
Do not use dynamic SQL, you are then vulnerable to SQL injection. Rather use SQL queries with parameters.
Do not have incrementing ids like user_id = 1, 2, 3 etc etc and then use that in a URL, something.aspx?user_id=1, i can then guess the next id and session hope. Same for accounts and what ever else is sensitive.
Watch out for XSS, (cross site scripting). If you accept user input and store it directly, make sure that they can't go insert alert() for their name or something.
This is by no means a complete list. Just the stuff that I have run into recently.
You could do much worse than reading Ross Anderson's Security Engineering book. The first edition is downloadable as a PDF and is a good read. I haven't read the second edition, but I suspect it's better and has more goodies in it.
Do note it is a book that explains how to build security in from the start, not how to break security, but the exposition of assorted security faults should give you a good idea for where to start looking.
To secure your win form application open it and try to do everything that lambda user shouldn't do! I'll explain:
If you "say enter yes or no", try with A-Z, 0-9 because that's what some users do to try to find some stack trace that could be interesting. So put validators everywhere.
Beware of connection to databases but if you come from web dev you should be more aware than me :).
The hardest part is to watch out about memory leaks or stuff like that, but that's in big big apps or in not well developed apps.
Related
After reading numerous threads on Stack Overflow about how to protect software, I realized you can't. Thankfully my software is targetted at hosting businesses (not a lot of them at that) and a handful of consumers. I don't think the software will be popular enough that anyone is going to crack it, but I would like to protect it.
In one of the threads I found, it had a list of half decent options. I have decided I would like to go with "Simple registration with revokable keys, verified online frequently."
I figured since my application is a C# NET Console Application that will be ran through a management container, I can just issue keys for it. Perhaps do a MySQL Database and keep a list of keys that can only be used on one install, and another list of keys that can be used on X installs. My application will be ran with command line parameters at startup anyways, so adding one like "-key 29839X900AQ" or something will alleviate the need for them to have to really worry about it too much.
Does anyone know of any information/sites that offer help on setting something like this up?
You can absolutely protect software and the threads that claim otherwise are in error. No one has cracked our system (when properly implemented) and we've had public contests to see if anyone can (disclaimer: I work for a software-protection company).
However, there are a zillion ways to approach this and there is no "free" system or software-only system that can't be cracked. Some, however, are strong enough that they will require a significant effort and unless your software appeals to a large market or costs a lot of $$ there will be little motivation for a cracker to put in the effort.
If I understand your proposed solution you will be vulnerable to people sharing keys. You can check to see if a single key always originates from the same IP address but that can be spoofed (to allow for illegal copying) or could potentially prevent legal customers from access.
Protection is like putting locks on the doors: more locks can conceivably keep out burglars, but it also makes it tougher for you to get in and out. And if there are too many locks it might just make the burglars look for a window to kick in. Since we do this for a living we have made a study of how people crack software and lots of times the protection schemes are easy to get around, just not in the way the original developer anticipated. The trick everyone wants to accomplish is to have the right strength to their protection without generating false negatives (blocking legitimate users falsely). Feel free to PM me if you need more help.
One way to do this is to use a web service where you keep a list of all revoked/disabled licenses (maybe in a database). From your app, you will ping the service from time to time to see if the currently used license has been revoked. If so, the license validation fails.
If you can use a third party system, take a look at CryptoLicensing which supports this exact scenario via its "Notify License Service On Validation" license setting.
Disclaimer: I work at LogicNP Software, the developers of CryptoLicensing.
I have a pawnshop CRUD app written 20 years ago with INFORMIX-SQL/SE (DOS) which is currently running on DOS 6.22 within Microsoft Virtual PC 2007 on Windows Vista. I would like to modernize this app with a GUI, SQL-based engine and retain its existing functionality. It doesn't require any networking or multi-user capability. I would prefer a product which is royalty-free.
I also would like to quickly re-write it with as little effort possible. Which tool would you recommend?
I'm debating whether to re-write my INFORMIX-SQL app with I4GL (character-based) or another Windows/GUI-based tool.
My app is very robust and has some incredible features which my users are very happy with. Only obstacle which is keeping me from effectively acheiving market penetration is, believe it, my app is char-based and I would like to duplicate the same functionality with a GUI. My feeling is that its quicker for a user to process a transaction with my char-based app vs. having to focus a cursor with a mouse, but cosmetics is hurting me!
I would like to know specific instances of limitations, bugs or drawbacks of using another development tool before I invest considerable amount of time evaling another product. Answers to this question could save me a lot of time and money!
If you visit www.frankcomputer.com you can view a video-demo of my pawnshop app. (CAVEAT: The website's in Spanish, use google translate to get a more-or-less decent translation of the text. Start the video at the two-minute mark, with 720p resolution and full-screen to best comprehend my app.)
If I were doing it, I would probably choose to write a WPF GUI in C# with a SQL Server Express backend database. An embedded database like SQLite might work as well. But the main reason I would choose that is because that's what I'm most familiar with. Someone else would likely choose something else...
I might also choose ASP.NET MVC and make it a web application if that were an option (you say that multi-user is not required, but I say it's not required yet).
Also, if you're not the one who's going to be developing it (i.e. you're going to hire someone to build it for you) then I would say that you should find the developer first and let them choose (or at least have a say in) the technology. If you choose the technology up-front then you're simply limiting the field of developers who'll be able to work with you and there's really not much point in that.
I'd recommend you use Python with a PostgreSQL backend. Now some will think this is overkill, but after watching your video and reading your site (I had to use a translator), I suspect the added flexibility is something you will truly enjoy by going this route.
The reasons I'd argue for this solution are:
Python and PostgreSQL are both great products with amazing communities when you need them.
Both products have a bright outlook in their development paths. Since you obviously spent a lot of time and effort tweaking SPACE, I'm betting you will do the same over the next 40 years. So, the tools you choose now need to be there for you as you continue your development cycle.
They are both free with friendly licenses.
Cross-platform support.
Scalability. You can use PostgreSQL installed locally and connect via socket or scale it all the way up to several servers using load balanced connection pooling.
Security.
Data integrity. This includes how easy it is to make your whole environment easy to backup and thus easy to restore in the event of a catastrophe.
Whatever tools you end up choosing. I wish you the best in this project. I can tell you are working on something you truly love and that is something more of us should strive for!!
Based upon your answers and your emphasis upon time to make the changes and that you don't seem to want to change the Application at all but it is being forced upon you by then you should certainly evaluate Genero from 4js.
This will allow you to utilise your existing code but provide a nicer looking front-end. You can also maintain a single codebase supporting both character and "Gui" clients.
Choose whatever language and technology is easiest for you. If you need DB access and a short lead time it sounds like Java or Visual Basic would be best. Both have plenty of free tools to get you started.
The top languages tags in StackOverflow are C# (by a long margin), then Java, PHP and DotNet, followed by C++ and Python. Some of that will be skewed by the Joel & Jeff origin of the site, but any of those is more than capable of the task. Personally, I'd go with Java or Python but I don't like being tied to the Microsoft stack.
wxWidgets and QT might be options for the GUI components.
Of the databases, mysql, SQL Server Express or Oracle Express Edition are all free and robust. SQLite is good enough for most single user applications though. I'd put this at the bottom of the 'importance' list. For small-scale single user apps, you should be able to chop and change DB platforms without much hassle. The biggest relevance would be in how you actually backup/copy/restore data in the event of disk failure or corruption.
This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
Protect .NET code from reverse engineering?
we just develop a application with C# winforms, is there any good encryption method to help us prevent from piracy ?
I saw some software may need hardware support to protect their software, how to implement that ?
Thanks in advance !
Okay, you are mixing up a few different concepts here.
Encryption is geared towards keeping people out of your data.
Obfuscation is used to try and prevent reverse engineering your code.
Licensing is used to make sure the number of copies in use does not exceed the number purchased.
You will want to research both obfuscation and software licensing. Obfuscation because you will want to prevent them from reverse engineering your licensing scheme to either duplicate it or simply bypass it.
From a licensing perspective there are a number of different avenues. Hardware protection means that your app queries a dongle of some type to retrieve a valid key. If the dongle is present AND the key is good, then your app runs.
Software licensing can be a bit more complicated. You'll generally have some type of phone home code which should send an encrypted version of the human readable / type-able key to your licensing server to verify it. You'll want to include some type of additional machine information (such as hard drive serial number) in order to make sure the key isn't being activated multiple times for different boxes.
Sometimes the activation process downloads additional files to make the app run. I hope that gives you a start.
Before you spend too much time and energy stopping piracy, make sure you have a clear set of goals for returns on the work that will justify spending the resources.
It's not a simple as it seems - there's a lot of evidence out there to indicate that most pirates just won't buy your product, no matter how good your security is. If they can't crack it, they'll just go somewhere else or do without. That means stopping piracy brings in very little in additional sales. More than that, pirates may even help to spread your software, so locking them out could actually lower your total sales.
So you need to think about why you're stopping pirates in terms of how it gives you or your company a net gain as opposed to just stopping the pirates from having a gain. This isn't a zero-sum situation, and so the way to maximize your own profits often involves allowing the pirates to have their moment as well. A basic obfuscator or naive product key (it doesn't have to be unbreakable) might be fine to catch some of the low-hanging fruit, but it's probably not beneficial to you to go much beyond that.
You might want to read these as well:
How do i prevent my code from being stolen?
Securing a .NET Application
I think that you're looking for obfuscation?
Protecting the code is done usually through obfuscation (look up Dotfuscator). Licensing protection most of the time is better served by third party tools such as FlexLm or Xheo.
How do you protect non-open source code against leaks?
Today with technologies such as USB drives, Internet drives and E-mail, how do people protect software assets?
Copyright and contract law seem to work for most companies. The technological fix is not always the right one.
In contrast to unwind's answer, I would say that restricting internet access and forbidding useful kit like USB drives is exactly the kind of thing which is going to demoralise and aggravate your employees into stealing your IP. Ultimately if someone inside your organisation wants to steal your IP they will.
I think the better approach is to treat your employees with a little respect and give them no reason to steal IP. If they want to work at a company they'll also want to protect that company themselves.
Then recognise that the value of your IP is seldom in the software itself (which will quickly become old and inert) and instead is usually in the heads of the people who wrote it, and moreso in the collective thought and experience of the people as a whole.
It is not the spoon which bends. It is yourself.
Well ... That's a rather wide-ranging question, here are some of the obvious methods:
Forbid users/employees to use USB drivers. This happens. In some workplaces, the ports are physically disabled (i.e. glued shut).
Don't allow users to freely surf the web.
Use aggressive filtering on e-mail, that removes attachments, or at least limits their size to something very small.
I'm not saying "do this and it's no problem", it will remain a huge problem, and also might become a human problem since the above will also make your employees feel non-trustworthy, which in turn might make some of them more likely to do something they shouldn't, as a protest.
Often the code base is so huge and complex that having it all at hands is useless without the authors/maintainers.
Since this is tagged C#, I'm wondering if you are talking about obfuscating the code or otherwise making it harder to decompile or actually protecting employees from stealing it?
Before going to a lot of trouble to protect employees from stealing it, it might be worth considering if it is a worthwhile process. I mean if you have a new trading algorithm, and a platform that can hit the market fastest then sure, that needs to be protected at all costs. But if one of your employees copies the source of your small web shops in house content management system, does it really matter? Your software might only be a small fraction of your perceived value to the client - there's the support, maintenance etc as well. And if your employee tried to approach your client to sell him the software cheaper, you'd sue him into oblivion.
As already stated above, going to excessive lengths to lock down your systems might only make employees feel like drones and might make them more likely to do something you don't want them to.
Use source control solution that authentication and authorization features are non-trivial to circumvent. That will allow you to segregate your repositories by project, and only one project would be leaked at at time.
I agree with the rest of the answers that technological solutions to source theft and leaks will just slow a malicious user down, not stop them. Best to do some threat analysis and build a social environment where malicious users aren't created or given access in the first place.
As discussed in similar questions here and here I want to protect my code from reverse engineering.
My situation is as Simucal describes in his (excellent) answer here:
Basically, what it comes down to is
the only chance you have of being
targeted for source theft is if you
have some very specific, hard to
engineer, algorithm related to your
domain that gives you a leg up on your
competition. This is just about the
only time it would be cost-effective
to attempt to reverse engineer a small
portion of your application.
I have exactly this situation. A hard to engineer algorithm which is elegant and valuable for our specific domain.
After spending months fine tuning and developing this the end result is very compact (approx. 100 lines of code) and elegant. I want to protect this specific part of the code from reverse engineering or at least make it reasonable difficult.
The scenario is a rich-client application written in C# and I have to deploy this part of the code - I cannot execute it from a webservice.
I think extracting the code and rewriting it in a unmanaged native binary is not an option due to performance reasons (and cross boundary issues).
Initially I wanted to do simple obfuscation but given the small size of the code I don't think this will offer much protection.
Ideally I would like to protect my whole application but there are two main issues that seem to make ordinary obfuscaters and 3rd party packers difficult to use:
The application offers a plugin interface and therefore some assemblies (and interfaces/classes) should not be obfuscated and packed
We still want to be able to get to a real stack trace when receiving error reports - potentially this could be done my mapping obfuscation to the real code.
Setting these issues aside (although I would appreciate any input on this as well), what is a good way to protect a tiny part of my code from reverse engineering? I am not concerned about anyone altering or hacking the code but want to make it difficult to understand and reverse engineer it.
It cannot be done. If your code can be run, then it can be read and reverse-engineered. All you can do is make it a little harder and, believe me, it will only be a little harder. You may not like the fact but most crackers are far better at cracking than anyone else is at making things hard to crack. The amount of effort to protect your code is usually not worth it, especially if it disadvantages your paying customers. Witness the stunning non-successes of DRM.
My advice is to not worry about it. If your algorithm is truly novel, seek a patent (although that got a little harder with the Bilski decision unless you tie it to a specific hardware implementation). Relying on trade secrets is also useless unless you only distribute your software to those that sign contracts that ensure they will not allow unfettered access. And then, you have to have a way to police this. The minute you put the binaries up on the internet or distributed them without a contract, I believe you'll be deemed to have lost trade secret status.
Relying on licensing is also fraught with danger - you may think that you can insert clauses in your license that prohibit reverse-engineering but many jurisdictions around the world specifically disallow those provisions. And the Russian mobsters who whoever are responsible for most of the cracking are unlikely to honor said provisions anyway.
Why don't you just concentrate on making your product the best it can be? The goal is to stay ahead of the crowd rather than lock them out altogether. Being the first to deliver and always having the best product in a competitive group will ensure your prosperity far more than wasting a lot of effort on useless protection (IMNSHO).
This is just my opinion. I may be wrong. I've been wrong before, you only need ask my wife :-)
You should obfuscate the complete code since it gets harder to reach that small valuable part. The smaller the code gets, the easier it becomes to understand it. Most obfuscators should not mess with public interfaces since there are many obfuscated libraries out there.
However I think you should rather convince users that there are no special tricks there instead of trying to hide it. To quote Kaiser Soze, "the greatest trick The Devil has ever pulled is to convince the world that he doesn't exist".
And of course you can always file a patent for your invention and protect yourself legally.
Aside from obfuscation it is almost worthless, even Microsoft (ScottGu etc) basically say that people with the right amount of intent and ability will reverse engineer an application and in .NET a basic defense is licensing and IP instead of trying to guard your code through obscurity or some other means of preventing reverse engineering.
That is part of the reasoning of why they released the BCL source instead of keeping it private.
one option is to use the license key and/or hardware fingerprint to decrypt the sensitive code at runtime and emit it as IL; this will make it invisible to static reverse-engineering tools (e.g. Reflector)
also detect the presence of a debugger and refuse to run in debug mode, except possibly in very limited circumstances (i.e. on your machine)
note that this will make debugging very difficult for you, and nearly impossible for others (if this is an end-user app that's not a problem, but if it is a library or framework for other developers to build upon, that's a problem)
note also that making a copy of physical memory to disk and using offline tools on the memory-dump will reveal your decrypted algorithm, so it is fairly easy to defeat - but far more trouble than most people will bother with
the whole thing is a trade-off between difficulty for you vs deterrence for the few bad apples vs potential loss due to theft/plagarism
good luck, and let us know what you decide!
If your code is that sensitive, put it where nobody can get to it.
E.G. provide a client or web page for people to access some service that exposes your functionality.
That service can sit behind an external firewall and communicate with a backend server behind an internal firewall, where your sensitive code runs.
For extra measure, obfuscate that code.
This would require compromising several layers of security before getting to your code.
You can obfuscate it at the C# or CIL level but what is really going to make it impossible is that the IL compiler is designed to create the most efficient machine code that it can to actually execute.
So, to reverse engineer your algorithm, get the machine code and run standard disassembly tools on it. Trace the data through the system by following it forward from the standard input API calls to the standard output API calls.
Face it, if someone wants it, they can have it.
You can make it hard to casually figure it out. For example, I wanted to see what was in some database managed by a Java application. It turned out that the Java decompile was really messy, full of odd functions and classes and namespaces all with the same names, intentionally trying to hide what was really going on.
I could have fixed up the decompiler I was using so that it renamed everything as A_namespace instead of just A and then the function flow would have popped right out to the Eclipse call tracing graphs.
Instead I just threw up my hands and got on with real work rather than rewriting decompilers.
So, you can hide it from casually interested folks, sure.
Most obfuscators allow you to specify which methods/classes you want to keep from being obfuscated. SmartAssembly for instance let you mark methods or classses with attributes, while others let you select the methods in a UI to exclude from the process. You ought to be able to have pretty fine grained control of the process, and so you can have your cake and eat it.
You will however run into problems if you are using reflection.
I've heard good comments about the Spices.Net Obfuscator. It should be able to greatly increase the time necessary to get at the algorithm.