Zend optimizer gekraakt?

[Verwijderd]

Ik kwam een bericht tegen op http://www.geenredactie.n...end-is-gekraakt%E2%80%A6/ daarin staat dat Zend is gekraakt.

Wat weten jullie hiervan? Ik ga zo een test file sturen om het te testen.
Graag jullie mening erover.

[Mammon]

Ik heb hier nog niks over gehoord maar als ik het zo lees vind ik het verhaal en de bron hoogst onbetrouwbaar.

[Verwijderd]

Ik heb een bestand gestuurd wil het wel ff zien hahaha..
dus ben benieuwd als ik wat terug krijg post ik het..

[Verwijderd]

mm ik ben best wel onder de indruk, zit wel een klein foutje in zag ik maar dat is voor een phper heel makkelijk aan te passen.

Jeetje.. de 2 bestandjes php kan je hier downloaden http://rapidshare.com/files/68374661/index-de-ze-nd.rar.html

Wie weet sinds wanneer dit eigenlijk gekraakt is?

[BCC]

Zend compiled toch gewoon naar bytecode? Dus dan heeft iemand de bytecode weer omgezet naar PHP.. Een disassembler/decompiler oftewel: nieuwswaarde 0?

[ Voor 11% gewijzigd door BCC op 08-11-2007 21:55 ]

[Peter]

Nee, niet helemaal. Een aantal jaar terug was er ook een dergelijke de-compiler voor vorige versies van de Zend Optimizer, het is dus ook niet nieuw. Een dergelijke de-compiler kan de code vrij gemakkelijk terugzetten naar normale PHP code, wat meestal gebeurd door het moment in de php-engine te vinden waar de gecompileerde code toch weer naar normale PHP code moet gaan om uitgevoerd te kunnen worden.

[Verwijderd]

@Bcc Ja dat geloof ik ook wel, maar waarom zeggen ze dan dat het zo veilig is? Dat snap ik niet helemaal.

@Peter Nee klopt dat had ik toen ook gevonden maar die werkte niet helemaal, maar dit blijft toch 99,9% te werken.

Nou ik vind het wel grappig dat het gebeurt is. Voor mij geen zend optimizer haha maar een andere oplossing bedenken of vinden.

[Peter]

Voor mij werkte het echter prima hoor Heeft dan waarschijnlijk met het script te maken

[Verwijderd]

mm dat denk ik dan ook,

[BCC]

Verwijderd schreef op donderdag 08 november 2007 @ 21:59:
@Bcc Ja dat geloof ik ook wel, maar waarom zeggen ze dan dat het zo veilig is? Dat snap ik niet helemaal.

@Peter Nee klopt dat had ik toen ook gevonden maar die werkte niet helemaal, maar dit blijft toch 99,9% te werken.

Nou ik vind het wel grappig dat het gebeurt is. Voor mij geen zend optimizer haha maar een andere oplossing bedenken of vinden.

Probleem heb je ook bij Java, .Net, ruby..C.. dus wat wil je precies oplossen? Alles is altijd te decoompilen...

[Verwijderd]

Peter schreef op donderdag 08 november 2007 @ 21:56:
...wat meestal gebeurd door het moment in de php-engine te vinden waar de gecompileerde code toch weer naar normale PHP code moet gaan om uitgevoerd te kunnen worden.

What about bytecode?

[Verwijderd]

Wat ik wil oplossen is een 100% veilige compiler.. want zend is dus te kraken.

[rvanlooijen]

Verwijderd schreef op donderdag 08 november 2007 @ 22:04:
Wat ik wil oplossen is een 100% veilige compiler.. want zend is dus te kraken.

Hmja het enige wat ik hieraan gedaan heb is zelf een php scripted oplossing geregeld, hoewel het daarmee simpelweg niet te voorkomen is dat eindgebruikers de code kunnen achterhalen. Je maak het in ieder geval wel een flinke stap lastiger en daarnaast is het onmogelijk om zo maar 1 op 1 je applicatie te decrypten...

Ik ben benieuwd naar de officiele uitwerking van dit gebeuren, het zou zomaar kunnen dat mensen weer eens erg veel hebben betaald voor een product wat flink tegenvalt. Immers, je code hoeft maar 1 keer gedecrypt te zijn om op straat te liggen...

[Peter]

Verwijderd schreef op donderdag 08 november 2007 @ 22:03:
[...]

What about bytecode?

Samen met een stel anderen zit ik in een team dat GTA San Andreas naar een 200-man online spel gemaakt heeft, met niets anders dan een .exe bestand. Dat stopt echt niemand hoor, het maakt het wel moeilijker, maar het is zeker niet onmogelijk. Bytecode is naar ASM (ware het PHP-specifiek) te converteren wat weer teruggezet kan worden naar gewone PHP code. Verder zijn er voor zover ik weet geen compilers die echte bytecode genereren voor PHP scripts.

[Verwijderd]

Ik ben benieuwd naar de officiele uitwerking van dit gebeuren, het zou zomaar kunnen dat mensen weer eens erg veel hebben betaald voor een product wat flink tegenvalt. Immers, je code hoeft maar 1 keer gedecrypt te zijn om op straat te liggen...

