On opening my executable file in MSIL disassembler it shows information of my application(like literals, function, properties, resources,...) even after I assigned them private.
How can I hide these information from disassembler.
You want to look for an obfuscation solution. Remember that while private members cannot be accessed by other code, they still do exist. However, obfuscation can make it more difficult to discern what your code is doing.
An obfuscater. The information will still be there but the names will be nonsense designed to be as confusing as possible.
Generally speaking you can't. Your best bet if you are worried about someone reverse engineering your code is to consider the following techniques:
Obfuscate the code
Assembly encryption (Note: I have no experience or working knowledge of this or the details of how it works).
Compile to a native assembly instead of a MSIL assembly.
The last option pretty much defeats the purpose of .NET assemblies however it will be much harder to reverse engineer from the native assembly to C# code than from MSIL to C#. The reality is though that if someone has your DLL(s) then given enough effort and/or time the original (or fairly close) source can be developed.
Related
How can I prevent my C# exe from exe extractor like
http://www.telerik.com/products/decompiler.aspx and
https://www.jetbrains.com/decompiler/
You Cant prevent it if you think practically but you can do it in such way that even after extract its don't get in much use or not easy to understand.
It is impossible to make your code impossible to decompile.
Additionally, there's no such thing as "encrypting" a .NET assembly (or any binary) while still maintaining its ability to be executable.
What you're looking for is an obfuscator - a tool that mangles the code enough to make it harder for a human reader to understand. There is one called Dotfuscator.
I think what you're looking for is something like this http://www.red-gate.com/products/dotnet-development/smartassembly/ Which is an Obfuscator designed to make your code Difficult (but not impossible) to Reverse Engineer and Decompile, Please do note however, that it is impossible to prevent Decompilation but it is possible to make the person's life harder trying to decompile it.
i need to use SLGetWindowsInformation in slc.dll but i would rather implement my own version than pinvoking it 200 times on application start up and create the datatypes it need, so is it illegal to disassemble the library and write my own code that leech the behavior of this function
p.s i'm using c# so i won't inline an assembly, ill just copy the behavior
is it illegal to disassemble the library and write my own code
That depends on where you are. There are jurisdictions where reverse engineering is a protected consumer right, and so any attempt to prohibit it in a user agreement is null and void. There are jurisdictions where reverse engineering is not a protected consumer right, and therefore you may only do so if your license agreement allows it.
If you are somewhere where you can reverse engineer legally, there may still be restrictions from other laws (such as patents) on the code produced, though patents can get in the way even if you don't copy anyone and arrive at the idea in an independent manner, along with further innovations (though ironically patents were originally designed to actually encourage innovation).
Really, you're better off avoiding the issue entirely and never look at code that does something while you're trying to do the same thing, unless that code is released under a license that allows it.
i would rather implement my own version
Why not just implement your own version? If you think you can do better than someone else, do you really need to copy that someone else?
This is really a question for a lawyer and not for a programmer, but...
It all depends on the license of the library. AFAIK system dlls are subject to MS license you agree with before the installation and I bet there's a little line that forbids any kind of disassembling. Even with free libraries you should be careful, because most don't like reverse-engineering. If you need to modify a library, it should be open-source with a license, that permits it.
I want to run a thread that checks the memory image of the current executable, for protection reasons. Any ideas how to do CRC on the current memory executable (WinAPI or .NET way)? My app is written in .NET.
Signing your assemblies will give you as good verification as you can get with relation to verify CRC of .Net assembly (see Rodrigo's answer).
If you are worried that someone will patch assembly at runtime you probably worried too much. It requires better understanding of runtime to in memory patch IL for a method that is already JIT'ed compared to simply disassembling your .Net code and fixing it up (including removal of your CRC checks).
If you doing it more for fun than you shoud be able to find base address where assembly is loaded and compute CRC of some sort... or see if pages are marked as modified...
I think that's going to be quite difficult in .NET. When an executable is loaded, it can potentially be split up and loaded into several different regions in memory. You'll need to acquaint yourself with the Window's Executable format:
http://www.microsoft.com/whdc/system/platform/firmware/PECOFF.mspx
as well as the Windows executable loading process.
You'll might also want to concern yourself with depenency dlls as well. You'll be making so many native calls, that you might want to consider doing this in C.
Not much of an answer, I'm afraid.
Any runtime check you do will have the following drawbacks:
False positives. Because this is .NET, you cannot assume the runtime doesn't modify your in-memory code. You may detect a hack where there is none.
Any run-time check you make will be no more secure than the code you are trying to protect. This includes any runtime mechanism you create in your app such as periodic CRC checks, sentinel processes, or even checking with a server where the request can be faked.
You will decrease performance in your legitimate application, where the pirated version will run better without all these checks
You will do nothing to solve patching your EXE.
I understand that you are just trying to make it as hard as possible, even though it's not 100% uncrackable. But the solutions you propose (and likely any solution you can implement yourself) will do extremely little to thwart any average cracker.
Because this is such a demanded feature though, I would look for 3rd party solutions where they have put forth the effort for a sophisticated solution which can be updated as cracking techniques evolve. I cannot recommend any personally though.
I am not aware of a way to do this in .NET.
If you are interested in protecting you executables, you can generate a new key with sn and add it to AssemblyInfo.cs, so that if the application is modified at least it will not run.
Jon Skeet's Miscellaneous Utility Library contains a method to compute the Adler32 checksum on a stream. Its usage would be:
MiscUtil.Checksum.Adler32.ComputeChecksum(stream);
As for creating a memorystream out of the assembly that is currently running... I don't know if that is even possible (or advisable).
Can I encrypt an assembly (using AES/DES) and deploy? I simply don't want people to use Reflector to view the code of my assembly.
Unless you are going to use reflection to load the assembly manually, after it's been unencrypted, no. It will still have to live in unencrypted mode in memory, and any memory dump will be able to get it. You can obfuscate it, which makes reflector mostly useless. What's the real worry behind this?
even if you could encrypt everything, since .net use CIL, somewhere in the process, it will become unencrypted and from that point on, it can be de-assembled into source code.
Take a look at DeployLX CodeVeil. It encrypts your assembly so it can't be read by Reflector. CodeVeil integrates itself very deeply into the .NET runtime so it is not decrypted until just before it's converted to actual x86 code by the just in time compiler. The way it packs the MSIL in your assembly, it cannot be dumped from memory to reverse engineering.
Use some standard exe-packer like upx, aspack, ...
AES/DES won't help you since your assembly must have the key for decryption as well. You'll need some kind of anti-debugging tricks as well. Be aware though - decryption hinders your debugging capabilites of delivered assemblies.
You could start with obfuscation. It's not as strong as exe-packers/encryptors but a good start for managed programs.
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