Anti-Piracy eigen software - Softwareontwikkeling

maandag 25 maart 2002 22:40

Acties:

Topicstarter

Ik ben haast klaar met het (opnieuw her-)schrijven van eigen software (een bulletin bulletin board system) in PHP. Nu zijn er nog een aantal andere projecten (Portal met modulesysteem met nieuws shop enzovoorts waarmee iemand in 15 minuten z'n eigen portal gecustomized en al online kan hebben, al 1/5 deel af, meeste modules moeten nog + een paar projecten die ik hier niet uit de doeken doe, zijn nogal origineel nl.) en die software wil ik dus verkopen. Ga m'n eigen bedrijfje opstarten enzovoorts.

Nu ben ik aan het denken geslagen om anti-piracy tegen te gaan, ik zoek een model waarmee ik niet alleen m'n huidige software maar ook alle toekomstige projecten mee kan beveiligen. Ik heb al een aantal oplossingen bedacht, maar kunnen jullie me misschien tips geven, wijzen op dingen die ik vergeten ben, betere manieren geven?

=--------=

1) Software alleen via internet aanbieden (dus niet op cd met manual en in doos enzo), naar de klant toegemailt in een zipje met een uniek password.

Voordelen:

-Simpel, hoeft geen ingewikkeld geautomatiseerd proces ontwikkeld te worden zodat er zonder mijn interventie een kopie van het product ge-'unique'-d word en naar de klant toegestuurd wordt.

Nadelen:

-1 klant hoeft het maar te kopen, te unzippen, opnieuw te zippen en te releasen via een warez group. Niet echt effectief dus.

=--------=

2) Routine inbouwen bij bijv. een installatiescript, waarbij dmv een keygenerator wordt gekeken of de serial die de gebruiker gekregen heeft bij aanschaf wel klopt.

Voordelen:

-Bij het releasen van de software in een warezgroup kan dmv de serial de gebruiker getraceerd worden en zo mogelijke actie ondernomen worden.

Nadelen:

-De gebruiker hoeft maar een klein beetje verstand te hebben van PHP om de desbetreffende routine uit het script te halen of te vervangen door iets dat wat er ook maar ingevoerd wordt toch als correct beschouwd.

=--------=

3) Routine inbouwen op een onregelmatig gebruikte maar toch belangrijke plek in de software (bijv: de pagina om de algemene opties van de software te wijzigen) die de serial die de gebruiker gekregen heeft bij aankoop en het domein waar de software op draait naar de server te sturen van het product en dmv een daar bijgehouden database te kijken of het domein en de serial bij elkaar horen.

Voordelen:

-Klant kan zelf z'n serials beheren, kan bij een verhuizing dus even naar de server van het product gaan, inloggen en z'n domein wijzigen zodat er automatisch een nieuwe serial in plaats van de oude gegenereerd wordt.

-Software hoeft niet ge-'unique'-d te worden, aangezien een serial die door de gebruiker zelf ingevoerd kan worden niet in de software zelf nagekeken wordt maar op de server van het product, en zodoende de gebruiker alleen de software kan draaien op de hoeveelheid domeinen waarvoor licences zijn aangeschaft.

Nadelen:

-Server mag niet down zijn, anders zou een klant z'n opties niet meer kunnen wijzigen. Ookal kan dat 'uitgerekt' worden door bijv de opties nog 3x te kunnen wijzigen voordat het software pakket beslist dat na die 3x dat de server niet bereikt kon worden de opties niet meer gewijzigd mogen worden. Ook zou een klant bij een verhuizing van de site geen nieuwe serial kunnen laten genereren en zodoende ook de software niet kunnen laten draaien op het nieuwe domein.

=--------=

4) Geen serialscript in de software, en ook geen uniekheidsfactor (aka serials dmv de server vergelijken), maar de software heel goedkoop verkopen en supportlicensies uitgeven. (dus voor elke maand dat een gebruiker zgn. 48hrs-support (garantie dat de klant binnen 48 uur gehopen wordt en dat een mogelijke krietieke bug in de software binnen datzelfde termijn opgelost wordt) wilt dient de gebruiker een extra 1maands-support licensie aan te schaffen)

Voordelen:

-De 'serieuze' klanten (bedrijven bijv.) zullen wel graag support willen voor het geval dat er iets mis zou kunnen gaan.

-Ookal wordt de software gereleased via warezgroups, veel mensen kunnen er niet veel mee. (althans: dat is de bedoeling; zie nadeel)

Nadelen:

-Zie hierboven. Aangezien software zo klantvriendelijk mogelijk dient te zijn (maar toch tegelijkertijd zo customizable mogelijk) is het niet zo moeilijk om het pakket te beheren. Oftewel: een paar opties instellen en klaar is kees: een kind kan de was doen.

=--------=

Oftewel, er is niet echt iets goeds. Natuurlijk, niks is waterdicht, maar er moet toch een betere manier zijn dan die waar ik al over gedacht heb? Misschien heb ik iets vergeten en is een van deze manier toch geschikt door er een extra factor in te gooien?

