[VB] Trial versie voor programma *

[Verwijderd]

Ik heb een applicatie gemaakt die voorzien moet worden van een trial time-out. Na x dagen mag het programma niet meer functioneren. Wie kan mij helpen aan de regels / methodes over hoe je die zo goed mogelijk kan inbouwen, zodat het simpel verzetten van de systeemtijd niet voldoende is om het te omzeilen?

[Verwijderd]

maybe dat je bijvoorbeeld maar 30 uur het progrmama kan draaien ?? is ook we grappig.. of dat je hem maar 10 keer mag starten.. en dat ie na 3 uur automatisch af sluit?

[whoami]

Ik kan me vaag herinneren dat er hier al eens een topic over geweest is, maar ik kan hem niet terugvinden.

[D2k]

leuk algo verzinnen en wegschrijven in het register
als die waarde wordt aangepast programma stoppen, als die waarde afloopt ook het programma stoppen. oid

[LuCarD]

Misschien is deze post interresant...

[rml]JonkieXL in "[ Alg] Safe code"[/rml]

This is called "darwinian selection among wannabie crackers" :-)

[Xanthus]

http://www.woodmann.com/fravia/protec.htm
Daar staan wat tips om je software goed te beveiligen, waarvan een paar van toepassing op trials.

He! JonkieXL heeft dezelfde lijst, al heeft die van die link ook andere.

[Sponge]

op www.pscode.com staan ook een aantal voorbeelden, zelf zal ik zoeits ook moeten maken .. maar dat baseer ik liever niet op andere voorbeelden

[Feyd-Rautha]

Een mogelijk oplossing kan zijn dat je de systeemdatum opslaat bij het installeren en dan deze opgeslagen datum steeds gebruiken om te controleren hoeveel dagen er nog overschieten...

[Gerco]

Gebruik indien mogelijk een externe time-server, maar dan zit je direct vast op het verplicht hebben van een internet connectie.

Verder is de systeemtijd inderdaad niet te vertrouwen. Je kunt 'em wel gebruiken, maar zorg dan iig dat de systeemtijd van deze run later moet zijn dan de tijd van de vorige run. Eventueel gecombineerd met een "hoe lang draai ik" systeem, zoiets dus: [tijd van deze run] > [tijd van vorige run] + [hoe lang draaide ik de vorige keer]

[Verwijderd]

Feyd-Rautha schreef op 14 augustus 2002 @ 14:00:
Een mogelijk oplossing kan zijn dat je de systeemdatum opslaat bij het installeren en dan deze opgeslagen datum steeds gebruiken om te controleren hoeveel dagen er nog overschieten...

Is inderdaad leuk, maar als ze bij de 1e start hun datum op 2009 zetten moet ik dat dus ook checken. Het is wel de opdracht om een aantal DAGEN op te kunnen geven dat de applicatie mag werken.

Ook moet ik niet hebben dat ze voor het opstarten de datum even terugzetten, opstarten en de datum weer herstellen, dus ik zoek een mooie secondaire check, maar bedankt voor alle links hier, ik ga ze meteen doorlezen.

[Verwijderd]

Wat je misschien zou kunnen doen, is dat de exe van het programma gewoon een lege exe met een zip erin is die die automatisch uitpakt naar een bepaalde directory. De exe die uitgepakt is checkt dan de checksom van de originele exe en die van hemzelf, is er iets mis...

[PdeHoog]

Misschien een idee:

- de datum van installatie geencrypted in de registry wegschrijven onder een fake-item
- de datum / tijd van de laatste run geencrypted in de registry wegschrijven onder een fake-item (initieel gevuld met datum installatie)
- controle op systeemdatum voor datum installatie
- controle op systeemdatum voor datum laatste run
- controle op systeemdatum voor datum installatie + trial

