[php] source encryption

[oogapp0ltje]

ik ben al enige tijd bezig aan een product dat commerciëel gezien potentieel heeft om het te gaan redden. Nu ben ik niet paranoïde ofzo, maar ik zou het erg zonde vinden als iemand de broncode zou aanpassen/voor eigen doeleinden gebruiken. Plus het feit dat in de broncode zelf gegevens staan waarvan ik niet wil dat andere deze zomaar kunnen zien. Ik wil dit dus beveiligen.

Nu weet ik dat er een aantal standaard oplossingen zijn voor dit probleem:

• obfuscation: onveilig, maar maakt source onleesbaar
• zend encoder: veilig, maar vereist een extra installatie van zend op de server
• source guardian: veilig, maar vereist een extensie in php.ini
• andere tools...

alle andere tools die ik tegen ben gekomen (zoals bCompile en turckMMCache) vereisen een geinstalleerde extensie/programmatje server-side. Vaak zelfs nog op zo'n manier dat PHP opnieuw gecompileerd moet worden. Dit gaat ten koste van de portabiliteit van het product dat ik wil distribueren. Is er een oplossing voor dit probleem die overeenstemd met mijn wensen?

[Tux]

De PHP engine heeft geen standaard mogelijkheden om ge-encrypte bestanden uit te voeren, dus een module op de server is nodig.
En een beetje webhoster draait tegenwoorig toch wel Zend Optimizer tegenwoordig

[AtleX]

Veel webhosters draaien tegenwoordig gewoon Zend Optimizer, en dan kan de server gewoon overweg met Zend encoded stuff. Het nadeel is alleen dat Zend Encoder een klein kapitaal kost, het duurt even voor je dat hebt terugverdiend.

[Verwijderd]

je kan ook iOncube encoder gebruiken.. deze hoeft niet persee geinstalleerd te zijn, want er zit een .mod of .so (geen idee meer, maar zoiets) file bij... en die wordt door het php script ingelezen... meer info: http://www.ioncube.com/

[oogapp0ltje]

ja... maar toch gaat het ten koste van de portabiliteit, het is een extra requirement voor een webserver wat ik graag wil voorkomen. ik heb er aan gedacht om zelf een phpscript te schrijven die de source 'decompiled' before execution. maar volgens mij kan dat niet zonder dat je key/password ook op de webserver staat opgeslagen, en daarmee is dus nogsteeds je source niet erg veilig.

[NMe]

Ik denk dat je moet gaan kiezen tussen de verschillende "kwaden". Ik ken geen andere manieren van source bescherming dan die je nu zelf al genoemd hebt, en ik betwijfel dat die bestaan voor een standaard PHP-install.
Wat betreft obfuscaten: er zijn tools die je source vanzelf voor je kunnen obfuscaten. Op die manier hou je zelf gewoon je eigen, leesbare source, en distribueer je de onleesbare. Nadeel is natuurlijk dat hier (met een hoop werk) ook wel uit is te komen. Daarom zou ik gewoon voor de oplossing met de Zend Encoder gaan. Zoals Tux al zegt wordt dat bij het merendeel van de hosts wel ondersteund.

[oogapp0ltje]

Verwijderd schreef op zaterdag 02 april 2005 @ 13:04:
je kan ook iOncube encoder gebruiken.. deze hoeft niet persee geinstalleerd te zijn, want er zit een .mod of .so (geen idee meer, maar zoiets) file bij... en die wordt door het php script ingelezen... meer info: http://www.ioncube.com/

goeie tip, ik ga er even naar kijken.

[oogapp0ltje]

het is alleen mogelijk om ioncube te gebruiken zonder extensions wanneer php draait in safe mode (de functie dl() werkt dan, waarmee handmatig een extension geladen kan worden). Ioncube bied dus ook niet de portabiliteit die ik wens. Is er echt geen oplossing voor dit probleem?

[samo]

Ravenof schreef op zaterdag 02 april 2005 @ 14:19:
het is alleen mogelijk om ioncube te gebruiken zonder extensions wanneer php draait in safe mode (de functie dl() werkt dan, waarmee handmatig een extension geladen kan worden). Ioncube bied dus ook niet de portabiliteit die ik wens. Is er echt geen oplossing voor dit probleem?

Je kan er ook voor kiezen een pakket met vereisten aan te bieden:
- of zend engine optimizer geinstalleerd hebben
- of jij regelt hosting
En als het een commercieel product betreft, kan je een gebruikersovereenkomst sluiten waarin de gebruikende partij accoord gaat de broncode te laten zoals het is.

[ Voor 2% gewijzigd door samo op 02-04-2005 14:32 . Reden: sorry tux ]

[Tux]

samo-arne schreef op zaterdag 02 april 2005 @ 14:21:
[...]

- of zend engine geinstalleerd hebben

Als php op een server draait staat Zend Engine er _altijd_ op Ik denk dat jij Zend Optimizer bedoelt.

[pietje63]

Wat ook mogelijk is, is om een gedeelte van de bestanden alleen op je eigen host te laten draaien en deze dan vanuit de andere bestanden op te roepen.

