Zend Encoded Files te decoderen

[AW_Bos]

Ik hoorde via iemand op MSN dat er een bedrijf is wat Zend schijnt te kunnen recoveren.

Ze beweren zelf Zend Encoded files te kunnen decompileren.
is dit nou werkelijk mogelijk of zou riekt dit naar vette onzin?
Voor 30 te decompileren bestanden zou je 80 doller kwijt zijn.
Ok, als kerstcadeu kan iedereen via een mailadres een zend encoded file sturen die hun schijnen te kunnen decompilen...

Maar moet ik dit nou geloven of niet. Zend Encoded files is niet anders dan binaire shit wat computertaal is, misschien is het deels te decompileren.

Ik heb dit dan ook nog niet uitgetest, omdat ik geen eigen Zend Encoded files heb, maar ik zal binnenkort eens een testje uitvoeren hiermee

Weet iemand hier misschien meer van ?
En is dit nou illegaal of niet? (Daarom plaats ik dan ook maar geen linkjes naar die desbetreffende site...)

[ Voor 19% gewijzigd door AW_Bos op 23-12-2005 13:04 ]

[AtleX]

Op de Zend site kan je een gratis trial van de Zend Encoder downloaden, die kun je gebruiken om een file te maken om naar hun te sturen. Dan zie je vanzelf wat er gebeurt . Verder lijkt me dit problemen geven met copyright en license issues, als ik de source van (My)React opstuur en die decompiled terugkrijg is dat niet helemaal legaal.

[ViNyL]

Volgens mij is juist het hele idee dat jij zelf toegang tot je source hebt als je het compiled met de Zend encoder... Dus waarom zou je het dan willen decoden?

En volgens mij is het ook (nauwelijks) goed te decompilen.... En ja in principe is decompilen een crime zo niet een sin...

[Helmet]

De optimizer moet het toch op een of andere manier uitvoeren dus die zal het ook min of meer "decoden"

[BlaTieBla]

Binnen Coldfusion is het ook mogelijk om je source te encoden. Veel commerciele ontwikkelaars verspreiden zo hun applicaties. De 'trails' zijn dan fully functional, maar met 'nag-screens'. Door ze te decoden kan je ze weer normaal lezen en aanpassen naar eigen inzicht. Niet dat het altijd even legaal is, maar toch.

Overigens begrijp ik wel waarom je zoiets zou kunnen decoden (die zend decoder service). Ik heb het zelf nml ook wel eens gehad dat ik de source kwijt was, maar nog wel een encoded versie had. In dat soort gevallen scheelt het wat uurtjes coldfusion inklop-werk.

Lijkt me wel dat je van te voren even moet aan kunnen tonen dat het inderdaad jouw code is die ze moeten ontcijferen.

[ Voor 4% gewijzigd door BlaTieBla op 23-12-2005 13:17 ]

[AW_Bos]

Iemand die ik ken heeft een stukje source van zijn site even door Zend Optimizer gegooid, doorgemaild naar hun, en kreeg vervolgensn die oorspronkelijke code weer terug ..
Dat het mogelijk is, verbaast me...

Ik ben bezig met een CMSproject aan het uitdenken waarmee ik de bedoeling had alles in ze Encoden met een goedkope licentie ofzo, en dat naar de gebruiker stuur.
Maar ik denk er nu beter over om het maar op mijn server te laten, en iets te maken dat de gebruiker het alleen kan gebruiken....

Of zou er een nieuwere versie komen van Zend SafeGuard waarmee je niks meer terug kan halen?

BlaTieBla schreef op vrijdag 23 december 2005 @ 13:16:
Lijkt me wel dat je van te voren even moet aan kunnen tonen dat het inderdaad jouw code is die ze moeten ontcijferen.

Dat bedrijf meldt er volgens mij niks over VOlgens hun site zouden ze alles kunnen accepteren , maar ik neem aan dat er mensen met gezond verstand werken....

[ Voor 27% gewijzigd door AW_Bos op 23-12-2005 13:24 ]

[Verwijderd]

Tja eerst zien dan geloven. Ik vind het iig een sterk verhaal.

[Glashelder]

Waarom is decompilen illegaal

[CyBeRSPiN]

Verwijderd schreef op vrijdag 23 december 2005 @ 13:21:
Tja eerst zien dan geloven. Ik vind het iig een sterk verhaal.