BTW: Ik heb ook al gedacht Zend Encoder aan te schaffen, maar dat is nu gewoon nog niet rendabel, omdat ik ook niet verwacht dat m'n huidige project super zal gaan lopen (aangezien er al zoveeeel verschillende bulletin board paketten zijn), dus dat is eigenlijk geen optie. Pas als het huidge project goed loopt of een van m'n andere projecten van de stapel af is en klaar is voor release zou ik Encoder aan kunnen schaffen.

maandag 25 maart 2002 22:48

Acties:

brammetje

Tja, een beveiliging inbouwen in een 'open-source' pakket gaat gewoon nooit werken, zelfs closed-source pakketten worden gehacked..

enige reele oplossingen lijken mij de laatste en natuurlijk Zend Encoder icm met een serial..

maandag 25 maart 2002 22:52

Acties:

Orphix

Zoals je al zegt, als je met PHP een produkt aflevert kan het nooit waterdicht zijn omdat de source nou eenmaal beschikbaar is. Elke security-check die er in zet kunnen ze eruit strippen. Je kan ze natuurlijk heel obscuur ergens neerzetten, maar een beetje programmeur vindt ze altijd wel.

De enige manier waarop je het goed kan doen is door de Zend encoder te gebruiken en dan checks in het script inbouwen. Je geeft al aan dat dit voorlopig niet rendabel is, en dat kan ik goed begrijpen.

Voor een board zou ik er maar gewoon rekening mee houden dat veel mensen je software illegaal zullen gebruiken.
Puur vanwege het feit dat diegene die perse gratis een (commercieel) forum willen hebben komen er toch wel aan. Is het de jouwe niet, dan wel een ander. (Bedenk dat wanneer jouw forum illegaal draait, het nog wel reclame is!)
Er zijn gelukkig genoeg mensen die nog wel een bedrag van 100 euro voor een goed stabiel forum willen betalen + support. Vooral dat laatste is erg belangrijk want dat onderscheidt je van de gratis troep.

HTH

maandag 25 maart 2002 22:58

Acties:

Verwijderd

Misschien een beetje omslachtig, maar misschien haalbaar.

Bepaalde cruciale handelingen door een PHP script op afstand (bijv de server van jouw bedrijf) laten uitvoeren. Dit script is een blackbox, dus een buitenstaander kan er wel iets in stoppen en iets uit krijgen maar weet niet wat er gebeurt.
Dit script koppel je aan een logbestand. Requests van niet geregistreerde gebruikers (klanten) worden afgewezen, waardoor hun bbs niet functioneert)

Nadelen:
- Jouw server moet altijd werken / online zijn
- Werkt niet zonder internet verbinding (lokaal gebruik in een netwerk)

hmm.. best wel onzin eigenlijk, kun je net zogoed direct het bbs op jouw server hosten...

maandag 25 maart 2002 22:58

Acties:

Aetje

Troubleshooting met HAMERRR

