5

If I need the user to enter a password to open the Delphi-generated exe and I use a code like this but not a simple password as this :

if password='1234' then begin
   form2.show
end;
ain
  • 22,394
  • 3
  • 54
  • 74
Billo .S
  • 119
  • 1
  • 10
  • You can take a look of my answer to a similar question on SO. It shows how to use DPAPI to store sensitive data in a more secure manner: http://stackoverflow.com/questions/13145112/secure-way-to-store-password-in-windows/13146105#13146105 – iPath ツ Dec 28 '12 at 12:07

3 Answers3

10

No, that will almost certainly be stored as cleartext within the executable.

In fact, no amount of effort will make the executable secure since the checks are done locally - all an attacker needs to do is to edit the executable file to modify the conditional jumps, and your tests will be bypassed. The way these things are usually secured is to move such power away from the attacker. For example, send a user-input password up to a central server that you control, and have the checks done there, sending back something that's needed (and that cannot be faked by a replacement server) only if the checks succeed.

However, that's a lot of possibly unnecessary effort. If all you're trying to do is keep out the casual cracker, you may be able to do so just with a little obfuscation, such as XORing the password with a keyphrase so that it's no so obvious in the executable. Doing the same thing with the password entered by the user, and then comparing those, means that the plaintext password will not be visible.

A scheme like that won't stop a determined cracker but it will make it harder for the vast majority. The idea of security (IT, home, or any other type) is not always to make it impossible to defeat, just to make it hard enough to be less worthwhile.

It really depends on who you're trying to defeat - that will dictate how complex your scheme should be.

Alternatively, you may want to consider an option raised by hvd in a comment. Have the executable simply be a stub which has the actual executable as encrypted data. This would be decrypted using a user-entered key and written to the filesystem, checked for validity, and then run.

Because the password is not within the stub itself, it is not susceptible to an easy attack. The password only exists with the creator (used when making the stub) and the user (hopefully only in their head). Someone who obtains just the stub has no easy way to run the encrypted executable.

Again, there are ways to get around that, but they all involve getting the password without the executable (brute force, social engineering, etc).