Dat ben ik dus ook, dit kan namelijk niet zonder gevolgen blijven.
Ik had hem wel een mailtje gestuurd, maar hij zegt dat er een versie momenteel in omloop is, die wel veel fouten heeft maar niet de orginele in omloop brengt omdat hij in gesprek is met zend nederland om de bugs te maken.

vind het nog al niet een bug, dit is gewoon een gat van 10 meter breedt..
Maar toch wel respect voor iemand die dit kan

Samen met een stel anderen zit ik in een team dat GTA San Andreas naar een 200-man online spel gemaakt heeft, met niets anders dan een .exe bestand. Dat stopt echt niemand hoor, het maakt het wel moeilijker, maar het is zeker niet onmogelijk. Bytecode is naar ASM (ware het PHP-specifiek) te converteren wat weer teruggezet kan worden naar gewone PHP code. Verder zijn er voor zover ik weet geen compilers die echte bytecode genereren voor PHP scripts.

Nee van een exe bestand snap ik dat ook nog wel, maar de php wordt zo weggeschreven met beveiligingen dat ik dit nooit had verwacht.. Wel cool trouwens dat je in een team zit van GTA SA vind het spel onwijs geweldig..

[frickY]

Peter schreef op donderdag 08 november 2007 @ 21:56:
Nee, niet helemaal. Een aantal jaar terug was er ook een dergelijke de-compiler voor vorige versies van de Zend Optimizer, het is dus ook niet nieuw. Een dergelijke de-compiler kan de code vrij gemakkelijk terugzetten naar normale PHP code, wat meestal gebeurd door het moment in de php-engine te vinden waar de gecompileerde code toch weer naar normale PHP code moet gaan om uitgevoerd te kunnen worden.

De Zend Optimiser encode niet, maar compileert. Net als wat je PHP engine doet op het moment van uitvoer.

Normaliter wordt je php-bestandje geparsed, gecompileert, en gerunned.
De Zend Optimeser parsed en gecompileerd je bestand, en slaat dat resultaat op. Die versie is kant en klaar om te runnen; bytecode. Daarom is het ook een optimizer, je slaat de zware stap van het parsen over.

Bytecode zou je kunnen reverse engineren maar je zou dan nooit hetzelde bestand terug kunnen krijgen als het orgineel. Comments worden door de parser bijvoorbeeld niet eens overgenomen, en zouden dus sowieso verloren moeten zijn. Ook alle tabs en regeleindes worden genegeert, die zijn immers zonde van de ruimte. Uit de bytecode kun je echter wel de functionaliteiten achterhalen, en opnieuw uitschrijven in PHP syntax.

Ik meen dat de laatste Optimzer/Guard de bytecode ook ietwat obfuscate om reverse engineren moeilijker te maken, maar onmogelijk zal het nooit zijn. Zo blijkt.

[ Voor 4% gewijzigd door frickY op 08-11-2007 23:16 ]

[Peter]

Dat commentaar verloren gaat en variable/functie namen gescrambled worden is natuurlijk iets dat je sowieso kan verwachten van een goede compiler c.q. optimizer zoals deze van Zend. Wat er hier gedaan wordt is dan ook precies dat, na vijf major PHP-versies en een groot deskundig team mag je van Zend in ieder geval wel verwachten dat commentaar etc. gestripped wordt, decompilen zal echter altijd mogelijk blijven, tenzei ze geavanceerde runtime-code systemen zoals een anti-tamper systeem gaan implenteren, wat het wel een enorm stuk ingewikkelder zou maken.

Nogmaals, het is moeilijk, maar zeker niet onmogelijk

[Verwijderd]

Dat decompilen mogelijk is, betekent nog niet dat je code krijgt waar je ook echt iets mee kunt. Het zou prima kunnen dat de boel zover geoptimaliseerd is, dat de basisstructuur die is ontworpen nergens meer in te herkennen is. Omzetten naat bytecode levert niet zo gek veel op als je het alleen maar omzet naar instructies. De enige winst die je dan boekt, is dat de parsetijden lager worden.
De truc is natuurlijk om als compiler enkele optimalisaties te doen, zodat de programmeur niet zo efficiënt mogelijk hoeft te werken. Iedereen hier weet hoe onleesbaar of niet-onderhoudbar code kan worden als je de code efficiënter maakt.
En daar zit het hem nou in. Als de Zend Optimizer je code omzet naar bytecodebrij, is het redelijk aannemelijk dat iemand die je code probeert te stelen er enorm onoverzichtelijke code terugkrijgt. Als dat zo is, is de taak volbracht. Als iemand uit bytecode prachtig onderhoudbare code weet te genereren, verdient die persoon echt een prijs.

[Gonadan]