Ja inderdaad, de oorspronkelijke code terugkrijgen is sowieso een fabel, commentaar zal nooit meegenomen worden bij het encoden (bespaart een hoop ruimte), en wellicht dat er van functienamen ook niet veel overblijft als het optimaal ge-encode is.

Glashelder schreef op vrijdag 23 december 2005 @ 13:36:
Waarom is decompilen illegaal

Je bezit zelf de software niet, maar je hebt het recht om er gebruik van te maken, aanpassingen maken is vaak niet toegestaan volgens de licentie.

[ Voor 26% gewijzigd door CyBeRSPiN op 23-12-2005 13:37 ]

[AW_Bos]

Glashelder schreef op vrijdag 23 december 2005 @ 13:36:
Waarom is decompilen illegaal

Licenties en dergelijke...

[Glashelder]

Ja maar dat maakt decompilen niet per defenitie illegaal. Het decompileren van een stuk software is (misschien) illegaal.

[AW_Bos]

Bij het gebruik ervan dan, lijkt me....
Net als DVD's, je mag ze ook backuppen voor je eigen, maar niet doorgeven aan iemand anders....

[Erkens]

Openmaken van exe's en decompilen

[AW_Bos]

Ik weet niet of je dat linkje gaf Erkens, wegens het eventueel overtreden van de policy hier, of als naslag ter uitbreiding van dit topic...

In ieder geval wou ik een discussie laten voortbestaan d.m.v. dit topic, in hoeverre dit legaal is of niet, en tot hoever dit kan.

[ Voor 70% gewijzigd door AW_Bos op 23-12-2005 14:02 ]

[BlaTieBla]

CyBeRSPiN schreef op vrijdag 23 december 2005 @ 13:36:
[...]

Ja inderdaad, de oorspronkelijke code terugkrijgen is sowieso een fabel, commentaar zal nooit meegenomen worden bij het encoden (bespaart een hoop ruimte), en wellicht dat er van functienamen ook niet veel overblijft als het optimaal ge-encode is.

Hoezo een fabel?? Binnen Coldfusion krijg je EXACT hetzelfde terug (na een decode actie met een twijfelachtig pakketje ). Waarom zou dat niet binnen die Zend oplossing kunnen?

Overigens haal ik CF alleen even als vergelijk aan voor wat het encoden en decoden van sourcecode betreft. Hoe dat Zend hier in de praktijk mee omgaat.... keine blasse Ahnung.

Overigens is overbodige ruimte in code niet per definitie een vertragende factor voor het uitvoeren van de code.

[ Voor 8% gewijzigd door BlaTieBla op 23-12-2005 14:05 ]

[Erkens]

AW_Bos schreef op vrijdag 23 december 2005 @ 13:59:
Ik weet niet of je dat linkje gaf Erkens, wegens het eventueel overtreden van de policy hier, of als naslag ter uitbreiding van dit topic...

als het was wegens eventueel overtreden van de policy dan had ik die link in een topic report gedaan

[NMe]

Helmet schreef op vrijdag 23 december 2005 @ 13:08:
De optimizer moet het toch op een of andere manier uitvoeren dus die zal het ook min of meer "decoden"

Waarom? Het hele idee van gecompileerde machinecode is juist dat het machinecode is, en er juist géén vertaalslag meer gemaakt hoeft te worden. Al gaat dat in het geval van de Zend Encoder niet helemaal op, die compileert namelijk naar een eigen formaat, wat vervolgens alsnog naar machinecode wordt omgezet. Het aantal vertaalslagen bij "normale" PHP-files en Zend encoded files is dus precies gelijk.

[AtleX]

En dus hebben de makers van bovengenoemde website de Zend Encoder of de Zend Optimizer (beiden closed source) moeten reverse engineeren oid om de werking te kunnen achterhalen. Lijkt me ook illegaal.

[NMe]

Er zal inderdaad weinig legaals zijn aan die service. Maar of het ook illegaal is als jij gebruik wil maken van die service, dat weet ik niet. Uit de FAQ waar Erkens al naar linkte:

Decompilen mag voor het tot stand brengen van intercompatibiliteit, zorgen dat proggies (interfaces) met elkaar kunnen communiceren. Dat mag alleen als je zonder het decompileren de intercompatibiliteit niet tot stand kan brengen en je het proggie rechtmatig in je bezit hebt.

Je mag dus een programma (laten) decompileren, mits het met het doel is intercompatibiliteit te kunnen toevoegen aan andere apps.

[SmartDoDo]

Lijkt me veel beter in SA op z'n plek