paxdiablo
  • 854,327
  • 234
  • 1,573
  • 1,953
  • Please can you clarify more ? is it possible to crack the password or impossible ? – Billo .S Dec 27 '12 at 22:19
  • 5
    Not only is it possible, it's extremely easy. –  Dec 27 '12 at 22:21
  • @hvd can you tell me how ? – Billo .S Dec 27 '12 at 22:24
  • 1
    Comment on your edit: having it checked by a server is possible, but means the program cannot be used on computers without internet access. Another alternative is to use the supplied password to decrypt the main code. –  Dec 27 '12 at 22:24
  • 1
    @Billo.S The way I'd try it is to run your program in a debugger, set a breakpoint on the string compare function (I'm not sure what it's called right now, it would require finding it anyway), and see which arguments get passed. –  Dec 27 '12 at 22:25
  • 2
    Another downside to using a server is that it can be bypassed with a local server that returns a fake success reply. I've used that technique myself a couple of times. – Remy Lebeau Dec 27 '12 at 22:26
  • @hvd Oh, that's a relief ! Ok what if an MD5 hash was used intead of the password and yet stored in the exe, will still be possible to crack it ? – Billo .S Dec 27 '12 at 22:28
  • 1
    @Billo.S In that case, it's easier to simply remove the check from the executable than it is to figure out the password, as paxdiablo's answer says. Still not very hard. –  Dec 27 '12 at 22:29
  • 1
    @Remy, the fake server can't return something that's needed - stuff like data required for the program to function correctly. – paxdiablo Dec 27 '12 at 22:30
  • 2
    Anything that is stored in the exe itself can be extracted, sometimes very easily. Even if you encrypt the data, it is still easy to obtain using tools like ICE or IDA, which simply wait for the exe to decrypt the data into memory before then extracting it. So the short answer is, there is no way to protect your exe file itself. Anyone with the right tools, time, and effort can break into it if they really want to. – Remy Lebeau Dec 27 '12 at 22:30
  • thank you @hvd , but how to remove check from executable how can this be ? – Billo .S Dec 27 '12 at 22:31
  • 3
    @RemyLebeau How do you do that when the decryption key is based on the entered password, and the user does not have the password? –  Dec 27 '12 at 22:31
  • 1
    @hvd, the key to decrypt executable (using a user-entered password) should go in as an answer - that's worth an upvote. – paxdiablo Dec 27 '12 at 22:31
  • 2
    @paxdiablo: Yes, it can, if you can work out the protocol used to communicate with the main server and figure out what input it takes and what output it generates. Like I said, I've used this technique myself before, so I know it is possible. To secure that connection, you need to use SSL/TLS as well as verified certificates to protect the connection, even from MITM attacks. – Remy Lebeau Dec 27 '12 at 22:33
  • 1
    If you like, feel free to include it in your answer. It's late, I can't phrase it well enough for a good answer right now :) –  Dec 27 '12 at 22:33
  • 2
    @hvd: obviously, if the decryption is based on user entry, then you need to enter the right value. That is where brute force tools come into play, if you have the time and patience, and the app is nt smart enough to twart brute force attacks. But not all software is that smart. I've seen apps that use private keys to encrypt/decrypt their internal data from the exe, with the assumption that encrypting data at compile-time is safe. It is not. ICE/IDA can simple wait for the app to use its own private key to decrypt the data, then snag up the decrypted data from memory before it gets discarded. – Remy Lebeau Dec 27 '12 at 22:37
  • 2
    Passwords, and hashes of password, should not be stored in the exe itself at all. – Remy Lebeau Dec 27 '12 at 22:38
  • 2
    @RemyLebeau It's funny that this is essentially what Delphi's own installers effectively do, with their 7zip password-protected files :) –  Dec 27 '12 at 22:39
  • 1
    @Remy, something like game data (the data for a level in your game) or remote code to be downloaded and run can't be faked by a server. Your comment is correct if you _can_ work out the output based on the input but that's not always the case. The intent was to have something on the server which the program would be deficient without, _and_ that was not something that was easily replaced. I'll clarify. – paxdiablo Dec 27 '12 at 22:39
  • 1
    @RemyLebeau If you've brute-forced the password, you no longer need to run the app in a debugger to dump its decrypted form, btw. You can just run the program and enter the password. –  Dec 27 '12 at 22:41
  • @hvd: true. On the other hand, if the app is not using strong encryption, a debugger can be used to find where the password is being processed and maybe be able to help you decypher the algorithm used. That is how keygens get created, for instance. – Remy Lebeau Dec 27 '12 at 23:30
10

Just to demonstrate HOW unsecure it is, consider this small console application:

program Project1;

{$APPTYPE CONSOLE}

{$R *.res}

uses
  System.SysUtils;

procedure StartProgram;
begin
  writeln('You entered the correct password. Welcome to this awesome program!');
end;

procedure EndProgram;
begin
  writeln('That is not the correct password. Goodbye.');
end;

var
  PW : string;

begin
  write('Enter password: ');
  readln(PW);

  if PW = 'SuperSecretPassword' //See if you can spot this in the image
    then StartProgram
    else EndProgram;

  readln;
end.

Compile it, and open the exe-file in a hex-editor. The screenshot is from XVI32, but I suppose any hex-editor will look somewhat similar:

enter image description here

Not so super secret after all.

Svein Bringsli
  • 5,640
  • 7
  • 41
  • 73
  • 1
    There's a simple solution to this problem. Of course, it only solves this one, and not more advanced things like hooking the jumps, but it's fairly easy to avoid this single problem of casual observation of the password. (Separate functions that each return part of the password, located in different non-adjacent sections of the code, and called at runtime to assemble the password.) – Ken White Dec 28 '12 at 04:54
  • Yep, e.g. just assemble your password to match against in the initialization code. Note that all of these will not stop someone using a debugger like IDA, but for hiding the password from the casual snooper techniques like these are enough. Reminds me of the DOS days where we would replace characters in the executable to change the copyright message ;-) – Jan Doggen Dec 28 '12 at 07:23
  • Even with an obfuscated password, a crack would still be an easy jump over the checking "if" statement. If you want this to be secure, you'll have to add the check all over the place. If you really want to protect against hackers: use a professional solution like Software Passport's Armadillo or some such. They are in a far better position to keep up with hacking methods than any of us are. – Marjan Venema Dec 28 '12 at 09:29
3

No. If somebody wants, they can reverse engineer the executable and get the password.

Justin Niessner
  • 242,243
  • 40
  • 408
  • 536