Verwijderd schreef op vrijdag 09 november 2007 @ 09:40:
Dat decompilen mogelijk is, betekent nog niet dat je code krijgt waar je ook echt iets mee kunt. Het zou prima kunnen dat de boel zover geoptimaliseerd is, dat de basisstructuur die is ontworpen nergens meer in te herkennen is. Omzetten naat bytecode levert niet zo gek veel op als je het alleen maar omzet naar instructies. De enige winst die je dan boekt, is dat de parsetijden lager worden.
De truc is natuurlijk om als compiler enkele optimalisaties te doen, zodat de programmeur niet zo efficiënt mogelijk hoeft te werken. Iedereen hier weet hoe onleesbaar of niet-onderhoudbar code kan worden als je de code efficiënter maakt.
En daar zit het hem nou in. Als de Zend Optimizer je code omzet naar bytecodebrij, is het redelijk aannemelijk dat iemand die je code probeert te stelen er enorm onoverzichtelijke code terugkrijgt. Als dat zo is, is de taak volbracht. Als iemand uit bytecode prachtig onderhoudbare code weet te genereren, verdient die persoon echt een prijs.

Zend compiled ook niet echt, het is meer encryptie. En dat kan twee kanten op.
Je krijgt na het decompilen dus ook weer PHP code terug.

[Janoz]

Zend compileert wel degelijk. Zend maakt van je spulleboeltje echt geen php code wanneer je applicatie draait. Wat Zend doet is het tussenproduct nemen en dit eventueel ietsje encrypten (vraag me af of ze dat doen). Niks meer en niks minder.

Hoe zou je anders het optimaliseren verklaren wanneer, zoals jij beweert, er alleen maar stappen toegevoegd worden?

[Gonadan]

Stappen toegevoegd? Ah als in encrypten.
Ok, encryptie is het ook niet.

Ik bedoel meer dat het wel compilen is maar niet naar échte bytecode als bijvoorbeeld het compilen van C.
Dan kan je geen C code meer terug krijgen, in het geval van Zend kan je het proces gewoon terugdraaien (als je weet hoe). En krijg je dus geen ASM voor je kiezen.

@hieronder, da's wel heel veel oefening (in mijn geval )
Ik kan het wel lezen en schrijven, maar om daar nou een heel C programma uit te analyseren gaat mij wat ver.

[ Voor 19% gewijzigd door Gonadan op 09-11-2007 14:10 ]

[Peter]

Je moet niet vergeten dat C ook naar ASM wordt gecompiled, en ASM kan op haar beurt weer gelezen worden, met oefening is het niet eens zo heel verschillend van normale C code

[Janoz]

Owh wacht, ik lees je bericht verkeerd. Ik dacht dat je bedoelde dat de zend optimizer je gecodeerde spul weer omzette naar php en dat dan uitvoerde, maar ik lees nu dat dat helemaal neit zo is ...

Maar goed. Van assembly code kun je best weer C maken. Het zal niet dezelfde code zijn als je oorspronkelijk hebt gecompileerd, maar er is zeker wel C code te genereren die naar exact dezelfde machine code vertaald wordt. Dat 'terugdraaien' heet gewoon decompilen en dat kan met C, C++, java, C# en dus ook met PHP.

Wat wel zo is, is dat het met php een stuk makkelijker is. In C gaan eigenlijk alle variabelenamen verloren (daarom heb je ook de headers nodig wanneer je wilt compileren/linken). Omdat je @runtime (want te baseren op variabelen) op elke plek bestanden kunt includen moet ook altijd bekend blijven hoe elke variabele heet. Obfuscaten is dus zo goed als onmogelijk en alle originele variabelenamen zullen moeten worden opgeslagen.

[Verwijderd]

C wordt helemaal niet naar bytecode gecompileerd. C wordt gecompileerd naar machine-specifieke instructies.
Bytecode is platformonafhankelijke code, die voornamelijk een eenvoudige representatie is van de human readable code waarmee de developer werkt. Bij het compileren naar bytecode kunnen al enige optimalisaties plaatsvinden, maar dit is niet noodzakelijk. Het is vooral de bedoeling om de code sneller te kunnen laden, zodat het sneller aan de JIT compiler gevoerd kan worden. Deze laatste produceert de nodige processorinstructies.

En nu mogen jullie uitleggen hoe jullie erbij komen dat de bytecode die Zend Guard produceert is om te zetten naar de originele code. Het lijkt mij dat alle niet-relevante gegevens zijn weggelaten, zoals commentaar, whitespace, etc, en dat er optimalisaties hebben plaatsgevonden waar dat handig was. Bijvoorbeeld optimalisaties die je zelf niet doet omdat je code er onleeesbaar van wordt. Het lijkt mij niet verboden voor de compiler om bepaalde functies naar inline instructies om te zetten.

Natuurlijk is het prima mogelijk om software te schrijven die PHP code oplevert, maar de vraag blijft of die code dan ook een beetje bruikbaar is.

Ik ben overigens best geïnteresseerd in software die automatisch documentatie toevoegt aan mijn code

[Gonadan]

De code die ik terugkrijg is exact de code die het origineel was. (zonder commentaar)

Op volgorde van declaraties en haakjes na.
Functie en variabelenamen zijn ook zoals origineel.

[ Voor 5% gewijzigd door Gonadan op 09-11-2007 14:47 ]

[Janoz]

