Beveiligen tegen kopieren van jou software

[mikezwet]

Hallo,

Ik heb me (vannacht ) afgevraagd hoe het in filemaker mogelijk zou kunnen zijn je programma te beveiligen tegen kopieren.

 

Oke, iemand mag mijn programma dupliceren maar het moet niet mogelijk zijn het te openen als het is doorgegeven aan familie, kennissen, collega's of erger op het internet word verspreid.

 

Ik weet niet of er hier mensen ervaring mee hebben en volgens mij is er nog geen post over op dit forum dus misschien is het leerzaam om eens over dit onderwerp te filosoferen en misschien tot een goeie veilige oplossing te komen.

[mikezwet]

TS trapt af:

 

Zelf had ik bedacht aan de hand van een ip adres te controleren of de gebruiker wel de gebruiker is aan wie ik het programma heb geleverd. Nadeel is als iemand geen vaste verbinding of geen statisch ip adres heeft.

Ook als de gebruiker naar de een andere computer/locatie verplaatst is dit geen oplossing. Eigenlijk is het helemaal niet haalbaar denk ik.

 

Werken met wachtwoorden lijkt mij ook niet veilig omdat iemand gewoon zijn wachtwoord meegeeft met de kopie.

 

Niemand hier zal op grote schaal paketten verkopen(?) dus in principe zou je elke verkochte database een uniek iets kunnen geven. Misschien kan hier wat mee gedaan worden.

[Gido_]

Ik ben hier ook veel over aan het denken, voor het geval ik ooit massaal "paketten" ga verkopen

 

Ik denk dat er toch wel wat te bedenken is, maar je lijkt me altijd in bepaalde mate je klant te moeten irriteren, al denk ik dat het beslist binnen de perken te houden is.

 

- je kan checken op verandering van een aantal status parameters van de PC en indien verandering: binnen bep. periode contact met jou nemen voor bv nieuw paswoord of unlock truukje. Is niet sympathiek en je moet dan wel redelijk goed bereikbaar blijven.

 

- Zelf dacht ik aan iets dat bv om het half jaar een contactname vereist (of toch één keer per leven ) Daarbij zou ik dan bv van hen een code krijgen die op een aantal parameters gebaseerd is, en met die code kan ik dan weer een truukje terugmailen hoe ze op "de laatste waarschuwing" verderkunnen. De clou is om dat zo te maken dat dit truukje een boel variaties heeft al naargelang de parameters, zodat het minder interessant wordt om die truuk te publiceren, want voor de volgende klopt het dan toch weer niet :lol:

Om een doorzichtig vb te geven: stel dat ik een code terugkrijg waaruit ik begrijp dat zij de 15e van een maand hun waarschuwing hebben gekregen, dan kan ik bv zeggen dat ze op een bepaald vlakje 15 keer CTRL-ALT-KLIK moeten doen om verder te kunnen (maar dan wel minder doorzichtig maken en met meerdere plekjes en toetsenvariaties).

 

Ik denk dat zo één keer wel te tolereren valt. Als je dat tijdstip zo lang mogelijk uitstelt, kunnen een boel mensen dit kopiëren en er daarna mee in de problemen komen Tegen dan zit er dusdanig veel data in dat je ze mss kan bangmaken om te kopen ipv hun waardevolle data te riskeren...

Ik denk zelfs dat er geavanceerde truuks zijn om je database niet via een relatie open te laten krijgen eens ze "fataal afgesloten" wordt; of alleen op jouw manier, zodat ze weer moeten kopen om aan hun data te geraken. De meesten zullen sowieso niet eens weten dat dat gaat.

 

- Als je echt een heeeeel populaire applicatie gaat maken, kan je overwegen ze op tijd zelf op eMule te zetten met de nodige time bombs erin na 8 maand of zo , zodat men plots een "lock" krijgt en moet kopen of data kwijt. Maar ik vrees wel dat dit niet legaal is op één of andere manier... Spijtig wel

[Gido_]

P.S. Ik weet nu niet of ze een applicatie die volledig opgebouwd is rond copy/paste technieken nog eens opnieuw gaan willen kopiëren Ik denk dat jij wel veilig zit

[Gido_]

Wat demo betreft, las ik de tip:

 

"A nifty way of really making sure a runtime demo is useless after X days or X uses. Run a script that changes the users account or - deletes the user account.

 

After your solution has time-bombed. This will surely render the demo useless."

- -

 

Hier iets ivm het openen via een relatie:

