PHP compilen, kan dat en zo ja hoe?

[Verwijderd]

PHP compilen, kan dat en zo ja hoe? Ik wil dus zo'n exe-bestandje uploaden naar de server en dan gebruiken in mijn webpagina, zodat de hoster mijn bron niet kan achterhalen.

P.S. Ik heb ooit eens iets gelezen over het compilen van PHP, maar dat was geen betrouwbare bron. Ik schat dit forum hoger in en daarom post ik het dus hier. Nou, alvast bedankt. En dit vind ik een andere post als een paar posten terug.

[E-Vix]

Ik heb er in ieder geval nog nooit van gehoord...

Kijk anders eens op www.php.net of er daar soms iets over staat. als het kan dan staat het daar vast wel.

[razor-x]

Op vrijdag 07 september 2001 20:13 schreef E-Vix het volgende:
Ik heb er in ieder geval nog nooit van gehoord...

Kijk anders eens op www.php.net of er daar soms iets over staat. als het kan dan staat het daar vast wel.

* razor-x ook niet

[Janoz]

Op wat voor server moet het uiteindelijk draaien?

[Verwijderd]

hmm ik weet het zo niet hoor
PHP is een scripttaal, maar dit terzijde zijnde.
Indien PHP gecompileerd kon worden tot een exe bestandje, dan zou het toch sterk platform afhankelijk worden? Dan zou je script niet meer overdraagbaar zijn van een WindowsNT systeem naar een Unix systeem als je beslist van webhost te veranderen. Bovendien denk ik niet dat ISP's er zo blij mee zullen zijn als er in het wilde weg EXE's worden geupload en uitgevoerd op hun servers, want PHP wordt tenslotte serverside uitgevoerd.
Misschien dat het wel gaat, maar of je het script dan ook kunt gebruiken voor publieke webruimte? Dat denk ik imo niet.

[wasigh]

Ik heb er wel ooit van gehoord dat ze daar mee bezig waren..

Zend misschien?

[Aike]

Volgens mij laat php je broncode toch al niet zien, en wat zou je er aan geheim willen houden ? Geen wachtwoorden in de code hé!!

[Verwijderd]

Op vrijdag 07 september 2001 20:09 schreef gang-ster het volgende:
Ik wil dus zo'n exe-bestandje uploaden naar de server en dan gebruiken in mijn webpagina, zodat de hoster mijn bron niet kan achterhalen.

Dat kan je hoedanook toch niet vermijden/controleren. Dan kan je beter zelf een server oprichten.

[wasigh]

Als het is om geheim te houden zou ik over stappen op servlets. die je obfucated compiled en dan op de server zet
knappe jongen die achter de src komt

(heb ik al verteld dat dat ook sneller is als.... )

[Verwijderd]

Ik struikelde zonet over dit draadje
is dit misschien wat je bedoeld?

[topic=222623/1/25]

[Disciplus-Simplex]

Ben geen PHP-er maar ik heb me geloof ik laten vertellen dat je de source-code kan encrypten. Deze wordt tijdens een aanroep real-time gedecrypt en vervolgens gecompileerd (uiteraard) en voila de http-stream wordt naar de client gestuurd.
ASP-pagina's kun je sowieso encrypten met een MS-tooltje. Deze encryptie is helaas zo slecht dat je het net zo goed niet kan doen
Tis dus maar te hopen dat dit niet zo is voor PHP.

[Verwijderd]

Ik weet niet hoe dat werkt met die servlets. Kan ik dan nog wel in PHP blijven programmeren of moet ik dan op JAVA overgaan? Ik heb wel redelijk wat ervaring met PHP, maar met zoiets als JAVA(= heel andere manier van programmeren) heb ik geen ervaring. En ik bedoel niet die post.

[wasigh]

Op vrijdag 07 september 2001 20:31 schreef gang-ster het volgende:
Ik weet niet hoe dat werkt met die servlets. Kan ik dan nog wel in PHP blijven programmeren of moet ik dan op JAVA overgaan? Ik heb wel redelijk wat ervaring met PHP, maar met zoiets als JAVA(= heel andere manier van programmeren) heb ik geen ervaring. En ik bedoel niet die post.

Servlets zijn Java natuurlijk, al moet het theoretisch mogelijk zijn php naar java bytecode om te zetten (maar dat is een heel ander verhaal)

Java is niet een andere manier van programmeren, het is alleen een andere syntax (en object ge-orienteerd natuurlijk )