Hmz... Waar ik werk pakken ze dat anders aan:
Op een van de compjes komt een licensieserver te draaien. Deze regelt alle licensiering. Deze server genereert een key (pakt 't MAC adres van de LAN adapter en het HD serial nummer en laat er 'ns 'n lekker algoritmetje op los), en die key stuurt ie (of vraagt ie de klant te versturen naar) het bedrijf. Bedrijf vervolgens stuurt een of meerdere serials (voor elk produkt uniek) terug. De app controleert bij starten of een geldige serial voor dat systeem aanwezig is door de licentieserver te queryen. (deze staat dus gewoon naast de app geinstalleerd).

Voordelen: Voor elke app, voor elke vorm van licensering slechts een tooltje. Alles is te regelen met een licentieserver (aantal gebruikers, aantal maal gebruik ect.)

Nadeeltje: Als dat tooltje dus gehakt wordt... ... ...

Forget your fears...
...and want to know more...

maandag 25 maart 2002 23:00

Acties:

Orphix

Op maandag 25 maart 2002 22:58 schreef Aetje het volgende:De app controleert bij starten of een geldige serial voor dat systeem aanwezig is door de licentieserver te queryen. (deze staat dus gewoon naast de app geinstalleerd).

Tja en dat kan je er met PHP dus gewoon uitrippen...

maandag 25 maart 2002 23:03

Acties:

Verwijderd

Ik heb ooit eens een programma gehad en om dat te gebruiken moest je registreren met een controlecode die uniek is voor elke PC. Die controlecode mailde je dan naar de programmeur en aan hand van die code, stuurde hij de registratiecode op om het programma te gebruiken.

Het vreemde van dat systeem was, dat na formatteren van de harddisk die controlewaarde weer anders was.

Ik snap allemaal niet hoe zoiets werkt, maar misschien kan je d'r wat mee.

Maar ook hiervoor geldt natuurlijk: je kan het uit de PHP code rippen

maandag 25 maart 2002 23:44

Acties:

Grum

Als jij niet denkt genoeg geld te gaan verdienen om zend encoder te kunnen betalen... dan hoef jij je zeker niet druk te maken over 'kiddos' die er met je code vandoor gaan.

Als je product niet bekend is word het ook niet gejat en levert het nix op. Als het daarintegen wel bekend is dan levert het genoeg geld op en kan je altijd nog overwegen om het close source te maken mbv Zend Encoder (weet wel dat het behoorlijk onzinnig is want je verliest populariteit en compatibiliteit)

maandag 25 maart 2002 23:57

Acties:

.oisyn

Moderator Devschuur®

Demotivational Speaker

.edit: onzin, niet goed gelezen

.edit2: toch nog maar even een reactie

Ik denk dat je je meer moet richten op wat je wel verkoopt, ipv wat je niet verkoopt. Als jij een redelijke omzet weet te creeeren dan boeit het helemaal niet of het gewarezd wordt of niet (en zie het maar zo: als het een goed produkt is wordt het toch wel gewarezd, niets aan te doen)

Dus persoonlijk zou ik kiezen voor punt 4. Ligt er natuurlijk wel aan aan wie je je product wil verkopen (bedrijven geven veel meer om support dan particulieren), en als je goede aantrekkelijke afspraken kunt maken dan zijn volgens mij vrij veel mensen geinteresseerd. Bovendien kun je het onderverdelen in goedkope en duurdere licensies, en korting geven voor licensies op lange termijn (bijvoorbeeld jaarbasis is relatief goedkoper dan maandbasis).

En behalve de bugs vallen de feature requests natuurlijk ook onder support, en dat maakt het voor bedrijven helemaal interessant. Want als jij een op maat gemaakt produkt kunt afleveren voor relatief weinig geld, dan zullen ze sneller voor jouw produkt kiezen dan voor een een of ander standaard geval.

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.

dinsdag 26 maart 2002 00:18

Acties:

raptorix

Ik ga binnenkort ook weer wat zaken uitbrengen, wil het eigenlijk als een soort van open source gaan aanbieden waar men eigenlijk alleen betaalt als het commercieel ingezet wordt, daarnaast hoop ik juist met support te verdienen, en niet zo zeer op verkoop van het product.

dinsdag 26 maart 2002 00:28

Acties:

DiSiLLUSiON

Topicstarter

Grum:

Ik denk NOG niet genoeg te kunnen verdienen om het rendabel te laten zijn. 1 pakketje verkoopt heus niet zo toppie, in de eerste plaats omdat er al zoveel bulletin board paketten op de markt zijn en als tweede omdat ik geen geld heb reclame te maken, mond-op-mond reclame is het enige wat ik me nu nog kan veroorloven. In Juni komt een rekening vrij met een paar mille erop waarvan ik er wel een gedeelte in wil steken, maar dat is pas in Juni, en zolang ga ik niet wachten. Ik verwacht dat het pas rendabel wordt zodra OF m'n bulletinboard pakket beter verkoopt dan gedacht, OF ik 1 van m'n andere projecten af heb, die groter zijn (en sommige ook origineel en hopelijk gewild) en zodoende dus meer inkomsten genereren.

1 ding snap ik niet van je uitspraak: waarom zou ik compatibiliteit en populariteit verliezen als ik m'n pakketten gecodeerd zou uitgeven? Bij pakketten als bulletin boards zijn zgn. 'Hacks' heel populair, als een gebruiker iets d'r in stopt wat (nog) niet in het officiele pakket zit, dat snap ik, maar voor de rest? en voor zover ik weet wordt Zend Optimizer ondersteund door dezelfde platformen als die PHP ondersteunen.. En zit het er bij de meeste hosts vaak al op, dus hoeft een klant het niet te installeren behalve als die een eigen server heeft.

Racetows:

Dat klinkt als het anti-rip systeem wat MS gebruik in Windows XP. Een leuk systeem icm Zend Encoder, maar daarmee zadel ik de klant wel met extra problemen op in het geval een deel van de server vervangen wordt (wat vaak gebeurt, nieuwe hd, nieuwe proc, extra ram enz.), dus dat kan ik eigenlijk niet maken vind ik..

Aetje: Dat licensieprog moet dus ook in PHP geprogrammeerd zijn, omdat er anders niet genoeg compatibiliteit is, en zodoende kan het dus alsnog veranderd worden.

d0g1e: Damn, daar zeg je me wat hey.. Als 'erbij' het product als service aanbieden, dat het op de server van het product gedraaid wordt. Dat is opzich wel een goed idee! ...Alleen denk ik niet dat het rendabel is, want bandbreedte is erg duur natuurlijk. En anders moeten er bij die service-paketten er banners bij komen, en dan wordt het 1 van de zoveel sites die dat soort services aanbieden, en dat zie ik eigenlijk niet zo zitten.. maar het idee heeft opzich wel wat, 'k ga er ff over denken of dat mogelijk is.. niet IPV, maar als extra product zegmaar.. thnx!

Orphix:
Daar heb je wel gelijk in, als veel mensen m'n software illegaal draaien is het natuurlijk goede reclame, maar ik ben wel bang dat straks mócht het pakket popi worden dat 98% illegaal de software draaien, en m'n inkomsten nogniet eens genoeg zijn om de website(server) van het product draaiende te houden, bij wijze van spreken.

brammetje:
Is dat wel rendabel denk je? Aangezien software tegenwoordig zo gebruiksvriendelijk mogelijk moet zijn, en mijn software dat natuurlijk ook is, begin ik steeds meer twijfels te krijgen of mensen zulke support-licences wel zullen kopen als ze de software kopen, aangezien het configureren en beheren van het pakket kinderspel is.. Of verkijk ik me nu en zullen veel bedrijven die extra kosten voor lief nemen in ruil voor de zekerheid dat ALS er wat mis gaat er 48hrs support is?

dinsdag 26 maart 2002 00:37

Acties:

SPee

Ik zou het direct aan de man verkopen en zelf installeren.

Uitleggen en draaiklaar afleveren. In combinatie met een persoonlijke serial haal je zelfs een paar nadelen(1

) weg.

voordeel: je ziet elke klant, je houdt controle op wat hij doet.

nadeel: je krijgt veel werk, kost tijd/geld, je paketten kunnen (te) duur worden, het kan alsnog gekopieerd worden.

let the past be the past.

dinsdag 26 maart 2002 00:39

Acties:

vassago

Als bedrijven 48-uurs support willen is het belangrijk, als het belangrijk is zullen ze niet kiezen voor een onbekend pakket van een een-mans bedrijfje (no offense) maar voor een pakket van een bekend bedrijf.

Tenzij je software zo uniek is dat je de enige bent...

Bovendien, betalen voor bugfixes?
Ik neem aan dat je wat anders bedoelt met support contract. (ie. user errors e.d.)

dinsdag 26 maart 2002 00:46

Acties:

DiSiLLUSiON

Topicstarter

vassago: Dus wat je zegt is dat een licence-systeem niet haalbaar is.

En met 48hrs support bedoel ik dat als er problemen zijn (wat dan ook, installatie, configuratie, probs door verkeerde serverconfig ofzo) die binnen 48 uur max verholpen zullen worden. Met bugfixes bedoel ik dat bij niet-kritieke bugs (dus bugs die niet met security ed te maken hebben) er pas na een week of 2 een update uitkomt waar die patches allemaal in verwerkt zitten. Bij kritieke bugs daar zal binnen 48 uur max een update voor in de membersarea van de site staan, en de klanten met een supportlicence zullen meteen op de patch gewezen worden en geholpen worden met het installeren, mochten ze daar hulp bij nodig hebben (dáár betalen ze voor), klanten zonder supportlicence zullen zelf regelmatig op de site moeten kijken of er patches of updates zijn en die dan van de server moeten halen en zelf installeren.

SPee: Het probleem is dan dat dat alleen kan bij klanten die woonachtig zijn in Nederland of waar het bedrijfspand / serverpand in Nederland staat.

dinsdag 26 maart 2002 01:19

Acties:

Grum

DiSiLLUSiON:
1 ding snap ik niet van je uitspraak: waarom zou ik compatibiliteit en populariteit verliezen als ik m'n pakketten gecodeerd zou uitgeven? Bij pakketten als bulletin boards zijn zgn. 'Hacks' heel populair, als een gebruiker iets d'r in stopt wat (nog) niet in het officiele pakket zit, dat snap ik, maar voor de rest? en voor zover ik weet wordt Zend Optimizer ondersteund door dezelfde platformen als die PHP ondersteunen.. En zit het er bij de meeste hosts vaak al op, dus hoeft een klant het niet te installeren behalve als die een eigen server heeft.

Mond op mond reclame gaat nou eenmaal het beste door de warez scene heen. Daarnaast kan je als je et 'encode' geen hacks meer toevoegen en je stelling dat je het overal kan draaien moet ik je helaas in teleurstellen het is maar op een paar specifieke configs te draaien.

Supported operating systems:
Linux (glibc 2.1),
Red Hat 7.1,
Sparc Solaris 2.6 / 7 / 8,
FreeBSD 3.4 / 4.0 / 4.3

Tuurlijk zal het met wat gepiel op wel meer plekken draaien maar het gepiel schrikt gebruikers al af. Wat is der nou beter dan een opensource forum met je copyright erin/erop wat iedereen graag wil gebruiken omdat het 'lekker simpel' is.

Ik vrees dat je ook fout zit met je redenatie dat Zend Encoder bij veel hosts al is pre-installed. Het is extra werk met een extra kans op problemen, vergt extra documentatie/uitleg en vaak wegen deze dingen niet op tegen de evt winst en dus wordt het gewoon niet installed.

Als je echt groot wil worden moet je dus ook denken aan UBB/VBB post converters om op te slaan in je eigen database. Het gemak van de gebruiker moet voor alles gaan want zonder je gebruikers heb je nou eenmaal nix.

Zoals al eerder is gemeld:

Focus op wat je WEL kan krijgen en niet op wat je niet kan krijgen. Warez zijn niet zo fout .. je krijgt er een enorm goede naamsbekendheid mee en niet alleen in de 'foute' kringen maar ook in de kringen die jou graag geld geven voor support en een mooi brok software.

Yet another € 0.02

dinsdag 26 maart 2002 01:26

Acties:

Basszje

Reisvaap!]

