Doug,
Thank you for your reply.
Let me make sure that I understand: so you are suggesting embedding the Perl program (that contains the IP) in some sort of C wrapper program and then compiling the C program?
If this is the case what is the executable that I deliver? Is this a standalone C executable?
will the Perl program need to be provided in addition to this executable or the Perl code will be "hidden" (I understand that not completely...) INSIDE this executable? | [reply] [Watch: Dir/Any] |
I would appreciate a pointer to an example where perl code is embeded in a C wrapper to be (C) compiled.
Thanks. | [reply] [Watch: Dir/Any] |
That's not going to help you. It's trivial to break that "protection". Why do you persist in not believing many, many people who tell you that your approach will not work?
If you embed the entire Perl program verbatim in your C code, I can use the strings binary to pull out the Perl program verbatim.
If you obfuscate the Perl program within the C code to defeat the strings attack, but link dynamically against libperl, I can subvert the dynamic loader to load my own binary instead which prints the Perl code instead of evaluating it.
If you obfuscate the Perl program within the C code and statically link against Perl, I can attach a debugger and find the point at which you call into Perl and dump the Perl program from running memory.
(If you don't understand exactly what I mean by any of this and you don't know exactly how to do any of it, you're certainly not a strong enough programmer to implement any of them. I don't mean to sound harsh, but these are basic security attacks against even strong obfuscations.)
This is almost a law of physics: You cannot rely on the security of any information provided to a hostile client.
| [reply] [Watch: Dir/Any] [d/l] [select] |
>I would appreciate a pointer to an example where perl code is embeded in a C wrapper to be (C) compiled. Thanks.
like here?
| [reply] [Watch: Dir/Any] |