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.
Related
Apps downloaded from the Windows Store are installed in this location:
C:\Program Files\WindowsApps
If you look inside this folder you can access each application's .exe and use reflector to decompile them.
Currently, my Windows RT application sends a password over SSL to a WCF service to ensure that only people using my app can access my database (via the service).
If my code can be read by anybody, how can I ensure that only people using my Windows 8 app are accessing the service?
Thanks!
In the very general sense, it is impossible. If ever you create anything that is placed on the customer's computer, eventually you will stumble upon someone that will manage to decipher your code and understand how to call your service. You may obfuscate it into insane levels, but still it has to be executable by the processor, so the processor has to understand it. And if it does, then potentially anyone knowing assembly can understand it too. You may smartly obfuscate it so that it will be very time-consuming to cleanup the code from unimportant trash, but still, at some point of time someone will read it.
One of common defenses is in trying to detect who* is actually trying to use your service. This is why all the "portals" require you to "register". This way, the application identity is marginalized and it is the user who provides login, password, PGP keys, etc is checked and verified whether he/she is allowed to actually run your service.
Also, on the OS/framework layer, there are several ways to selectively provide "licenses" to your customers and then in your application you may use keys/hashes from the licenses to authenticate in your service. This may partially remove from the user the burden of remebering the passwords etc, or it may provide an additional authentication factor, or it may simply be a yes-no flag that allows to run the app or not. Still, it will not guard your code against being read. Licenses just help in verifying if the software copy is legit and if belongs to that specific user/computer.
You may act selectively only against 'reflectoring' (or dotpeeking, or ildasming, or ...). Those tools really make the decompilation easy (although the original reflector is now paid software). So, the simpliest form would be to use obfuscator that will make the decompilation impossible or harder - that cuts some percentage of the potential code-readers and you can assume scriptkiddies are gone. You may ignore obfuscators and you may write the service connector in native code (C++, not C++/cli). That will make the code completely un-reflectorable and un-ildasmable, and that will cut off another large percentage of people, but with some will still be left (me and thousands of others, but that's much less than millions).
While this does not give you definitive answer, I wanted to show you that you can only get some "level of hardness", but you cannot make it totally safe from being read. This is why you should focus on making the service access in that way, that showing your code to a stranger on the street does not compromise your security.
Now gettint to your problem: the core thing seems to lie not in the fact that your app uses some secret algorithms, but rather - that you have hardcoded the password in. You see, there's with this approach, they do not need to read your code at all. They just need to listen what data your app sends over the sockets..
Another issue is that everyone uses the same keyphrase.
A hardcoded magic string may be some sort of validation, but never authentication. If you want the app to be register-free, make the registration silent and automatic at first run? Of course, you will just bounce the problem: anyone could read the code and learn how to autoregister, and then they will make a clone.. But, again, like I've said: you never know who's on the other side. Is it your app, or is it an ideal-clone of it? Or maybe is it a clone that uses your own hacked-a-bit libraries to connect to you? If it looks like a duck, and quacks like a duck, it is a duck..
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.
I have application which needs to use a dll (also written by me) which has be independently verified by a government agency. We plan to modify the dll very rarely due to the re-verification which would be required. I want to prevent inadvertent modifications to this dll being picked up by my application. Is there a way to create a hash code for the dll and set up my application to only use this specific version.
This way if someone modified some of the code for the dll, when we build and run the application the app would fail to load the dll (because it had changed).
Any ideas/suggestions?
Cheers,
James
Using Strong Names does part of this and prevent anyone else tampering with your assembly, but doesn't stop you doing it by accident and then resigning.
We use an independent process to start our main application. Before launching the main app, the start up app MD5's all the assmeblies and compares them against a list of those it expects to see, if something has changed, the MD5 fails and the main app is not loaded.
If you really wanted compile time checking, you could probably write a pre-build step that did the same MD5 comparison and failed the build if it had changed.
I know that if you click on a dll Reference in your project you can select 'Specific Version' in its properties and set it to True, will this not do what you are after?
Phill
As Colin mentioned Strong Naming your assemblies will be the key as this includes both versioning & signing the assembly. The following couple of blog posts may help you with strong naming & versioning:
http://www.csharp411.com/net-assembly-faq-part-3-strong-names-and-signing/ (might be also worth reading the next part of this about the Global Assembly Cache)
http://philippetruche.wordpress.com/2008/08/12/net-assembly-versioning-lifecycle/