Jump to content

Protect php source code


o3d

Recommended Posts

Does any one have a better idea to protect PHP files so that you can distribute a 'release' without the customer being able to read the source files. There are tools on the internet which costs money, BUT your are dependant on their software and if its not open source, its not trustworthy.

 

What I've done so far is writing an ISAPI DLL in borland cpp and installed it under iis6. Basically you call this isappi dll and it decrypts the encrypted php files and executes them respectively. It is thread safe (as is php). There are other methods available on the net that you use to encrypt your pages, BUT the decryption algorithm is found in your main php file and duh, if you can read the main file, you can easily decrypt all other files, so that is a bad idea. Any other ideas? Possibly to write a PHP extension perhaps but I have not been able to get that working on borland cpp.

Link to comment
Share on other sites

  • 2 weeks later...
  • 1 month later...
  • 2 weeks later...
  • 2 months later...

To encrypt php source files is not the problem, the problem is that when you decrypt your php files in an extension library you will have to parse the decrypted php code to a script to be eval'ed.

 

sometin like this:

<?PHP

dl('cryptor.so');

eval(decryptFile('myEncryptedFile.php'));

?>

 

Should you want to sell this code to a customer, they can easily just echo the contents of decryptFile('filename'); and view the source. So this was a bad idea to start off with.

 

My next challenge is going to be to try and modify the Zend Engine to be able to accept either a normal php file or an encrypted php file. By doing this i should be able to give a customer a new php library as well as encrypted files which would not interfere with his current php files. Please give me your thoughts on this.

Link to comment
Share on other sites

I have been trying to decode using base64 but was unsucessful.  What is the proper way to decode base64.  Here is the file I am trying to decode.

 

<?php $_F=__FILE__;$_X='P0Q+P1lUWQ0gdSoJdElySy1JeEtjWXctS31Hb3pZVFkJKnUNIElySUljdkdfSXd9S3coKTsNIA0gY0d4MXQucigndElySy1JeEtjWXctSVR9S3IuemNHeHpZVFknKTsNIA0gJC5zLUR9Li5fS31Hb2NHaigkX008TmgzJ2NCfWpyYy4nUiw2JF9NPE5oMyd9MXN0QmMuJ1IsNiRfTTxOaDMnS31Hb0p9MXRyJ1IpOw0gDSANID9E';$_D=strrev('edoced_46esab');eval($_D('JF9YPWJhc2U2NF9kZWNvZGUoJF9YKTskX1g9c3RydHIoJF9YLCd1VzVQOFZrb2xjSFFTWHkyRm0gNFJ0Cnc8MGhiM11nSmpwRTZNZjc9VT5LTGlBR3hhMXo5WmRldltuTy5zWVRESU57Q31CcXIvJywnL0QwNTN4Mms5aVZNezdacTRHCkpddUF0T0JUNltFSHZnS1ggUH04akw8cj15MW5jUWwuTndXVW9SSUZkYnBoPnNTWXphbUNlZicpOyRfUj1zdHJfcmVwbGFjZSgnX19GSUxFX18nLCInIi4kX0YuIiciLCRfWCk7ZXZhbCgkX1IpOyRfUj0wOyRfWD0wOw=='));?>

Link to comment
Share on other sites

  • 1 month later...

I wlunder why do you want to release an encrypted software? IMHO I would realase it open so the users will be able to develope plugins to the software that could be used as a feature in the next release just like what vBulletin did, but in the other hand protect the copyrights of the orginal code ..

 

 

Link to comment
Share on other sites

  • 2 weeks later...

I wlunder why do you want to release an encrypted software? IMHO I would realase it open so the users will be able to develope plugins to the software that could be used as a feature in the next release just like what vBulletin did, but in the other hand protect the copyrights of the orginal code ..

 

Hello SpireLink.. Actually the author of the topic is trying to create something more secure .. so such things have to be encrypted inorder to protect from other users..

 

Will this help ??

 

Original Code -> Base64 Encode -> DES Encrypt -> Encrypted Code [Encryption Process]

 

Encrypted Code -> DES Decrypt -> Base 64 Decode -> Original Code [Decryption Process]

Link to comment
Share on other sites

  • 2 weeks later...

Hi d.shankar,

 

The problem i'm still having is at some point, you will have to eval your decrypted code. At this point, any person with some php sense would be able to just echo whatever is sent to the eval function and that would be clear php text (except in obfuscation ofcourse, but can be interprete still).

 

What needs to be done is to modify the zend file parser process to accept two types of files, clear text php and encrypted php files (which can be identified by a possible fixed header in the encrypted file). Unfortunately this envolves serious understanding about zend (which i don't have, but am learning very quickly). You will need to give a custom php-release for each customer who will then be able to interpret your encrypted php code.

 

Will keep everybody updated as to my progress, but it's going slow, so anyone with more experience are welcome to help.

Link to comment
Share on other sites

  • 1 month later...
  • 2 weeks later...
  • 3 months later...
  • 3 months later...

I think it's pretty useless.

 

If you write anything of any value, it would come with a support contract.

 

From a business perspective, it makes so much more sense to pay the creator than to pay someone who works for me to:

a) learn the framework/code and