Jup ik zou het gewoon gratis doen voor de pielers, maar ongratis voor bedrijven (oid?).

En met support, dat wordt zowiezo de toekomst denk ik. Goedkopen software, maar betalen voor de support.
En bedrijven hebben liever goede support dan iets gratis hoor.

Beware of listening to the imposter; you are undone if you once forget that the fruits of the earth belong to us all, and the earth itself to nobody.

dinsdag 26 maart 2002 01:31

Acties:

.oisyn

Moderator Devschuur®

Demotivational Speaker

Op dinsdag 26 maart 2002 01:19 schreef Grum het volgende:
Focus op wat je WEL kan krijgen en niet op wat je niet kan krijgen.

idd, precies wat ik al zei dus, maar volgens mij heeft ie over mijn reactie heen gelezen (waarschijnlijk omdat ik m later geedit heb) (en nu voel ik me buitengesloten

)

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.

dinsdag 26 maart 2002 01:47

Acties:

RgR

<quote>
(...) dat is de bedoeling; zie nadeel)

Nadelen:

-Zie hierboven.
</quote>

Help, ik loop vast!

dinsdag 26 maart 2002 01:49

Acties:

Grum

OiSyN: idd, precies wat ik al zei dus, maar volgens mij heeft ie over mijn reactie heen gelezen (waarschijnlijk omdat ik m later geedit heb) (en nu voel ik me buitengesloten )

