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
Related
I'm developing an application in c# which uses an .xml file to obtain information that is used inside the logic of the app. When a new version of the app is launched, a setup is created (using Inno Setup Compiler) and after successfully installing the setup, the .xml is placed inside the setup files of the app. This .xml file contains about 200 objects with 4 properties each of sensitive data.
I got asked to launch a customer version of the app, and a requirement for this version is to remove the access or manipulation of this .xml file, since it contains sensitive data that the customer should not be able to see or manipulate.
My senior engineer told me to simply implement the information inside a list in the source code, so that the use of the .xml file is removed and the customer can't manipulate this info once installed the app, as it would be hidden inside the source code, but this seems really inefficient for me and i would need to change a lot of logic about the use of the .xml file inside the app for this to work.
Is there a way to create a setup of the app and hiding this file in the setup files so it cant be manipulated by the customer?
If there isn't, what approach could you suggest me to do? Or do i have no options but to do this the hard way?
If you want to make it harder for the end user to modify the information, while still keeping a separate configuration file that won't require code change of the application itself, you can sign the file and have the application verify the signature.
A simplest way is to to calculate a hash of a file and "secret" value. Of course it is hardly tamperproof. But in the end, there's no tamperproof way to prevent a user from manipulating data on his/hers own computer. It's only about how hard you want to make it.
A better way would be to use a proper certificate for the signature. The application will know only the public key and will use it to verify a signature created with a private key, which will never leave the development team.
From a theoretical standpoint, if your program can get hold of the data, then a user with full control of the computer on which the program is running can also get hold of the data if they try hard enough. That means you can make it difficult for them, but you can't make it impossible. So if that's what you're trying to achieve, you need to be quite clear about the limitations of the approach.
How difficult should you make it? Well, if it's purely a commercial risk, you should make it hard enough that the cost of getting the data is greater than the benefit. If the risk can't be measured in that way, for example if there are legal requirements for you to protect the data, then that isn't going to be good enough.
For some situations, it's probably enough to encrypt the XML file, and bury the decryption key deep within the logic of a compiled program written in a language that doesn't allow easy decompilation. That's likely to be better than simply burying the XML data within the compiled program, which is what your senior engineer is suggesting. But her suggestion may be OK too. It really shouldn't be too difficult to change the program logic from reading an external file to reading a string constant within the program.
I'm trying to release a software I wrote to multiple Computers in several different locations. The Program itself is a Windows Forms Application. To install it I added a setup project which also works perfectly fine. All files get copied to the right folders and the choices the user can make during the installation work without a flaw. But:
The only problem is that the config file, which contains sensible data like for example the SQL connection string, gets also copied / installed on the target computer.
Is there a way to store this data unreadable for the user in the application?
I thought about just writing it in a class since the application gets obfuscated but I'm not sure if this is secure enough and if this really is a way to go...
Any help appreciated!
You might cryptographically secure the sensitive file with a private key embedded in code itself with an obfuscation scheme. This is better then embedding all sensitive config data in code since you would not need rebuild-test-release your application when only your config changes.
Theoretically, If an application running in user mode can -anyhow- access the plain sensitive data, so can the user(de-obfuscation, memory dump etc). Since all information needed to generate or decipher the sensitive data is present offline (code, disk, memory), one -with enough skills- can determine the decryption scheme by examining the code (even the machine code)
Think of an application as a user with rapid calculation and massive memory skills so it can de-obfuscate your code on the fly and do the needed calculations to decrypt the "safe" data
It's impossible that the config file/data is only readable for the program but not for the user, because you can decompile the program and search for the conection String, but you can make it to the user as hard as possible.
You can also write a php script or something else that checks the request and can block requests from specific ips if the script notice that the user spam requests or send rubbish data.
Perhaps it is enough to you also, that you create a new database user which limited write and read permissions has, so that the user didn't have the opportunity to do bad things with the Connection String.
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.
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.
Does anybody know the solution for this? I create an exe file of my software. After first installation I have to disable the exe, so it cannot be run again because when someone purchases the software from me they can install it only once.
To do this you'll need to store something somewhere, that something could be:
A file
A registry entry
A call to a web service you own that stores a unique identifier for the machine, and is checked on subsequent installation attempts (Note: If you choose this method you must be clear and up-front with your users that it's what you're doing).
Bear in mind that a determined user will be able to circumvent file and registry methods and also quite possibly the web service method. The former two by using something such as Process Monitor to identify the files/registry entries you're writing to and clear them. For the latter, by using something like Fiddler to identify the web service calls you're making and replacing the responses with ones that allow them to bypass your protection.
Remember, ultimately the user can disassemble your code and remove the protection mechanisms you've put in place, so don't rely on them being 100% un-breakable
Forget it, mate. It's software - you absolutely cannot enforce something like that because the user has complete control over the environment where the binary runs, including reverse engineering, virtualization, backups etc. etc. And the ones who you want to foil are precisely the ones who will go to any length to thwart any protection measure you could invent.
No, the only thing that works is to force an online connection and register, on your system, the fact that a particular binary was installed once, then forbid it the next time. That requires you to make each installer different and have a cryptographically strong key generator, and it's still susceptible to replay attacks - but it's the only thing that is not useless by definition.
(Well, either that, or make your software so insanely great that people will fall in love you and want to give you the money. That solution is probably even harder.)
You could store the installation path in the registry or some secret location and have your .exe check that if it has started from a location different than the one stored, to simply exit, as you probably don't want to tell the user what you are doing.