Verwijderd schreef op vrijdag 09 november 2007 @ 14:23:
En nu mogen jullie uitleggen hoe jullie erbij komen dat de bytecode die Zend Guard produceert is om te zetten naar de originele code. Het lijkt mij dat alle niet-relevante gegevens zijn weggelaten, zoals commentaar, whitespace, etc, en dat er optimalisaties hebben plaatsgevonden waar dat handig was. Bijvoorbeeld optimalisaties die je zelf niet doet omdat je code er onleeesbaar van wordt. Het lijkt mij niet verboden voor de compiler om bepaalde functies naar inline instructies om te zetten.

Welke etc? Commentaar zal zeker weg zijn en het indenten zal ook zeker niet ongelijk zijn aan het orgineel, maar het karakter van php maakt optimalisaties erg lastig. Functies inlinen gaat lastig omdat er geen enkele manier bestaat om het bereik van die functie aan te geven. Elke functie leeft immers in de global scope en zou door elk geinclude stukje php aangeroepen kunnen worden. Daarnaast is het maar net de vraag of het daadwerkelijk die functie is. Vaak is pas @runtime (en niet compiletime) bekend welke functie nu daadwerkelijk bedoeld wordt.

[Verwijderd]

Er is veel besproken zie ik. Ik zal mij eerst even voorstellen.
Mijn naam is ProfNie! ik ben de persoon die de bug heeft ontdekt en met zend in gesprek is.

Je mag mij alle vragen stellen die je wilt, en ik zal zoveel mogelijk beantwoorden.
Alleen de manier hoe vertel ik niet omdat dit een afspraak is met zend nederland.

Tevens zal ik ook mee lezen en reageren in dit topic.

[Verwijderd]

Het kan natuurlijk aan mij liggen, maar ik ben niet echt onder de indruk hoor. Het gaat erom of het in de praktijk nuttig is om stukken van grote projecten te "stelen".

Janoz schreef op vrijdag 09 november 2007 @ 15:02:
Welke etc?

Puntkomma's, accolades, haakjes, etcetera, al is het natuurlijk best mogelijk om code te produceren die aan fatsoenlijke normen voldoet.

Commentaar zal zeker weg zijn en het indenten zal ook zeker niet ongelijk zijn aan het orgineel, maar het karakter van php maakt optimalisaties erg lastig. Functies inlinen gaat lastig omdat er geen enkele manier bestaat om het bereik van die functie aan te geven. Elke functie leeft immers in de global scope en zou door elk geinclude stukje php aangeroepen kunnen worden. Daarnaast is het maar net de vraag of het daadwerkelijk die functie is. Vaak is pas @runtime (en niet compiletime) bekend welke functie nu daadwerkelijk bedoeld wordt.

Dat is waar, maar als er binnen een bestand zowel een functiedefinitie staat, als een functieaanroep, dan is het mogelijk om die aanroep te vervangen door wat code. De functiedefinitie moet sowieso bestaan. Ik denk ook aan het concateneren van wat strings, dat soort zaken.
Maar je hebt natuurlijk gelijk dat het geen C is, wat dat betreft.

[RaZ]

Verwijderd schreef op donderdag 08 november 2007 @ 22:04:
Wat ik wil oplossen is een 100% veilige compiler.. want zend is dus te kraken.

Aangezien alles te kraken is, bestaat er niet iets als '100% veilig'.

Schrijf je eigen compiler, en dan vind men het niet interresant om enkel jouw dingen te kraken.Hoe groter de polulariteit van een beveiliging, hoe uitdagender het is voor de krakers.

[Verwijderd]

Cheatah, het gaat er ook niet om dat je onder de indruk moet zijn. Wij willen gewoon dat zulke pakketen veilig zijn. Doordat wij deze bug hebben gevonden geven wij hieraan aandacht zodat mensen moeten beseffen dat het lek is momenteel.

En wij gebruiken het niet om te stelen, anders had ik het al online gegooit. of had ik op illigale files wel dezend gedaan.

Ik kan wel zeggen dat wij de echte source terug halen en niet een vergelijkbare functie zoals momenteel gezegd is.

[Verwijderd]

Verwijderd schreef op vrijdag 09 november 2007 @ 16:25:

Ik kan wel zeggen dat wij de echte source terug halen en niet een vergelijkbare functie zoals momenteel gezegd is.

Dit is dan weer wél interessant. Ik heb nooit naar de geproduceerde code gekeken, maar dat zou betekenen dat naast de bytecode, ook de originele source in het bestand terug te vinden is. Waarschijnlijk wel versleuteld, maar dan op een niet zo geweldige manier. Of de bytecode representatie is een beetje té letterlijk.

[LauPro]

Voor zover ik weet zijn er voor de Optimizer/Guard een aantal regels waaraan je moet voldoen om de code goed af te schermen. (En aantal opties instelbaar.) Met name dat verhaal met globale scope en bijvoorbeeld het gebruik van variabelnamen. Dit zijn dingen waar je rekening mee kan houden tijdens het ontwikkelen en als je ook nog eens het geheel als package beschouwd kan je binnen die package zeker wel eea aan mangling doen.

Resources (teksten, afbeeldingen etc) binnen de applicatie zijn natuurlijk altijd aan te passen, of je moet deze in een of andere vault meeleveren maar hoever ga je dan.

Mocht het zo zijn dat je van Zend PHP bytecode letterlijk naar PHP code terug kan (los van whitespace en comments) dan hebben ze de plank goed misgeslagen.