ow shit .. dat had ik er nog bij willen zetten

.. maar ik was een beetje in me sas en met andere dingen bezig omdat onze eigen nameserver met bind emulatie bind's kont schopt!

sorry!

dinsdag 26 maart 2002 01:53

Acties:

.oisyn

Moderator Devschuur®

Demotivational Speaker

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.

dinsdag 26 maart 2002 02:00

Acties:

DiSiLLUSiON

Topicstarter

Grum:

Hmm, ik heb me blijkbaar behoorlijk verkeken op de 'encoder-issues'.. Vooral de compatibiliteit schrikt wel heel erg af, Zend Encoder wordt nu wel heel wat minder aantrekkelijk zo.

Importscripts heb ik al (voor vBulletin 1.1.x & 2.0.x, Ikonboard 3, UltraBoard 2000 en phpBB 1.4.x. UBB ben ik nog niet aan begonnen maar staat wel op de planning. Ook zit ik eraan te denken een importscript te maken voor phpBB 2.x zodra die uit is, Ezboard en Phorum. Weet iemand nog een ander forum wat redelijk bekend is?), en die zullen als 'goodies' bij het pakket worden bijgeleverd.

En thnx voor die € 0.02, 'k wordt nog eens rijk zo

Basszje: M'n focus ligt eigenlijk niet op de 'thuisgebruiker', want die zullen via warez kanalen toch wel aan elk softwarepakket kunnen komen wat hun hartje belangt. M'n focus ligt dus meer op bedrijven, m'n forum software is ook al klaar om als module in m'n portal project geschoven te worden.

OiSyN: en mijn excuses

En zoals ik al zei, m'n focus ligt meer op bedrijven. Ik krijg regelmatig emailtjes van een aantal bedrijven over wanneer m'n software nou al klaar is

en ik ben ook aan het praten met een redelijk groot nederlands bedrijf wat domeinnamen verkoopt en dedicated server plaatsen en ruimte op hun servers enzo, om licensies van m'n product (en toekomstige producten) voor een kleine prijs te kunnen verkopen aan hun zodat hun die bij hun hostingpakketten kunnen leveren zodat het bij aanschaf van een van hun hostingpakketten de software al geïnstalleerd en klaar voor gebruik is.

Dat met die langere-licencies-zijn-goedkoper was ik al van plan.

Ook heb je idd wel gelijk met dat feature-requests onder support vallen, en dat zal ook gebeuren, maar er komt misschien ook een optie om het pakket helemaal naar hun wensen aan te passen, zodat het alleen bevat wat de klant nodig heeft en waarschijnlijk iets sneller is, mocht daar vraag voor zijn.

raptorix: Het zal ook geen open source worden. Programmeergrage klanten mogen best hacks uitbrengen, maar als een klant zo'n hack installeert zal er geen support gegeven worden, wat vanzelfsprekend is, en ook zal de software niet door anderen verkocht mogen worden. Het wordt dus closed-source, alleen je kunt de source bekijken

Want zend encoder is nu helemaal geen optie meer.

dinsdag 26 maart 2002 02:00

Acties:

raptorix

Het leukste is als je een goede core opzet en een community eromheen kan bouwen, wees wel vanaf beginaf duidelijk hoe het met de copyrights zit, er zijn de laatste tijd behoorlijk wat systemen die als opensource zijn gestart, verandert in gesloten source. Als je daar vanaf begin af aan duidelijk in bent zal niemand het je kunnen verwijten.

dinsdag 26 maart 2002 09:31

Acties:

Verwijderd

Een bedrijf als jelsoft (vbulletin) gebruikt jouw manier 1. Volgens mij is dit de best manier.. Ik denk dat je je code niet moet encode met zend alleen al vanwege je hacks / support community..

Maak iets op je site wat er voor zorgt dat het kopen waard is.. Speciale "geheime" sectie.. ik weet het niet maar verzin iets..

dinsdag 26 maart 2002 09:40

Acties:

Verwijderd

Een ander alternatief tot het gebruik van Zend Encoder is het schrijven van je eigen PHP module (ja, in C ja) welke cruciale functionaliteit en license checking bevat en deze binair leveren.

Dit is dezelfde manier waarop Zend haar producten levert.
Zij baseerd haar codes op MAC address.

Voordelen:

Je levert je source mee, waarmee je indirect feedback genereert. Klant kan moeilijk module weghalen.

Nadelen:

Je zult voor ieder platform welke je wilt gaan supporten deze module moeten maintainen. En tja, PHP is een - maar dan is C nog een heel ander verhaal!

dinsdag 26 maart 2002 09:50

Acties:

TheDane

1.618

Op dinsdag 26 maart 2002 09:31 schreef TimD het volgende:
Een bedrijf als jelsoft (vbulletin) gebruikt jouw manier 1. Volgens mij is dit de best manier.. Ik denk dat je je code niet moet encode met zend alleen al vanwege je hacks / support community..

Maak iets op je site wat er voor zorgt dat het kopen waard is.. Speciale "geheime" sectie.. ik weet het niet maar verzin iets..

hierop inhakend:

ik kan me voorstellen dat de volgende zaken zoiets 'koopwaardig' maken; oftewel echt toegevoegde waarde zijn voor een forum:

• integratie met office netwerk (userlist/domain uit server extracten, adresboeken, authenticatie)
• integratie met andere (lopende) (web-)applicaties

Voor beide punten moet je wel inhouse service verlenen hoogstwaarschijnlijk, maar bedrijven hebben dan wel een custom BB, in sync met hun lopende zaken

weet alleen niet of 't zomaar kan

dinsdag 26 maart 2002 11:47

Acties:

Verwijderd

We zijn het er wel over eens dat beveiligen tegen hackers die je php code gaan wijzigen niet echt mogelijk is.
Je hoeft het ze echter ook weer niet al te makkelijk te maken.
Je kan denken aan het volgende:
Er is een demo versie van je code die volledig werkt (dat is meteen goede reclame). Die demo zorgt ervoor dat op diverse plaatsen in je programma Demo versie o.i.d. op je scherm komt te staan.
De tekst demo versie staat natuurlijk niet als clear text in je code maar in een encrypted bestandje. In je code lees je dat bestand uit en de waarden die je uitleest gebruik je in de display functies.
Crackers kunnen natuurlijk simpel de display aanroep vervangen en daarvoor in de plaats hun eigen text tonen. Echter, dan moeten ze wel voor hun gekraakte versie een crack tooltje schrijven dat de text (bijv. bedrijfsnaam) kan aanpassen voor anderen (waardoor het voor bedrijven die tegen dat programma aanlopen meteen duidelijk is dat ze niet legaal bezig zijn). Om het nog moeilijker te maken kan je ook bepaalde code fragmenten (bijv. voor het wijzigen van de instellingen) in het encrypted bestand opslaan en 'on the fly' in je php code tussenvoegen (als dat mogelijk is, ben niet bekend met php).
Als iemand n.a.v. de demo geinteresseerd is en een licentie wil dan encrypt je voor diegene een nieuw bestand met daarin zijn licentie informatie die in het programma getoond wordt (bijv. in de about functie of in de titel).
Samen met het bestand met deze encrypted info geeft je hem een bestandje met daarin het unieke wachtwoord om je encrypted bestand te kunnen lezen. Je programma leest het wachtwoord in en decrypt de licentie info. Omdat jij alleen beschikt over het encryptie programma kan men niet zelf makkelijk de eigen informatie aanpassen.

dinsdag 26 maart 2002 19:48

Acties:

Infinitive

Allerlei moeilijke toeren gaan uithalen heeft geen zin, want iemand die voldoende kennis van php heeft zal zelfs de "encrypted code" ontcijferen, door te kijken hoe de string die aan eval() wordt doorgegeven in elkaar zit.

Je maakt het alleen voor mensen met wat minder kennis van php wat moeilijker... maar in dat geval kan je beter een obfuscator zoeken en over je code heengooien.

