NYCPHP Meetup

[David Roth]

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" <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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20100415/195581dd/attachment.html>