Bovendien zijn de Optimizer en de Guard twee aparte producten.

[ Voor 18% gewijzigd door LauPro op 09-11-2007 16:36 ]

[Verwijderd]

Cheatah, klopt deze is doormiddel van het gebruiken van de bug helemaal terug te zetten.

LauPro, ik weet het las ook dat ze zend guard en zend optimizer door elkaar halen.
En dat ze de plak mis hebben geslagen daarin kan ik mij zeker vinden, het zal ook zsm opgelost gaan worden neem ik aan.

Wordt dus vervolgd...

[LauPro]

'Ze'? Jij lijkt mij hier diegene die opheldering moet geven want volgens mij hebben we het hier alleen over de Optimizer. En daarvan was het nooit de intentie dat die de code zou beschermen.

[Verwijderd]

Als je vanaf eerste post leest gaat het om beschermen van php codes.
Daar gebruik je niet de optimizer voor.

Het gaat erom dat de guard is gekraakt. die phpscript moet beschermen van het lezen van de source.

[LauPro]

Sommigen zien het obscuren van code ook als een 'beveiliging'. Als het echt zo werkt zoals jij pretendeert dan zie ik het triest in voor Zend. Je gaat geen licentie van 1000 dollar pj betalen als het systeem met een paar handelingen gekraakt kan worden. Dit kunnen nog wel eens rechtzaken worden in dit geval.

Weet je zeker dat er geen optie in zit waarmee je het niveau van beveiliging in kan stellen? Of dat de scripts die je 'decompiled' met een hele oude versie van de Guard zijn bewerkt?

[BCC]

Ik begrijp zowieso niet waarom mensen php code zo beschermen. Websites zijn over het algemeen outward facing en daardoor voor een paar honderd euro door een indier van rentacoder na te bouwen. Daarnaast bevatten de meeste PHP sites ook niet direct rocket science.

[ Voor 21% gewijzigd door BCC op 09-11-2007 17:13 ]

[LauPro]

Dan onderschat je de duur van sommige projecten. Het kan jaren duren voordat een website echt helemaal goed is doorontwikkeld met alle functies etc, voor een bedrijf is dit dan van heel groot belang.

Bovendien zit er in een website ook nog een commerciële waarde vaak.

[Verwijderd]

LauPro : nee daarom ben ik ook in gesprek met zend, het maakt niet uit welk nivo of versie je pakt. Ik kan alles omzetten in source.

Natuurlijk deel ik dit alleen met zend om dit soort dingen te voorkomen als rechtzaken.
Ik vind hacken en kraken goed zolang je het doet om bedrijven te helpen.

Maar we (Zend en ik) zijn druk bezig met het probleem.

[LauPro]

Misschien was ik niet helemaal duidelijk, maar als dit waar is dan is het geen 'probleem' maar een gigantische design flaw. Waarbij het product gelijk absoluut geen waarde meer heeft. Het is alsof een slotenfrabrikant voor een hele serie de masterkeys gratis uitdeelt.

[Verwijderd]

Je was wel duidelijk hoor, inderdaad heeft het geen waarde als het gekraakt is, maar als het probleem is opgelost dan heeft het zijn waarde weer terug.

[Verwijderd]

er is veel geschreven zie ik.. Wel leuk dat prof nie zelf ook hier komt schrijven. Kan je mischien wat meer vertellen? over hoe je het gedaan hebt? Ben eigenlijk wel benieuwd

[LuCarD]

Verwijderd schreef op zaterdag 10 november 2007 @ 23:24:
er is veel geschreven zie ik.. Wel leuk dat prof nie zelf ook hier komt schrijven. Kan je mischien wat meer vertellen? over hoe je het gedaan hebt? Ben eigenlijk wel benieuwd

Totdat hij uitgepraat is met Zend zul je waarschijnlijk weinig van hem horen hoe hij het gedaan heeft.

En dan heb je nog een grootte kans dat het stil blijft tot dat er een nwe patch of versie uit komt.

[Verwijderd]

LuCarD schreef op zondag 11 november 2007 @ 09:56:

Totdat hij uitgepraat is met Zend zul je waarschijnlijk weinig van hem horen hoe hij het gedaan heeft.

En dan heb je nog een grootte kans dat het stil blijft tot dat er een nwe patch of versie uit komt.

Die op dit moment al waardeloos is. Patches voor zulke flaws werken niet met terugwerkende kracht.

[Verwijderd]

LuCarD - Nee inderdaad zal ik het niet zomaar bekend maken.. Tenzij ik echt het gevoel krijg dat het ze niet zo boeit.. dan zal ik het kenbaar maken, omdat ik heus niet de enige bent die zulke dingen kan ontdekken..

Cheatah - Ja klopt dit werkt alleen voor nieuwe bestanden die met de update van zend ingepakt worden. Maar hiervoor is dan ook een taak weggelegd voor Zend.

Nicojr - Ik leg het dus momenteel ff niet uit.. Mischien later dat ik er wat dieper op in zal gaan.

[We Are Borg]

Verwijderd schreef op zondag 11 november 2007 @ 11:27:
[...]

Die op dit moment al waardeloos is. Patches voor zulke flaws werken niet met terugwerkende kracht.