je hebt dan afgedekt dat:
1) de systeemdatum altijd na datum installatie moet liggen
2) de systeemdatum altijd na de datum van de laatste run moet liggen
3) de systeemdatum altijd voor de datum installatie + trial_periode moet liggen

De gebruiker komt er na de trial_periode achter dat de applicatie niet meer werkt, zet z'n datum terug en valt dan door de mand bij controle 2.

Een idee?

[Crazy D]

Verwijderd schreef op 14 augustus 2002 @ 15:04:
Ook moet ik niet hebben dat ze voor het opstarten de datum even terugzetten, opstarten en de datum weer herstellen, dus ik zoek een mooie secondaire check, maar bedankt voor alle links hier, ik ga ze meteen doorlezen.

Zie Gerco. Dus ook laatste run-datum bijhouden, als die lager is dan de vorige keer (- een marge, een paar minuten mag natuurlijk wel maar 1 of 2 dagen is al wel wat opvallend, laat staan een maand oid) is het niet goed.

[Sponge]

Verwijderd schreef op 14 augustus 2002 @ 15:04:
[...]


Is inderdaad leuk, maar als ze bij de 1e start hun datum op 2009 zetten moet ik dat dus ook checken. Het is wel de opdracht om een aantal DAGEN op te kunnen geven dat de applicatie mag werken.

Ook moet ik niet hebben dat ze voor het opstarten de datum even terugzetten, opstarten en de datum weer herstellen, dus ik zoek een mooie secondaire check, maar bedankt voor alle links hier, ik ga ze meteen doorlezen.

Hier staat ook iets over in het eerder genoemde topic "Safe code.." (zie eerste replies), door gebruik van andere bestanden.

[Verwijderd]

Om tijd terug zetten te voorkomen kun je de tijd vergelijken met log-files e.d. (de tijd van die bestanden mag niet hoger zijn dan de huidige tijd).

[Xanthus]

Verwijderd schreef op 14 augustus 2002 @ 16:48:
Om tijd terug zetten te voorkomen kun je de tijd vergelijken met log-files e.d. (de tijd van die bestanden mag niet hoger zijn dan de huidige tijd).

Naast dit ook controleren of de systeemtijd niet lager is dan de tijd van installatie:
anders kan iemand de klok vooruit zetten bij het installeren.

[Pooh]

Een tip: schrijf de initiele waarde van de systeemtijd niet weg bij installatie, maar bij de eerste keer starten. Dit heeft 2 voordelen:

1. Tooltjes die de tijdens de installatie het register monitoren (om uninstallen eenvoudiger te maken) hebben geen grip op je beveiliging.
2. Het is wat 'eerlijker' tegenover je gebruikers. Als je het product wel installeert, maar niet gebruikt, verloopt de trial-periode ook niet.

[Verwijderd]

PdeHoog schreef op 14 augustus 2002 @ 15:23:
Misschien een idee:

- de datum van installatie geencrypted in de registry wegschrijven onder een fake-item
- de datum / tijd van de laatste run geencrypted in de registry wegschrijven onder een fake-item (initieel gevuld met datum installatie)
- controle op systeemdatum voor datum installatie
- controle op systeemdatum voor datum laatste run
- controle op systeemdatum voor datum installatie + trial

je hebt dan afgedekt dat:
1) de systeemdatum altijd na datum installatie moet liggen
2) de systeemdatum altijd na de datum van de laatste run moet liggen
3) de systeemdatum altijd voor de datum installatie + trial_periode moet liggen

De gebruiker komt er na de trial_periode achter dat de applicatie niet meer werkt, zet z'n datum terug en valt dan door de mand bij controle 2.

Een idee?

Lijkt zeker een goed idee, alleen ik kan alleen naar HKEY_LOCAL_MACHINE schrijven onder het kopje software, anders hebben de gebruikers vaak weer geen recht, dus ben ik bang dat ze de key wel zullen vinden.

