Hey all, The use case here is something similar to what Chris mentioned above, in that my organization develops and maintains a piece of software and we host this software on the client's premises, not ours. The obfuscation is just meant to be another hurdle to complicate life for the would-be attacker. If someone was determined enough to break in and reverse engineer it, it wouldn't be the end of the world either, as there is no mission-critical code or super secret Google search algorithm within.
I looked at a few options and it seems like there are two classes of obfuscators here- ones that use additional software (ie. loaders) and ones that don't. The ones that don't are really crappy, since the only thing it can really do is change the var names, constants and strings. The rest of the syntax is still relatively intact (it has to be, otherwise how will it be interpreted?) The ones with loaders look more attractive. Still not a silver bullet, but this is more attuned to what I'm looking for. The only other option is some kind of PHP compiler that converts the PHP into binary, but we're not willing to go there just yet. Hope this helps Lester On Apr 14, 2010 2:00 PM, "Chris Snyder" <chsny...@gmail.com> wrote: On Wed, Apr 14, 2010 at 1:47 PM, Patrick Saint - laurent <patr...@saint-laurent.us> wrote: > You are... The typical use case for obfuscation is to deliver working code to a client that doesn't already have a history of paying you. When the check clears, the client gets the unobfuscated version. Yes, they could steal the code and run, but they will still have to pay someone with "intermediate knowledge of php internals" in order to decompile it. One hopes it's easier to just pay you. _______________________________________________ New York PHP Users Group Community Talk Mailing List...
_______________________________________________ New York PHP Users Group Community Talk Mailing List http://lists.nyphp.org/mailman/listinfo/talk http://www.nyphp.org/Show-Participation
