Broncode beschermen
Ik weet niet of dit van belang is, maar we draaien MacOS als server met Apache, PHP en MySQL. Geen frameworks of iets dergelijks. Oplossingen mogen zowel betaald als gratis (open source) zijn.
Stop dan maar met zoeken want een manier om dit te beschermen vind je niet en zal je nooit vinden maar je kan het wel onleesbaar maken door het net als google te doen :) maar dan nog zou je alleen html zien en js
Gewijzigd op 02/04/2014 16:53:46 door Reshad F
Neen, als zijnde de daadwerkelijke PHP code op de server. We draaien een applicatie op servers die in beheer zijn van onze klanten. We willen de code en daarmee onze product (intellectueel eigendom) beschermen tegen gebruik zonder onze toestemming.
Je moet daarom altijd zorgen dat je het origineel in bezit hebt, maar bij dergelijke projecten zullen deze altijd in een GIT/SVN/CVS omgeving staan. Waarna ze bij het deployen door de decoder heen gaan.
Gewijzigd op 02/04/2014 16:57:06 door - Ariën -
Kun je dat eens toelichten?
Bij grote projecten wordt vaak aan versie-beheer gedaan. Geen verplichting, maar puur een voorbeeld over de workflow van het werken aan een project.
Gewijzigd op 02/04/2014 17:06:11 door - Ariën -
http://codeit.sg/php_encoder/
Als ik dit zo zie, vraag ik me af of er geen schimmige dingen mee worden 'gecompiled'. Dan zou ik als bedrijf liever voor Zend of IonCube gaan.
Als ik dit zo zie, vraag ik me af of er geen schimmige dingen mee worden 'gecompiled'. Dan zou ik als bedrijf liever voor Zend of IonCube gaan.
Iets schimmigs verbergen in versleutelde opcode is bij beide echter natuurlijk nog steeds mogelijk, dus ik zou me wel twee keer bedenken voordat ik iets uit onbekende bron installeer dat IonCube of Zend Guard gebruikt. (Of je moet het ding in een sandbox plus een firewall verpakken, maar dan verlies je weer performance en blijft mogelijk toch nog een beveiligingslek onontdekt.)
Een alternatief is niet alle PHP-code bij de opdrachtgever parkeren, maar een API gebruiken. Eenvoudig maar herkenbaar praktijkvoorbeeld: je hoeft klanten niet je complete postcodedatabase cadeau te doen; je kunt ook een postcode-API beschikbaar stellen.
Inmiddels:
- blijft Zend Guard hangen op PHP 5.6
- zit IonCube op versie 10 en kan t/m PHP 7.2
- kan SourceGuardian t/m PHP 7.4
Van wat ik her en der op internet zou de performance van IonCube beter zijn, maar ook Source Guardian belooft versleuteling van bytecode.
Er zijn obscure sites die beloven de versleuteling te kunnen kraken, wat me niet helemaal geruststelt. (https://www.startpage.com/do/dsearch?query=decode+ioncube)
De enige andere optie die ik ken om IE te beschermen als onderdeel van een bedrijfsgeheim is door de code niet prijs te geven aan een klant, bijvoorbeeld door extern te hosten op een server in eigen beheer.
Ik ben benieuwd of er nog meer mensen zijn die hier ervaring mee hebben.
Zijn er tegenwoordig nieuwe inzichten in hoe IE te beschermen?
SaaS behoorlijk in, en dan hoef je niet aan zulke bescherming te denken omdat je het zelf voor de klant host.
Maar als je toch zelf het product wilt verkopen aan de klant, die het zelf host dan is IonCube nog steeds de beste oplossing. Ik zie dat ze ook PHP 7.3 en 7.3 ondersteunen, zolang de nieuwe functies van deze versies maar niet gebruikt worden.
Of het veilig is durf ik niet te zeggen. In een ver verleden heb ik ooit eens uit onderzoek een Zend-encoded PHP-applicatie gedecompileerd met wat een dergelijke encoder. Volgens mij werkte dat programma door 'reversed engineering' toe te passen. De stijl van programmeren was ook totaal anders. Een switch() werd uiteindelijk vertaald in een sloot if-else'jes. En geavanceerde array's werden een onleesbare spaghetti-brei. Vanzelfsprekend was er dus ook geen commentaarblok te lezen.
Als je het product in encoded versie aan een klant wilt leveren. Zorg dan voor een goede waterdichte juridische clausule dat het niet toegestana is om de applicatie te reverse-engineren of de source probeert te achterhalen. Je kan eventueel nog een licentiecheck inbouwen die elke dag een seintje geeft, of een controle uitvoeren of de bestanden ongewijzigd zijn (met md5_file() ). In dat laatste geval moet je bij nieuwe versies van de bestanden wel de juiste hash bijhouden.
Tegenwoordig is Maar als je toch zelf het product wilt verkopen aan de klant, die het zelf host dan is IonCube nog steeds de beste oplossing. Ik zie dat ze ook PHP 7.3 en 7.3 ondersteunen, zolang de nieuwe functies van deze versies maar niet gebruikt worden.
Of het veilig is durf ik niet te zeggen. In een ver verleden heb ik ooit eens uit onderzoek een Zend-encoded PHP-applicatie gedecompileerd met wat een dergelijke encoder. Volgens mij werkte dat programma door 'reversed engineering' toe te passen. De stijl van programmeren was ook totaal anders. Een switch() werd uiteindelijk vertaald in een sloot if-else'jes. En geavanceerde array's werden een onleesbare spaghetti-brei. Vanzelfsprekend was er dus ook geen commentaarblok te lezen.
Als je het product in encoded versie aan een klant wilt leveren. Zorg dan voor een goede waterdichte juridische clausule dat het niet toegestana is om de applicatie te reverse-engineren of de source probeert te achterhalen. Je kan eventueel nog een licentiecheck inbouwen die elke dag een seintje geeft, of een controle uitvoeren of de bestanden ongewijzigd zijn (met md5_file() ). In dat laatste geval moet je bij nieuwe versies van de bestanden wel de juiste hash bijhouden.
Gewijzigd op 04/11/2020 17:03:08 door - Ariën -
- Ariën - op 02/04/2014 17:51:15:
http://codeit.sg/php_encoder/
Als ik dit zo zie, vraag ik me af of er geen schimmige dingen mee worden 'gecompiled'. Dan zou ik als bedrijf liever voor Zend of IonCube gaan.
Als ik dit zo zie, vraag ik me af of er geen schimmige dingen mee worden 'gecompiled'. Dan zou ik als bedrijf liever voor Zend of IonCube gaan.
Link werkt niet :(
Jan R op 04/11/2020 18:09:04:
Link werkt niet :(
- Ariën - op 02/04/2014 17:51:15:
http://codeit.sg/php_encoder/
Als ik dit zo zie, vraag ik me af of er geen schimmige dingen mee worden 'gecompiled'. Dan zou ik als bedrijf liever voor Zend of IonCube gaan.
Als ik dit zo zie, vraag ik me af of er geen schimmige dingen mee worden 'gecompiled'. Dan zou ik als bedrijf liever voor Zend of IonCube gaan.
Link werkt niet :(
Al weer 6,5 jaar oud.
Gewijzigd op 04/11/2020 18:32:48 door - Ariën -