Daar dacht ik ook al aan. De manier van 'inpakken' zal opnieuw moeten worden aangepakt en zolang de files niet opnieuw door het software pakket worden gehaald zijn de oude files niet veilig. Lijkt me geen leuke taak om als bedrijf te moeten vertellen

[Verwijderd]

LauPro schreef op vrijdag 09 november 2007 @ 17:16:
Misschien was ik niet helemaal duidelijk, maar als dit waar is dan is het geen 'probleem' maar een gigantische design flaw. Waarbij het product gelijk absoluut geen waarde meer heeft. Het is alsof een slotenfrabrikant voor een hele serie de masterkeys gratis uitdeelt.

Maar het is ook een design flaw, de uitvoerende server moet namelijk unencrypted bytecode hebben wil ie de boel kunnen draaien. Je hoeft dus enkel even in het geheugen van de server te snuffelen om de bytecode te verkrijgen en die is eenvoudig terug om te zetten naar PHP code.

Ik vraag me toch heel sterk af of dat uberhaupt wel te beveiligen is...

De beste `beveiliging` is IMHO om diep in een project ergens een ET phone home te zetten, oftewel 1 of 2 regels code die even de uitvoerende locatie doorgeeft naar een centrale server. Menig dief zal niet de hele broncode doorploegen of een heel uitgebreide firewall incl logging op de server hebben staan (of wel erop hebben staan maar niet weten hoe die werkt).

Als men dan de boel jat en start zal jij als eigenaar daarvan weten en de persoon erop aanspreken (vaak is het wel bekend wie er toegang en het motief heeft).

Deze oplossing kost in principe niets en is eenvoudig te regelen, het is niet 100% veilig aangezien iemand met kennis ervan weet dat ie dat eruit moet gooien bij het jatten, maar de persoon die de boel jat kan nooit heel slim zijn anders zou ie de boel niet gaan jatten

Ik heb ooit een situatie meegemaakt waarbij iemand ontslagen was na het 'hergebruiken' van code in een project dat hij zwart erbij deed. Hij werd gepakt door een verborgen ET phone home.

[Glimi]

Verwijderd schreef op vrijdag 09 november 2007 @ 14:23:
C wordt helemaal niet naar bytecode gecompileerd. C wordt gecompileerd naar machine-specifieke instructies.
[...]

Hangt af van de compiler: llvm-gcc compileert naar de LLVM virtual instruction set, welke gewoon een portable typed assembly taal is.

[Janoz]

Verwijderd schreef op maandag 12 november 2007 @ 10:40:
[...]

Maar het is ook een design flaw, de uitvoerende server moet namelijk unencrypted bytecode hebben wil ie de boel kunnen draaien. Je hoeft dus enkel even in het geheugen van de server te snuffelen om de bytecode te verkrijgen en die is eenvoudig terug om te zetten naar PHP code.

Mwah, dat zou ik nog niet echt een design flaw willen noemen. Het gebeurt namelijk veel meer. Denk aan de java classfiles, maar ook aan gecompileerde C(++) code. Deze zijn ook wel weer terug te vormen tot sourcecode. Het punt is meer dat je met een enorme bak terug getransformeerde code niet zomaar een werkbare situatie hebt.

De grootste flaw hier is dat blijkbaar de orginele code (mee)ge-encrypt wordt. Ik vraag me zelfs af of ze uberhaupt wel bytecode gebruiken..

[Verwijderd]

Jawel ze gebruiken zeker wel bytecodes..
Bepaalde mensen beweren ook dat zend al veel langer gekraakt is, maar dit is gewoon het opvangen van de output die normaal op de website zichtbaar wordt, dit is dus totaal waardeloos. aangezien de helft niet klopt in de code..

Alleen door een bug in Zend Optimizer die je code uitleest kan je dus inplaats van een output de hele source terug halen..

[Verwijderd]

Janoz schreef op maandag 12 november 2007 @ 10:54:

De grootste flaw hier is dat blijkbaar de orginele code (mee)ge-encrypt wordt.

Precies. Dat zou nergens voor nodig moeten zijn.

Ik vraag me zelfs af of ze uberhaupt wel bytecode gebruiken..

Dat lijkt me wel, die optimizer moet toch ergens de performancewinst vandaan halen. Al moet ik zeggen dat ik nooit heb gebenchmarkt.

[Glimi]

Verwijderd schreef op maandag 12 november 2007 @ 11:20:
Precies. Dat zou nergens voor nodig moeten zijn.

Er zijn legio redenen om source te includen in een executable. Bijvoorbeeld een taal welke compileert naar een ander host platform, zodat de foutmeldingen in termen van de source gegeven kunnen worden ipv de host language. Verder zou je ook nog de source kunnen includen om die samen met een run-time profile te kunnen hercompileren om zo meer performance eruit te slepen (zie SELF en LLVM)

edit:
Ik vergat idd ff te vertellen dat het voor dit systeem niet zo relevant is

Verwijderd schreef op maandag 12 november 2007 @ 11:20:
Dat lijkt me wel, die optimizer moet toch ergens de performancewinst vandaan halen. Al moet ik zeggen dat ik nooit heb gebenchmarkt.