putStr $ map (x -> chr $ round $ 21/2 * x^3 - 92 * x^2 + 503/2 * x - 105) [1..4]

dinsdag 26 maart 2002 23:05

Acties:

Stewie!

Keen must die!

Als je echt zeker wilt weten dat niemand jouw code kan lezen, bouw dan een "hosted version" van jouw progje. Die host je op je eigen server, en dan zeg je tegen je klant:
- progje kan je gebruiken voor €bla/maand
- progje wordt altijd automatisch (door jou dus) geupdate, dus geen zorgen om oude versies en verkeerde updates
- progje heeft vooledige support (makkelijk te leveren, want staat toch op JOUW server)
- progje blabla kan niet zo snel effe verzinnen
- progje gebruikt altijd de nieuwste servers: makkelijk te doen, gewoon altijd de nieuwste apache server met php en mysql gebruiken en desnoods nog sablotron en gdlib enz

Alleen moet je zorgen voor:
- dataverkeer dat teveel wordt, open desnoods een account bij een of andere hoster en stuur de rekening + 25% door naar je klant
- ruimte op server
- server capaciteit, als je bijvoorbeeld scripts hebt die zoveel van de processor vragen dat die wel effe bezig is

ik hoop dat ik je hiermee heb geholpen

Strava: https://www.strava.com/athletes/149347154

dinsdag 26 maart 2002 23:38

Acties:

tomato

Wij bieden onze forumsoftware ook 'hosted' aan.

Met een druk op de knop heeft iedere klant de nieuwe versie van de software, voor ons is support erg gemakkelijk te leveren, geen gezeik met verschillende serverconfiguraties, etc.

woensdag 27 maart 2002 11:02

Acties:

sopsop

[v] [;,,;] [v]

Mijn voorkeur zou uitgaan naar een componentje dat eens in de zoveel tijd contact zoekt met jouw server die dan controlleert of de versie geregistreerd is.
Denk aan een IP-check of iets dergelijks.
Stel dat jouw server off-line is dan zorg je dat er een 'tellertje' gaat lopen die, laten we zeggen, een week lang probeerd om contact te zoeken. Mocht dat niet lukken dan schakelt het Bulletin Board op demo-modus. Beperkte functionaliteit iig.
Als een copieerder dan jouw bulletin board installeert, wordt dit gemeld aan jouw component op je server. Die checkt of er betaald is. Vervolgens geef je hem wel of niet authorisatie.
Zo heb je meteen inzicht in het aantal demo-versies en kun je eventueel zelfs versies uitschakelen.
Tevens is door het gebruik van componenten het 'jat' werk wat minder omdat niet overal die componenten kunnen worden geinstalleerd (wat ook weer een nadeel kan zijn).
Maar zo hou je iig het component uit je code.

BTW je zou dan wel een aantal triviale visualisatie dingen in je component moeten bouwen anders slopen ze je check op component uit je PHPtje.

woensdag 27 maart 2002 14:55

Acties:

Dennis

Mijn nieuwe forumsoftware ga ik denk ik ook in zend leveren, en daar zit dus een hele licentiemodule ingebouwd, inclusief allerlei features die in bepaalde licenties wel/niet zijn toegestaan.

Mensen kunnen straks op mn website het pakket online kopen, en ik maak voor mezelf een backend waarmee ik een bestelling kan goedkeuren (als er is betaald dus). Vanaf dan is er toegang voor die persoon en is de licentie geldig.

De persoon kan het pakket installeren met het eveneens zend ge-encodeerde installatiescript die tevens invoering van de licentiecode bevat, die dan bij installatie mijn server om validatie vraagt (de blackbox die eerder is beschreven in dit topic, alleen dan éénmalig).

Licenties zullen bij mij onleesbare strings worden, hoe ik dit ga doen weet ik nog niet, maar aangezien de source toch wordt ge-encodeert, zal het zo zijn dat hoe ingewikkelder ik het zelf maak, hoe moeilijker het is voor buitenstaanders om de code te kraken.

Overigens zal op elke normale pagina van het forum (het script dus) worden gekeken of de licentie geldig is. Misschien dat als na tijdmetingen blijkt dat het een tijdrovende contrôle is, ik deze contrôle beperk tot slecht enkele pagina's.

Trouwens wel een interessante kwestie dit

woensdag 27 maart 2002 15:03

Acties:

chem

Reist de wereld rond

als je de boel zend-encode, kan je gewoon het IP address in de source bakken (evt. dmv. binhex oid 'versleuteld')

Bij non-IP match: niks 'zeggen' de eerste week bv, maar vooral lekker mailtjes naar jezelf laten sturen etc...

Klaar voor een nieuwe uitdaging.

woensdag 27 maart 2002 20:30

Acties:

DiSiLLUSiON

Topicstarter

TimD: Wat zou ik de klant dan voor extra's aan kunnen bieden waar ze voor zouden willen betalen? behalve support dan?