Maar de checks zelf lijken voldoende, maar wat gebeurd er als iemand z'n klok altijd op de installatiedatum zet, programma start en de klok weer bijsteld naar de normale tijd? Dan moet ik deze check dus al op meerdere punten in de applicatie uit gaan voeren. Verder lijkt ie me behoorlijk. Bedankt alvast.

[Verwijderd]

Poohbear schreef op 14 augustus 2002 @ 17:18:
Een tip: schrijf de initiele waarde van de systeemtijd niet weg bij installatie, maar bij de eerste keer starten. Dit heeft 2 voordelen:

1. Tooltjes die de tijdens de installatie het register monitoren (om uninstallen eenvoudiger te maken) hebben geen grip op je beveiliging.
2. Het is wat 'eerlijker' tegenover je gebruikers. Als je het product wel installeert, maar niet gebruikt, verloopt de trial-periode ook niet.

Is inderdaad netter. Zal het ook zo aan gaan pakken. Ik had ook i.p.v. de gegevens naar het register schrijven ( datum eerste start, dagen voor trial, etc ) in de executable zelf willen wegschrijven, maar helaas kan de .EXE zelf niet een gereserveerd deel in de .EXE beschrijven als hij zelf runt. Leek me anders wel een leuke.

[PdeHoog]

Verwijderd schreef op 14 augustus 2002 @ 19:35:
[...]


Lijkt zeker een goed idee, alleen ik kan alleen naar HKEY_LOCAL_MACHINE schrijven onder het kopje software, anders hebben de gebruikers vaak weer geen recht, dus ben ik bang dat ze de key wel zullen vinden.

.....en daarom wil je hem geencrypted wegschrijven

Maar de checks zelf lijken voldoende, maar wat gebeurd er als iemand z'n klok altijd op de installatiedatum zet, programma start en de klok weer bijsteld naar de normale tijd? Dan moet ik deze check dus al op meerdere punten in de applicatie uit gaan voeren. Verder lijkt ie me behoorlijk. Bedankt alvast.

Dat is er inderdaad eentje waar ik nog niet aan had gedacht. Je zou een soort centrale functie kunnen schrijven die je bij elke functionaliteit aanroept, waarbij je dan controleert of de datum / tijd van de laatste run globaal overeenkomt met de huidige datum / tijd.

Aan de andere kant....je hebt met de eerder door mij genoemde controles waarschijnlijk al 80% van de gebruikers zover dat ze je applicatie niet meer gebruiken. Die vinden het te lastig worden denk ik (althans zo zou ik redeneren). Je moet je dan ook afvragen of het zinnig is om zover te willen gaan. Waarschijnlijk gaat dan de 80-20 regel in werking treden en besteed je 80% procent van je tijd om 20% van de gebruikers buiten de deur te houden.

[PdeHoog]

Verwijderd schreef op 14 augustus 2002 @ 19:37:
[...]


... Ik had ook i.p.v. de gegevens naar het register schrijven ( datum eerste start, dagen voor trial, etc ) ....

Wat dacht je van een fake-bestandje ergens diep in de windows-directory verstopt? Je kunt daar alle data geencrypted in verstoppen. Hooguit dat een installmanager oid een en ander vind.

[Xanthus]

PdeHoog schreef op 15 augustus 2002 @ 01:30:
[...]


Wat dacht je van een fake-bestandje ergens diep in de windows-directory verstopt? Je kunt daar alle data geencrypted in verstoppen. Hooguit dat een installmanager oid een en ander vind.

Dat is wel makkelijk te vinden met bijv FileMON, of met een decompiler een reference naar dat bestand. Dan kan dat bestand bijv gedelete of veranderd worden. Je kan beter zo'n bestand als 1 van de verschillende plekken waar de datum is opgeslagen gebruiken. Misschien als begintijd ook de lastmodified van een bestand dat aangemaakt wordt bij installatie.

[Shir]

