Re: How do I textually combine a large number of modules into a single file?

Replies are listed 'Best First'.
Re^2: How do I textually combine a large number of modules into a single file? by jettero (Monsignor) on Sep 07, 2011 at 10:25 UTC
The problem can't really be solved by using a compiled language either. There are decompilers for every compiled language. The code won't be pretty, but you can figure it out enough to rip off what ever it is the obfu was guarding. Indeed, I recall seeing a proof that in a general sense, obfu is impossible. I can't find it on google scholar searches, and I don't recall the author. I did find a paper that showed deobfu is NP-Easy though (Appel). Not sure how relevant that is though… Anyway, I would say the only way to prevent them from seeing your code is to run it as a web service (or similar) so they can't get at the executing process.	[reply]
Re^2: How do I textually combine a large number of modules into a single file? by Vlad, the IM-perler (Novice) on Sep 08, 2011 at 07:13 UTC
Not quite. Don't think of it as Obfuscation, think product activation. And no the web activation method is not suitable.	[reply]
Re^3: How do I textually combine a large number of modules into a single file? by Anonymous Monk on Sep 08, 2011 at 09:28 UTC
You can keep all the .pl/.pm files encrypted, decrypt them in ram, but you'll have to put the .dll/.so files on disk... not rocket surgery, but doesn't really hide anything RFC: SecureString - Obfuscated / masked strings exept when you need them perlc does not hide source Module::Crypt - Encrypt your Perl code and compile it into XS PAR::Filter::Crypto - Encrypt Perl files in PAR archives Module::CryptSource - Encrypt and Decrypt source for Binary Packagers PerlApp decompile Here is a commercial obfuscator made more readable by B::Deobfuscate	[reply]
Re^3: How do I textually combine a large number of modules into a single file? by afoken (Chancellor) on Sep 08, 2011 at 18:33 UTC
Don't think of it as Obfuscation, think product activation. Essentially the same problem. Your program contains checks à la `is_product_activated()`. And you don't want the end-user to use your product when it is not "activated". As a minor variant, the "activation" allows decrypting encrypted code needed for advanced features. Did you know that perl can load and run an arbitary script whenever it is started (search for "sitecustomize.pl" in perlrun)? So monkeypatching those functions should be quite easy. And of course, there is B::Deparse, making all obfuscation futile. Decrypting the encrypted code can be done using the required decryption functions of the program, e.g. from sitecustomize.pl. The code can then be written to a plain file, using a simple `print` if it is `eval""`uated, or using `B::Deparse` for more complex setups. Product activation is just nonsense. Look at Microsoft's current products. You are told that you have to activate them, but that's not true. People found various ways to circumvent the need for activation. One old and trivial way is to set the clock to the far future, install the product, turn the clock back, and enjoy a decades long evaluation phase. Another way is to fool the product into thinking it runs on an OEM system, where the activation is not needed. And you can bet that Microsoft invested a lot of work into the product activation. Hire a good lawyer, make him write a good contract for selling your product. Sell support and updates for your product, not just the product. Alexander -- Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)	[reply] [d/l] [select]