the_uxreal: ich glaube, wir reden an einander vorbei
Es geht darum, die Lizenz oder den Schlüssel in wesentliche Programmfunktionen einzubinden. Dazu braucht man ein Konzept für das gesamte Programm und nicht nur die Überprüfung (ich weiß allerdings nicht, in wieweit sich diese Punkte in NET umsetzen lassen - die "nativ Sprachler" sollten aber keine Probleme haben)
1.die Lizenzabfrage muss also über die gesamte Anwendung verteilt sein (und zwar nicht als Aufruf zu einer Funktion, sondern am besten immer leicht unterschiedliche).
2.die Erfolgs/Fehlermeldungen sollten nicht unmittelbar nach der Prüfung auftauchen, sondern verzögert (durch Timer, Threads). Am besten ist auch die Prüfung von der Eingabe zeitlich getrennt - nicht umsonst melden viele Programme nach der Keyeingabe, dass sie nun neugestartet werden möchten.
3.Die Meldung an den Benutzer sollte zwar gut sichtbar sein, aber möglichst nicht für den Cracker - sprich: statt den String "registrierte Version" auszugeben, bietet es sich an, diesen selbst zu zeichnen, als Bild beizulegen (lohnt sich aber nur, wenn das Programm auch sonst viele Bilddateien nutzt) oder zumindest nicht so offensichtlich zu machen
Bsp:
Code:
zeichne_buchstaben('n',pos(1,1));
dummy_aufruf;
zeichne_buchstaben('i',pos(1,2));
dummy_anweisung;
zeichne_buchstaben('c',pos(1,3));
dummy_aufruf;
zeichne_buchstaben('h',pos(1,4));
dummy_anweisung;
zeichne_buchstaben('t',pos(1,5));
dummy_aufruf;
zeichne_buchstaben('r',pos(1,2));
dummy_anweisung;
zeichne_buchstaben('e',pos(1,2));
dummy_aufruf;
zeichne_buchstaben('g',pos(1,2));
....
Ausgabe: "nicht registrierte Version"
Bei C könnte man das sogar mit Macros erledigen, die das automatisch generieren - oder man schreibt sich vorher ein kleines Programm, welches bei eingabe eines Strings diesen zerlegt.
Der Benutzer bekommt die Meldung ganz normal zu sehen - im Speicher wird man allerdings keine Strings finden - und der Cracker hat damit erstmal viel weniger Hinweise auf wichtige Codestellen.
Liest man den Key nicht aus einer Datei ein, empfielt es sich eine eigene Einleseroutine zu verwenden - man ließt dann Buchstabe für Buchstabe ein und fügt es in das Eingabefeld ein. Irgendein vor der Prüfung gestarter Thread/Timerfunktion holt sich die Eingabe und prüft sie in regelmäßigen Abständen. Vorteil: der böse Cracker wird zwar im Speicher den Eingabestring finden - allerdings wird dann mehrere male pro Sekunde von der internen Windowszeichenfunktion (ja, Eingabefelder werden auch nur gezeichnet
)darauf zugegriffen. Das macht das gezielte Platzieren von Hardware Breakpoints (on access) sehr schwer - und ohne diese kommt man nicht so leicht an den Prüfthread. Allerdings weiß ich nicht, in wieweit dieser Tipp sich für NET eignet.
4. genauso verhält es sich mit dem abschalten wichtiger Funktionen nach dem die Trialzeit abgelaufen ist (hier gibt es aber eine andere Problematik, auf die ich gleich zu sprechen komme). Schön verzögern und wiederum unterschiedliche Funktionen an mehreren Programmstellen aufrufen. Sofern man Demos anbietet, gilt der obere Tipp: entweder die Funktion gar nicht ins Programm einbringen oder verschlüsselt - und nur die Richtigkeit der Entschlüsselung testen.
Das Abschalten sollte sich so gestalten, dass man einmal global die Funktion deaktiviert (dieser Schritt muss nicht ungebdingt maskiert werden - auch unmaskiert sind solche Aktionen nur schwer zu finden). Innerhalb der geschützten Funktion sollte nochmal eine Prüfung stattfinden und dabei folgende Logik berücksichtigt werden:
wenn die prüfung positiv war, heißt es, dass die Anwendung gepatcht/manipuliert wurde. Nun könnte man per Zufallsgenerator entscheiden, ob die Anwendung beendet wird oder nicht. Das Beenden natürlich wieder verzögert machen (Timer/Thread).
Solche Aktionen sind in soweit nützlich, als dass sie nicht wirklich reproduziert wedern können.
5.Checks einbauen. Diese können extremst nervig sein, besonders wenn es mehrere gibt
. Mir fällt der Name nicht mehr ein, aber irgendeine Anwendung hatte 4 Stück davon + einen eigenen Check für die restlichen Checkroutinen (Paranoia wäre durchaus zutreffende Bezeichnung
)
Man startet heimlich einen Thread/Timer, der dann ab und zu gewisste Codestellen auf Manipulationen durchsucht. Natürlich großflächiger angelegt (also nicht nur die wirklcih wichten 4 Bytes checken
). Davon hat man erstmal mehrere und kann auch ruhig einen oder zwei "Checker" von einem anderen überwachen lassen. Gibt es da Ungereihmheiten, entscheidet man wieder per Zufallsgenerator, ob weitergemacht oder beendet wird (ich würde die Rate je nach Häufigkeit der Checks auf 1% oder noch weniger setzen - damit auch z.B schön Zeit vergehen kann, bevor das Programm sich beendet).
6.Programm beenden: immer mehrere Beendefunktionen haben und möglichst nicht über ExitProgramm oder ähnliches. Bei Windows simuliert man das Beenden über Usereingaben, sofern man Windowsnachrichten nutzen kann: SendMessage, this,bla,WM_CLOSE. Das ist deutlich schwerer zurückzuverfolgen. Vor allem wenn nur Zufallsbasierend beendet wird und dann auch mehrere Funktionen dafür gibt.
7.Speichern der Lizenzinformation: niemals im Klartext, sonderund als abgewandelter Wert. Kein geXORe des Strings (fällt direkt auf), sondern als Zahl - eine Möglichkeit wäre es, diese Information zwischen den anderen Einstllungen, die man speichert, zu verstecken oder zu verteilen.
Auf den Usernamen verzichtet man am besten komplett.
Zu dem Trialzeitproblem: hier besteht die große Schwierigkeit, die tatsächlich vergangene Zeit festzustellen. Denn dazu muss man vorgegebene Methoden nutzen. Es gibt zwar paar Tricks (arbeiten mit Dateien - eine wird bei der Installation erstellt, eine andere wird bei jedem Programmstart neu erstellet - nun ließt man die Timestamps der beiden Dateien ein und vergleicht diese), aber größtenteils versucht man ja zu bewirken, dass eine Nutzung über X Tage hinweg nicht möglich ist. D.h die Prüfungen kann man zwar so ähnlich wie bei der Serial verteilen, allerdings sind diese deutlich schwerer zu verstecken.
Insgesamt sieht man, dass es verdammt viel Aufwand sein kann, den man abwägen muss. Insbesondere bei größeren Projekten kommt auch viel Testaufwand dazu - denn nichts ist schlimmer, als wenn bei dem Endkunden, der die Lizenz erworben hat, ein False-Positiv auftritt oder auch in der Trial/Demo das Programm durch den False-Positiv scheinbar "abstürzt".
![[HaBo]](/styles/default/logoklein.png){kind=small}