[Erkens]

-NMe- schreef op vrijdag 23 december 2005 @ 15:14:
Je mag dus een programma (laten) decompileren, mits het met het doel is intercompatibiliteit te kunnen toevoegen aan andere apps.

en dan alleen als je het zonder decompilen niet zal lukken

[T-MOB]

Je hoeft de zend encoder helemaal niet te decompilen om dit uit te zoeken. De encoder transformeert input naar output. Door input met output te vergelijken kun je best een programma maken dat dezelfde transformatie doet (of een omgekeerde).
Wat ik wel vreemd vind aan het verhaal is dat de ZendEncoder blijkbaar commentaar, variabelnamen en loopstructuren intact laat. Ik zou verwachten dat de optimizer hier wel in zou gaan optimaliseren. Het idee van de encoder is immers dat het script one-way wordt getransformeerd in code die:
a. sneller wordt; en
b. de originele code beschermt tegen ongewenst kopiëren.
Nu blijkt dat belofte b. niet waargemaakt wordt en dat aan belofte a. blijkbaar nog te verbeteren valt. Eigenlijk is de Zend Encoder dus een vreemd stukje software.

[sanfranjake]

En inmiddels staat íe in BV, omdat dit topic daar nog beter op z'n plaats is

[Erkens]

T-MOB schreef op vrijdag 23 december 2005 @ 16:31:
Je hoeft de zend encoder helemaal niet te decompilen om dit uit te zoeken. De encoder transformeert input naar output. Door input met output te vergelijken kun je best een programma maken dat dezelfde transformatie doet (of een omgekeerde).

het gaat er ook niet om dat je de zend encoder decompiled maar de encoded php files

Wat ik wel vreemd vind aan het verhaal is dat de ZendEncoder blijkbaar commentaar, variabelnamen en loopstructuren intact laat.

Heb je hier een voorbeeld/bewijs voor?

[NMe]

T-MOB schreef op vrijdag 23 december 2005 @ 16:31:
Je hoeft de zend encoder helemaal niet te decompilen om dit uit te zoeken. De encoder transformeert input naar output. Door input met output te vergelijken kun je best een programma maken dat dezelfde transformatie doet (of een omgekeerde).

Zonder decompileren is dat puur giswerk, en dus praktisch onmogelijk. Het lijkt me dus dat je voor zoiets de Encoder moet decompileren.

Wat ik wel vreemd vind aan het verhaal is dat de ZendEncoder blijkbaar commentaar, variabelnamen en loopstructuren intact laat. Ik zou verwachten dat de optimizer hier wel in zou gaan optimaliseren.

Java doet bijvoorbeeld hetzelfde bij gecompileerde files. Een vriend van me heeft ergens een decompiler vandaan gehaald die Javacode wist te decompileren, inclusief variabelenamen. Commentaar ook geloof ik, maar dat weet ik niet zeker. Zelf heb ik niet echt interesse in zo'n decompiler, dus meer weet ik er ook niet vanaf.

Het idee van de encoder is immers dat het script one-way wordt getransformeerd in code die:
a. sneller wordt; en

Dat doet de Encoder niet, maar de Optimizer. De Encoder belooft alleen alles in het werk te stellen om je code te beschermen, niet sneller te maken. Dat het effectief wèl sneller wordt, komt omdat je de Zend Optimizer moet draaien om encoded files te gebruiken.

b. de originele code beschermt tegen ongewenst kopiëren.
Nu blijkt dat belofte b. niet waargemaakt wordt en dat aan belofte a. blijkbaar nog te verbeteren valt. Eigenlijk is de Zend Encoder dus een vreemd stukje software.

Mwah, ik denk dat ze redelijk wat doen om je code te beveiligen. Het probleem is dat elke beveiliging te kraken is, mits er genoeg tijd overheen gaat.

[aex351]

Modbreak:

Dat doen we maar niet

[ Voor 62% gewijzigd door pasta op 23-12-2005 20:33 ]

[T-MOB]

Erkens schreef op vrijdag 23 december 2005 @ 18:48:
het gaat er ook niet om dat je de zend encoder decompiled maar de encoded php files

Er werd in het topic gesuggereerd dat het bedrijf dat die dienst levert illegaal bezig was. Daar doelde ik eigenlijk op.

Heb je hier een voorbeeld/bewijs voor?

Ik ging er van uit dat dit verhaal klopt:

AW_Bos schreef op vrijdag 23 december 2005 @ 13:18:Iemand die ik ken heeft een stukje source van zijn site even door Zend Optimizer gegooid, doorgemaild naar hun, en kreeg vervolgensn die oorspronkelijke code weer terug ..
Dat het mogelijk is, verbaast me...

-NMe- schreef op vrijdag 23 december 2005 @ 18:53:
Zonder decompileren is dat puur giswerk, en dus praktisch onmogelijk. Het lijkt me dus dat je voor zoiets de Encoder moet decompileren.

Als je gestructureerd te werk gaat lijkt het me zeker niet onmogelijk. Gewoon met op zichzelf staande statements beginnen en de output analyseren. En dan kijken wat het effect is van een enkele wijziging. Een groot deel kun je nog automatiseren ook.

Mwah, ik denk dat ze redelijk wat doen om je code te beveiligen. Het probleem is dat elke beveiliging te kraken is, mits er genoeg tijd overheen gaat.

Maar wat ik dan vreemd vind is dat ze de mogelijkheid die er is om data weg te gooien niet benutten. Variabelnamen zijn totaal niet relevant meer in de "gecompileerde" versie. Functies, loopstructuren, je kunt ze allemaal omschrijven naar code die sneller is voor de machine, maar waar een mens geen touw aan vast kan knopen. Op die manier wordt het onmogelijk om de originele code terug te halen, je gooit immers informatie weg. Dat is ook wat ik altijd dacht dat de Zend Encoder deed.

[Erkens]

T-MOB schreef op vrijdag 23 december 2005 @ 20:08:
Er werd in het topic gesuggereerd dat het bedrijf dat die dienst levert illegaal bezig was. Daar doelde ik eigenlijk op.

nou, de dienst die het leverd zou illegaal zijn

Maar wat ik dan vreemd vind is dat ze de mogelijkheid die er is om data weg te gooien niet benutten. Variabelnamen zijn totaal niet relevant meer in de "gecompileerde" versie. Functies, loopstructuren, je kunt ze allemaal omschrijven naar code die sneller is voor de machine, maar waar een mens geen touw aan vast kan knopen. Op die manier wordt het onmogelijk om de originele code terug te halen, je gooit immers informatie weg. Dat is ook wat ik altijd dacht dat de Zend Encoder deed.

Dat is dus niet van de encoder doet maar de optimizer
*knip*

[ Voor 13% gewijzigd door pasta op 23-12-2005 20:34 ]

[frickY]

-NMe- schreef op vrijdag 23 december 2005 @ 14:31:
[...]

Waarom? Het hele idee van gecompileerde machinecode is juist dat het machinecode is, en er juist géén vertaalslag meer gemaakt hoeft te worden. Al gaat dat in het geval van de Zend Encoder niet helemaal op, die compileert namelijk naar een eigen formaat, wat vervolgens alsnog naar machinecode wordt omgezet. Het aantal vertaalslagen bij "normale" PHP-files en Zend encoded files is dus precies gelijk.

Volgens mij is dat niet waar.

De ZEND Encoder parset de PHP-files namelijk. De PHP-source wordt omgezet naar voor de engine hap-klare stukken. Daarom ondervind je ook een performance winst wanneer je je files encoded; de parses hoeft er niet meer overheen.
Daarom is het ook onmogelijk een ZEND encoded file terug te "decoderen" naar de oorspronkelijke PHP-bron.

Wellicht dat je een decompiler kunt bouwen welke aan de hand van de enconded file kan verzinnen welke PHP-syntax daarbij hoort, maar dan nog zul je daar nooit exact je orginele source uit krijgen

[NMe]

@frickY:

quote: http://www.zend.com/store/products/zend-encoder.php

How Does it Work?

The Zend Encoder compiles and converts plain-text PHP scripts into a platform-independent binary format known as a 'Zend Intermediate Code' file. These encoded binary files are the ones that are distributed instead of the human-readable PHP files. The performance of the encoded PHP application is completely unaffected!

The Zend Optimizer, a free download, is the run-time environment that enables end-users to transparently execute these files as if they were regular PHP scripts. The Zend Optimizer not only provides an additional level of increased security against reverse engineering, it also improves performance speed.

De performance verandert dus niet door het gebruik van de Encoder, maar door het gebruik van de Optimizer. Verder is wat de Encoder uitpoept dus geen machinecode, maar code die de Optimizer kan lezen en vertalen naar machinecode.

[aex351]

aex351 schreef op vrijdag 23 december 2005 @ 18:57:

Modbreak:

Dat doen we maar niet

Wat is het probleem met het geven van een link naar de bijbehorende website ? Je gaat mij toch niet vertellen dat het decoderen illigaal is, wat dus niet het geval is. Dus ik begrijp niets van je modbreak.

[ Voor 22% gewijzigd door aex351 op 24-12-2005 04:45 ]

[NMe]

aex351 schreef op zaterdag 24 december 2005 @ 04:43:
Wat is het probleem met het geven van een link naar de bijbehorende website ? Je gaat mij toch niet vertellen dat het decoderen illigaal is, wat dus niet het geval is. Dus ik begrijp niets van je modbreak.

Decoderen is niet illegaal, decompileren in dit geval wel, en die service dus al helemaal.

Trouwens, als je het niet eens bent met een modbreak dan geldt eigenlijk hetzelfde als wanneer je het niet eens bent met een slotje.

[pasta]

offtopic:
Decoderen is wel degelijk illegaal, iig in de meeste gevallen wel. Tenzij de auteur(s) van Zend expliciet toegeven dat decoderen mag, gaat het meestal tegen de AV van Zend / $product dat gecodeerd wordt in.

[aex351]

Ik kan het bevestingen dat de zend geencodeerde bestanden binnen een seconde weer te decoderen is. Zend liegt gewoon dus op hun website. Betaal je honderden dollars voor de zend encode pakket om vervolgens het zo weer te kunnen decoderen

[ Voor 41% gewijzigd door aex351 op 24-12-2005 05:46 ]

[HunterPro]

ik mag best een zelf geencode bestand decompileren. Decompileren en RE'en is alleen in de States verboden dmv de DMCA. Als jij zelf de rechten op het geencrypte bezit (waar imo een <?php echo "hello world"; ?> ook onder valt, eigenlijk is dat meer public domain, maargoed) mag je dat best decrypten. Gezien het feit dat een product als Zend geen bal kan veranderen aan intellectuele eigendommen en rechten op broncodes (zou een beetje gek worden hey ) blijft het eigendom van de code onverminderd bij de (originele) auteur. Die mag dus best decoden. IMO dus geen reden om de site van die decrypt-service eruit te mod-breaken.

Daarnaast vind ik het interessant, daar ik meerdere producten uitgezet heb middels de Zend suite (zowel encoded als de licensing-tool die Zend biedt). Ik ben dus erg benieuwd in hoeverre mijn applicaties 'vatbaar' zijn voor dit verhaal (en ook naar de reactie van Zend erop).

[ Voor 20% gewijzigd door HunterPro op 24-12-2005 06:25 ]

[elevator]

Hier staat ook een best leuke discussie over dit verhaal van iemand die toch wel goed bekend staat in de 'PHP wereld', en van een auteur van een van de bekendere encoders.

Grappig is wel dat bovenstaand verhaal, de uitleg van Zend die -NMe- quote tegenspreekt

[F_J_K]

HunterPro schreef op zaterdag 24 december 2005 @ 06:24:
blijft het eigendom van de code onverminderd bij de (originele) auteur. Die mag dus best decoden. IMO dus geen reden om de site van die decrypt-service eruit te mod-breaken.

offtopic:
Hmja, ik mag ook mijn eigen auto openbreken en de autoradio er uit halen, maar verwacht niet dat een topic over het openbreken van auto's lang open blijft. Ik mag van mezelf best het wachtwoord van mijn eigen Windows installatie achterhalen maar gooi een topic met die vraag hard dicht. De hoofdreden van zoiets is niet het decoderen van eigen files
Maar goed, wellicht is dit een aparte discussie waard. Praten over het beleid in BV is niet iets voor hier

Daarnaast vind ik het interessant, daar ik meerdere producten uitgezet heb middels de Zend suite (zowel encoded als de licensing-tool die Zend biedt). Ik ben dus erg benieuwd in hoeverre mijn applicaties 'vatbaar' zijn voor dit verhaal (en ook naar de reactie van Zend erop).

Inderdaad. Als iemand veel geld uitgeeft aan iets om de code te verbergen, zou ik op zijn minst een duidelijke verklaring en belofte van beterschap willen zien als blijkt dat het heel simpel & snel is terug te halen terwijl ze het verkopen als "ensuring your investment and source code are protected from copyright infringement".

[aex351]

Daar gaat de encoded bestanden van react web software

[ Voor 4% gewijzigd door aex351 op 24-12-2005 16:00 ]