Een mogelijkheid zou ook het opslaan van een intermediate language (AST bijv). Dan bespaar je puur op parsen, dis-ambigueren en meer van zulk soort frontend zaken.

[ Voor 31% gewijzigd door Glimi op 12-11-2007 12:04 ]

[Verwijderd]

Glimi schreef op maandag 12 november 2007 @ 11:58:

Er zijn legio redenen om source te includen in een executable. Bijvoorbeeld een taal welke compileert naar een ander host platform, zodat de foutmeldingen in termen van de source gegeven kunnen worden ipv de host language. Verder zou je ook nog de source kunnen includen om die samen met een run-time profile te kunnen hercompileren om zo meer performance eruit te slepen (zie SELF en LLVM)

Maar in dit geval gaat het om een systeem waarbij het de bedoeling is dat je broncode beschermd wordt. Dan is het op zijn minst een beetje "onverstandig" om die broncode ook in het bestand te zetten. Tenzij je het versleutelt, maar dan nog is het natuurlijk niet de bedoeling dat de server het kan ontcijferen.

[DataGhost]

Cheatah, ik denk dat dat vooral een PHP-specifiek probleem is. Hoe wil je namelijk iets als

PHP:

// heleboel code
$bla = $_POST["variabele"];
print $$bla;
// of nog erger
$bla();

in bytecode gaan omzetten? Juist. Dan zit je dus al gauw aan het 'includen' van min of meer de gehele source, alhoewel je wel een paar dingen zou kunnen optimaliseren.

[ Voor 24% gewijzigd door DataGhost op 12-11-2007 12:39 ]

[Verwijderd]

Dit kan prima in bytecode hoor, er is geen reden waarom dat niet zou kunnen.

Het zal inderdaad wel te maken hebben met het feit dat de bytecode niet op ieder platform zomaar kan draaien en dus de source erbij moet zodat er weer nieuwe bytecode uit gehaald kan worden (maar waarom dan uberhaupt bytecode erbij stoppen?).

Maar best wel bad dit, voor zo'n duur systeem.

[TheBlasphemer]

Ik heb het idee dat het allemaal een beetje uit zn proporties/context is gerukt.
Het leuke aan PHP is dat ik een functie kan declaren (laten we zeggen functieBlaat), en daarna moet ik door middel van een string ($a="functieBlaat";) die functie weer aan kunnen roepen: $a();
Verder kun je zelfs variables dmv een string gereferenced worden:
$a="Test";
$b="a";
echo $$b; zal dan "Test" weergeven.
Dit soort trukjes zijn juist de kracht van PHP: het biedt allemaal leuke (en soms handige) constructies, en de ondergang van dit soort optimizers: er zit niets anders op dan voor elke variable bijhouden wat de originele naam is.
Tuurlijk kun je de bovenstaande stukjes wel optimaliseren, maar wat als bij de functie-aanroep $a veranderd wordt door een ge include bestand? of wat als in het volgende stukje $b halverwege vervangen wordt door een of andere rekensom waar user-input in voorkomt ?
Dit alles komt er op neer dat je dus niet alleen bytecode hebt, zoals bij C of een andere low-level taal, maar naast die bytecode ook de variable/functie-namen.
Bytecode op zich is niet zo erg, hier kun je alleen de logica van het programma uithalen: wat het doet. Hiermee kun je dus wel functies terug krijgen (of iets wat op het origineel lijkt), maar niet de functie-naam of variable naam. Kortom, je moet alles goed doorlezen om er uberhaupt achter te komen wat de functie nou precies doet.
Met de toevoeging van variable and functie namen zie je hem waarschijnlijk al aankomen: Je kan de bytecode terugveranderen naar PHP-achtige code, waarbij de functie en variable-namen zijn behouden: prima leesbare code, alleen je comments ontbreken

Kortom: door de manier waarop PHP opgezet is, zal dit probleem er altijd zijn. Je kan geen compleet onkraakbare versleuteling maken, want dan zou je het script niet meer kunnen draaien.

(Toevoeging: Zelfs C-bytecode/ASM kun je meestal nog heel veel informatie uit krijgen. Hoe denk je dat keygenners te werk gaan?)

[Verwijderd]

Inderdaad, je zou versteld staan als je ziet wat Ida Pro nog ervan kan maken.

[Janoz]

@TheBlasphemer:
Ten eerste, C compileert over het algemeen niet naar bytecode .

Verder zou ik dergelijke constructies niet 'de kracht' van php willen noemen. Constructies die daarmee te maken zijn kunnen ook op een veel nettere manier gemaakt worden zonder variabele variabelen te gebruiken. Variabele variabelen zijn over het algemeen een onderhoudshel. Maar goed, er kan nog best wel iets geoptimaliseerd worden. Het enige verschil is dat er niet 'geobfuscate' kan worden.

Probleem hier is dat de originele sorcecode bewaart blijkt te zijn. Incl commentaar, en ja, dat is behoorlijk ernstig gezien het beschermen hiervan de core functionaliteit is van het product.

edit:Hmm, ik dacht weer dingen gelezen te hebben die helemaal nergens stonden ..

[ Voor 6% gewijzigd door Janoz op 12-11-2007 14:40 ]