Ik heb geen idee om wat voor script het gaat en of dit in jouw geval mogelijk is maar ik heb dit tijdens een installatie wel eens gebruikt om een configuratie weg te schrijven (via ftp omdat dit op sommige hosts uitgeschakeld was) en om installaties van mijn script te loggen (en zo mensen die de copyright mededeling verwijderden uit te schelden).

[NMe]

pietje63 schreef op zondag 03 april 2005 @ 01:31:
Wat ook mogelijk is, is om een gedeelte van de bestanden alleen op je eigen host te laten draaien en deze dan vanuit de andere bestanden op te roepen.

Ik heb geen idee om wat voor script het gaat en of dit in jouw geval mogelijk is maar ik heb dit tijdens een installatie wel eens gebruikt om een configuratie weg te schrijven (via ftp omdat dit op sommige hosts uitgeschakeld was) en om installaties van mijn script te loggen (en zo mensen die de copyright mededeling verwijderden uit te schelden).

Als je dat zou doen, dan heb je twee opties: HTML doorgeven, of PHP code doorgeven. HTML doorgeven zorgt voor een soort van beveiliging, maar weinig dynamiek, terwijl PHP-code doorgeven simpelweg geen nut heeft, omdat degene die je script dan gebruikt, ook beschikking krijgt over diezelfde PHP code, door simpelweg op te zoeken waar die code opgehaald wordt, en het dan weg te schrijven naar een bestand. Bovendien werkt geen van de sites die je script gebruiken in het geval dat je eigen site uit de lucht gaat, om welke reden dan ook.

Al met al is dit niet echt een beveiliging waar ik voor zou kiezen.

[JayVee]

turckMMCache bestaat niet meer. De ontwikkelaar daarvan werkt nu bij Zend. Daarnaast wekt het niet meer met PHP >= 4.3.10. Het project gaat echter verder als eAccelerator.

Zelf had ik bijna Turck gebruikt om ons systeem ge-encode en vele malen sneller bij een klant te draaien. Helaas lukte het toen niet meteen om het op Windows aan de praat te krijgen, dus hebben we het niet gedaan. Voor de volgende klanten zoek ik echter zelf ook een manier om het te encoden. Het liefste natuurlijk zo dat het meteen sneller wordt!

[teun-v]

Heb je al gedacht over de installatie, bijvoor beeld door middel van rpm. Hiermee is het mogelijk om veranderingen in de configuratie aan te brengen bijvoorbeeld een regel toe te voegen in php.ini maar ook het plaatsen van alle benodigde bestanden (extensions).

[simon]

Ravenof schreef op zaterdag 02 april 2005 @ 14:19:
het is alleen mogelijk om ioncube te gebruiken zonder extensions wanneer php draait in safe mode (de functie dl() werkt dan, waarmee handmatig een extension geladen kan worden). Ioncube bied dus ook niet de portabiliteit die ik wens. Is er echt geen oplossing voor dit probleem?

volgens mij kan dl() ook buiten safe mode om, tenminste in php.ini stond hij bij mij aan zonder dat safe mode aan stond.

[Verwijderd]

Het is al gezegd.. maar als je zeker wilt weten dat niemand bij je broncode kan, gewoon niet het pakket verkopen, maar de dienst verkopen die je pakket levert.

Zelf de hosting regelen dus, dan weet je zeker dat ze niet bij je bronbestanden kunnen komen.

[Janoz]

AtleX schreef op zaterdag 02 april 2005 @ 13:04:
Veel webhosters draaien tegenwoordig gewoon Zend Optimizer, en dan kan de server gewoon overweg met Zend encoded stuff. Het nadeel is alleen dat Zend Encoder een klein kapitaal kost, het duurt even voor je dat hebt terugverdiend.

Dat valt heel erg mee. Juist voor dit soort eerderkleinschalige producten hebben ze bij zend het small buisness program. Daarbij betaal je voor de encoder maar iets van $295. Dat lijkt mij in ieder geval een minimale investering.

[Verwijderd]

http://www.phplockit.com/

misshien is dit iets ? het is alleen php encryptie zonder server extensies of iets dergelijks. Het is misschien niet zo veilig als Zend maar zeker een optie aangezien het programmatje maar 30 dollar kost.

[Bananeman]

Ravenof schreef op zaterdag 02 april 2005 @ 14:19:
het is alleen mogelijk om ioncube te gebruiken zonder extensions wanneer php draait in safe mode (de functie dl() werkt dan, waarmee handmatig een extension geladen kan worden). Ioncube bied dus ook niet de portabiliteit die ik wens. Is er echt geen oplossing voor dit probleem?

Hoe zou die oplossing dan moeten werken als a) het niet in PHP (Zend Engine) zit, en b) je geen extra software wilt/kunt installeren? Gaat niet vanzelf, natuurlijk.

[simon]

encrypten van source = foetsie portabiliteit... kun je niets aan veranderen

[Verwijderd]

