Perlapp Code Protection

Posted by wibble on 2011-02-13 08:55
Forums: PDK Support | OS: Debian / Ubuntu

I know this question gets asked periodically but what is the current situation re reverse engineering a perlapp executable to extract sourcecode?

Does the perlapp extract readable source as it runs?

How safe are my algorithms within a perlapp executable?

Is the only way to keep source confidential to rewrite it in C++ or somesuch? What a pain that would be....

ron7 | Wed, 2011-03-02 15:51

There's an answer to this in the FAQ. Basically, some obfuscation takes place, but if you are really concerned, take your own steps.

wibble | Thu, 2011-03-03 02:30

Yes I read the FAQ.

It isn't really much of an answer which is why I posted the question.

I do understand why AS accept no responsibility and why they don't want to discuss the subject very much.

However code security is important to many potential users of perlapp and it is hard to "make your own arrangements" if you don't know what you are dealing with. Googling this subject returns a wide variation of opinion from "don't waste your time" to "There is currently no known method of cracking a perlapp"

It would be nice if AS published a "Best Practice" guide to help developers work towards the strengths of perlapp (if it has any) with regard to security.

I'm no expert but my guess is that reverse engineering perlapp is not easy but possible for the right people - but then you could say that about a truly compiled executable.

So not much wiser then....

grahams
ActiveState Staff
Mon, 2011-03-21 15:30

PerlApp takes what we feel is the most secure tactics possible for Perl code.

Source code is never extracted to disk by PerlApp, however dlls and bound files will be. Dll substitution is a potential attack vector, but not one I have ever encountered. It's possible to have the Perl script do MD5 checksums against dlls to make this more difficult, but the main difficulty with attempting to prevent this line of attack is that it does not really address the true vulnerability. Someone skilled enough to create a suitable binary would be aware of other means to attack a running executable.

As you point out, there is no way to prevent a sufficiently skilled attacker, who has access to the hardware which runs a file, from determining the contents of any file. This is as true for compiled languages as it is for scripted languages, it merely takes a different order of skill to pull it off.

If you have security concerns and applications which run on an end-user's system, you should have a suitably crafted license and usage agreement; and if those users really can't be trusted, it may be best not to sell product to them.

The only truly secure method to distribute an application is to provide it as a web service, where the attacker cannot access the memory of the system running the application.

PerlApp is as secure as we can make it. We suggest two additional practices, which can increase security somewhat.
-Data should not be included as part of the Perl script. Sensitive data should be in separate files, which can then be encrypted and decrypted by the Perl script as required.
-Code can't be encrypted, however Perl programs can be made somewhat more secure, whether they are wrapped or not, by writing key parts of the application as XS code. This does not prevent interception, but requires that a potential attacker must understand C as well as Perl, thereby raising the bar on the skill level required somewhat.

wibble | Thu, 2011-03-24 15:48

Thanks.

I suppose this is what I wanted to hear "PerlApp is as secure as we can make it.", rather than "We don't really care - it's not our problem".

That some effort at least has been put into this issue by AS and that the Perl code is never decrypted to disk...