[PHP] Licentie binden aan modules

[T i M]

Ik heb een web applicatie gebouwd waaraan je modules kunt toevoegen. In de "kale" applicatie zonder modules zit alleen een facturatiesysteem.

Je kunt voor een bepaald bedrag per jaar modules voor kopen (web, game, stream en colocatiemodule). Nu wil ik aan de hand van de licentiesleutel kijken welke modules iemand mag activeren in zijn applicatie.

Nu ben ik aan het twijfelen of dit wel de juiste manier is, omdat er al 4 modules zijn. Ook is het de bedoeling dat er in de toekomst meer modules beschikbaar komen. Dus dan zou je teveel combinaties krijgen.

In de licentiesleutel die je ingeeft in de "kale" applicatie is een timestamp verwerkt tot wanneer de sleutel geldig is en het klantnummer.

[Verwijderd]

Ga je dan ook je applicatie encoded op een server zetten? Anders heeft een licentie systeem in PHP niet zo heel veel zin namelijk. Zeker niet als je klant fout wilt doen (lees niet betalen) en toegang heeft tot de PHP code.

maar als je het bitwise in een sleutel zet, kun je redelijk wat verschillende modules kwijt in een longword.

[T i M]

Alles wordt natuurlijk geencode mbv Iconcube.

[GlowMouse]

Kan de applicatie verbinding maken met internet? Je zou namelijk een soort phone-home functie in kunnen bouwen, die gebruikers eenmalig dienen te draaien zodra ze een nieuwe module willen gebruiken.
Zou je in de licentiecode de modules op willen nemen, heb je per 6 beschikbare modules een karakter nodig (met een karakterset van 64 tekens). Daarnaast moet je een checksum in je licentiecode hebben, zodat mensen niet gewoon dat enkele karakter kunnen wijzigen. Met enkele tientallen modules zou dat nog geen erg groot probleem zijn. Wel valt het op wanneer iemand een extra module koopt, en daarbij precies twee tekens in zijn code veranderen, dus er moet nog een encodering overheen.

[Verwijderd]

de TS zegt toch dat hij een 'web applicatie' heeft gebouwed. dus een web-bases met de browser bezoekbare applicatie. server-sided dus.

wat je dan het makkelijkste kunt doen is gewoon een database table gebruiken met voor elke module 1 collom. als je een nieuwe module toevoegt, maak je 1 extra collom aan in je database. en dan voor elke gebruiker 1 rij.

je kan dit wel via bitwise gaan doen maar dat is lang niet zo flexible daarnaast zijn bitwise opperaties in php altijd 32-bit en dus kan je maximaal kun 32 modules kwijt. dat kan genoeg zijn maar ook niet. zolang je alles toch server-sided draait heb je legio aan mogelijkheden over hoe je dit wilt doen.

ander scenario:
je hebt een web-applicatie gemaakt welke op de server van de gebruiker komt te staan. in dat geval heb je een echt probleem omdat php namelijk een interpetet language is welke gewoon in plain-text wordt opgeslagen. dus welk systeem je ook bedenkt de gebruiker kan altijd zo even in kladblok dat eruit slopen en lekker zijn gang gaan.

de enige oplossing is dan je source-code encrypten. ik geloof dat zend daar een tooltje voor heeft.

[GlowMouse]

Verwijderd schreef op vrijdag 20 april 2007 @ 14:40:
de TS zegt toch dat hij een 'web applicatie' heeft gebouwed. dus een web-bases met de browser bezoekbare applicatie. server-sided dus.

Web-applicaties kunnen op een intranet draaien, zonder contact met de buitenwereld.

wat je dan het makkelijkste kunt doen is gewoon een database table gebruiken met voor elke module 1 collom. als je een nieuwe module toevoegt, maak je 1 extra collom aan in je database. en dan voor elke gebruiker 1 rij.

Lees eens over normaliseren.

je dit wel via bitwise gaan doen maar dat is lang niet zo flexible daarnaast zijn bitwise opperaties in php altijd 32-bit dus maximaal kun 32 modules kwijt. dat kan genoeg zijn maar niet. zolang je alles toch server-sided draait heb je legio aan mogelijkheden over hoe je dit wilt doen.

Je kunt gewoon meerdere stukjes met bits achter elkaar verwerken om die limiet te omzeilen.

[Plopeye]

Wat betreft het 32 bits verhaal maar 32 mogelijkheden net als wat mijn voorganger al zei, je hebt veel meer mogelijkheden. 32 bits dan heb je 2 macht 32 mogelijkheden is dus ruim 4,3 miljard...

[T i M]

Meer dan 10 modules gaan er niet komen hoor, dus dat is het probleem niet. Verder komt mijn applicatie niet op een intranet te draaien.

[Verwijderd]

met een internet applicatie doel ik op een dienstverlening van de TS over het internet.
ja je kunt meerdere intergers aan mekaar hangen echter wil dit nog niet de beste oplossing te zijn.

wat nog steeds onduidelijk is is of de TS in controlle is over de server en dus de sourcecode of dat zijn sourcecode op de server van de klant komt te draaien. dit maakt nogal wat uit want PHP is gewoon een stuk tekst wat een ieder kan bewerken die een beetje php kan.

als de applicatie draait op een server die niet in controlle van de TS is, dan kun je hoog en laag springen met bitwise en databases. het werkt niet omdat je hele beveiliging gewoon eruit gesloopt kan worden.

