Beefy Boxes and Bandwidth Generously Provided by pair Networks
go ahead... be a heretic
 
PerlMonks  

Code hiding in Perl

by sumanta (Novice)
on Jun 26, 2015 at 07:23 UTC ( [id://1132086]=perlquestion: print w/replies, xml ) Need Help??

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

I have been working on to find a solution to hide the business logic of a Perl code so that the project can be delivered to the customer network without much concern. Ofcourse I am sure that it's almost impossible to completely secure the code from "too curious" eyes, but I tried to make things harder for them. Now I need your thoughts/suggestions/criticism for the below mentioned approach.

I have developed 2 different executable using C programming language. (i) The first program is responsible for encrypting the Perl code with password protected custom encryption logic. This will also modify the Perl script to change Shebang line (to include custom perl intertreter) and add another BEGIN block which restricts use of default Perl interpreter & debugger. (ii) The second program (namely myPerl.exe) has actualy replaced the original "Perl.exe" interpreter. It is responsible for decrypting the encrypted Perl code and perform an in-memory execution. Now the password can be stored in a scattered way inside the encrypted Perl code. It will also restrict the debug mode so that the code can not be viewed. Although the debugging can be performed by providing a password.

I have implemented this already and it's working fine. During the time of execution it is expected to decrypt the code, so it slightly increases the execution time, but I have no problem with that. I will be very happy to receive your valuable feedback/suggestions on this approach. Thanks in advance.

Replies are listed 'Best First'.
Re: Code hiding in Perl
by Anonymous Monk on Jun 26, 2015 at 07:27 UTC

    ..hide code...Now I need your thoughts/suggestions/criticism for the below mentioned approach....I will be very happy to receive your valuable feedback/suggestions on this approach. Thanks in advance. Comment on Co..

    See all the previous discussions, they all apply , your scheme is old :) if a user can run it he can decode it

    See ?node_id=3989;HIT=hide, ?node_id=3989;HIT=hide+code...

      I have gone through many such threads but didn't find any solution/approach which talks about modification of default interpreter to execute (in-memory, hence can't be seen) a password protected encrypted code .. I would like to know how will they decode it?

        See B::Deobfuscate. Any approach to hiding Perl source code will be done through a filter which eventually calls eval on the decoded Perl code. Getting at the source code then just requires replacing eval with print.

Re: Code hiding in Perl
by Anonymous Monk on Jun 26, 2015 at 08:35 UTC

    You haven't shown any code or explained the details of your obfuscation scheme, and you say your code works, so what kind of feedback are you looking for? On the general approach you've already said a central point yourself:

    it's almost impossible to completely secure the code from "too curious" eyes

    Yes, knowledgeable people will still be able to get the source of the program, all obfuscation does is make it a little bit more difficult.

      The encryption is done through custom C executable and the execution of encrypted binary code can only be done through another C executable (dummy Perl interpreter) and it does in-memory execution like this.

      perl_run(my_perl); eval_pv(buffer, TRUE);
        The encryption is done through custom C executable and the execution of encrypted binary code can only be done through another C executable (dummy Perl interpreter) and it does in-memory execution like this.
        perl_run(my_perl); eval_pv(buffer, TRUE);

        Easily broken:

        1. start a debugger
        2. load the "encrypted" program from the debugger
        3. set a breakpoint at the call to eval_pv(), or at the first instruction of eval_pv()
        4. start the program
        5. instruct the debugger to show the contents of buffer
        6. copy contents of buffer to a text file
        7. kill the program
        8. exit the debugger

        It was explained a thousand times or more, but once more for you:

        Perl is designed to evaluate unencrypted source code, so at some point, you have to decrypt the encrypted code. Alternatively, you can feed perl a prepared parse tree, in unencrypted form. Again, you have to decrypt the encrypted tree before passing it to perl. B::Deparse can reconstruct perl source code from the tree, so you gain exactly nothing from using a tree.

        Both ways, you have to decrypt the encrypted data, so your executable must contain the decryption algorithm and the required decryption key. Both can be exctracted from the executable to create an independant decryption tool. Or, as I explained above, one can simply stop the execution of the program at the point where the decrypted data is passed to perl API functions. That's usually much less work.

        And there is NO WAY to prevent that.

        See also:

        Alexander

        --
        Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

        See overload::eval. It replaces the ENTEREVAL opcode with its own. eval_pv parses the code and then executes the ENTEREVAL opcode before running the code within the eval.

        Also, if the program string exists as one large buffer in RAM, its easy to freeze the program as soon as it opens a file (for example) and then dump the memory.

Re: Code hiding in Perl
by RonW (Parson) on Jun 26, 2015 at 21:29 UTC

    The most you can do is make it inconvenient enough to "keep honest people honest".

    Your scheme might accomplish this. Your employer's legal department might be able to craft a suitable license agreement to help with this.

      The most you can do is make it inconvenient enough to "keep honest people honest".

      Your scheme might accomplish this. Your employer's legal department might be able to craft a suitable license agreement to help with this.

      If the legal department's work is done, and the client has signed the contract, there is no need to "make it inconvenient".

      Alexander

      --
      Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
        If the legal department's work is done,

        And if you're a one-man band?


        With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
        I'm with torvalds on this Agile (and TDD) debunked I told'em LLVM was the way to go. But did they listen!
Re: Code hiding in Perl
by sundialsvc4 (Abbot) on Jun 26, 2015 at 10:51 UTC

    Echoing more-or-less the sentiments already expressed here ... it would be far better for you to find a way to trust the customer’s network, and, by extension, the customer himself.   Or, at least, hire a lawyer to write you a decently bullet-resistant contract.   Your alternative strategy appears to have been to install a custom modified Perl interpreter (!!) on that same customer’s “untrusted” (sic ...) corporate network, and I doubt that you can show me (or the Honorable Court) that you had written authorization from a VP-or-higher to do such a thing.

    The only reason why I’d allow a third-party contractor to do such a thing is if I didn’t (yet) know he was doing it.   Why is this third-party “hiding [my?] business logic” from me?   “Is he setting me up for future extortion?”   (I’m quite serious.)

    You have concocted an elaborate technical ploy and ... like so many others who kit-bashed a pseudo-cryptographic something-or-other ... you can’t see through it nor see (or acknowledge) its faults even though, or because, others have quickly pointed them out to you.   But you also don’t seem to have considered that this sort of thing could land you in a courtroom, having lost your contract, your former-client’s case, and your goodwill.

    In saying this, I intend neither to be personal, nor crucifying.   Merely to be coldly blunt and candid.   You have, in more ways than one, stepped on ice where you should not be.   Reverse your steps, carefully but quickly.

Re: Code hiding in Perl
by Anonymous Monk on Jun 26, 2015 at 16:31 UTC
    "I have implemented this already and it's working fine."

    Hogwash! Show us code or it does not exist.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://1132086]
Approved by Corion
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others studying the Monastery: (5)
As of 2024-06-13 11:16 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found

    Notices?
    erzuuli‥ 🛈The London Perl and Raku Workshop takes place on 26th Oct 2024. If your company depends on Perl, please consider sponsoring and/or attending.