Volgens mij kan je beter een crippled versie maken, bijvoorbeeld zonder opslaan o.i.d.

[Sponge]

Shir schreef op 15 augustus 2002 @ 11:15:
Volgens mij kan je beter een crippled versie maken, bijvoorbeeld zonder opslaan o.i.d.

En als je dat doet ook echt de opslaan code weghalen!! Anders is een simpele patch waarschijnlijk al genoeg om toch nog opslaan functionaliteit te krijgen..

[Gerco]

Gewoon de crippled features eruit halen met conditionele compilatie. Dat is mijn inziens de enige manier om waterdicht een shareware versie ergens van te maken.

Het enige wat je dan nog hebt is dat mensen een volledige versie kunnen kopen en die verspreiden. Maar dan kun je een serienummer ofzo embedden (NIET laten weten dat zo'n nummer erin zit) en bijhouden van wie dat nummer is. Dan weet je in ieder geval wie je kunt aanklagen als je een illegale kopie tegenkomt.

Je moet in de EULA natuurlijk wel aangeven dat de kopieen afzonderlijk identificeerbaar zijn, anders mag het niet geloof ik, maar niemand leest EULA's dus dat maakt niet zoveel uit. Alhoewel steeds meer mensen ze gaan lezen gezien de laatste gedragingen van ons aller favoriete software fabrikant.

[MrBrown]

Ik denk dat het aanmaken van registry keys en bestandjes ver weggestopt niet echt een goed idee is, mensen die die stuff willen cracken kunnen daar altijd wel achter komen. Als je data ergens wegschrijft moet je dat gewoon lekker op een logische plaats doen, en zorgen dat het goed genoeg geencrypt ofzo is.. Anders een andere methode bedenken.

Waar je overigens ook nog wel even rekening mee moet houden zijn re-installs. Je wilt niet dat na verstrijken van je trailperiode de user uninstallt en reinstallt en alles werkt weer....

[Pooh]

MrBrown schreef op 15 augustus 2002 @ 13:15:
Ik denk dat het aanmaken van registry keys en bestandjes ver weggestopt niet echt een goed idee is, mensen die die stuff willen cracken kunnen daar altijd wel achter komen. Als je data ergens wegschrijft moet je dat gewoon lekker op een logische plaats doen, en zorgen dat het goed genoeg geencrypt ofzo is.. Anders een andere methode bedenken.

Waar je overigens ook nog wel even rekening mee moet houden zijn re-installs. Je wilt niet dat na verstrijken van je trailperiode de user uninstallt en reinstallt en alles werkt weer....

Hoe wilde jij onder windows bescherming bieden tegen re-installs, op een andere manier dan via een registry key of een weggestopt bestandje?

[MrBrown]

Kan idd niet anders dan in een bestandje/regkey, maar 't zit 'm mij in dat verborgen... Als je daar je hele methode vanaf laat hangen is het een kwestie van tijd voordat men het vind.

Nou zit ik te denken... Op een logische plaats wordt idd ook lastig toch, want als je het bestand/regkey weghaald ben je idd zuur...

[Narf109]

Ik heb zelf wel eens gebruik van http://www.activelock.com/ gemaakt, kon je zelf trial-, share- en crippleware mee maken

[Pooh]

MrBrown schreef op 15 augustus 2002 @ 14:06:
Kan idd niet anders dan in een bestandje/regkey, maar 't zit 'm mij in dat verborgen... Als je daar je hele methode vanaf laat hangen is het een kwestie van tijd voordat men het vind.

Nou zit ik te denken... Op een logische plaats wordt idd ook lastig toch, want als je het bestand/regkey weghaald ben je idd zuur...

Het kan wel echt veilig, maar dan moet je via 't web gaan werken. Zelfs de compilatiedatum+100 dagen ofzo gebruiken is niet echt veilig, omdat mensen hun klok kunnen verzetten (of je zou met een externe time-server moeten gaan werken).