Maar misschien dat een van de php-goeroe's je verder kan helpen (als je java vragen hebt, kan ik je misschien wel verder helpen )

[Verwijderd]

Het is inderdaad encrypten van PHP pagina's. Hiervoor heeft Zend een tweetal programma's ontwikkeld om dit mogelijk te maken. Namelijk de Zend Encoder Unlimited en de Zend Optimizer. De laatste is de zend-extension voor PHP die nodig is om de ge-encrypte bestanden te kunnen uitvoeren. Deze extension is gratis (ik weet niet of dat ook voor commercieel gebruik geld) en heeft daarnaast ook nog het voordeel dat het je pagina's optimaliseerd waardoor je server meer requests kan afhandelen. De encoder is helaas dus niet gratis, en zelfs eigenlijk wel pittig geprijst (namelijk $2400).. Voor een huis, tuin en keukenprogrammeur dus eigenlijk niet te doen...

[Infinitive]

* Infinitive heeft een idee:

Zou het mogelijk zijn de source van php te veranderen dat hij 1) niet een file opend opgegeven via de commandline (cgi-mode), maar een file die (encoded) is opgeslagen "intern" als een string.

Volgens mij een kwestie van in de main-functie beginnen en kijken waar de cmd-line geparsed wordt, deze voor een deel aanpassen. Vervolgens kijken hoe een file geopend wordt (en i.p.v. de file reads een decrypt read van de interne variable). Verder gooi je je gehele file in in string in de source code (een static string), en verder encode je deze ook nog op een simpele manier (en in je source decode je de string voordat je deze gebruikt). Vervolgens bak je je code als cgi-module (als je 'm kan compilen en je hebt cgi support op je server dan kan je dat gewoon doen) en daar is je executable.

Misschien moest ik dit maar eens gaan proberen als ik tijd heb... klinkt nog niet eens onmogelijk... morgen de php source-code nog maar eens een keer downloaden...

[Slagroom]

Volgens mij is er wel zoiets... moet je eens op php.net kijken... daar vindt je iets over GTK of zo... ik weet niet als ie kan compilen... maar ja... moet je maar ff kijken... hij kan wel forms maken enzo

[Orphix]

jah maar dan zijn je scripts niet echt meer uitwisselbaar...dus dan begrijp ik het doel niet helemaal meer?

[Verwijderd]

Dit kwam ik voor mijn vakantie tegen, ik heb het nog niet bekeken maar misschien is het wat: http://gtk.php.net

[StephanL]

Op zaterdag 08 september 2001 07:34 schreef eldeejee het volgende:
Dit kwam ik voor mijn vakantie tegen, ik heb het nog niet bekeken maar misschien is het wat: http://gtk.php.net

dat is alleen geen script meer, daarmee kan je met php programma's maken

[Verwijderd]

Ik zie dus dat ik of al moet binnengelopen zijn voordat ik zo'n suite kan kopen of al rijk moet zijn van mezelf. Nou, dat zijn weer lekkere hulpmiddelen voor het groeien van PHP als taal.
Heeft er niemand anders ooit gedacht van: Ik ga dat echt niet betalen, ik maak zelf ff (binnen een paar maanden) een programmatje waarmee hetzelfde kan.

[Verwijderd]

http://www.zend.com

moet je wel kopen

[Verwijderd]

niet betalen, ik maak zelf ff (binnen een paar maanden) een programmatje waarmee hetzelfde kan.

Ik ben bezig met m'n ideetje
Een stand-alone compilatie van php met het scriptje erin geembed (met een simpele vorm van encryptie zodat je de source niet zomaar kan lezen, tenzij je aan het debuggen gaat... maar de meeste copy&paste php mensen kunnen dat niet).

Je moet dan wel voor elk script een nieuwe php bakken... niet erg efficient (nogal groot wat mb's betreft), maar je hebt dan wel voor elk php script een aparte config file en je kan de source niet zomaar lezen (en dat was de bedoeling).

Koste alleen wat moeite om de structuur van php door te krijgen...

[Verwijderd]

Geweldig! Hoe ga je dat dan precies doen? Ik zou echt niet weten hoe je zou moeten encrypten/decrypten en in welke taal je dat dan zou gaan doen. Ja, ik encrypt wel eens met md5, maar dan heb je het wel gehad. Ik wilde trouwens dat mensen die zo'n site hosten de source niet kunnen zien. Het moet eigenlijk dus alleen door PHP worden gelezen en niet echt gededrypt kunnen worden zoals bij een exe-bestand (tenminste ik denk dat dat daar voor geldt). Kun je me een keer een berichtje via ICQ #33031622)of via MSN (Goron)sturen als het af is?

[Gerco]

Kun je dan niet beter in de php source de filereader dinges aanpassen zodat hij (Blowfish) geencrypte files kan lezen? Embed de key in de php source of in de php config file.

Op die manier kun je geencrypte source opslaan en heb je nog steeds maar 1 php executable nodig. Het lijkt me ook nog eens een veel simpelere wijziging in de php source dan wat jij voorstelt.

[Verwijderd]

Ja, maar dan moet wel je provider *jouw* custom php-executable accepteren.

En in dit geval hoef je alleen maar CGI mogelijkheid te hebben en het doet het al.

Als encryptie dacht ik heel simpel het volgende te doen (de uitvoer wordt dan naar een header-file geschreven die dan in php geinclude wordt):
(voorbeeld code:)

code:

const char *key = "blabla...";
char data[] = "<? .... ?>";
char *p;
char *q;

p = data;
q = key;
while (*p)
{
    *p ^= *q;

    p++;
    q++;
    if (!*q)
      q = key;
}

Vanzelfsprekend moet de php executable hetzelfde weer doen om de code terug te krijgen (*als* je dit truukje weet en je weet waar de key en de encrypted-data-string zijn opgeslagen, dan kan je de originele code eruit hacken, maar de meeste mensen zullen dit niet kunnen).

De reden voor een simpele encryptie: het decrypten moet niet veel tijd kosten.

[Bigs]

Vroeger was er een (geinterpreteere) programmeertaal Euphoria, die kon je programma's ook 'encoden'. Dat hield gewoon in dat ie alle commando's verving door 1 teken, al je variabelen onbegrijpelijke namen gaf en alle strings codeerde ofzo. Op zich kun je zoiets voor PHP ook wel maken, gewoon met een extra scriptje/progje voor de PHP module die het weer decodeert naar gewoon PHP (maarja, dat kan dan natuurlijk ook weer misbruikt worden door personen om het gewoon los te decoderen).

[Verwijderd]

MD5

Die kan je hiervoor niet nemen, deze encrypt maar 1 kant op.

Kun je dan niet beter in de php source de filereader dinges aanpassen zodat hij (Blowfish) geencrypte files kan lezen? Embed de key in de php source of in de php config file.

Ik ken Blowfish niet... is daar een RFC/documentatie van? (tuurlijk )

Kun je me een keer een berichtje via ICQ #33031622)of via MSN (Goron)sturen als het af is?

_als_
Ik heb geen ICQ of MSN geinstalleerd, je zult dan dit topic in de gaten moeten houden

Weet iemand eigenlijk of je wat ik nu aan het doen bent wel mag doen wat licence agreements ofzo? Ik ga het niet verkopen ofzo (het is voor mij niets waard).

Zijn er trouwens nog GoT'ers die de php source-code een beetje kunnen?

[voorlopige analyse]
Ik ben er achter dat voor het inlezen van het script (als dat script geen includes heeft) alleen de code in de functie "open_file_for_scanning" (en mogelijke functies die door die functie wordt aangeroepen) van belang is (om de read-code te wijzigen), daarna zit het script in een of andere geheugenbuffer.

[Verwijderd]

't is me gelukt. Het is nog niet af, maar het doet het:

na het compileren zit het script in de executable (php) gebakken. Ik run m'n script door (./php) in te tikken (als webpagina zou je dan moeten renamen naar index.cgi ofzo).

Commandline parameters en ook een file via de commandline heb ik uit de source gehaalt om het security gat te dichten wat er zou zijn als je de php-executable in je webtree zet. Je wil deze php-executable toch niet gebruiken om andere scripten uit te voeren behalve hem zelf. De meeste opties van php kan je op compile-time al opgeven, vandaar dat zelfs een php.ini niet nodig is

Ik moet nu nog even de encryptie regelen en nog wat tooltjes maken die een script in de source plakt en dan het script herbouwd (onder linux een kwestie van make).

Weet iemand trouwens hoe je php onder windows compileert? Want nu werkt het alleen nog maar onder linux...

Wat eigenlijk nog beter zou zijn is het volgende: php compileert runtime je code naar een linked list van instructies. Als je i.p.v. je source code php meteen deze linked list aan kon rijken dan zou dat betekenen dat je een speedboost en een eigenlijk niet te decrypte source hebt. Maar goed, dat is wel erg lastig om te maken

[Orphix]

Wat eigenlijk nog beter zou zijn is het volgende: php compileert runtime je code naar een linked list van instructies. Als je i.p.v. je source code php meteen deze linked list aan kon rijken dan zou dat betekenen dat je een speedboost en een eigenlijk niet te decrypte source hebt. Maar goed, dat is wel erg lastig om te maken

hehe, een soort PHP intermediate bytecode
ik begrijp je idee nu beter (had er niet aangedacht dat je php ook als cgi programma op je hoster kan uitvoeren)
helaas is mijn php dll hier al 980 kb...dus het zou mooi zijn als je dat nog kleiner zou kunnen maken. Of meerdere scripts in 1 executable....
je zou natuurlijk als argument een scriptnaam kunnen opgeven, en dat die aan de hand daarvan het juiste script laadt (die al meegecompileerd is)

[Gerco]

Op zaterdag 08 september 2001 19:26 schreef Orphix het volgende:
hehe, een soort PHP intermediate bytecode

Laat dat nou precies zijn wat die Zend Encoder Unlimited doet

je zou natuurlijk als argument een scriptnaam kunnen opgeven, en dat die aan de hand daarvan het juiste script laadt (die al meegecompileerd is)

Je zou natuurlijk ook dat script NIET mee kunnen compileren en laten laden uit een file. Dan hoef je maar 1 executable te hebben en een stapeltje encrypted sourcefiles.

[Verwijderd]

Een hele explosie van berichten. Misschien komt er nog een keer wat uit. Ik post het anders over een half jaartje nog eens. Heb ik ook geen ICQ meer nodig

[Infinitive]

Damn. Bij de compilatie van PHP worden een tweetal tooltjes (bison en flex) gebruikt. Dat kon ik onder linux niet zien want zo'n make gaat daar veel te snel voor. Onder windows viel het me op omdat ik deze twee programma's niet had (je kan ze downloaden op http://www.monmouth.com/~wstreett/lex-yacc/lex-yacc.html ).

Nu is het probleem dat bison/flex _juist precies de file genereren waar ik de belangrijkste aanpassingen aan heb gemaakt. Onder linux voerde bison/flex blijkbaar een check uit of de output file al bestaat en of deze nieuwer is dan de file die hij zelf overnieuw gaat genereren, want onder linux wordt 'ie niet overgeschreven (vandaar dat het niet opviel). Onder windows wel, dus die veranderingen ben ik kwijt...

Toen ik het zaakje mee naar huis wilde nemen had ik nog even een "make clean" gedaan, want die onder linux gecompileerde files heb ik onder windows niet nodig. Maar in de makefile staat ook dat hij dan de file van bison/flex moet deleten. Ofwel, ik ben het hele zaakje kwijt

Dat is op zich nog niet zo erg, want het waren maar een aantal wijzigingen en ik weet nog waar ze moeten komen. Het probleem zit 'm juist in dat ik die wijzigingen moet gaan maken in een file die automatisch gegenereerd wordt van een template en in die template bestaat de functie die ik aan wil passen niet (die wordt blijkbaar gegenereerd).

De enige oplossing die ik kan bedenken is het volgende: op elke linux systeem zal die file wel hetzelfde zijn en op elk windows systeem zal die file ook wel hetzelfde zijn (misschien is die gegenereerde file onder windows en linux hetzelfde, want er komen #ifdef WIN32 enzo onder linux in voor). Nu kan ik ook de output van die file pakken en opslaan als een andere file, en nadat de automatische code gegenereerd de automatische file vervangen. Ik ben alleen geen held in linux en windows makefiles... Met wat geluk zou ik die automatische code generatie eruit kunnen slopen.

Er zitten hier vast wel wat mensen die meer weten over bison/flex, kunnen die een toelichting geven?

Dan heb ik ook nog het probleem dat bij mij php absoluut niet onder windows wil compileren (vooral "Cannot open include file: 'arpa/inet.h'" maakt me het level zuur, het lijkt me juist dat deze include voor linux is bedoelt). Misschien dat ik anders maar eens een oudere versie moet nemen (4.0.5 i.p.v. 4.0.6).

Dus ja, verwacht voorlopig nog even geen resultaat... maar het komt eraan.

hehe, een soort PHP intermediate bytecode

Het probleem zit 'm weer bij dat bison/flex. De source van die code wordt door bison/flex gegenereerd. Die code is nogal lastig (veel macro's/slecht leesbare functienamen), wat wel zal komen omdat het automatisch gegenereerd wordt. Maar in principe zou het mogelijk moeten zijn om het compile en het execute gedeelte van php te scheiden.

Als je er overigens even over nadenkt, kan je de volgende dingen zeggen:
* de programma structuur blijft hetzelfde, dus ook die boom van opdrachten.
* de interne variablen worden in een hash-array gegooit. Een deel ervan bestaat uit programma variablen en een aantal uit environment (CGI/cookie/etc) variablen.
* De hash-array(s) kan je dus voor een deel al hard inbakken, even als de linked list. Het andere gedeelte moet dan run-time geladen worden. Helaas is deze stap nogal lastig.

Verder is het bekijken van php's source-code wel aardig... als je php gebruikt en je kan c/c++ dan moet je er ook eens in kijken en zien hoe php achter de schermen werkt. Wat je dan ziet is dat php eigenlijk alleen maar een schil is om de zend-engine heen (vergelijk php met een library&os en zend met een compiler).

[Johannes]

Ik ken wel het programma PHPCompiler, die volgens mij net zoiets deed als je wilde. Je kan 'm hier downloaden, maar de officiele site, www.deskcode.com/phpcompiler is al een hele tijd down.(Jammer genoeg, want ik zat even vaak op Deskcode als op GoT)

Het is wel nog duidelijk een 0.02 versie, en ik weet niet of er nog wel verder aan gewerkt wordt. Ook heb ik het zelf nooit gebruikt, maar misschien is het te gebruiken.

[Infinitive]

Op zaterdag 08 september 2001 21:17 schreef Gerco het volgende:

Laat dat nou precies zijn wat die Zend Encoder Unlimited doet

Ja, dat las ik net.

Je zou natuurlijk ook dat script NIET mee kunnen compileren en laten laden uit een file. Dan hoef je maar 1 executable te hebben en een stapeltje encrypted sourcefiles.

Hum ja, dat heb je al gezegt. Hoewel je dan maar 1 php executable hoeft te bakken, moet je wel een php op een bereikbare plaats hebben staan (en vooral niet in je webtree -> om php.cgi?/etc/passwd te voorkomen), maar dan moet je wel voldoende rechten hebben om daarbij te komen, etc.

Ik ken wel het programma PHPCompiler, die volgens mij net zoiets deed als je wilde. Je kan 'm hier downloaden, maar de officiele site, www.deskcode.com/phpcompiler is al een hele tijd down.(Jammer genoeg, want ik zat even vaak op Deskcode als op GoT)

Ja die doet hetzelfde. Het progje werkt bij mij wel niet, maar de bedoeling is hetzelfde. Dus ja, dan hoef ik ook niet verder te gaan (tenzij iemand interesse heeft?). Is wel leuk om te doen, maar als er al iets voor is dan hoeft het voor mij niet.

[Gerco]

Op zaterdag 08 september 2001 22:17 schreef Infinitive het volgende:
Hoewel je dan maar 1 php executable hoeft te bakken, moet je wel een php op een bereikbare plaats hebben staan (en vooral niet in je webtree -> om php.cgi?/etc/passwd te voorkomen), maar dan moet je wel voldoende rechten hebben om daarbij te komen, etc.

Dat moet je ook met jouw source-erin-compilen oplossing. Je moet die executables ergens neerzetten. Op een goed geconfigde webserver heeft een cgi-user geen rechten om in /etc/passwd te lezen, dus dat is het probleem niet.

Er zijn wel meer plaatsen die php als cgi gebruiken en daar geen problemen mee hebben. Ik bouw alleen voort op die oplossing, dan hoef je minder werk zelf te doen.

[Infinitive]

Dat moet je ook met jouw source-erin-compilen oplossing. Je moet die executables ergens neerzetten. Op een goed geconfigde webserver heeft een cgi-user geen rechten om in /etc/passwd te lezen, dus dat is het probleem niet.

Klopt. Als je het zo ziet dan maakt het eigenlijk niet uit welke manier je neemt. Net erna wat je zelf makkelijker vindt.

Het programmatje waar Tardino op wees pakt het nog wat handiger aan: het bakt de file gewoon direct in het resource-gedeelte van de exe-file het dumpt de source-code gewoon aan het eind van de exe-file. Dan hoef je die niet meer te hercompileren. Maar ja, ik zou dan weer niet weten hoe je zoiets dan weer onder linux doet.

En gang-ster, check eens dat progje van Tardino en kijk eens of je er wat aan hebt.

[Verwijderd]

Zijn er op dit gebied nog nieuwe ontwikkelingen?