Ik heb een applicatie ontwikkeld in delphi6. Nu wil ik echter voorkomen dat de koper mijn programma zomaar gaat verspreiden. Hoe kan ik het beste te werk gaan om bv een licentie code te schrijven voor 5 pc's (zijn eigen bedrijf bijvoorbeeld?)
Kijk maar es goed naar hoe Microsoft het in Windows XP heeft opgelost. Dus, met een computer-id
Er zijn 100 mogelijkheden.
Je kunt InstallShield gebruiken met een dll om licentiegegevens te controleren. Deze gegevens kun je eventueel aanmaken afhankelijk van de ID van de HD ofzo, maar er zijn zo veel mogelijkheden, dat je hier niet zo maar even 1-2-3 een antwoord op kunt krijgen.
Zo kun je ook nog de licentie berekenen aan de hand van gebruikers en bedrijfsnaam, zodat bij het kopieren van de app door een ander bedrijf elke keer de gegevens van het bedrijf waar het voor gemaakt is verschijnen op de rapporten: is ook best een goede beveiliging, want dat vinden de meeste bedrijven toch echt niet tof...
Je kunt InstallShield gebruiken met een dll om licentiegegevens te controleren. Deze gegevens kun je eventueel aanmaken afhankelijk van de ID van de HD ofzo, maar er zijn zo veel mogelijkheden, dat je hier niet zo maar even 1-2-3 een antwoord op kunt krijgen.
Zo kun je ook nog de licentie berekenen aan de hand van gebruikers en bedrijfsnaam, zodat bij het kopieren van de app door een ander bedrijf elke keer de gegevens van het bedrijf waar het voor gemaakt is verschijnen op de rapporten: is ook best een goede beveiliging, want dat vinden de meeste bedrijven toch echt niet tof...
[ Voor 37% gewijzigd door OZ-Gump op 13-06-2003 14:56 ]
Verwijderd
Hiervoor zijn verschillende methodes, allemaal kraakbaar.
De beste methode is imo een zgn. 'dongle', een device welke je in de printerport of USB poort stopt. Deze dongle bevat je licentie.
Probleem met licentiecodes is dat het niet voorkomt waar je bang voor bent; nl. dat de klant het kopieert op meerdere PC's. Immers, de klant heeft al een licentiecode.
Overigens mis ik een beetje wat je zelf al geprobeerd hebt, heb je uberhaupt al iets geprobeerd?
De beste methode is imo een zgn. 'dongle', een device welke je in de printerport of USB poort stopt. Deze dongle bevat je licentie.
Probleem met licentiecodes is dat het niet voorkomt waar je bang voor bent; nl. dat de klant het kopieert op meerdere PC's. Immers, de klant heeft al een licentiecode.
Overigens mis ik een beetje wat je zelf al geprobeerd hebt, heb je uberhaupt al iets geprobeerd?
[ Voor 3% gewijzigd door Verwijderd op 13-06-2003 14:56 ]
Er is op zich redelijk veel te vinden over licenties and licentie vormen, wat heb je zelf al erover gevonden?
Back In Black!
"Je moet haar alleen aan de ketting leggen" - MueR
Nou ik ben een beetje gaan brainstormen over expiration dates ofzo voor het programma. De klant heeft weinig tot geen verstand van de code, en dat iets kraakbaar is, dat snap ik. Maar het idee moet er zijn...het moet niet mákkelijk zijn om het zomaar te verspreiden.
Een 'dongle' vind ik wat ver gezocht. Maar als ik het in de sfeer van machine-code en expiration dates zoek, ben ik dan goed op weg?
Een 'dongle' vind ik wat ver gezocht. Maar als ik het in de sfeer van machine-code en expiration dates zoek, ben ik dan goed op weg?
Daar ben ik het gedeeltelijk mee eens wat je daar zegt.Verwijderd schreef op 13 juni 2003 @ 14:55:
Hiervoor zijn verschillende methodes, allemaal kraakbaar.
De beste methode is imo een zgn. 'dongle', een device welke je in de printerport of USB poort stopt. Deze dongle bevat je licentie.
Probleem met licentiecodes is dat het niet voorkomt waar je bang voor bent; nl. dat de klant het kopieert op meerdere PC's. Immers, de klant heeft al een licentiecode.
Overigens mis ik een beetje wat je zelf al geprobeerd hebt, heb je uberhaupt al iets geprobeerd?
Het gebruik van een dongle is idd de beste oplossing maar in het programma zou ergens een verwijzing moeten staan naar de dongle, als die er uit word gevist dan heeft de dongle ook geen zin meer, ik weet wel zeker dat dat de beste oplossing is want niet iedereen kan zomaar even een crack maken voor een programma
Het gaat mij ook niet om een onkraakbaar progsel, enkel het feit DAT er een barricade is die moet worden geforceerd.Robthebest schreef op 13 June 2003 @ 15:05:
[...]
Daar ben ik het gedeeltelijk mee eens wat je daar zegt.
Het gebruik van een dongle is idd de beste oplossing maar in het programma zou ergens een verwijzing moeten staan naar de dongle, als die er uit word gevist dan heeft de dongle ook geen zin meer, ik weet wel zeker dat dat de beste oplossing is want niet iedereen kan zomaar even een crack maken voor een programma
Handigste is om een programma bij z'n eerste 'run' een uniek doch reproduceerbaar getal te laten genereren uit diverse hardware-aspecten van het systeem. Dit moeten ze dan aan jou mailen waarna jij er een unieke vervolgkey van maakt. Zodra deze vervolgkey in het programma zit zal het op die computer blijven draaien.
Zodra men de HW verandert krijgt men simpelweg een nieuwe vraag om licentiecode, en jij daarmee een nieuw mailtje. Zorgen dat je het niet 100000 keer verkoopt
Zodra men de HW verandert krijgt men simpelweg een nieuwe vraag om licentiecode, en jij daarmee een nieuw mailtje. Zorgen dat je het niet 100000 keer verkoopt
Ik denk dat je dan wel aan hardware id's zit verbonden, dat zou een oplossing kunnen zijn, licenties is een oplossing dat eenvoudig te omzeilen is, je zou het ook "groots" aan kunnen pakken en het software pakketje te laten valideren met een server op het internet
Je zou een expiration date heel makkelijk kunnen maken zodat in ieder geval de gemiddelde eindgebruiker er niet omheen komt:
Sla de datum waarop de app verloopt op als integer. Een date in Delphi heeft een waarde, bijvoorbeeld 37785 (vandaag!). Als je vervolgens een licentie-berekening bedenkt om een gebruikersnaam, de verloopdatum en het aantal users in mee te nemen, dan ben je een heel eind.
Voor 'ons' stelt het niet zo veel voor, maar een eindgebruiker komt er denk ik niet heel snel door. Zodra geknoeid wordt met de datum, de gebruikersnaam of het aantal gebruikers, klopt de licentiecode niet meer en houdt het pakket op met werken.
Verder (voor de mensen die nu meteen gaan roepen: systeemdatum verzetten!) kun je elke keer dat er gestart wordt de datum en tijd in het register opslaan (eventueel ook weer als integer of whatever). Zodra de software gestart wordt op een datum voor de vorige datum (register) is er met de datum geknoeid en wordt de software gelocked. En dan moeten ze jou bellen (met een rode kop...
)
Sla de datum waarop de app verloopt op als integer. Een date in Delphi heeft een waarde, bijvoorbeeld 37785 (vandaag!). Als je vervolgens een licentie-berekening bedenkt om een gebruikersnaam, de verloopdatum en het aantal users in mee te nemen, dan ben je een heel eind.
Voor 'ons' stelt het niet zo veel voor, maar een eindgebruiker komt er denk ik niet heel snel door. Zodra geknoeid wordt met de datum, de gebruikersnaam of het aantal gebruikers, klopt de licentiecode niet meer en houdt het pakket op met werken.
Verder (voor de mensen die nu meteen gaan roepen: systeemdatum verzetten!) kun je elke keer dat er gestart wordt de datum en tijd in het register opslaan (eventueel ook weer als integer of whatever). Zodra de software gestart wordt op een datum voor de vorige datum (register) is er met de datum geknoeid en wordt de software gelocked. En dan moeten ze jou bellen (met een rode kop...
[ Voor 48% gewijzigd door OZ-Gump op 13-06-2003 15:19 ]
Hier is vast wel wat over te vinden met Google.
Er zijn zet commerciele mogelijkheden, a 120 tot 160 euro of zo. Bijvoorlbeeld:
http://www.delphizine.com...0302mr_p/di200302mr_p.asp
http://www.latiumsoftware.com/en/pascal/0020.php
Er zijn zet commerciele mogelijkheden, a 120 tot 160 euro of zo. Bijvoorlbeeld:
http://www.delphizine.com...0302mr_p/di200302mr_p.asp
http://www.latiumsoftware.com/en/pascal/0020.php
[ Voor 12% gewijzigd door lordsnow op 13-06-2003 15:32 ]
Verwijderd
Nuja, dat valt te automatiseren, he.curry684 schreef op 13 June 2003 @ 15:10:
Zodra men de HW verandert krijgt men simpelweg een nieuwe vraag om licentiecode, en jij daarmee een nieuw mailtje. Zorgen dat je het niet 100000 keer verkoopt
Verwijderd
Kijk hier eens:
http://www.torry.net/shareware.htm
of
hierzo: http://sourceforge.net/projects/tponguard/
http://www.torry.net/shareware.htm
of
hierzo: http://sourceforge.net/projects/tponguard/
thx, zal eens proberen wat code te maken! maui71 geweldige links!!
TurboPower ProActivate is één van de betere copy protected producten voor Delphi, momenteel heb ik nog géén van me programma's gekraakt op het internet gezien die gebruik maken van ProActivate. Tot korte tijd zat er wel een GROVE fout in, namelijk in het programma zelf zat ook de algoritme om keys te generen, dat is natuurlijk een NO GO.
Alleen jammer dat TurboPower niet meer bestaat, misschien kun je het via ebay nog krijgen.
Alleen jammer dat TurboPower niet meer bestaat, misschien kun je het via ebay nog krijgen.
Is een licentieserver een oplossing? In de meest botte oplossing maak je files licence1.txt tot license5.txt. Vervolgens open je in je .exe license1 t/m 5.txt totdat je er één exclusive kunt openen.
Om te voorkomen dat ze zelf license6.txt aanmaken moet je MD5 hashes in de files stoppen en die hardcoden in je .exe. Mochten ze ooit meer licenties bijkopen dan je in je .exe hebt staan dan heb je natuurlijk een probleempje.
Om te voorkomen dat ze zelf license6.txt aanmaken moet je MD5 hashes in de files stoppen en die hardcoden in je .exe. Mochten ze ooit meer licenties bijkopen dan je in je .exe hebt staan dan heb je natuurlijk een probleempje.
Man hopes. Genius creates. Ralph Waldo Emerson
Never worry about theory as long as the machinery does what it's supposed to do. R. A. Heinlein
Niet een technisch verhaal maar wel mn 2-centen
bezint eer gij begint. Zorg er voor dat de licentie module zeer goed getest is. Niets is zo irritant als betaald te hebben voor software en dan vervolgens toch niet kunnen werken omdat er iets mis is met de licentie. Ik weet niet wat voor een programma je hebt verkocht maar stel: het is een 'mission critical' programma en op zondagochtend crashed een van hun computers. Ze installeren het op een andere computer, het moet per slot van rekening zondag af zijn, maar wat blijkt, het programma wil niet installeren vanwege licentie gedoe. Ben je 24 uur bereikbaar als helpdesk? Zitten hier juridische consequenties aan vast? etc.
Moraal van het verhaal. Weeg goed de voors en tegens tegen elkaar af want code inbouwen die mogelijk de werking van je software negatief kan beinvloeden zonder dat de klant hiermee extra functionalitiet krijgt is altijd in het nadeel van de klant.
bezint eer gij begint. Zorg er voor dat de licentie module zeer goed getest is. Niets is zo irritant als betaald te hebben voor software en dan vervolgens toch niet kunnen werken omdat er iets mis is met de licentie. Ik weet niet wat voor een programma je hebt verkocht maar stel: het is een 'mission critical' programma en op zondagochtend crashed een van hun computers. Ze installeren het op een andere computer, het moet per slot van rekening zondag af zijn, maar wat blijkt, het programma wil niet installeren vanwege licentie gedoe. Ben je 24 uur bereikbaar als helpdesk? Zitten hier juridische consequenties aan vast? etc.
Moraal van het verhaal. Weeg goed de voors en tegens tegen elkaar af want code inbouwen die mogelijk de werking van je software negatief kan beinvloeden zonder dat de klant hiermee extra functionalitiet krijgt is altijd in het nadeel van de klant.
Dongles zijn idd wel 1 van de beste methodes, *mits* goed gebruikt. De meeste implementaties van bedrijven die een dongle gebruiken zijn hopeloos. Je kunt simpelweg checken of de dongle bestaat (vaak met 1 centrale functie uit de library van de donlge, of nog erger, in z'n eigen DLL
). Dat kan eruit gehaald worden zonder zelfs de dongle nodig te hebben. Zodra je ook de unieke codes uit de dongle gaat gebruiken werkt het beter, dan zal je echt de dongle nodig hebben om het te kraken (brute force is geen doen). Maar als je em hebt is het nog relatief eenvoudig. Vaak zitten er bij die pakketten kant en klare 'beveilig mijn programma' tooltjes, wat meestal neerkomt op het geencrypt inpakken van het programma (met als sleutel de nummers in de key). Ook die zijn goed te omzeilen, uiteraard heb je nog steeds de sleutel nodig (hoewel er wel af en toe enkel flaws in de encryptie worden gevonden die brute force toch weer mogelijk maken, maar dat komt zelden voor).
Het probleem met zo'n dongle is dat als je het communicatiepunt tussen de software en de dongle (of eigenlijk de library van de fabrikant) hebt gevonden, al die communicatie bewaard en later nagebootst kan worden. De meeste dongle fabrikanten leveren bij test-setjes de complete API documentatie mee, wat het nog gemakkelijker maakt.
De enige manier om dongles goed effectief te maken is stukjes van je eigen code (zelf, geen standaard inpak-tooltjes) te encrypten met waardes uit de dongle, op sommige dagen opeens hele andere checks gaan doen zodat je ze niet in 1 keer kunt loggen, de data op de dongle ook af en toe aanpassen, etc. Dat is allemaal een hoop werk en niet makkelijk, maar wel de enige manier om een dongle *echt* zin te geven (behalve dan dat je zowieso je programma onkraakbaar maakt zonder dongle). De meeste bedrijven hebben daar allemaal geen zin in en gebruiken gewoon de standaard tools die bij de dongle zitten.
Maar genoeg over dongles want die wilde je toch niet gebruiken. Commerciele oplossingen zijn vaak wel goed uitgedacht maar hebben een aantal zwakke punten. Een daarvan is dat je niet de enige bent met de beveiliging die ze bieden. Als het 1 keer gekraakt wordt, kunnen vaak alle programma's die dezelfde beveiliging gebruiken ook gekraakt worden. Vaak heeft elk programma wel weer een eigen variatie maar de basis zal hetzelfde blijven. Iets wat geautomatiseerd beveiligd wordt is vaak ook weer geautomatiseerd te kraken. Een ander zwak punt is dat de verbinding tussen het programma en de beveiliging vaak brak is. Zeker tooltjes die zichzelf gewoon aan de executable vasthangen. Maar dat hangt een beetje van de beveiliging af.
Zelf een beveiliging maken heeft iig als voordeel dat het uniek is (naja de ideeen vaak niet maar het geheel wel). Als je met tijdslimieten wil werken kijk dan eens naar andere plaatsen waar tijden worden opgeslagen, zoals boot log files of de windows event log.
Ook heel belangrijk is niet meteen duidelijke meldingen te geven dat er iets aan de beveiliging niet klopt. Dan is meteen het punt bekend waar het gecontroleerd wordt. Wat ook heel goed werkt is subtiele dingen doen die het programma onbruikbaar maken en lastig te vinden zijn. Dat moet wel gebeuren naast de normale foutmelding anders snappen 'echte' gebruikers niet wat ze overkomt. Een voorbeeld is bijvoorbeeld als je programma kan printen, zo nu en dan zwarte balken over je print heen te zetten als de beveiliging niet klopt. Normale gebruikers komen niet voorbij de foutmelding, maar een cracker kan die wel weghalen. Maar dan zit ie met het probleem dat z'n prints er niet goed uitkomen (met een beetje pech ziet hij dat 2 dagen later, erg frustrerend
) En uitvinden waar zwarte balkjes over de tekst heen geprint worden is een stuk lastiger dan het zoeken van een foutmelding.
Pas iig wel op dat je niet in de problemen raakt zoals TijnFLiP al zei, beveiling mag niet het normale functioneren belemmeren.
Het probleem met zo'n dongle is dat als je het communicatiepunt tussen de software en de dongle (of eigenlijk de library van de fabrikant) hebt gevonden, al die communicatie bewaard en later nagebootst kan worden. De meeste dongle fabrikanten leveren bij test-setjes de complete API documentatie mee, wat het nog gemakkelijker maakt.
De enige manier om dongles goed effectief te maken is stukjes van je eigen code (zelf, geen standaard inpak-tooltjes) te encrypten met waardes uit de dongle, op sommige dagen opeens hele andere checks gaan doen zodat je ze niet in 1 keer kunt loggen, de data op de dongle ook af en toe aanpassen, etc. Dat is allemaal een hoop werk en niet makkelijk, maar wel de enige manier om een dongle *echt* zin te geven (behalve dan dat je zowieso je programma onkraakbaar maakt zonder dongle). De meeste bedrijven hebben daar allemaal geen zin in en gebruiken gewoon de standaard tools die bij de dongle zitten.
Maar genoeg over dongles want die wilde je toch niet gebruiken. Commerciele oplossingen zijn vaak wel goed uitgedacht maar hebben een aantal zwakke punten. Een daarvan is dat je niet de enige bent met de beveiliging die ze bieden. Als het 1 keer gekraakt wordt, kunnen vaak alle programma's die dezelfde beveiliging gebruiken ook gekraakt worden. Vaak heeft elk programma wel weer een eigen variatie maar de basis zal hetzelfde blijven. Iets wat geautomatiseerd beveiligd wordt is vaak ook weer geautomatiseerd te kraken. Een ander zwak punt is dat de verbinding tussen het programma en de beveiliging vaak brak is. Zeker tooltjes die zichzelf gewoon aan de executable vasthangen. Maar dat hangt een beetje van de beveiliging af.
Zelf een beveiliging maken heeft iig als voordeel dat het uniek is (naja de ideeen vaak niet maar het geheel wel). Als je met tijdslimieten wil werken kijk dan eens naar andere plaatsen waar tijden worden opgeslagen, zoals boot log files of de windows event log.
Ook heel belangrijk is niet meteen duidelijke meldingen te geven dat er iets aan de beveiliging niet klopt. Dan is meteen het punt bekend waar het gecontroleerd wordt. Wat ook heel goed werkt is subtiele dingen doen die het programma onbruikbaar maken en lastig te vinden zijn. Dat moet wel gebeuren naast de normale foutmelding anders snappen 'echte' gebruikers niet wat ze overkomt. Een voorbeeld is bijvoorbeeld als je programma kan printen, zo nu en dan zwarte balken over je print heen te zetten als de beveiliging niet klopt. Normale gebruikers komen niet voorbij de foutmelding, maar een cracker kan die wel weghalen. Maar dan zit ie met het probleem dat z'n prints er niet goed uitkomen (met een beetje pech ziet hij dat 2 dagen later, erg frustrerend
Pas iig wel op dat je niet in de problemen raakt zoals TijnFLiP al zei, beveiling mag niet het normale functioneren belemmeren.
TurboPower heeft (bijna) al zijn producten aan de opensource community SourceForge geschonken. Ze zijn dus niet gratis en (kunnen) worden verder ontwikkeld door een ieder die dat wil.alienfruit schreef op 13 June 2003 @ 22:59:
TurboPower ProActivate is één van de betere copy protected producten voor Delphi.
Verder vind ik dongles enorm irritant als gebruiker en zal als het even kan zo'n product niet kopen. In het algemeen vind ik een licentie structuur afdwingen tot een bepaald niveau goed. De gewone gebruiker moet het niet al te gemakkelijk worden. Toch vind ik niet dat je verder moet gaan. Hoe moeilijker je het een hacker maakt, hoe moeilijker en onconfortabler je het je klanten ook maakt. En gekraakt kan het altijd wel worden. Dit artikel verwoord het heel goed wat ik bedoel.
We adore chaos because we like to restore order - M.C. Escher
Ik zou gaan voor een hardware-afhankelijke key waaruit jij een registratiecode kunt genereren specifiek voor een bepaalde computer. Verder zou ik een "grace period" toestaan van bijvoorbeeld een maand, zodat het programma ook volledig werkt zonder registratiecode ingeval van calamiteiten zoals geschetst door TijnFLiP. Het genereren van registratiecodes op basis van de hardwarekeys kun je geheel of gedeeltelijk automatiseren, zodat je hier ook geen omkijken meer naar hebt.
Dit is de methode die ik zelf een aantal jaren geleden gebruikt heb voor de verspreiding van een sharewareprogrammaatje. De beveiliging is nooit gekraakt en dat zal ook niet snel gebeuren als je een nichemarkt bedient.
Dit is de methode die ik zelf een aantal jaren geleden gebruikt heb voor de verspreiding van een sharewareprogrammaatje. De beveiliging is nooit gekraakt en dat zal ook niet snel gebeuren als je een nichemarkt bedient.
Ja, weet ik maar ProActivate is niet beschikbaar gesteld aan de opensource communityTurboPower heeft (bijna) al zijn producten aan de opensource community SourceForge geschonken. Ze zijn dus niet gratis en (kunnen) worden verder ontwikkeld door een ieder die dat wil.
Trouwens vind ik FlexLM beveiliging te goed werken, werkt soms niet eens als je een legale versie hebt, dan ben je zelfs nog uren aan het prutsen. KLOTE XSI! DIE!
Pagina: 1