Ik heb zelf ook voor deze vraag gestaan en ik heb gekozen om het zelf te hosten (gaat perfect voor mijn applicatie). De gebruiker krijgt een tooltje aangeboden, in die tool kan je een gebruikersnaam/wachtwoord invullen waarnee je toegang krijgt naar het niet open-source gedeelte van mijn script. Het script is grotendeels open-source, dus ik heb de scheiding zo gemaakt.

[JayVee]

Simon schreef op maandag 04 april 2005 @ 22:36:
encrypten van source = foetsie portabiliteit... kun je niets aan veranderen

Dat klopt niet helemaal volgens mij. TurckMMCache cached gewoon de door PHP gecompilede scripts. Met PHP-Encoder kon je vervolgens je scripts pre-cachen en ze distributen.
Ik weet niet wat er bij het compilen gebeurt en of scripts daardoor platform-afhankelijk worden. Maar ik kan mij toch best voorstellen dat het op dezelfde manier werkt als Java. Met een compiler die bit-code schrijft ipv machine code.

// edit: Oh, en door Turck gecachede / precompilede scripts waren "niet triviaal" te reconstrueren. Ik weet niet of daarvoor extra encryptie gebruikt werd. Je had iig de TurckLoader nodig (die in de cache zat maar die je bij je klant dus los kon installeren) om die scripts te kunnen draaien.

[ Voor 21% gewijzigd door JayVee op 05-04-2005 09:57 ]

[Suepahfly]

Was er ook niet zo'n ongeloofelijk ranzige "encoder" die er zoeits van

PHP:

eval(b64_decode("helelangestring"));

van maakte?


Van eval, echo maken werkte niet heb ik een keer geprobeerd maar vraag me wel af of dit ook nog maar enigzins veilig is. Om nog maar niet te spreken van de enorme overhead die je zo creeerd door eval te gebruiken.

[Bananeman]

Suepahfly schreef op dinsdag 05 april 2005 @ 10:09:
Was er ook niet zo'n ongeloofelijk ranzige "encoder" die er zoeits van

PHP:

eval(b64_decode("helelangestring"));

van maakte?

Tja...

PHP:

echo(b64_decode("helelangestring"));

Heb je je source weer

[ Voor 9% gewijzigd door Bananeman op 05-04-2005 11:48 ]

[simon]

JayVee schreef op dinsdag 05 april 2005 @ 09:54:
[...]

Dat klopt niet helemaal volgens mij. TurckMMCache cached gewoon de door PHP gecompilede scripts. Met PHP-Encoder kon je vervolgens je scripts pre-cachen en ze distributen.
Ik weet niet wat er bij het compilen gebeurt en of scripts daardoor platform-afhankelijk worden. Maar ik kan mij toch best voorstellen dat het op dezelfde manier werkt als Java. Met een compiler die bit-code schrijft ipv machine code.

// edit: Oh, en door Turck gecachede / precompilede scripts waren "niet triviaal" te reconstrueren. Ik weet niet of daarvoor extra encryptie gebruikt werd. Je had iig de TurckLoader nodig (die in de cache zat maar die je bij je klant dus los kon installeren) om die scripts te kunnen draaien.

caching != encryption imho...

[JayVee]

Simon schreef op maandag 04 april 2005 @ 22:36:
encrypten van source = foetsie portabiliteit... kun je niets aan veranderen

Encryptie hoeft toch niet per se portabiliteit tegen te gaan?

[Elijan9]

Ravenof schreef op zaterdag 02 april 2005 @ 12:54:

• obfuscation: onveilig, maar maakt source onleesbaar

Dat zou je eigenlijk niet eens als optie mogen noemen, dat is wel hele slechte reclame naar je klanten toe...

[simon]

JayVee schreef op dinsdag 05 april 2005 @ 14:48:
[...]

Encryptie hoeft toch niet per se portabiliteit tegen te gaan?

binnen php is geen standaard support voor het runnen van encrypted scripts. Dan verlies je binnen php portabliteit..

[Sendy]

Verder is het nooit 100% veilig (ook de genoemde produkten niet -- dat kan namelijk technisch niet). Het enige dat je doet is het, voor leken, moeilijker maken om het te gebruiken, terwijl de slimmen het kopieren en je ideeen jatten. Hierbij laat ik in het midden hoe slim je moet zijn om bij de slimmen te horen; hoe moeilijker jij het maakt hoe slimmer zullen we maar zeggen. Maar hoe moeilijker jij het maakt, hoe lastiger voor de leken.

Zoek dus de gulden middenweg.

[TRON]

Verwijderd schreef op maandag 04 april 2005 @ 21:10:
http://www.phplockit.com/

misshien is dit iets ? het is alleen php encryptie zonder server extensies of iets dergelijks. Het is misschien niet zo veilig als Zend maar zeker een optie aangezien het programmatje maar 30 dollar kost.

Vrijwel hetzelfde, maar dan gratis -> http://encode.qualitysign.nl/ Dus vrijwel nutteloos, omdat het redelijk simpel weer terug te vormen is.

[ Voor 9% gewijzigd door TRON op 05-04-2005 16:25 ]