in reply to Re^6: use of already eval()ed module (from string)
in thread use of already eval()ed module (from string)

My idea was that you are assuming that Inside of these presumptions using code to deencrypt the key should be "safe"

Simple example a loop doing XORs with values from a nested table.

XORs are easily reversed.

Plus some rotations if you want and gotos depending on temporary values in the middle.

Sorry, no ready to use suggestions.

Of course one could use B::Deparse to disassemble the Op-tree, but that's always the case.

HTH! :)

update

You could create such an algorithm with random values.

It's only important that

For clarification the algorithm would act here as the key.

Cheers Rolf
(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery FootballPerl is like chess, only without the dice

  • Comment on Re^7: use of already eval()ed module (from string)

Replies are listed 'Best First'.
Re^8: use of already eval()ed module (from string)
by bliako (Abbot) on Jan 15, 2019 at 11:30 UTC

    At this point i will set my goal as to be able to protect a password from a memory dump of a running script (re: password is specified by user at runtime, it is not stored in script but in script's runtime memory) by obfuscating it along your suggestions.

    I searched on CPAN for something similar to C#'s SecureString but couldn't find any.

      Btw are you bundling your own Perl or how do you stop an attacker to just patch eval to dump the code?

      Cheers Rolf
      (addicted to the Perl Programming Language :)
      Wikisyntax for the Monastery FootballPerl is like chess, only without the dice

        I am not bundling own perl but that's a good point. I guess check-summing a sub, even if it is possible, it is easy to break as afoken notes and hell to maintain. Maybe instead of bundling a perl executable, I can only bundle eval() and use override::eval to override any other eval?