Lots of entertaining replies. :-)
A security attacker could simply replace the program with something
else entirely. But I'm getting ahead of myself. If the main concern is
that someone could break into the hosting site and change the PHP code
to do something evil, than you could set-up a way to monitor the PHP
(.php) source code. Do a 'sum' of all the .php and related files.
Store this away from the PHP directories, and put it in the cron to
run to do a 'sum' of all the .php files and send an e-mail alert if
anything has changed along with the 'diff' output. This is assuming
this monitoring is being done on a production server where development
of the .php code isn't taking place with constant changes. With this
scheme, you would be made aware of a change in any PHP code that's on
the production server, and how it has been changed. This may reduce
the fear if wondering if the site has been attacked and if so, what
might have been changed.
If a program contained the "secret sauce" I think I'd look at writing
it in something that compiles like "C". At least there wouldn't be a
reason to have source code for it of any kind running on a production
server that's exposed to web attacks.
Hope this helps!
David Roth
On Apr 14, 2010, at 3:36 PM, Lester Leong wrote:
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
http://lists.nyphp.org/mailman/listinfo/talk
http://www.nyphp.org/Show-Participation