www.fmforums.com/forum/showtopic.php?tid/99347

[Gido_]

Het blijft toch wel een linke zaak

Een klant zijn data kan je niet in gevaar brengen, dus die moet echt HEEL GOED weten dat bv:

- hij exact na een half jaar even contact zal moeten nemen en daarvoor voldoende waarschuwingen en tijd zal krijgen

- zijn data in het ergste geval door jou te recupereren valt

 

Stel nu dat iemand met je "pakket" naar de brousse trekt en ineens vast komt te zitten...

 

Het moet dus duidelijk zijn dat hij hiermee akkoord gaat, of maar moet kiezen om het niet te kopen.

 

Om het wat fijner uit te werken...:

 

Ik zou die zeg maar halfjaarlijkse contactname bv 1 keer doen per PC-configuratie, zodat wanneer de applicatie van PC wisselt er na een half jaar opnieuw contact zal nodig zijn, ipv slechts één keer per leven Dat vangt een boel potentiële boosdoeners op (al moet ik eens bezien in hoeverre FM dat wel kan).

 

6 maand na opstarten laat je dan een trigger afgaan die een aantal gegevens op dat moment in globals zet. Hierop maak je een formule die hen een code bezorgt om naar jou te mailen. Je geeft daarvoor genoeg tijd en dagelijkse verwittigingen, die globals zullen niet verdampen

Met die code kan jij dan ontcijferen hoe die globals zijn ingevuld. Is dat bv met 9 en 12, dan baseer je daar gelijk de voorbedachte unlock-oplossing op (kan je zo simpel of moeilijk maken als je wil).

 

Er zijn best wel een hoop programma's (vroeger toch) die met slechts een aantal installaties werken. Was je die kwijt, dan moest je contact nemen, en meestal was dat ook best redelijk. Dus ik denk dat er wel een middenweg te bewandelen valt

 

Als je puur op datum werkt: oppassen! Stel dat die klant een paar maand zijn programma niet gebruikt en bij opstarten onmiddellijk vastzit omdat de trigger is afgegaan en "grace period" is verlopen...

[mikezwet]

je kan checken op verandering van een aantal status parameters van de PC en indien verandering

 

Dat zou inderdaad kunnen. Bij de eerste keer dat het programma word opgestart een aantal dingen vastleggen zoals: SystemPlatfor, SystemVersion, System IP adres. Bij nieuwe starts steeds controleren. Ook voor iedere gebruiker een eigen password en login naam.

Ik denk nu alleen weer: als iemand de lege database aan iemand anders geeft maakt de database die parameters gewoon aan voor die persoon

 

WebCamXP weet ik van dat deze elke keer een logje stuurt naar een server met je ip adres en gebruiksnaam. Je ziet dan op een gegeven moment dat JAN inlogt op 82.122.1.208 en even later een JAN 98.44.211.2 : Joepie JAN heeft een kopie-tje weggegeven of een dynamisch ip

 

Lastig dit

[Gido_]

Heb hier juist nog iets voorgepost, volgens mij kan dit dat opvangen.

Met IPs zou ik zelf nooit werken, want dat is een beetje zwaar irritant dat je *moet* verbonden zijn om te kunnen werken of zo. En de firewall verklapt sowieso dat jij met zoiets werkt en dat komt nogal flauw over dan, zeker als je app verder niks met internet te maken heeft

Kan zo'n check trouwens zonder hulpapp.? Anders kunnen ze die gewoon verwijderen. Al kan je daar ook weer op controleren...

Edited July 23, 2005 by Guest

[Gido_]

Als je zoiets in globals zet, oppassen dat een "save clone" en mogelijke import het niet kan tenietdoen. Maar meestal zitten er genoeg verscholen globals in een app., zodat die zonder ingevulde waardes toch onbruikbaar wordt (al is dat dan weer geen professionele manier van design mss )

[Wim Bongertman]

wij hebben het opgelost door standaard de adresgegevens van de gebruiker in te stellen met de kreet Demo. Op alle formulieren en schermen staan naam en adres van de gebruiker, demo geeft dan wel een erg onprofessionele indruk. Bij het opstarten haalt het programma de juiste adresgegevens uit een z.g. licentie database. Indien deze licentie database is vervallen of niet aanwezig is, komt het woord demo weer te voorschijn. De adresgegevens uit de licentie database worden via een opstart script in het programma geplaatst en worden bij het afsluiten weer vervangen in Demo. Indien men niet goed afsluit dan blijft welliswaar het gebruikersadres in het programma staan, maar bij de volgende keer opstarten zal hij toch eerst weer de licentie aanspreken. De licentie database is met wachtwoorden dermate beschermd dat niemand daar wijzigingen in kan aanbrengen. Het voordeel is dat het programma als demo kan worden verspreid. Wil een gebruiker het programma legaal gebruiken of een licentie verlengen, dan ontvangt hij een nieuwe licentie per email als bijlage.

