i am creating my own CMS frame work, because many of the clients i have, the have same requirements, like news module, newsletter module, etc.
now i am doing it fine, the only thing that is bothering me, is if a client wants to move from my server he would ask me to gibe him his files, and of course if i do so the new person who will take it he will see all my code, use it and benefit from i, and this is so bad for me that i spend all this time on creating my system and any one can easily see the code, plus he will see all the logic for my system, and he can easily know how other clients of mine sites are working, and that is a threat to me, finally i am using third party controls that i have paid for their license, and i don't want him to take it on a golden plate.
now what is the best way to solve this ? i thought it is encrypting, but how can i do that and how efficient is it ?
-should i merge all my CS files and Dlls in bin folder to one Dll and encrypt it, and how can i do that ?
i totally appreciate all the help on this matter as it is really crucial for me.
you should read this
Best .NET obfuscation tools/strategy
How effective is obfuscation?
In my experience, this is rarely worth the effort. Lots of companies who provide libraries like this don't bother obfuscating their code (Telerik, etc).
Especially considering what you are writing (CMSes are everywhere), you'd likely see more benefit from your time spent implementing features that put your product/implementation in a competitive advantage and make companies see that the software you are capable of writing has value, rather than the code itself.
In the end, you want to ensure you are a key factor in making software work for a company, not the DLLs you give them.
You'll need to precompile your site and obfuscate dlls.
Visual Studio has something like Dotfuscator Community Edition shipped with it. You could give it a try.
Of course, HTML output, CSS declarations, database structure and stored procedures code cannot be encrypted.
You can however try to compress CSS which will also reduce its readbility by humans.
Check here: The best approach to scramble CSS definitions to a human-unreadable state throughout an ASP.NET application
One other idea would be to use a frame in your HTML and put the most of the site pages inside of it. This way, it will not be visible when doing "View source".
Or just state it clearly that you offer whatever you're doing as a service and do not provide source codes of your work. I somehow doubt salesforce would be willing to give their sources to anyone who asks.
Related
I just found out that even though I obfuscate my application it can still be cracked using code injection. This pretty much makes C# completely useless for me. Is there really no way to protect or make the process very difficult to do? Do 'crackers' have to know any class names etc. to do this? Thanks!
UPDATE: I'm trying to protect a binary (exe) not code.
I've read somewhere on here from several users that whatever the code is written in, it can be decompiled. Think of it like this, how else would the system know how to run the code? It is the same concept.
Usually though, most developers(that I know of) don't worry so much about this. Of course, this is a good reason not to have any sensitive details within your code but rather somewhere else.
If you're worried about protected industry secrets, it's impossible to send a computer the right instructions, but expect those instructions cannot be read by a capable person. If your goal is to stop somebody from modifying your EXE, why not simply sign your executable?
http://blogs.msdn.com/b/shawnfa/archive/2007/01/10/combining-strong-names-with-authenticode.aspx
Any of the .NET languages, and Java can be de-compiled. This includes .Exe and .dll files. What you will need to do is get an tool that obfuscates the code.
I've listed one below for you so you can get an idea:
http://www.red-gate.com/products/dotnet-development/smartassembly/
Are you sure your code is worth the trouble for someone to do that? Very very few applications are.
I just had a conversation with my manager relating to checkin\out policies on a project I'm currently working on. Basically I tried to edit a file that was already checked out by another developer and I couldn't - I asked my manager why we couldn't edit the same class at the same time and he gave this reason for turning that functionality off: We had a lot of problems with developers editing the same Form (or anything visual done in the designer) and then cheking it in. Merging the changes in the designer generated code was a lot of hassle...
As I'm writing this I'm struggling to see what problem they were having - surely they were getting the latest code before trying to check something in??
Have any of you come across problems with editing the same Form (or something in the designer) as another developer and then checking into TFS? If so how did your team get around the problem? Did you also turn off the ability for developers to work on the same class?
EDIT: The following post (found here) is exactly the problem my manager was describing. Anyone know of a simpler way to resolve the issue than the ones in that post?
I would argue that the solution to your problem would be to establish best practices for source code modification.
Discourage people from going into UI code and arbitrarily jiggling the components around in the designer. Any reasonable UI modifications should be easily mergeable. Your best bet is to try and educate people as to the best way to merge in any given source control system. Also, as helpful as the designer is, ignorance of what code is being automatically generated in the background will be significantly detrimental in the long-term.
People who insist on locking checked-out files for the reasons you stated in your post typically wait long periods of time to check their code in. Naturally, the more time passes, the more code gets modified, so it makes merging difficult for these people. Checking in early, often, and incrementally requires people to think about their changes in stages, and for some coders, this is a rather painful cultural/psychological adjustment.
I've just checked back through the histories of some of my .designer.cs files and I can't see any changes that would cause a merge problems. There were no wholesale rearrangements of code for example.
Another thing to consider is to make sure that everyone does a "get latest" at regular intervals then any individual merge/resolution isn't going to be that great thus minimising the chances of anything going wrong.
It might also be worth investigating a 3rd party merge tool. There are plenty around.
Now it could be that the changes I've done are simple compared to the ones you've got so you should take my anecdotal data with a pinch of salt.
It can cause problems (in general) when a lot of people are editing UI concurrently. The merge logic will do a fine job merging things, but in a lot of cases the UI is drawn according to how things are added to the form. Your UI can get messed up quickly.
I don't know if I would use this as an excuse to enforce exclusive checkouts across the board, though. I might go from a (non programmatic) policy standpoint that says shared checkout for business logic, but exclusive for UI changes.
I would couple that with a strong MVP, MVC, or MVVM approach, though, which should limit the number of people that have to touch the UI concurrently.
As others have alluded to, keep one of the seminal rules of SCM in mind: merge early and often, and your problems are reduced. (along with that is "always get latest before you start working on the code).
Quite a few people have really taken interest in the dll's ivé sent them, and they're not the type that should be given away for free too often...
I was just wondering, if I were to sell my components, user controls etc, how would I go about protecting them, in terms of ownership/encrypting code (if possible) etc.. What steps have you taken to help prevent people using yours without paying for them?
You can use any commercial obfuscater which encrypt your functionality and giving error if decompile.
Here i have the whole list which are available in market.
I used many of them some are just encrypt string, public method, private methods,properties and all.
Just go through it.
see the whole list and article
The only truly secure way to protect your dll is not to give it to them. Expose it instead via a web-service etc (obviously this doesn't work in all cases). Every obfuscator can be broken with patience. Think how much the games industry spends on this, and things are broken / reverse-engineered within days, sometimes hours.
"Lawyers" may serve as a layer of protection, and obfuscation will certainly discourage idle browsing. But a determined hacker (for example, for commercial illegal spying) will be able to get at your code eventually.
I guess you simply need to weigh the costs and benefits...
Well, I will definitely put my copy right,company name and production name information to my DLL. Whenever anybody use it,those information still appear on my DLL. And if possible,I will try to use Dotfuscator tool from visual Studio which helps to obfuscate my DLL.
I'm a beginner so if there is a terminology for what I'm doing I don't know how to search for it. So forgive me if this has been asked before. So here is what I do. Before I make any major code changes, I make a copy of the projects folder and call it "project v6" for example. Then if I really mess things up and cant find a way to undo it, I just go back to the previous folder. This has been working well enough for me but sometimes I forget to do this and have to take 2 steps back. Is there an easier way to do this than the way I am now?
There are many source control tools, which keeps track of all this stuff. Git, subversion, cvs (used wikipedia links, which explains each with more detail. This can be done much more easily once you get used to them.
In both there is commit what you've done to a server (which may be your own machine). But you can store your code somewhere else (so you don't lose everything, in case your hard disk fails or something like that). Google Code is a good example.
Git - harder to use, but very powerful (more used when there are lots of people working on the same project, and even the same file sometimes), much easier to deal with branches and stuff like that (if you don't know what that is, so you probably don't need it yet)
svn (subversion) and cvs - simpler to use, with fewer resources available. Probably enough for your needs
What you're looking for is revision/source control software.
http://en.wikipedia.org/wiki/Revision_control
I absolutely agree you need to start using a source control system. Even if for no other reason than to ingrain good work habits, you will be required at some point to use a source control system.
Having said, if your IDE is Visual Studio (non-express editions) you can use an addins to:
zip the sln for you, such as codeproject - zipstudio
or
keep a "local file history à la Eclipse" visual local history
How do I protect the dlls of my project in such a way that they cannot be referenced and used by other people?
Thanks
The short answer is that beyond the obvious things, there is not much you can do.
The obvious things that you might want to consider (roughly in order of increasing difficulty and decreasing plausibility) include:
Static link so there is no DLL to attack.
Strip all symbols.
Use a .DEF file and an import library to have only anonymous exports known only by their export ids.
Keep the DLL in a resource and expose it in the file system (under a suitably obscure name, perhaps even generated at run time) only when running.
Hide all real functions behind a factory method that exchanges a secret (better, proof of knowledge of a secret) for a table of function pointers to the real methods.
Use anti-debugging techniques borrowed from the malware world to prevent reverse engineering. (Note that this will likely get you false positives from AV tools.)
Regardless, a sufficiently determined user can still figure out ways to use it. A decent disassembler will quickly provide all the information needed.
Note that if your DLL is really a COM object, or worse yet a CLR Assembly, then there is a huge amount of runtime type information that you can't strip off without breaking its intended use.
EDIT: Since you've retagged to imply that C# and .NET are the environment rather than a pure Win32 DLL written in C, then I really should revise the above to "You Can't, But..."
There has been a market for obfuscation tools for a long time to deal with environments where delivery of compilable source is mandatory, but you don't want to deliver useful source. There are C# products that play in that market, and it looks like at least one has chimed in.
Because loading an Assembly requires so much effort from the framework, it is likely that there are permission bits that exert some control for honest providers and consumers of Assemblies. I have not seen any discussion of the real security provided by these methods and simply don't know how effective they are against a determined attack.
A lot is going to depend on your use case. If you merely want to prevent casual use, you can probably find a solution that works for you. If you want to protect valuable trade secrets from reverse engineering and reuse, you may not be so happy.
You're facing the same issue as proponents of DRM.
If your program (which you wish to be able to run the DLL) is runnable by some user account, then there is nothing that can stop a sufficiently determined programmer who can log on as that user from isolating the code that performs the decryption and using that to decrypt your DLL and run it.
You can of course make it inconvenient to perform this reverse engineering, and that may well be enough.
Take a look at the StrongNameIdentityPermissionAttribute. It will allow you to declare access to your assembly. Combined with a good code protection tool (like CodeVeil (disclaimer I sell CodeVeil)) you'll be quite happy.
You could embed it into your executable, and extract and loadlibrary at runtime and call into it. Or you could use some kind of shared key to encrypt/decrypt the accompanying file and do the same above.
I'm assuming you've already considered solutions like compiling it in if you really don't want it shared. If someone really wants to get to it though, there are many ways to do it.
Have you tried .Net reactor? I recently came across it. Some people say its great but I am still testing it out.
Well you could mark all of your "public" classes as "internal" or "protected internal" then mark you assemblies with [assembly:InternalsVisibleTo("")] Attribute and no one but the marked assemblies can see the contents.
You may be interested in the following information about Friend assemblies:
http://msdn.microsoft.com/en-us/library/0tke9fxk(VS.80).aspx