[Verwijderd]

Incl commentaar? Daar geloof ik niets van, wat zou daar het mogelijke nut van zijn?

[Verwijderd]

//commentaar wordt niet meegenomen in de crypt dus is onmogelijk om mee te nemen in de source.

De orginele source haal je er wel uit, alleen wat niet wordt meegenomen in een crypt ontbreekt dus.
Dat is ook niet nodig omdat het niet gebruikt wordt.

[Verwijderd]

Heel apart, staat ergens beschreven wat er precies kapot is dan? (Bug report ofzo)

Vraag me toch af, is het zo dat de encryptie zelf gekraakt is, of is het zo dat een implementatie gekraakt is waardoor unencrypted spul uit het geheugen gehaald kan worden? (Zoals de sleutels bij blu-ray uit het PowerDVD geheugen gehaald zijn).

Het zou wel bizar zijn als Zend Guard de unencrypted source weer aan de PHP interpreter voert om deze opnieuw om te zetten naar bytecode...

[Verwijderd]

Nee TRRoads, staat nergens beschreven, en mag zelf ook niks los laten over het hoe en wat.
Alleen dat het dus mogelijk is binnen 2 uurtjes hele source codes terug te zetten.

Er zijn een aantal manieren waarop de bestanden zijn beveiligd en daar gaat het meeste tijd in zitten omdat er niet 1 standaard manier is. Dat is een kwestie van proberen en proberen.

En als je het van 1 bestand weet in die reeks.. heb je binnen 1 min. overige 100de bestanden omgezet..

[Verwijderd]

Ahjah, security through obscurity... ben ik niet zo'n gelover in.

[Spider.007]

Verwijderd schreef op maandag 12 november 2007 @ 11:20:
Jawel ze gebruiken zeker wel bytecodes..
Bepaalde mensen beweren ook dat zend al veel langer gekraakt is, maar dit is gewoon het opvangen van de output die normaal op de website zichtbaar wordt, dit is dus totaal waardeloos. aangezien de helft niet klopt in de code..

[...]

Nee hoor; zie Zend Encoded Files te decoderen; dat heb ik ook werkend gezien; ondanks dat de genoemde website inmiddels een ander doel dient

[ Voor 9% gewijzigd door Spider.007 op 12-11-2007 15:08 ]

[Verwijderd]

Heb je het ook echt werkend gezien? Je hebt werkend en werkend..

Heb je zelf een code geschreven? En die ingepakt met zend en daarna laten uitpakken?
Of gewoon een stukje script genomen en die laten uitpakken, en daarna de source bekeken.

Want daarin zit verschil, iets kan wel werken, maar niet de orginele source zijn. Met output's kan ik ook werkende scripts maken omdat de output je halve informatie geeft die je als phper makkelijk met de hand kan omzetten in een goede source.

Daar ben ik dus benieuwd na, want ik heb contact met zend, en volgens hun is niemand anders het nog gelukt, maar zeiden van wel..

[TheBlasphemer]

Janoz schreef op maandag 12 november 2007 @ 13:22:
@TheBlasphemer:
Ten eerste, C compileert over het algemeen niet naar bytecode .

Om het een en ander simpel te houden (ik kan moeilijk een geheel vak computer architectuur geven in 10 min), neem ik hier x86 ASM code maar even als gelijk aan bytecode
(in mijn opzicht is het ook in grote delen gelijk aan byte-code, met het grote verschil dat byte-code meestal door een interpreter wordt gelezen, en processor instructies door een processor )

[Verwijderd]

Ik heb ook even een Google tocht gedaan naar Zend Guard decrypt progjes en in no time een goed werkende oplossing gevonden. Ik heb een commercieel pakket gedownload welke was geencrypt met Zend en op enkele minimale foutjes na kwam er weer een hele nette source uit.

Het is dus inderdaad flink lek, als je daar geld in stopt hou je de script kiddies tegen, maar zelfs script kiddies met goede Google skills hou je niet tegen.

[BCC]

TheBlasphemer schreef op maandag 12 november 2007 @ 20:23:
Met het grote verschil dat byte-code meestal door een interpreter wordt gelezen, en processor instructies door een processor )

Groot verschil? Zo'n interpreter heet niet voor niets een virtual machine. Het is niets anders dan een andere instructieset.

[ Voor 7% gewijzigd door BCC op 13-11-2007 08:54 ]

[Peter_B]

Naar aanleiding van de gedane uitspraken in deze topic heb ik contact opgenomen met de Nederlandse partner van Zend. Zij vertelden mij dat dit is opgenomen met Zend en dat men bezig was de claim te onderzoeken. Tot op heden is er geen duidelijke uitspraak gedaan over wat er nu wel en niet blijft staan van de claim na nader onderzoek.

Heeft iemand hier meer informatie over de status van het mogelijke probleem met Zend Guard?

[LauPro]

Ik vind het toch opmerkelijk dat een dergelijk bedrijf hier niet gewoon een duidelijk antwoord op kan geven. Dit verhaaltje loopt nu al meer dan een maand, dat is toch absurt?

Of ze zien zelf ook wel in dat het einde nadert en dat het nu gewoon schadebeperking is.