[mikezwet]

Wim, dat is wel een goede oplossing!

 

Ik begrijp dat als iemand het programma verspreid, degene die het ook gaat gebruiken de gegevens van de "echte koper" in het scherm ziet.

 

Zodra het licentie bestand er niet bij is komt er demo te staan en is het bestand ook gelimiteerd omdat er demo staat.

[Wim Bongertman]

Je antwoord is me niet helemaal duidelijk, misschien een ongelukkig geformuleerde zin.

 

Standaard is de meegeleverde licentie een demo licentie. Als iemand het programma aanschaft, of een officiele gebruiker is, dan ontvangt hij een ingestelde licentie waar zijn adresgegevens instaan. Als de nieuwe licentie is geplaatst en het programma opnieuw wordt opgestart, staat de naam van de geregistreerde gebruiker in het programma. Het behoeft natuurlijk verder geen uitleg dat met een licentie ook een tijdslimiet kan worden ingesteld. Als er geen licentie tabel aanwezig is (misschien illegale kopie) dan start de boel niet op. Volgens mij is zo'n licentie tabel - mits wachtwoord beveiligd - een afdoende beschermmiddel om illegaal gebruik te voorkomen. Mocht iemand informatie hebben hoe een wachtwoord beveiligde tabel toch kan worden gekraakt, dan hoor ik het graag.

[Gido_]

Mocht iemand informatie hebben hoe een wachtwoord beveiligde tabel toch kan worden gekraakt, dan hoor ik het graag.

Geef het eens aan de mannen op www.fmforums.com , die leven daarvoor om dat uit te testen Dus door gewoon een relatie ermee te leggen geraak je er ook niet meer in?

Wat volstaat om dat te bereiken? (*als* dat mogelijk is)

 

Ben een leek mbt FM security en zou niet weten wat eerst lezen erover. Ik heb nochtans enkel een persoonlijk paswoord-systeem nodig en zo'n relatieve anti-kraak beveiliging, zoals jij noemt, denk ik.

Plus dat ik graag iets zou hebben waar zij niet zomaar inkunnen via een relatie, maar ik wel (om zo nodig hun data te recupereren).

[Gido_]

Nadeel bij Wim lijkt me dat er sowieso mensen zijn die er niet voor terugdeinzen een licentie te kopen en gewoon op het net te zetten (bedoeld of onbedoeld). Het lijkt me dan ook dat die licentie tabel gewoon kan verdeeld worden waardoor iedereen ermee aan de slag kan? Of steunt hij ook nog op één of andere verplichte match met info in de hoofdtabellen?

[mikezwet]

Nadeel bij Wim lijkt me dat er sowieso mensen zijn die er niet voor terugdeinzen een licentie te kopen en gewoon op het net te zetten (bedoeld of onbedoeld). Het lijkt me dan ook dat die licentie tabel gewoon kan verdeeld worden waardoor iedereen ermee aan de slag kan? Of steunt hij ook nog op één of andere verplichte match met info in de hoofdtabellen?

 

Voor zover ik begrijp werkt het bestand zonder licentie bestandje gelimiteerd omdat er demo verschijnt als het licentie bestand niet is gevonden. Is het wel gevonden dan staan de naam en adres gegevens van de koper overal vermeld. Als je bijv boekhoudsoftware hebt lijkt me niet dat je facturen gaat printen met iemands anders zijn naam erin.

 

Klopt dat wim? En voor wat voor soort applicaties gebruik je deze methode?

[Wim Bongertman]

Ik heb het idee dat op een of andere wijze mijn antwoord niet geheel duidelijk is.

 

Ons programma werkt standaard met een licentie welke de naam en adres van de geregistreerde gebruiker bevat. Verder hebben we in die licentie ook nog andere gegevens verwerkt zodat de licentie tijdelijk kan worden gebruikt. Standaard een jaar.

 

Bij het opstarten van de applicatie worden de licentie gegevens in het programma ingelezen. Tot zover duidelijk. Indien er geen licentietabel aanwezig is, worden de gegevens ingesteld als "demo". Het woord demo / of de geregisteerde gebruikers naam verschijnt op diverse schermen en op bijna alle output zoals facturen, lijsten etc. en is wat mij betreft een afdoende bescherming tegen gebruikers die niet willen betalen voor gebruik.

