"...once an intruder gets on the server..."

Moral of the story: don't let anyone break into your box in the first place.

jeffa

L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)

Maybe you should just ensure that people can't get to the source code of your programs.

-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.

But, for completeness, here's an example how to do it:

use strict;

open (EXE, "> myexefile.exe");
binmode(EXE);
print EXE getexe();
close (EXE);

my $login = `myexefile.exe`;
unlink('myexefile.exe');

sub getexe {
    return
     "\x4d\x5a\x90\x00\x03\x00\x00\x00\x04\x00\x00\x00\xff\xff\x00\x00
+\xb8\x00\x00\x00"
    ."\x00\x00\x00\x00\x40\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00
+\x00\x00\x00\x00"
    ."\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00
+\x00\x00\x00\x00"
    ."\xd0\x00\x00\x00\x0e\x1f\xba\x0e\x00\xb4\x09\xcd\x21\xb8\x01\x4c
+\xcd\x21\x54\x68"
    ."\x69\x73\x20\x70\x72\x6f\x67\x72\x61\x6d\x20\x63\x61\x6e\x6e\x6f
+\x74\x20\x62\x65"
    ."\x20\x72\x75\x6e\x20\x69\x6e\x20\x44\x4f\x53\x20\x6d\x6f\x64\x65
+\x2e\x0d\x0a\x24"
    ."\x00\x00\x00\x00\x00\x00\x00\x89\x97\xcf\x9d\xcd\xf6\xa1\xce\xcd
+\xf6\xa1\xce\xcd"
    ."\xf6\xa1\xce\xcd\xf6\xa0\xce\xc0\xf6\xa1\xce\x94\xd5\xb2\xce\xc4
+\xf6\xa1\xce\x9b"
    ."\xfe\xa7\xce\xcc\xf6\xa1\xce\xcd\xf6\xa1\xce\xcc\xf6\xa1\xce\x52
+\x69\x63\x68\xcd"
    ."\xf6\xa1\xce\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00
+\x00\x00\x00\x00"
    ## (more data here)
    ;
}
[download]

Thanks for the answer but I do not understand a couple of things.
What does the sub getexe() do, what are those wierd characters, what should I put in the getexe() because u specified  ##(more data here); ?

Thanks

Your original request asked how to "embed an executable file". The easiest way to do this is to convert your binary executable into a text-based string. One such way is to escape each byte using \xNN syntax. If your binary executable is 30k, you will have a string made up of 30,000 variations of "\xNN". The getexe() function is just returning this binary data to the main part of the program so it can be extracted to disk. You don't have to do it this way - I just thought it made it easier to read. I put the ##(more data here) in there because the post would have been really huge if I posted all 30k. Your executable code will be different anyway.

OK, merlyn makes a point that the exe (that you want to store user/pass in) can still be reverse engineered so it still is insecure. Good point, but lets presume for the moment that an intruder has not gained shell access to your box- yet.

Without doubt there are windows exploits that permit malicious types to view the sourcecode of your script - thus hardcoding the username and password in there is a bad idea - IF the database is accessible from the web - which if it is being called solely from a CGI or such - should not be the case. The sensitive database ought to be accessible from localhost(127.0.0.1) and possibly trusted hosts on a local network. Certainly NOT from the net in general.

So lets presume now that your server has been (owned/rooted/admin'd/crackered/whatever) invaded, well then the invader has access to your script source, hence can find the executable you are getting the user/pass from, hence can run that executable to glean the user/pass. This only adds one step for the invader, and a pretty simple one at that. Reading the user/pass from a properly permissioned file might be a better way, but I suppose that if your script can have read permission on it - then any would be invader could do the same. Windows monks prepare to flame me ....now but short of changing to a platform with (cough) fewer simple and (cough) obvious exploits - you're still up the security creek in a barbed wire canoe

Thanks for a lengthful comment....

But in any way, my users have to be able to connect to the database....so what's your most secure way to do that?

But in any way, my users have to be able to connect to the database.
Do they really connect to the database, or just to a cgi application which then connects to the db? It sounds as though you're only using a 'master' user/pass to have db access from cgi. Do your users have individual db accounts? Can the CGI perform it's duties for userX if it is logged in as userX ? In that case you would be mindful of the security of your CGI session, (where user/pass is being flung around) instead of being worried about your db master password being available to an intruder.

Seriously, if someone invades the box, this is all academic - all bets on security are off. Please describe your process more explicitly, post some code and more people may be able to assist you.


I can't believe it's not psellchecked