NYCPHP Meetup

[Lester Leong]

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" <chsnyder at gmail.com> wrote:

On Wed, Apr 14, 2010 at 1:47 PM, Patrick Saint - laurent
<patrick at 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...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20100414/356821cd/attachment.html>