In de licentie is tevens de bescherming ingebakken dat de data update's en programma update's niet kunnen worden verwerkt als de licentie demo of ongeldig is. Natuurlijk kan alles worden gekraakt, het gaat er om dat een normale gebruiker niet zomaar even de naam en adresgegevens in de licentie tabel kan wijzigen. Omdat elke licentie een uniek nummer bevat die vervolgens eenmaal kan worden gebruikt om data updates en programma updates in te lezen, lijkt mij dit voldoende beschermd.

 

De licentie database is met een uniek wachtwoord / master wachtwoord beveiligd.

 

Het voordeel blijft dat je een complete runtime als demo kan verspreiden. Als de gebruiker tevreden is, en het programma wil aanschaffen, dat hoef je alleen de licentietabel in te stellen en toe te sturen per mail. De gebruiker plaatst de licentie in de programma map en overschrijft dus de demo licentie, start het programma op en al zijn gegevens worden ingelezen.

 

natuurlijk kan iemand licentie tabellen via internet verspreiden, zo bevatten dat allemaal dezelfde naam en adressen, daar heb je als illegale gebruiker dus niets aan. Het enigste probleem zou zijn dat als iemand de licentie kraakt, hij dat de adresgegevens van een willekeurige gebruiker kan invullen. Maar door middel van een unieke sleutel kunnen dan data update's en programma update's nog niet worden ingelezen. Of de kraker zou ook die distributie voor zijn rekening moeten nemen, nou dan geef ik het op.

[pjotter]

Dit lijkt best goed beveiligd, wat ik mij alleen afvraag is als je alleen de demo versie gebruik en je achterhaald het master passwoord hiervan, is het dan bestand makkelijk om te zetten zodat hij niet naar de extra tabel vraagt voor de gegevens? Grootste nadeel bij Filemaker met beveiligen is nog steeds dat het master passwoord heel eenvoudig te achterhalen is.

[mikezwet]

Maar door middel van een unieke sleutel kunnen dan data update's en programma update's nog niet worden ingelezen.

 

Ik begrijp het.

 

Alleen van die unieke sleutel is me onduidelijk... Geef je elke database een unieke code die de (demo)gebruiker door moet geven en welke jij ook weer verwerkt in het officiele licentie bestand. Als die code overeen komt worden de adres gegevens geladen.

 

En wat bedoel je precies met data update's en programma updates?

 

Dit lijkt best goed beveiligd, wat ik mij alleen afvraag is als je alleen de demo versie gebruik en je achterhaald het master passwoord hiervan, is het dan bestand makkelijk om te zetten zodat hij niet naar de extra tabel vraagt voor de gegevens? Grootste nadeel bij Filemaker met beveiligen is nog steeds dat het master passwoord heel eenvoudig te achterhalen is.

 

Ik denk dat als iemand een database van jou aanschaft in 99,5% van de gevallen geen filemaker pro heeft en er niets van af weet dus ook niet zal gaan zoeken naar een password kraker voor filemaker pro.

Ook zal 99,5% van de gevallen niet weten dat z'n password te kraken is.

 

Dat ligt ook aan het soort programma, als je bijv iets gemaakt hebt om mp3's in te delen en downloaden (ik noem maar wat) zal het eerder gekraakt worden dan dat je een boekhoud pakket heb verkocht. Het soort gebruikers.

 

Ik zeg altijd, alles wat gemaakt word kan ook worden gekraakt, je bent nooit 100% verzekerd dat jou programma niet illegaal word verspreid. Het beveiligen houd een keer op.

[mikezwet]

Zelf hebben wij een calculatie programma (offerte, prijs berekening, zaagmaten, tekenen, ontwerpen ect.) voor de kozijn verwerkende branch. Dit programma werkt met een sleutel die in de printer poort word gestoken en een unieke code bevat.

 

Een bestandje op de harde schijf maakt een verglijking en als die hetzelfde is als die in de sleutel kan het programma gebruikt worden. In het begin hadden we een tijdelijke licentie, zat er waarschijnlijk een tijdslimiet op waardoor we steeds een nieuw bestandje kregen.

 

Een goede manier vind ik.

[Wim Bongertman]

