It's basically impossible to write an automatic converter from Perl to C without also removing the possibility of significant speed gains.

Perl has many features that C does not provide, and providing those features within C means slowing down C to the level that Perl is now. Perl is written in C.

Please see my response to ikegami. My end goal is to get an executable that is harder to reverse-engineer than perl2exe produces. I do not mind if the resulting speed is the same or even if I loose a little from the execution speed of my current Perl program

Rather than coming up with a programming solution to protecting your work by making it a little harder to read, is it possible to achieve one of the following?

• Copyright your work.
• License your work to your userbase.
• Work out a contract with your users that protects your interests.
• Give away your work but sell support, maintenance, etc.
• Think of some other means of protecting your interests that doesn't involve obscuring your work by enveloping it into an executable.

My point is that creating an executable with the intent of simply making it more difficult to read what you've written (first) won't guarantee that you'll accomplish the goal, and (second) may not be the most effective approach. There may be better ways to protect your interests. Think a little outside the technical box and you may come up with a real-world solution that is more appropriate.

Dave, Thanks for your suggestions. Unfortunately in the particular niche I am working I need more protection than the "non-technical solutions" you have kindly listed. Also, the constraint that I have right now is that an executable needs to leave my hands, I cannot at this point keep the exec on my machine ans allow remote access through an API...

Thanks for the info. Does anybody here have any experience positive or negative with B:C?

It used to have a reputation of not quite being all there, but someone's taken up development of it recently so things are probably improving.

--
In Bob We Trust, All Others Bring Data.

First thanks everybody for taking your time to answer my question. My goal is to get from my program something secure, an executable hard to reverse engineer to extract the code. I read that perl2exe is easily reversible, however C executables are much harder to break. In terms of performance I would be very happy if my executable is as fast as my Perl is, I could even live with something that is not significantly slower...

however C executables are much harder to break

That is a common myth, it simply isn't true.

I think that we've been here before. Lots of words can be said, but basically if you want to "protect" the source, use a compiled language. You can embed a perl program from within a C program. In fact, the perlembed man page explains how to do it.

- doug

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?

I would appreciate a pointer to an example where perl code is embeded in a C wrapper to be (C) compiled. Thanks.

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.

>I would appreciate a pointer to an example where perl code is embeded in a C wrapper to be (C) compiled. Thanks.

like here?

Cheers Rolf

I suggest that wrapping it in an executable should be considered a social measure. Its a clear sign that you don't want people to poke in there, although it won't stop them if they try.

In addition to appropriate contracts & licenses as above, you might also consider adding a watermark to the code to identify who leaked it when it inevitably gets out in a few years. Then bill the culprit for the extra copies floating around and/or damages incurred (write that part into the contract of course).

The only way to actually prevent the code from leaking is to keep it on trusted hardware being accessed only by trusted people ... even then, you can't be sure they're trustworthy or the only ones with access, but that is closer to a physical security issue. It also sounds like it isn't practical for your purpose.