Are there any ways to encrypted a project in ASP.NET, so my customers can not change change the function where it checks the license code?
No, it is not possible.
You can implement certain things that make it more difficult for customers to reverse or alter your program, in order such that it becomes cost-prohibitive to attempt such reversing or altering. But you cannot prevent them, if they are sufficiently determined, from reversing or altering your program.
Take a look at Eziriz's .NET Reactor. It's pretty good at protection. From ther site:
.NET Reactor prevents decompilation by
a variety of methods which convert
your .NET assemblies into processes
which no existing tool can decompile (
and which are also very likely to
prevent decompilation by any future
tool). .NET Reactor builds a native
code wall between potential hackers
and your .NET assemblies by producing
a file which cannot be understood
directly as CIL. Because the CIL in
your assembly is emitted intact only
at run time or design time (in a form
in which the source is completely
inaccessible), no tool is capable of
decompiling .NET Reactor protected
assemblies.
The native code wall created by .NET
Reactor between the hacker and your
source includes industry leading
NecroBit technology, which is
exclusive to .NET Reactor. .NET
Reactor's protection has never been
broken since the first release in
2004. These technologies make reconstruction of your source code
more difficult by so many orders of
magnitude that NecroBit is by far the
most effective protection you can use
for .NET assemblies.
Not if the customers are persistent and have even a modicum of skill. Obfuscation can only get you so far. Any .Net assembly can be decompiled.
See here for info:
https://web.archive.org/web/20210802164013/https://aspnet.4guysfromrolla.com/articles/080404-1.aspx
Added
Also, see this previous question:
.NET obfuscation tools/strategy
use Dotfuscator Community Edition that ships with VS. Also put checksum function to check if your EXE is changed or not.
Related
I've written a class in VB.Net that is consumed in an ASP.NET Web Application running IIS7. I use .NET Framework 4.0. The class performs a REST request to an online and retrieves an XML response containing strongly typed data.
This class also performs caching using an SQL Server database. The class is compiled to a .DLL and referenced by the Web Application. It works excellent and now I need to know how to make the class thread-safe.
I have no experience with making code 'thread-safe'. I don't know where to begin in determining whether or not it is thread-safe. Am assuming, because I didn't pay attention to this during development, that it is NOT thread-safe and that since it the web application will be used by many users at the same time that it must be payed attention to.
Can anyone point me on how to test for thread-safety? Are there any resources online that that will give me some ideas? Are there any rules of thumb that will tip me off as to where my main concerns are?
The easiest possible thing you can look out for is the use of "static" (C#) or "Shared" (VB.NET) variables. If these variables can be modified throughout the lifetime of the application you will likely run into threading issues which can really often result in "random looking" problems.
I would also be concerned about how you are doing the caching in your database as multiple .NET threads hitting SQL (for the cache) could cause issues as well depending on how its designed.
Bottom line is you are likely going to need to learn more about threading if you want to be sure this is going to not have issues. Probably the best book I have ever read in terms of simple to very complex C# topics is C# 4.0 In a Nutshell I would take a look at that book especially the threading chapters. (Seriously read the whole thing though) If you get that read through and have a good understanding of the concepts mentioned you should be fine.
i was reviewing some other posts here and found some options that I have done some research on, but haven't quite found the information i'm looking for, such as reliability and its request capacity and speed, etc.
So far i've found 3 possible methods of (3DES/AES) encryption for ASP.Net/Classic ASP compatibility are:
1.Capicom.DLL
But how much work is involved when using the .Net app, I've heard it places extra variables in the encrypted data, so it makes the process a bit more troublesome in .Net.
It is distributed by Microsoft, but how well can this function operate under heavy workloads?
2.Chillkat
Third party component, never tried it, and don't know how well it can handle large workloads. I have used a third-party one before, and it has just crashed out when the workload got too heavy on the server.
3.ASP.Net web service using .Net library
Use HTTPRequests from classic asp to get the data. This is a possibility, but i'm just thinking something that was internal, like a DLL, would be quicker and more efficient/reliable?
Any help with this would be appreciated. Thank you.
If you're using ASP.NET C#, there's an existing namespace which you can call that does the security stuffs for you.
System.Security.Cryptography Namespace
Now that Visual Studio 2010 RC is released I was wondering if anyone knows what pros/cons there are to upgrading my existing ASP.NET applications to target the .NET 4 framework? (Apart from waiting until the Final release which should be even more stable)
If you are not going to rewrite some parts of the application to use new features in ASP.NET 4.0, I don't think there are many benefits. Unless they introduced performance optimizations for already existing functionality, but I don't think you would get those automatically without modifying code.
Otherwise there are plenty of goodies like URL Routing, SEO optimizations, ViewState performance, etc.
At least, you must check if your webserver have support for ASP.NET 4.0 application pools.
Pros: You will be ready when it is final
Cons: Be ready for quite a few issues, if you have the time.
Here is a list and overview of some of the issues people are encountering and some praises:
http://weblogs.asp.net/scottgu/archive/2010/02/08/vs-2010-net-4-release-candidate.aspx
And my favorite resource as it is impossible to give you a break down of Pros and Cons considering what may be a pro for me, may be a con for you and vice versa:
http://social.msdn.microsoft.com/Forums/en-US/category/VSPreRelease,netdevelopmentprerelease,visualstudioprerelease,vstsprerelease
http://blogs.msdn.com/architectsrule/archive/2010/02/19/10-4-episode-41-downloading-and-installing-the-visual-studio-2010-release-candidate.aspx
If you're going to be using C# for your development, then here is one big thing that the next version of the framework and C# will have; Dynamic Types:
From Scott Hanselman's blog:
C# 4 (not 4.0, the marketing folks say it's .NET 4, etc.) adds the dynamic keyword. I've explained this saying:
"There's no way for you or I to know the type of this now, compiler, so let's hope that the runtime figures it out."
The key point here, in bold, because it's significant is: having the type dynamic means “use my runtime type for binding”.
This is something quite different from the current version of C# and could have some pretty signifigant ways in which code is written. So hidden in all of the hoopla, the new framework does have some added value compared to the current frameworks.
Hope this helps some.
You have the go live license --> you can use all new asp features in production.
But you will have a few problems with VS.
I have looked through the related questions, and none of them have provided me the information I am looking for.
Currently the team I work on does deployments of individual .aspx (and .aspx.vb) files for bug fixes/enhancments. I am trying to affect change, as I really believe that deploying the "whole compiled site" is less error prone. As this is a significant change from the way things have been done, my suggestions have ben met with significant resistance.
As my google-fu has not been up to par lately, I was hoping the SO community could either tell me that I am off my rocker, and that there is nothing wrong with moving individual files, or point me to some really good resources which would allow me to make a stronger case.
Edit:
This has all been great info, and reinforces the arguments that I have already been making, can anyone argue the other side?
Deploying individual files for bug fixes and deployment is not a wise strategy. It sounds like you need a comprehensive build and deployment process. That doesn't mean it has to be complicated as there are some good tools available nowadays.
Build and deployment can get detailed, so as a minimum start try taking a look at the Microsoft Web Deployment Tool (http://www.iis.net/extensions/WebDeploymentTool). Install the tool on your build server and install it on your deployment server. Stage your ASP.NET content locally using the Visual Studio Publish command, then use the above tool to synchronize the entire package on the deployment server. I like this approach because it can be completely automated. When doing builds and deployments, aim for complete automation to reduce potential errors.
This is the bare minimum, but you will at least be certain that when specific files are changed, they are ALL synchronized on the deployment server.
Personally to me rolling back immediately is most important. Again website projects are very hard when it comes to track the changes.
you can find a good detailed comparison here. I am reproducing the article here.
1) Deployment. If you need in-place deployment, this model is perfect. However, it's not recommended since you are exposing your logic in clear text. So, anybody who have access to physical server can mess with your code and you never going to notice this. You can try to make precompiled web site, but you going to end up with a lot of dll and almost untouchable aspx files. Microsoft recognized this limitation and released Web Deployment Project tool.
2) You need to keep track of what did you change locally and what did you upload to production server. There are no versioning control. Visual Studio has Web Copy tool, but this tool fails to help. I had to build my own tool, which kept track of changes based on Visual Source Safe.
3) When you hit F5 for debug execution it takes merely 2 minutes to compile and execute whole project. Of course you can attach debugger to existing thread, but this is not an obvious solution.
4) If you ever try to generate controls on a fly you will hit first unsolvable limitation. How to reference other pages and controls. Page and control compilation happens on a per directory basis. On best case you going to get assembly for each directory, in worst each page or control is going to get its own assembly. If you need to reference another page from a control or another page you need to explicitly import it with the #Reference directive.
So for,
customControl = this.LoadControl("~/Controls/CustomUserControl.ascx") as CustomUserControl;
You need,
But what if you want to add something really dynamically and can't put all appropriate #Reference directives? Or What if you are creating server control and it doesn't have ascx file, so you don't have a place for #Reference ? Since each control has it's own assembly, it's almost impossible to do reflection.
Web Application Projects which re-appeared in Visual Studio 2005 SP1. They solves all issues mentioned above.
1) Deployment. You get just one dll per project. You can created redistributable packages and repeatable builds.You can have versioning and build scripts.
2) If you did code behind change you can upload just one dll. If you did aspx change you can upload just aspx change.
3) Execution takes 2-3 sec maximum.
4) Whole project is in one assembly, which helps reference any page or control. Conclusion. For any kind of serious work you should use Web Application Projects. Special thanks to Rick Strahl for his amazing article Compilation and Deployment in ASP.NET 2.0.
I agree with Rich.
Further information:
Deploying your SOURCE code ala the .vb files to the server is a BAD idea. Compile it. Obfuscate if you can, just don't deploy straight source. Imagine an attacker which gains access to the system. They could easily change your code and you might not ever notice. Yes, you can use a tool like reflector to decompile. But it's really hard to decompile a full site, make the changes you want, and put them back into production.
Deploying a single file might very well cause some type of problem in a related module. I'm guessing you guys don't really do QA. Tell them it's time to grow up.
Compiling your site will reduce JIT (just in time) compilation. Think performance.
I'm also going to guess that pretty much everyone has production server access. This is bad from the company's perspective as you have no controls in place. What happens when an employee decides to cause some havoc before leaving?
What you are describing is inline with Cowboy coding. Sure, it's fun to ride to the rescue but this style frequently blows everything up.
It's bad for rolling back. If you deploy as a web site vs web app, yeah you can do quick patches of one or two files, but what if you ever need to roll back to a previous version? Good luck tracking down all the files that were updated to make the new version. I much prefer the concept of a "version" for organizational reasons, and the compiled web app is much more inline with this than a "website" project.
We had this dilemma and ended up going with the compiled version mainly for the security reasons. If your site is external facing you could be compromising your security by allowing the vb files to be out there in plain text. I realize one could still get your code if they really wanted to but it would be an additional hurdle they would need to go through. If you use Visual Studio as your development environment you can publish the site pre-compiled and check the named assemblies option when publishing and this will essentially create a dll for each aspx page so you can do the one off page changes if necessary. This was a great feature we found as we were constantly updating the whole site and there were times when things would get updated that shouldn't. After using that feature we no longer had updates getting pushed that shouldn't. As far as rolling back I hope your using some type of Source control / versioning system. Team Foundation Server is great for versioning/source control but it is quite pricey.
What is the best deployment strategy depends a lot on what kind of environment you are working in, and what kind of developers you are working with.
Visual artists that started with graphic layout and worked towards programming are much more in tune to individual page generation and release. Also the .aspx.vb files are simply server side scripting, not really programming.
Programmers usually start at the command line and branch out to environments such as the web and understandably feel that good programming practices should be applied too the web, including standard test and release cycles (and compiled code).
If the site is in constant flux the individual pages would make more sense, but if you are required to deliver an installation package to your production group msi files are the way to go, since they can be easily backed out if necessary.
If you evaluate what your groups needs are, which includes the varied experience of everyone in your group, you should be able to convince either yourself or the group. This is not a matter of which is better, but which provides the best business model.
Scenario:
Let's say I have four very similar applications (i.e. most of the functionality is the same, but they are different enough to justify each being seperate applications).
What is the best way to re-use the common functionality code between them? COM+? Web services?
In general I'd typically just have the code in a seperate project (dll), but anytime that's updated, the file has to be updated for each ASP.Net application, and wasn't sure if there was a better way of going about it.
Thanks!
If possible, you can create a Visual Studio solution with a DLL Project and a number of Web Application or Website projects. The web projects would have a "project" type reference to the DLL project, and everything would build at the same time. Then you could use the "Publish" tool for each of your web projects as needed.
If all the apps are on the same virtual server, consider placing the shared assembly in the GAC. This allows you to diverge versions should the need arise, and keeps everything in the same place as a bonus. Downsides: this assembly runs with full trust and you should use policy and CAS to ensure there are no elevation of trust leverage points for external untrusted assemblies. You'll also need to learn about the [AllowPartiallyTrustedCallers] attribute.
As for the other choices, COM+, meh, a bit heavyweight. Good for transactional stuff. Web services, not so good for data heavy services, but if done right, can be fairly maintainable. The more it's shared, the better the pay off.
You can have your project, but instead of adding the common dll to the project reference add the common project to all solutions and then add a reference to the common project.
This way you can have one project on any number of solutions and you have your problem solved ;)