b) confident enough not to break anything when making an update.

 

As an employee, I don't want that responsibility, either. I would much rather have the vendor support the product because he is liable for breaking old functionality and ensuring proper cycles are invested in the new stuff :)

Link to comment
Share on other sites

I see your point but when your programming a piece of software fair gain to anyone doing what Smarty did and stuff but strict web applications being sold as software would be good to encrypt it I mean you dont get the source for the games you buy do ya ;)

 

As a vendor it interests me to protect my work from code thieves too ;)

 

::)

Link to comment
Share on other sites

I think it's pretty useless.

 

If you write anything of any value, it would come with a support contract.

 

From a business perspective, it makes so much more sense to pay the creator than to pay someone who works for me to:

a) learn the framework/code and

b) confident enough not to break anything when making an update.

 

As an employee, I don't want that responsibility, either. I would much rather have the vendor support the product because he is liable for breaking old functionality and ensuring proper cycles are invested in the new stuff :)

 

Unfortunately not everyone thinks like you do my friend. A few years ago in my student days I developed an eCommerce client for a company. After a few months of providing support they found someone who would do it for much cheaper so cut ties with me and kept the software. Now days I include a self-destruct sequence in all my code just incase that happens again!

 

I'm totally new to PHP code encryption so if any one could point out some good tutorials or concepts I should learn about that would be great! If I do get anything I'll post it here.

Link to comment
Share on other sites

I think it's pretty useless.

 

If you write anything of any value, it would come with a support contract.

 

From a business perspective, it makes so much more sense to pay the creator than to pay someone who works for me to:

a) learn the framework/code and

b) confident enough not to break anything when making an update.

 

As an employee, I don't want that responsibility, either. I would much rather have the vendor support the product because he is liable for breaking old functionality and ensuring proper cycles are invested in the new stuff :)

 

Unfortunately not everyone thinks like you do my friend. A few years ago in my student days I developed an eCommerce client for a company. After a few months of providing support they found someone who would do it for much cheaper so cut ties with me and kept the software. Now days I include a self-destruct sequence in all my code just incase that happens again!

 

I'm totally new to PHP code encryption so if any one could point out some good tutorials or concepts I should learn about that would be great! If I do get anything I'll post it here.

 

I think thats ultimately your fault. Or, I have a different/better sense of business. If you planned on having a managed service you would get in to contract for product fee + support for X period. If you didn't plan on having a managed service, the price of your software should go up. If they come to you for more business, awesome. If they don't, you should have still made money.

 

I'll let you guys play in your sandbox, though.

Link to comment
Share on other sites

*bump* :D

 

Unless someone got access to the actual file, they can't view the php source code anyway, so why need to encrypt it, or does it mean HTML as well?

 

 

 

 

I think he means his HTML/CSS

Link to comment
Share on other sites

  • 1 month later...

To encrypt php source files is not the problem, the problem is that when you decrypt your php files in an extension library you will have to parse the decrypted php code to a script to be eval'ed.

 

sometin like this:

<?PHP

dl('cryptor.so');

eval(decryptFile('myEncryptedFile.php'));

?>

 

Should you want to sell this code to a customer, they can easily just echo the contents of decryptFile('filename'); and view the source. So this was a bad idea to start off with.

 

My next challenge is going to be to try and modify the Zend Engine to be able to accept either a normal php file or an encrypted php file. By doing this i should be able to give a customer a new php library as well as encrypted files which would not interfere with his current php files. Please give me your thoughts on this.

 

Well, you can do the call with call_user_function() inside the extension to decipher the file, and zend_eval_string() to run the code, so no echo there.

Link to comment
Share on other sites

There's a fundamental problem in that the code must be decrypted on the customer's machine.  So it's a question of how well you can obfuscate the process, rather than making it impossible for the customer to access unencrypted code.

 

Distributing compiled code (in the way that Xcache and APC store compiled code) will go some way to obfuscating.  That means the customer has to reverse engineer the code to get source without variable names, and possible with incorrect structure as well (due to optimizations or ambiguous object code).

 

Then if you're serious you can have code which decrypts code which decrypts the real program.  That's the kind of thing programmers would do on the old Apple II and similar PCs to stop people copying their games.  Rarely will people have the knowledge and time to go through two layers, only to find that they get compiled code that they have to decompile.

 

Then you can go extreme and write your own self-modifying assembly code to decrypt the program .. that will drive people crazy :)  Even when they view that code, they can't see what it really does until they run it (or simulate running it).

 

These are all obfuscation ideas, because that's what you need here, rather than foolproof encryption.

 

 

keeB, you're making the assumption that your clients know what's best for them :)

Link to comment
Share on other sites

  • 3 weeks later...
This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.