[C#] Demoversie van Applicatie

[Davio]

Beste Tweakers,

Ik heb een applicatie waarvan ik graag een Demo-versie wil maken.

Mijn eerste idee was om het programma 30 dagen lang volledig te laten gebruiken, maar na onderzoek op internet blijkt dat time demo's bijna altijd gewoon een slecht idee zijn, omdat ze eenvoudig zijn te omzeilen.

Nu dacht ik dat het misschien beter zou zijn om een gehandicapte versie van mijn volledige programma te maken.

Ik heb zelf een nieuwe Build Configuration aangemaakt genaamd 'Demo' en een compile-time constant genaamd DEMO toegevoegd.

In de source doe ik dan bijvoorbeeld

C#:

#if DEMO
            internal const int MAXUSERS = 3;
            internal const int MAXPROFILES = 3;
            internal const int MAXREPORTS = 10;
            internal const int MAXODBCS = 1;
            internal const int MAXJOBS = 1;
            internal const int MAXOPENED = 10;

            private int reportsOpened = 0;
#endif

Check in de GUI voor als de gebruiker probeert een nieuwe gebruiker toe te voegen...

C#:

#if DEMO
            //dc is een DataContext (LINQ to SQL)
            if (this.dc.Users.Count() == MainClass.MAXUSERS)
            {
                MessageBox.Show(
                    this,
                    @"Het maximum aantal gebruikers voor de demo-versie is bereikt.",
                    @"Maximum Bereikt",
                    MessageBoxButtons.OK,
                    MessageBoxIcon.Information);

                return;
            }
#endif

Is dit een beetje een handige manier? Zouden jullie het hetzelfde doen of anders?

[Sebazzz]

Constanten worden gewoon in een assembly embedded, en zijn te veranderen. Je zou zelfs heel het programma kunnen decompileren en alles op Int32.MaxValue zetten.

[DoDo]

Ik gebruik een licensing DLL voor demo's van mijn applicaties. Hierbij kan de user de software downloaden, waarbij hij een serial krijgt die 30 dagen geldig is.

Verder obfuscate ik nog alle sourcode (.NET eenvoudig in reflector te zien).
Het programma dat ik gebruik voor licensing heet "Seriousbit Ellipter".

[IceM]

Het is een illusie om te denken dat een tijdsbeperking eenvoudiger dan wel moeilijker te omzeilen is als een resource limitatie. Zeker in het geval van een .net assembly is het vrij eenvoudig te kraken. Hou gewoon in je achterhoofd dat als je applicatie populair genoeg is het vroeg of laat toch in gekraakte vorm op het net komt. Bespaar je de tijd en moeite om je applicatie zo veel mogelijk dicht te timmeren en bouw er een simpele beveiliging/check in zodat niet elke willekeurige gebruiker je check kan omzeilen en daardoor aangezet wordt tot aanschaf van een volledige licentie.

[Niemand_Anders]

Onze applicatie werkt op basis van X.509 certificaten. Zodra het certificaat (licentie) ongeldig wordt (is), werkt de applicatie niet meer. Om aanpassingen van de systeemtijd aan te pakken, vragen wij zelf de (UTC) tijd op middels NTP. Wij accepteren een maximale afwijking van 4 uur. Indien de NTP server niet bereikbaar is, start de applicatie niet. Echter wij zijn in de positie om deze NTP requirement af te dwingen.

Om decompilatie te voorkomen gebruiken wij de commerciele (build machine) versie van Dotfuscator. Bekende decompiler tools zoals reflector kunnen niet overweg met de assembly.

[Hydra]

De beste manier om te voorkomen dat een demoversie binary gekraakt wordt is door ervoor te zorgen dat bepaalde functionaliteit er gewoon niet in zit. Dergelijke checks op constanten zijn extreem simpel te kraken. Dus verwijder bijvoorbeeld ook de code om een gebruiker toe te voegen.

[Gerco]

De beste manier om een demoversie te maken is, mijns inziens, om bepaalde features *niet* in je demoversie te compileren. De save-feature bijvoorbeeld, of de reporting, net wat voor jouw applicatie zinvol is. Op die manier kun je die code ook niet heractiveren met een hack of recompile, de code zit er gewoon niet in.

Aan de andere kant houden beveiligingen alleen eerlijke mensen eerlijk. Oneerlijke mensen omzeilen de beveiliging toch wel (door in dit geval de volledige versie van de app te kopieren ipv de demo versie te hacken) en kun je niet tegen houden.

Doe gewoon iets wat zinvol is voor jouw applicatie. Als een time limit of een maximaal aantal users zinvoller is dan het weglaten van features, bouw dan gewoon die limieten in. Proberen je applicatie waterdicht te maken is zinloos en neemt alleen tijd in beslag die je ook had kunnen besteden aan functionele zaken.


Dit betekent natuurlijk niet dat je moet volstaan met een vinkje "demo versie" in de settings ofzo. Een beveiliging moet wel enigszins effectief zijn om eerlijke mensen eerlijk te houden.

[ Voor 10% gewijzigd door Gerco op 08-10-2010 13:11 ]

[Davio]

Sebazzz schreef op vrijdag 08 oktober 2010 @ 12:51:
Constanten worden gewoon in een assembly embedded, en zijn te veranderen. Je zou zelfs heel het programma kunnen decompileren en alles op Int32.MaxValue zetten.

Zou het dan zinvoller zijn om alles hardcoded te maken?

En wat betreft het niet toevoegen van bepaalde features: Dit is juist iets wat ik met mijn Compile Constant probeer te bereiken, want hij compileert alles binnen de #if DEMO toch alleen als ik die aan heb staan?

En dan zou ik de rest gewoon in de #else kunnen plaatsen?

Bedankt voor alle reacties tot nu toe in ieder geval.

[Gerco]

Davio schreef op vrijdag 08 oktober 2010 @ 13:16:
En wat betreft het niet toevoegen van bepaalde features: Dit is juist iets wat ik met mijn Compile Constant probeer te bereiken, want hij compileert alles binnen de #if DEMO toch alleen als ik die aan heb staan?

Hij compileert de limieten nu alleen in de demo versie ja, maar waar we op doelen is meer iets als dit:

C#:

#if DEMO

  MessageBox.Show("Saving files is not available in the DEMO version of MyAwesomeApp.");

#else

  // Code om bestand te saven

#endif

Op deze manier zit de logica voor het opslaan niet in de demo versie en is het dus onmogelijk om die te activeren door een constante te veranderen oid.

[Davio]

Bedankt, Gerco, dat is waar ik zelf ook aan dacht.

Ik ben inmiddels ook aan het zoeken naar een goede (gratis) obfuscator en kwam op deze uit: Eazfuscator, http://www.foss.kharkov.u...cator/dotnet/Default.aspx

Iemand hier ervaringen mee?

[YopY]

quote: davio

Zou het dan zinvoller zijn om alles hardcoded te maken?

Een constante is hardcoded, . const X = 1 is hetzelfde (functioneel gezien) als gewoon '1'. If (users > MAX_USERS) is ook hetzelfde als if(users > 5).

@topic, denk er ook aan om niet alleen je applicatie dicht te timmeren, maar om ook voordelen toe te kennen aan een legale versie, zoals support en updates en dergelijke.

Ligt een beetje aan het type applicatie, natuurlijk. Een Starcraft 2 wordt goed verkocht omdat het gekoppeld is aan een online community en profiel, waar je je ook echt buitengesloten bij gaat voelen als je niet een legale versie hebt.

[DoDo]

Davio schreef op vrijdag 08 oktober 2010 @ 13:37:
Bedankt, Gerco, dat is waar ik zelf ook aan dacht.

Ik ben inmiddels ook aan het zoeken naar een goede (gratis) obfuscator en kwam op deze uit: Eazfuscator, http://www.foss.kharkov.u...cator/dotnet/Default.aspx

Iemand hier ervaringen mee?

Qua obfuscaten doet hij zijn werk goed, het enige probleem voor mij was dat hij alle DLL files samenvoegd. Mijn software is een plugin voor een ander systeem, waarmee ik foutmeldingen kreeg als hij de dll files samenvoegde.

Ik gebruik nu Phoenix Protector, en deze werkt voor mij perfect. Te vinden op:
http://www.ntcore.com/phoenix.php

[Davio]

YopY schreef op vrijdag 08 oktober 2010 @ 13:57:
[...]


Een constante is hardcoded, . const X = 1 is hetzelfde (functioneel gezien) als gewoon '1'. If (users > MAX_USERS) is ook hetzelfde als if(users > 5).

@topic, denk er ook aan om niet alleen je applicatie dicht te timmeren, maar om ook voordelen toe te kennen aan een legale versie, zoals support en updates en dergelijke.

Ligt een beetje aan het type applicatie, natuurlijk. Een Starcraft 2 wordt goed verkocht omdat het gekoppeld is aan een online community en profiel, waar je je ook echt buitengesloten bij gaat voelen als je niet een legale versie hebt.

Ja, functioneel is het hezelfde, maar ik vroeg me af of de waarde van een constant niet stiekem toch veranderd kon worden zoals Sebazzz aangaf, of worden ze tijdens het compileren al allemaal vervangen, wat logischer lijkt?

Het zijn immers geen variabelen...

[RobIII]

Niemand_Anders schreef op vrijdag 08 oktober 2010 @ 13:03:
Onze applicatie werkt op basis van X.509 certificaten. Zodra het certificaat (licentie) ongeldig wordt (is), werkt de applicatie niet meer. Om aanpassingen van de systeemtijd aan te pakken, vragen wij zelf de (UTC) tijd op middels NTP. Wij accepteren een maximale afwijking van 4 uur. Indien de NTP server niet bereikbaar is, start de applicatie niet. Echter wij zijn in de positie om deze NTP requirement af te dwingen.

En als ik nou eens een DNS record aanmaak en zelf een NTP servertje ga draaien?

Davio schreef op vrijdag 08 oktober 2010 @ 14:06:
Het zijn immers geen variabelen...

Een constante is gewoon een variabele (lees: plek in het geheugen waar "een" waarde staat) waarvan de compiler je tegenhoudt deze te wijzigen.

[ Voor 18% gewijzigd door RobIII op 08-10-2010 15:14 ]

[AtleX]

De laatste keer dat ik een demo heb verspreid van 1 van mijn applicaties heb ik gewoon de save & open onderdelen eruit verwijderd door middel van een compiler directive zoals beschreven in de topicstart. Die code is dan helemaal niet aanwezig in de build die verspreid wordt, dus dat is wel heel moeilijk te kraken. Natuurlijk zijn de volledige versies dan nog wel te kraken en te verspreiden, maar de kans daarop was al wat kleiner.

[yade]

Ik zou werken met een licentiebestand waar die waarden in staan. Deze zou ik asynchroon encrypten waarbij de public key in de applicatie zit en de private key natuurlijk alleen bij jou bekend is waardoor jij alleen die licenties kan maken. Stop hier zoveel mogelijk variabelen in die je applicatie gebruikt en dan is het kraken niet meer een constante aanpassen, maar het licentiemechanisme eruit slopen.

Voordel is ook dat je per klant specifieke licenties kan maken.

[Hydra]

Davio schreef op vrijdag 08 oktober 2010 @ 14:06:
Ja, functioneel is het hezelfde, maar ik vroeg me af of de waarde van een constant niet stiekem toch veranderd kon worden zoals Sebazzz aangaf, of worden ze tijdens het compileren al allemaal vervangen, wat logischer lijkt?

Een constante zoals const int ONE = 1 wordt compile time gewoon vervangen voor 1 ja. Dus het maakt geen hout uit, een constante is in een .exe extreem simpel om te zetten.

M.i. zou iedere programmeur eens een beetje assembly moeten leren en eens naar de utivoer van een compiler moeten kijken als 'ie een simpel programmatje compiled. Dit is m.i. kennis die iedere programmeur moet hebben.

yade schreef op vrijdag 08 oktober 2010 @ 16:45:
Ik zou werken met een licentiebestand waar die waarden in staan. Deze zou ik asynchroon encrypten waarbij de public key in de applicatie zit en de private key natuurlijk alleen bij jou bekend is waardoor jij alleen die licenties kan maken. Stop hier zoveel mogelijk variabelen in die je applicatie gebruikt en dan is het kraken niet meer een constante aanpassen, maar het licentiemechanisme eruit slopen.

Voordel is ook dat je per klant specifieke licenties kan maken.

Pff. Dat soort dingen is meestal ook een kwestie van een JE naar een JNE omzetten. De beste manier om functionaliteit te beschermen is die er gewoon niet in te stoppen.

De software van m'n werkgever heeft ook een vrij uitgebreide licentiebeveiliging en die is er ook relatief simpel weer uit te hacken als je in een debugger door de executable stept.

[ Voor 39% gewijzigd door Hydra op 08-10-2010 16:47 ]

[yade]

Uiteindelijk komt alles neer op de weakest link en dat is het uiteindelijke punt van beslissing, alles is te kraken. Daar heb je gelijk in.

De licentie methode voorkomt wel weer dat je twee binaries moet gaan onderhouden en je hebt gelijk een soort van beveiliging voor de volledige versie. Je hoeft de klant alleen maar de nieuwe licentie te mailen als deze tot aankoop overgaat.

Maar goed, het beslissingspunt vinden met een debugger is al lastiger dan een constante aanpassen.