Not sure if I misunderstood:

1. In order to use the C debugger, you would need access to the source. The source can be stashed away after the executable is created. - sorry this is a misstatement. It has been a long time since I've used gdb, so the source may not be required. Ahh! Just realized you were talking about the Perl debugger.

No, I was not talking specifically about the perl debugger, but of course, the perl debugger usually has source access (except for XS code).

Source code is not needed to debug a compiled program. You won't have nice C source in the debugger output, but you can step through the disassembled code and set breakpoints, even if the debug information has been stripped from the binary.

Semi-automatic disassemblers like IDA can be very helpful to find places to set breakpoints at runtime. Just reading the relevant parts of the disassembly can be sufficient, if the de-obfuscation / decryption code is a single function. And yes, IDA can disassemble executables for many different processors and operating systems.

2. The C program would not relinquish the password if the inode of the registered script has changed, meaning the script has changed - so a hacker can't add a "die" or just print the password.

I can make the perl program print out the secret and stop without ever touching the main script. Have a look at how I injected the DBIspy module.

I can have a second perl script modify the script and restore all meta-data in the inode (see lstat and especially utime). File size won't change for an injected die, I can easily pad the file with some commented-out garbage to the old size.

I can use environment variables to modify @INC and thus load modified modules. Your code surely uses strict somewhere. Guess how hard it would be to include DBIspy or similar in a modifed copy of strict.pm.

I can use LD_PRELOAD to load an additional library into the perl interpreter. Code in the library would be executed before perl's main(), would call the magic password program and abort the program before perl's main() is reached.

Update: strace-demo

/tmp>cat secret-keeper.c
#include <stdio.h>

int main(int argc, char ** argv)
{
        // note: security checks omitted
        fputs("find me, I'm the secret",stdout);
        return 0;
}

/tmp>make secret-keeper
cc     secret-keeper.c   -o secret-keeper

/tmp>strip secret-keeper

/tmp>cat secret-reader.pl
#!/usr/bin/perl

use strict;
use warnings;

my $secret=qx(./secret-keeper);
print "The secret is <$secret>\n";

/tmp>perl secret-reader.pl
The secret is <find me, I'm the secret>

/tmp>strace -o trace perl secret-reader.pl
The secret is <find me, I'm the secret>

/tmp>grep -C5 find trace /dev/null
trace-read(5, "", 4)                          = 0
trace-close(5)                                = 0
trace-ioctl(3, TCGETS, 0x7ffeddbf80a0)        = -1 ENOTTY (Inappropria
+te ioctl for device)
trace-lseek(3, 0, SEEK_CUR)                   = -1 ESPIPE (Illegal see
+k)
trace-fstat(3, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
trace:read(3, "find me, I'm the secret", 8192) = 23
trace-read(3, "", 8192)                       = 0
trace---- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=12034,
+ si_uid=1001, si_status=0, si_utime=0, si_stime=0} ---
trace-fstat(3, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
trace-close(3)                                = 0
trace-wait4(12034, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) =
+ 12034
trace:write(1, "The secret is <find me, I'm the "..., 40) = 40
trace-rt_sigaction(SIGHUP, NULL, {SIG_DFL, [], 0}, 8) = 0
trace-rt_sigaction(SIGINT, NULL, {SIG_DFL, [], 0}, 8) = 0
trace-rt_sigaction(SIGQUIT, NULL, {SIG_DFL, [], 0}, 8) = 0
trace-rt_sigaction(SIGILL, NULL, {SIG_DFL, [], 0}, 8) = 0
trace-rt_sigaction(SIGTRAP, NULL, {SIG_DFL, [], 0}, 8) = 0

/tmp>
[download]

Alexander

The C program would not relinquish the password if the inode of the registered script has changed, meaning the script has changed - so a hacker can't add a "die" or just print the password.

Guess I'll edit DBI.pm instead and have the connect method print @_ before doing anything else.

As afoken said, if you have both the hidden secret and the means of revealing the secret in the same place at the same time, then an attacker will be able to learn the secret, whether by subverting your decoding process or by learning how it works and applying it himself. You can make this more difficult, but you can never make it impossible, as has been repeatedly demonstrated by the ongoing wars between digital content providers and digital content pirates. The content providers have thrown boatloads of money at it and hired people far smarter than you or me, and the pirates invariably crack each new scheme in far less time than it took to devise and implement the scheme in the first place (often within a single day).