chester has asked for the wisdom of the Perl Monks concerning the following question:

Greetings monks,

I am charged with the unpleasant task of "password-protecting" a windows .exe file, or otherwise stopping a user from running this executable unless authorized. Search didn't turn up much that's similar to my problem. The complications:

I realize that calling this "security" is a bit of a stretch. But I only need this to be "secure" to the point where the average non-hacker would be defeated, and the average hacker would be slowed down or perhaps annoyed enough to make it not worth the effort. This is what I came up with so far:

use warnings; use strict; use Convert::UU qw(uudecode); use Digest::MD5 qw(md5_hex); use Win32::Process; use Win32; use File::MkTemp; print "Password: "; chomp( $_ = <STDIN> ); my $dep; if(md5_hex($_) eq '207f499c334c2a3199f748a327b1b515') { # For added "security" (I use the term lightly) we're going to use + a random filename. $dep = mktemp('XXXXXXXX', $ENV{'TEMP'}) . '.exe'; print "Password OK. One moment please.\n\n"; open OUT, '>', $dep or die $!; my $uu; { local $/; $uu = <DATA>; } binmode OUT; print OUT uudecode($uu); close OUT; # We need to pass along the command line arguments my $com = join ' ', ($dep, @ARGV); # And the current directory; this script is always called via .bat +files, # so the current working directory should always be set; we don't c +are what it is, # but we need to let the process know below chomp(my $curr_dir = `cd`); my $proc; Win32::Process::Create( $proc, # Process object $dep, # Filename $com, # Command line args 0, # Should the process inherit fileh +andles? (No.) NORMAL_PRIORITY_CLASS, # Priority (normal) $curr_dir # Process' working directory ) or die $!; $proc->Wait(INFINITE); print "Please don't close this window. It will close itself automa +tically in a few seconds.\n"; } END { # Delete the temp file. This won't be run if the script doesn't ex +it normally! unlink $dep if $dep; } __DATA__ # long uuencoded string of the original .exe goes here

I then take this script and run it through PAR to create a standalone .exe, and then I will distribute this wrapper exe as a drop-in replacement for the original .exe.

Some unresolved problems with my solution:

Can you think of anything else I could do here, or anything I'm overlooking? I particularly don't like the END block. (This is my first post. Thanks in advance.)

Replies are listed 'Best First'.
Re: Password-protect an arbitrary windows executable?
by 5mi11er (Deacon) on Aug 05, 2005 at 18:43 UTC
    Yech. Ok, are you sure Perl/Par is the right answer? I'd personally guess it's not.

    A quick google search returned this promising looking link, among others.

    Update: added the google search link

    -Scott

      "Yech" is pretty accurate. I'm not at all sure that Perl is the right answer, but I don't have access to a C compiler here. Also, Perl already has modules for things like uuencode and MD5 etc. Finally, I'd like something I can see the source code for, so I know what it's doing. (Not having to pay for it is also nice...)

      I've seen some tools for sale, but the program you linked me to (for example) does MUCH worse than my script. It copies the original .exe to an unprotected backup on purpose. However you may be right; I'll reconsider looking for something to purchase. Thanks for the reply.

        No source AND no C compiler, but you've got Perl? Interesting environment for this project...

        ++ for wanting to know what's happening during the obfuscation process. Unfortunately it's fairly well accepted that attempting to protect perl code with perl is not a good option; I can't imagine attempting to protect an exe with perl will be any better.

        Good luck,

        -Scott

Re: Password-protect an arbitrary windows executable?
by jfroebe (Parson) on Aug 05, 2005 at 19:12 UTC

    Hi,

    I think you would be better off using policies on the windows box. Here's a good write up on the matter.

    Jason L. Froebe

    Team Sybase member

    No one has seen what you have seen, and until that happens, we're all going to think that you're nuts. - Jack O'Neil, Stargate SG-1

      This would be good, except that not all the machines will be Windows XP. Some will be Windows 98; I don't believe 98 has the ability to set security policies like that. (If I could change the OS on these laptops, I wouldn't be using Windows at all...)