Kepz: Ik ben al geschoold in VB & PHP, C of C++ zou een welkome toevoeging zijn, maar is dat wel cross-platform? nee toch? want dan is er meteen hetzelfde grote nadeel als bij Zend Encoder. En besides, dat kost te veel tijd, dan duurt het nog langer dan als ik tot Juni zou wachten en Zend Encoder zou aanschaffen.

TheDane: Dat is wel leuk en aardig, maar van veel office environments heb ik de ballen verstand, ik weet niet wat voor software ze gebruiken en waarvoor enzo. Dus dat is een leuke service als dat zou kunnen. En het zou opzich wel kunnen, maar dan zou ik er een aparte lijn producten naast moeten aanbieden, die ik voor elke klant apart onderhoud. Als ik bij het standaard product feature-requests krijg die ook voor andere klanten interresant kunnen zijn, kan ik die er gewoon in programmeren en klaar. Met jouw idee moet ik als ik een aantal klanten heb met elk een custom pakket al die pakketten naast elkaar moeten onderhouden. En ik denk niet dat ik dat kan, dat ik daar de tijd voor heb, ookal hebik geen real life

Remark: Je bedoelt een soort van KEY bestand? Dat als die niet in de software dir staat, de software automatisch op 'demo' mode overgaat met DEMO overal neergekalkt, en wanneer een klant een licencie heeft aangeschaft en die KEY in de dir heeft gezet de software kijkt of die KEY wel goed is? Dat is wel een goed idee. Het is hetzelfde als kijken op de server of de domeinnaam wel klopt en de licensie niet is verlopen, alleen dan verschoven naar client-side. Alleen dan moet die KEY natuurlijk wél encrypted zijn, en de encryptie mogelijkheden van PHP zijn nou niet echt je van het. Maar 't is opzich wel een erg goed idee, ik zal er ff wat meer over nadenken. Thnx!

Infinitive: 'obfuscator'? Kan je me uitleggen wat je daarmee bedoelt? een soort Zend Encoder?

DaMorpheus: d'r was al iemand anders in dit topic die dat idee pitchde, ik zei toen al dat ik erover zou denken en dat heb ik gedaan. Het kan wel rendabel zijn onder bepaalde omstandigheden, ik ga er zo met dat hosting bedrijf waar ik al onderhandelingen mee voer over praten of ze d'r wel oor voor hebben of niet. Thnx iig.

boppert: Dat is optie 3, en ookal met een timertje is de afhankelijkheid van de server een nadeel, omdat zo de software ook niet in intranetten gedraaid kan worden.

ddc & chem: mja het nadeel is dus dat Zend Encoder lang niet op elk platform kan, daarom heb ik besloten die ook niet te gebruiken.

woensdag 27 maart 2002 20:46

Acties:

Justice

kijk als niemand weet dat je protectie erin zit, maar dat jij wel op de hoogte gehouden wordt is natuurlijk optimaal. niemand zal zoeken maar jij weet wel dat er wat aan de hand is. (dus: wel protectie voor user, maar notificatie alleen naar de maker toe)

misschien kan je dat combineren met functies die uitvallen (functies die je alleen bij langere tijd (per sessie of totaal) gebruiken tegenkomt). Doordat het programma dan in het begin goed werkt, wordt men wel bekend met het programma, maar dan blijkt dat bepaalde opties fouten veroorzaken of in mildere vorm geen informatie doorgeven etc, en omdat jij zelf support levert..

hebben gelicenseerde bedrijven daar geen last van, want hun versie werkt naar behoren. maar ik weet niet of je dan slechte mond op mond reclame krijgt, hoewel je bestaande klanten het dan wel voor je opnemen.

hoe je dat moet programmeren zou ik niet weten (ben geen programmeur) maar misschien is het het overdenken na.
voorbeeldje in een voetbalgame ofzo: als je de finale van een tournooi bereikt, is de computertegenstander zo goed dat je nooit kan winnen, als je een illegale copie hebt. snap niet dat dit nooit gedaan is trouwens

Human Bobby

donderdag 28 maart 2002 13:10

Acties:

Verwijderd

Op woensdag 27 maart 2002 20:30 schreef DiSiLLUSiON het volgende:
Kepz: Ik ben al geschoold in VB & PHP, C of C++ zou een welkome toevoeging zijn, maar is dat wel cross-platform? nee toch? want dan is er meteen hetzelfde grote nadeel als bij Zend Encoder. En besides, dat kost te veel tijd, dan duurt het nog langer dan als ik tot Juni zou wachten en Zend Encoder zou aanschaffen.

Het is net zo crossplatform als je het zelf maakt natuurlijk en tja, het zou inderdaad langer duren. Maar als je moet kiezen tussen 'wat meer tijd nemen' en 'verlies lijden' heb ik m'n keuze snel gemaakt.

Infinitive: 'obfuscator'? Kan je me uitleggen wat je daarmee bedoelt? een soort Zend Encoder?

PHP Obfuscator leest je code in en doet wat trucjes er mee zoals MD5 hashes maken van function calls en variabelen..
Google is sjoer friend.