[Verwijderd]

wat nog steeds onduidelijk is is of de TS in controlle is over de server en dus de sourcecode of dat zijn sourcecode op de server van de klant komt te draaien. dit maakt nogal wat uit want PHP is gewoon een stuk tekst wat een ieder kan bewerken die een beetje php kan.

Nee daar wordt een bytecode compiler voor gebruikt (net als bij react dus) je krijgt geen php code maar een compiled versie van die code.

[Verwijderd]

Verwijderd schreef op vrijdag 20 april 2007 @ 15:32:
[...]


Nee daar wordt een bytecode compiler voor gebruikt (net als bij react dus) je krijgt geen php code maar een compiled versie van die code.

dat is waar ik op doelde dat zend hier een tooltje voor heeft.

echter wordt native php gewoon als plain-tekst opgeschreven en ingelezen. de php JIT compiler verwerkt dit tot bytecodes. wat zo'n tool doet is de plain-tekst versie alvast omzetten naar bytecodes en die nog eens een keertje encrypten alvorens ze aan te bieden aan de php-runtime.

php wordt toch echt native als plain-tekst opgeslagen.

*edit: die tool van zend heet zendguard. er is ook een opensource programma in ontwikkeling wat ongeveer het zelfde moet kunnen.

zie ook:
http://www.php.net/manual/en/ref.bcompiler.php
http://www.zend.com/products/zend_guard

[ Voor 14% gewijzigd door Verwijderd op 20-04-2007 15:49 ]

[GlowMouse]

Mijn reply van 14:42 had ik haastig getypt, en kwam daarom misschien wat onaardig over.

Wat betreft het 32 bits verhaal maar 32 mogelijkheden net als wat mijn voorganger al zei, je hebt veel meer mogelijkheden. 32 bits dan heb je 2 macht 32 mogelijkheden is dus ruim 4,3 miljard...

Iedere bit kan 0 of 1 zijn, afhankelijk van of je een module gebruikt of niet. Met 32 bits heb je 4,3 miljard verschillende configuratiemogelijkheden, maar dat komt precies overeen met het aantal mogelijkheden om een aantal van 32 modules te activeren. Je kunt er dus echt maar 32 modules afzonderlijk aan/uit zetten.

Docey: Ioncube (zie derde post) doet hetzelfde als Zend Guard. Hoewel er voor beide encoders ook decoders in omloop zijn, en er dus geen echte bytecode wordt geproduceerd (google op zend decoder), is dit over het algemeen toch een aanvaard niveau van beveiliging.

Met maximaal 10 verschillende modules zou ik 3 karakters opofferen om de modules via bits te encoden. Je hebt dan groeimogelijkheden tot 18 modules, mocht het ooit nodig zijn.

[Verwijderd]

32-bit kun inderdaad zien als 32 boolean true/false of aan/uit waardes.

zend decoder zit volgensmij in het pakket zend guard inbegrepen en ja die zijn inderdaad een heel stuk moeilijker om te kraken. vergelijk het met het aanpassen van de sourcecode wat je makkelijk in elke tekstverwerken kan en het aanpassen van een assembly wat ook wel lukt maar toch heel veel meer kennis over de internen van php vereist. vergelijkbaar met het verwijderen van de copieerbeveiliging van computer games die vaak ook helemaal in de assambly zit verweven. alleen mensen die echt weten wat ze doen lukt dat. zend guard werkt ook met naam obfuscatie zodat alle name van classess, functies en variable worden gerandomized wat weer een extra'tje toevoegt en de lat nog hoger legt.

ioncube ken ik zo niet maar zal inderdaad wel ongeveer het zelfde doen dus daar doe ik uitspraak over.

[GlowMouse]

Verwijderd schreef op vrijdag 20 april 2007 @ 22:03:
zend decoder zit volgensmij in het pakket zend guard inbegrepen en ja die zijn inderdaad een heel stuk moeilijker om te kraken.

Zend decoder is geen product van Zend, maar iets waar je op kunt Googlen. Het product van Zend heet namelijk Zend Optimizer, en dat moet je als module in PHP gebruiken om via Zend Guard beveiligde scripts te kunnen draaien.
Wat ik probeerde te zeggen, is dat er voor Zend Guard en Ioncube decoders beschikbaar zijn. Daarmee krijg je gewoon weer een leesbare broncode terug waar je de beveiliging uit kunt slopen. Zie bijvoorbeeld hier, hier en hier. Via (automatische) obfuscatie kun je het eruit slopen van de beveiliging na het decoden iets moeilijker maken, maar zo moeilijk als jij het schetst, is het dus niet.

[ Voor 7% gewijzigd door GlowMouse op 20-04-2007 22:26 ]

[TheRebell]

de kans dat een bedrijf die jouw applicaie draait in de (gecodeerde) broncode gaat zitten rommelen is denk ik dermate klein dat je je hier nu niet echt (gelijk)druk om hoeft te maken. Een bedrijf koopt jouw pakket omdat het het zelf niet kan maken en is al blij dat het nu hier gebruik van kan maken.
Uiteraard zit er een kans in dat iemand er eens iets in gaat rommelen, dat kun je incalculeren en bijvoorbeeld (gedeeltelijk) in de kostprijs verrekenen.

De meeste ISP's maken er trouwens niet zon punt van om de decoder ook op de server te zetten en daarbij is deze gratis en heeft deze nauwelijke negatieve invloed op de performance