Ons programma is gemaakt om de databestanden voor onze leveranciers (dierenspeciaalzaken) te beheren. Voor de gebruiker zijn deze databestanden heel belangrijk. Zij bevatten namelijk de gegevens welke de leveranciers beschikbaar stellen, en kunnen worden gebruikt om bestellingen mee samen te stellen. Verder bevatten ze tientallen acties en aanbiedingen. Om te voorkomen dat data update's over het internet verspreid worden - en dus zonder licentie kunnen worden verwerkt - ontvangt iedere gebruiker regelmatig een gepersonaliseerde data update waarin de artikelnummers en inkoopprijzen per gebruiker zijn versleuteld. Bij het inlezen in het pakket met de correcte sleutel, worden deze gegevens uiteraard terug gecodeerd. Nadeel is dat iedere gebruiker een data update moet ontvangen die voor zijn pakket apart is aangemaakt. Er werken nu plm. 100 gebruikers met het pakket, het aanmaken van deze speciale databestanden doet filemaker echter in hele korte tijd zodat dit een acceptabel iets is.

 

Vervolgens zijn we het pakket natuurlijk regelmatig aan het verbeteren, of worden er wensen van gebruikers toegevoegd / aangepast. Dit zijn de programma bestanden welke de geregistreerde gebruikers ook ontvangen. De data van de verschillende modules wordt naar buiten gebracht, er worden lege legemodules in de programma map geplaatst en automatisch worden de naar buiten gebrachte gegevens weer ingelezen. Deze lege modules zijn door iedereen te updaten, ook demo of illegale gebruikers. Maar zonder accurate data zijn deze modules niet echt functioneel.

[mikezwet]

Verder hebben we in die licentie ook nog andere gegevens verwerkt zodat de licentie tijdelijk kan worden gebruikt. Standaard een jaar.

 

Ik heb nog 2 vragen:

 

* Als je de datum ingeeft wanneer je de licentie activeerd doe je waarschijnlijk de verloopdatum + 1 jaar. Filemaker checkt wanneer het die dag is en slaat op slot. Wat doet een gebruiker dan?

 

* En als ik de datum van mijn computer terug zet kan ik gewoon nog een tijdje ermee werken, uitstel van executie Hoe heb je dat opgelost?

[Wim Bongertman]

Nou die datum is niet zo moeilijk. Iemand die de moeite zou willen nemen om de datum op de computer terug te zetten loopt met heel veel dingen vast. Ons programma ontvangt data update's die zijn voorzien van datums dus krijg je een wel heel vreemde situatie als je de computer datum 1 jaar terug zet. Denk bijvoorbeeld aan de volgorde van de update's. Bovendien wat denk je van een factuur die met zo'n datum zal worden verstuurd. Niets is 100%- afdoende, maar als je de licenties niet te duur maakt, koopt iedereen die het programma wil gebruiken wel een licentie.

 

De datum in de licentie is inderdaad een datum tot ....(bijvoorbeeld 1 maart 2006). Komt het programma hier overheen verschijnt er regelmatig een licentie verleng herinnering, dat is irritant genoeg. Verder ontvangt de gebruiker geen update's meer

[Gido_]

Grootste nadeel bij Filemaker met beveiligen is nog steeds dat het master passwoord heel eenvoudig te achterhalen is.

Toch niet bij een runtime? (als je het eruit verwijderd hebt)

Dat geeft één van de paswoordprogramma's zelf toe:

Limitations

 

* Databases protected with FileMaker Developer Tool are not supported

En dat moet ik helaas/gelukkig (al naargelang ) bevestigen.

Maar misschien ken jij een beter programma dan...?

Edited July 25, 2005 by Guest

[pjotter]

Een runtime versie kun je gewoon het bestand zelf nemen en daar het wachtwoord uithalen.

[Gido_]

Mss zijn we over een verschillend soort wachtwoord bezig (ben geen security kenner)..., maar als je bij het maken van een runtime aanduidt om het master password eruit te laten/halen, dan geraakt niets daar toch aan? Want het is er gewoon niet.

Ik heb in elk geval al genoeg van die bestanden gezien waar een paswoordprogramma niets mee aankan Dus hoe doe jij dat dan? Kraak voor de sport dan eens www.dataisland.com/mixology.html

Ik moet het niet hebben, maar laat weten of het gelukt is

[mikezwet]

Ik heb het eens geprobeerd met een eigen database en hij komt er alleen achter dat de login namen admin en gebruiker zijn. Het wachtwoord schijnt er ook staan maar is niet goed

 

Het zal allemaal wel meevallen met het aantal krakers, toch?