I have a dll with an "authentication" method in it that checks if a password is valid, like this:
public static void AuthenticationExample(string password)
{
if (PasswordIsValid(password))
this.locked = false;
}
To prevent the password from being "cracked" by a loop, I want the method to crash the entire application if authentication fails, like this:
public static void AuthenticationExample(string password)
{
if (PasswordIsValid(password))
this.locked = false;
else
Crash();
}
Is there a way of doing this?
Alternatively, what is a better way of protecting a dll?
CLOSING WPF:
You can just call the main window and close it or throw a custom exception.
PASSWORD PROTECTION:
I had same issue. Finally, understood that whatever you do, it can be cracked. Nothing is fail proof. If your license verification is done on the cloud, like sending some info to a server and receiving back response, it can be managed to an extent.
Just because everything can be hacked, doesn't mean that you have to leave your product wide open for cracking. You can add some barriers so that it is little hard for the crackers. If the product is worth the effort, eventually someone will hack it.
For my applications, I have 2 or 3 licensing steps (which can slow down a hacker but not stop him/her)
A dll (say, DLL-A) with cryptography methods for verifying a license. DLL-A will be placed in working directory. Along with that, a copy of this dll (say, DLL-B) will also be placed as an embedded resource.
During runtime, when the DLL-A is about to be loaded, the DLL-B will be extracted and hash for both will be compared. This is to ensure that DLL-A is not tampered with. In case, DLL-A is tampered, the DLL-B will replaced DLL-A.
Along with that dll method, a XML-Signed file will also be used. This will be verified somewhere in the code.
A C++ native library, with different cryptography methods. This will also be used similar to DLL-A /DLL-B procedure (steps 1,2).
Thus, in my application, i generally use 3 to 4 different license verification scheme. All are independent. Even though everything can be hacked and broken, the hacker will have to be fed up trying to hack all the 4. And with every year, I change my licensing methods and update the new app. So, this means that for every year, hacker has to spend hard time to hack it. (Which should eventually make them feel frustrated).
Above all, I also have cloud based verification for my apps (the ones which store credentials in cloud DB). But, there are still some clients who expect their app to run without connection to internet (due to some security reasons).
Note: Eventually everything is hackable. Point is you just make it hard for hackers.
Related
I am in the middle of developing an application in Winforms and there just doesn't seem to be any protection from decompilation of the executables and other generated assemblies... there are tools that decompile literally within seconds. There are obfuscators available; however, I am specifically looking for a free one.
I store some pretty sensitive strings within the application, and though I try my best to keep them encrypted or in the local sqlite database, there is always that one, single point of failure that leaves the entire application vulnerable. I checked out a couple of obfuscators, both open source and commercial offerings. The open source one seems to be broken, and the commercial ones are priced quite steeply, which is unaffordable for an indie developer like me.
I am aware that an executable has to run in memory, and this in itself makes it vulnerable. And a determined attacker can eventually decompile an application. However, I want to make this process as expensive as possible. At the very least I would want to protect the strings within my application.
My question is, is there just no way to protect an application assembly from getting reverse engineered if I decide not to use any of the expensive options available?
There's lots of protection in Windows. But it's all there to protect the your users from you, not the other way around.
The simple fact of decompliation is: "As long as a computer can still execute it, it can also still decompile it."
Execution is a process that translates binary into actions.
Decompliation is a process that translates binary into code.
If one is blocked, the other is blocked as well.
Obfuscation can make it harder to read the decompiled code. But that is about all it can do.
I store some pretty sensitive strings within the application, and though I try my best to keep them encrypted or in the local sqlite database, there is always that one, single point of failure that leaves the entire application vulnerable
Every string, is only as save as the place you keep it at. The same applies for encryption keys. There are 2 limited workarounds:
if it is around comparing the input to something in the backend - like you do with passwords - password security can work. Modern PW security means not even the Adminsitrator can figure out the passwored, yet you can still compare user input to it.
You could move the strings into a seperate application. Instead of giving applications the SQL Server Connection string, you give it access to a WebService that you control. Only the WebService actually knows how to contact the Database.
It depends on your practical scenario what you can do. But in the end, if a string or other peice of information is to be useable, it is vulnerable in memory.
This is probably coming off as a REALLY broad question.
But is there a way to have my applications code (or some of it) stored on a server, and download it and execute it securely?
I've been seeing ASP.net everywhere but I don't fully understand it. Is this basically exactly what im looking for, or is it some kind of C# Website Hosting, like xampp?
Either way, what im looking to do, is to be able to download some C# methods, not an entire namespace and be able to reference code like, System.*, Program, Form1 and such from those methods.
I managed to get CSHarpCodeProvider working and with System references using its CSharpParameter but it uses a direct namespace, essentially asking for an entire full valid .cs file, whereas I want to load in methods only and not have it secluded but to be interactable with all existing code.
This is probably a lot to ask and probably doesn't exist.
Here's my formula:
Make a request to website.com/api/login.php?e=email#domain.ext&p=Pass123, returns obfuscated C# code along with the first line of text being an MD5 hash of the C# code, Email, Password and random generated strings/numbers/symbols.
Generate the verification hash on the C# Client Side, send the returned hash back to the website on a different php script, That script will verify if it's correct and will return a session token even if it's an incorrect hash (meaning the request was tampered with).
The C# returned from the first request, This seems good to go, Everything matches up. Replace the placeholder garbtext like <!!TOKEN!!> with the token from request 2 without doing verification checks at all.
Execute the finalized C# code.
The finalized C# code will do stuff like create methods that would be used throughout the application including a private bool x() that returns if the application is licenced/purchased.
Use application as normal using the methods created.
Notes:
Having some unixtime checks in the hash and inside bool x() and such would be a good idea to further prevent un-licenced intrusion.
Pros:
The application is theoretically almost impossible to "Crack". To crack it, you would have to manually replace all the functions. Obfuscate the code on server-side before returning to the C# client and it will be extremely hard to do and would be very time consuming.
Can be auto-updated and you wouldn't need to update the .exe unless you did vast changes.
Cons:
Will require a lot more server power depending on the size of your userbase.
Costs you and makes profit a lot smaller if your selling an application licence.
Internet connection needed no-matter-what!
Startup time would be slower.
Downtime can seriously impact your application.
[This question has nothing to do with login credentials, or the user/player inputting any kind of pass-phrase, etc; thank you and keep reading.]
First off, my question has already sort of been asked, here and here. My question is different than either of these though, because I am not connecting through the internet to get data or concerned with any type of "logging in". To put this as simply as I can, I am making a game, and my games resources are all encrypted into a proprietary format, which takes a single password to decrypt the data. I have to hide that password in the source code. I can't think of any other way than to keep the password within the application itself. Encrypting the password within another file would still take a password, and that just starts this endless circle of where to hide that password, and so on.
This got me wondering, how do modern games handle their resource decryption passwords? Think of games like Call of Duty, Elder Scrolls, Grand Theft Auto, etc. They encrypt their data, right? So that means that they need a password/salt/etc to decrypt it. Such a password would also need to be within the executable, too. So where do they hide it? How do they obfuscate it?
I considered one option, which seems like it would actually be pretty good. Basically, I would construct a method which would run through some bizzare gauntlet of mathmatical computations, construct a string, and return the data to serve as the password. Someone could just rip the method out of the code and then launch it in their own private app, but at least it wouldnt be so blatant as:
public const string ResourceDecryptionPassword = "MY_AWESOME_DECRYPTION_PASSWORD";
Also, I considered just keeping the password as a large hardcoded array of bytes, which I could convert back to a string during application start.
Can anyone suggest any other solutions to this problem?
Also, and I forgot to mention: the source code of my game will be obufsicated. This is a no brainer, so it will already make it difficult to visually walk through the code. I just need a good solution for how to hide the password for my encrypted resources.
Based on the comments you received, you already know that "hiding" a security key in the code is NOT a good practice. It's Security through obscurity and it's not efficient.
For games, it was used long time ago. Then with the advance of world wide web, games required an online connection to register/activate the game.
However, these games were so popular they ended cracked whatsoever (by replacing the online activation by a dummy check). That's why a big part of the modern games content (if not all) is now only available when connected to the game servers.
Anyway some games retains parts of the old scheme and use DRM while others (Pillars of Eternity) don't have any.
The common principle is all DRM is to make the reverse engineering of the key (or the debugging of the whole program) difficult: Easy to compute, difficult to debug.
Like a hundred or so embedded encryption/decryption (with hundreds of keys).
Another example is this DRM software that process the code into a VM.
Call unmanaged code to decrypt the data.
Detect any debugger and kills it.
Generate decryption unmanaged code, compile it and run it.
Anything sufficiently complex will do.
I've even seen some financial well known console that refused to launch when VNC is run on the machine... Others complained about Process Explorer.
However, such a hiding job is complex and if you're saying the code will be obfuscated, it should be handled already by the obfuscation software.
By the way, you shouldn't miss windbg if your intent is to play games.
My software (written in C#/.NET) have a simple key license system to activate certain resources. The way it works is: it creates a unique code based on the running computer's hardware, then mix this value with the client's activated licenses to create a password that will, on that specific computer, liberate access to the determinated resources. The key given to the client is a file with the password.
The way it verifies this is even simpler: the software calculates the expected password, and then matches with the password stored on the file. If it matches, the resources are liberated.
So, since the software itself calculates the correct password, I wonder if it's possible to someone take the software's DLLs and hack them to discover the calculation method.
Yes, and if you don't put effort in to obfuscating your code it is trivial to do.
There will always be ways to get around any protection you put in place, the only thing you can do is make it difficult enough that any attacker will get too frustrated and declare it is not worth his time to try and reverse engeneer your software. It is just a matter of how much time/money is it worth it to you to keep that one extra person from trying.
I wrote a fairly extensive answer to a similar question here that goes over what steps you can do to mitigate the problem, but there is nothing you can do to stop it.
I'm developing a program in C#.
It connects to the internet to see if this copy is valid.
Currently I'm just sending the licence key and getting a response (0 or 1) if the key is valid.
The problem is that some users just fake the data with some packet capturing tool and replay it.
So the application is very easy to crack. How can I prevent this?
Here is what I essentially want to prevent:
Network replay attacks
Authentication "emulators"
It should be impossible to find out what data is sent.
Maybe I should add the current time and then encrypt the packet ?
So it's always different ?
Attention: Please don't warn me that it's easy to crack the application itself by modifying it. I know that. This question is only about the network part.
If you use SSL or HTTPS then you don't have to worry about users cracking the data packets. This is easy because the libraries already exist and are easy to implement. With C# and IIs for example it is just a matter of installing the certs and changing a few configuration items. (Maybe a recompile with some slight code changes).
Assuming you actually want to prevent license abuse there are far better ways to do this. The "phone home" approach is easy to roll yourself, but as you've noticed it's full of holes.
Disclaimer: I work for a company that makes commercial tools to solve these license management and copy-protection issues. There are other similar products available from a variety of vendors.
This isn't that different from thinking about how to do setup for your application. Choices are roll your own or buy an existing 3rd party toolset. Rolling your own at first blush make seem cheaper, but that's perhaps only because you haven't really discovered all the true requirements to create something robust and reliable. The 3rd party tool vendor needs to charge for their products, but they've spent years discovering all the issues with particular problem set and have solved the problems. So that eliminates work for you and leaves you free to focus on where your application can add value.
The difference is if you get setup wrong your users will be irritated; if you get copy protection wrong your product will be pirated.
In any event, reducing license validation checking to a binary "either/or" condition is extremely easy to crack--doing that check over the net makes it 10 times easier (record playback attack). Modern approaches encrypt the executable and the license is contained in the key to decrypt it (this is an oversimplification since the actual methodology includes a lot more complexity to make it virtually impossible to get around). Only by having a valid license can the executable be decrypted on program load and run.
If you want to do it the way you've described, consider this:
Have the app use a predictable, changing value (such as a lookup from a table of random numbers coupled with some external value like time) to create some kind of hash. Have the server implement the same code. The server sends the hash to the app, which compares it to its own hash. If they match, the app is allowed to run. If they don't, it errors out. Since the hash is different on ever startup attempt, recording it over the network won't allow the user to get it to run the next time it tries to start.