This is what I'm trying to accomplish:
I have two applications. One is a client application the other one would be a compiler. Client uses encryption and for safety reasons I would like the users to be able to run the 'compiler' application, that would hard code a security key inside already compiled binary, so each client has its own encryption key stored inside of it. Is this even possible or the solution would be crazy? Thanks.
Sure all you are talking about is rewritting the MSIL code. Microsoft does this all the time with code contracts. Here is a link to an article explaining how: http://msdn.microsoft.com/en-us/magazine/cc188743.aspx
Another example: http://www.codeproject.com/Articles/20565/Assembly-Manipulation-and-C-VB-NET-Code-Injection
If your assembly is strongly signed, you cannot modify it. You cannot save back a modified .net assembly to disk. However, you can build your assemble ( As Kevin stated) to be able to modify the code loaded in memory at runtime. It will not affect the image on the disk and the modification will be run at every time the application is started.
Related
I got .net dll (originally, written in C#) which is being updated / released from time to time. There's a small part of code I need to modify inside this dll which suits my usage needs.
I'm able to do these changes every time using dnSpy but I don't like doing it manually every time.
Is there possibility to automate the process of code change inside dll and how can it be done?
Is it easier to convert dll to IL and change IL instructions and then compile it back or should I do full decompile to C# and then recompile it back using Roslyn?
The code I change is always the same and is changed to the same result code.
A possible solution for what you want to achieve is Mono.Cecil.
With Cecil, you can load existing managed assemblies, browse all the
contained types, modify them on the fly and save back to the disk the
modified assembly.
This library is being used by tools like coverlet which change the assembly on the fly in order to be able to compute code coverage.
That being said, I highly agree with Marc Gravell comment that at the first glance this seems to be the wrong approach and a change in design would be more appropriate.
I am developing a software in C#. On user dashboard there will be some icons of our applications when a user clicks a icon the application ( exe file ) will be downloaded from our server and will be stored in user's computer somewhere. I want to make this applications ( exe files ) only be executed from this software and not by directly accessing by file system. Is their any solution for it so that the user can only execute application through the software and not by directly accessing it?
No, that is completely impossible*. No matter how good your encryption is, no matter how obfuscated your program is, people will recover the keys and break it. Not to mention the fact that to execute code, the computer has to have a copy of the unencrypted code; and when there's a copy, another copy can easily be made. Don't bother.
* The closest thing you can get to it is probably implement an entire new language and run it in your VM, which is heavily obfuscated. However, as it is well-known, there is no such thing as irreversible obfuscation. Also, this would be really slow, as you could never compile it for fear of recovery of the contents from memory, and you'd have to create a new compiler, since any resemblance to native code would make it trivial to decipher.
Great question.
You can decrypt assembly to memory by wrapper, which gets key from server after veryfing the license, and then wrapper will create domain and execute this assembly in it.
To avoid debugging software you can use Confuser from codeplex/com
Is it possible to create an app in C++ or C# so I can patch a exe file for copy protection purposes?
So if a user has an account on my website with the software tied to it, I can require them to enter a key which is checked with the database and then execute or show an error.
When I say "patch", I mean applying to an already built/compiled exe. Thanks for the help. :)
Its easily possible, many packers and protection systems like Themida do this, however, things like this can be easily cracked, thus you need to evaluate the effort vs reward required for someone to hack your program.
However, to directly answer your question, your best bet is to hook the code entry point defined in the PE and have it redirect to your checker (OS dependant). UPX is an opensource executable packer, and should provide a good base to use or point of reference asa it hooks the entry of the executable to run the unpacking engine. You can also find a few articles on packers and protectors here.
Depending on how complicated your copy protection is, "patching" may be in the simplest case just boiled down to writing a few bytes at selected offsets in the protected EXE file. This project may be interesting.
I've 2 .NET c# application without any security features. I wanted to implement a security mechanism myself which i will describe below, and i would like your comments if this is would work or there are things which i dont know.
So, when i need to run MyApp, i run AuthenticationAPP, this app will ask me for a security code.
IF code is correct -> load MyApp;
ELSE -> do not load app
What i was wondering is if there is a method to bypass this kind of mechanism and therefore transforming my authenticaitonAPP in uselessAPP very easly or if those methods are hard to implement.
thank you for any ideas/clarification.
You need to prevent the .net runtime from loading and executing any of the assemblies in MyApp. To ensure that you need to specify code permissions for your assemblies.
The code permissions has to check for a condition that can only be set correctly by AuthentificationAPP. It could something as simple as an encrypted call parameter from AuthentificationAPP to MyApp.
Then you have to make sure that your code can't be reverse engineered by a third party. So you have to look into code obfuscation and signing.
I think you can add code permissions on assembly level. So it could be that all you need is to add a single source file with assembly level code permissions and call context verification to each of you 1000 programs and the recompile those.
There exist different wrapping protection solutions like VMProtect, ASProtect, Armadillo etc.
Maybe they will fit your task.
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).