Timebomb - Programmausführung zeitlich begrenzen.

nuts

Hey,

ich suche Ideen wie man einem Programm eine zeitlich begrenzte Nutzungsdauer geben kann.

Dazu gibt es zwei Einschränkungen:
1. offline Betrieb muss möglich sein
2. Registrierungseinträge möchte ich vermeiden

Was ich dem "gemeinen" User zutraue ist der "blöde" Trick das Systemdatum zu ändern um die Nutzungsdauer zu beeinflussen und leicht erkennbare Datumseinträge in einer Konfigurationsdatei zu ändern.

Hintergrund:
Damit das Programm sinnvoll arbeiten kann muss ich von Zeit zu Zeit geänderte Basisdaten bereitstellen.
Nur da einige bestimmt glauben schlauer zu sein wird darauf möglicherweise verzichtet und man versucht selbst rumzuwurschteln.

Ich dachte mir das so:
1. Installation -> Zeitpunkt kryptisch (Passwort im Quellcode) in der Konfigurationsdatei ablegen
2. Beim Startup die Systemzeit auslesen
3. Prüfen ob die Systemzeit hinter dem Installationszeitpunkt liegt und ggf. die rote Karte zeigen
4. Über Datediff den Installationszeitpunkt mit der Systemzeit vergleichen und beim Überschreiten einer bestimmten Zeitspanne kommt wieder die rote Karte
5. Updates über einen Patch, der den neuen Zeitpunkt wieder kryptisch ablegt und die Basisdaten mitbringt.

Was meint ihr? Einen wichtigen Aspekt vergessen? Gibt es Risiken? Oder andere Ansätze?
Ich hab da leider null Erfahrung im Umgang mit reinen Usern und weiss daher nicht auf was ich achten sollte. :wacko:

Gruß nuts

P.S.
Decompilierer usw. ist bekannt und spielt keine Rolle.

**chip**

Solltest auf immer beim ausführen das aktuelle Datum Speichern. So kannst feststellen ob zwischen dem letzen und dem aktuellen Start das Datum zurückgesetzt wurde.

Kleiner

Hi!

Ich denke mir, Stunden-Tage-Wochen wieviel auch immer hoch rechen verschlüsselt speichern wie den rest auch, einlesen ruterzählen speichern beim beenden.
Wehr meine Idee!

Lg Kleiner

andygo

Hi,

meine spontane Idee ist:

Unabhängig von der Systemzeit setze doch einfach einen Timer
der die aktive Nutzung deines Programmes erfasst und cryptisch
speichert. und bei jeder Nutzung den zuvor erfassten Wert addiert.

So ist irgendwann der aktive Nutzungszeitraum voll. Eine entsprechende
Prüfung sollte auch immer mal wieder während das Programm läuft erfolgen.

Cyberdyne

Zitat von nuts

Was ich dem "gemeinen" User zutraue ist der "blöde" Trick das Systemdatum zu ändern um die Nutzungsdauer zu beeinflussen und leicht erkennbare Datumseinträge in einer Konfigurationsdatei zu ändern.

Was machst du wenn der user deine Konfigurationsdatei (mit kryptischen Inhalt) einfach kopiert und sich den Installationszeitpunkt merkt?

Der user kann dann nämlich deine Konfigdatei mit seinem backup überschreiben und dann den "blöden" Trick anwenden (Systemdatum ändern). Das Programm "denkt" dann, es ist gerade eben erst gestartet worden.

Keine rote Karte weit und breit

Lösung für das Problem:
-keine-

hellboy3

Zitat

offline Betrieb muss möglich sein

Hmm das ist das Problem ansonsten hätte man ja zeit und datum aus einer I-net seite lesen können....

nuts

Also jedes Ausführungsdatum muss man auch abspeichern.
Sonst kann das Systemdatum ja immer auf einen Wert zwischen Installation und Ablauf geändert werden.
Danke für den Hinweis chip.

Dann gehts weiter:

Man macht nach der Installation gleich ein Backup und überschreibt im Fall der "roten Karte" die bisherige Konfig.-Datei.
Jetzt kann man bei einem Systemdatum zwischen Installation und Ablaufdatum das Programm weiter verwenden
Tjo so leicht kanns gehen - dazu fällt mir jetzt auch nichts mehr ein

Vielleicht doch besser einen versteckten Eintrag in der Registrierung.

**chip**

Fakt ist, dass man jede Begrenzung auf irgendeinem Wege umgehen kann. Hier muss also schlicht eine aufwand zu nutzen Entscheidung getroffen werden.

Btw. je mehr Aufwand betrieben wird ein Programm zu sichern, desto mehr Anreiz ist es für Leute diesen Schutz zum umgehen.

Bitboy

Die einzige externe Quelle für die Uhrzeit scheinen demnach die Basisdaten zu sein.
Was würde dagegen sprechen einen verschlüsselten hash zu speichern?
Das programm kann dann anhand dessen prüfen ob sie von dir selbst sind. und ebenfalls zu welchem datum die erstellt wurden.
mit 2mal basisdaten aktualisieren hast du also ne messbare und meiner meinung nach nicht manipulierbare zeitmessung.
(etwas ungenau aber für den zweck reicht es)

nuts

Stimmt den ersten Bezugspunkt könnte man von den Basisdaten holen.
Der Zweite muss aber übers Systemdatum geholt werden oder?

Bitboy

So wie ich das verstanden hab nicht. Die Basisdaten müssen ja "von zeit zu zeit" angepasst werden.
Also kann auch das 2. Datum über die Basisdateien ermitelt werden.

**Oscar**

Mal noch ein anderer Vorschlag:
Statt die aktuelle Systemzeit für einen Vergleich auszulesen (die ja leicht manipulierbar ist), könntest Du die Zeit des letzten Systemstarts benutzen.
So müsste Otto-Normaluser schon die Systemzeit verstellen, einen Neustart machen und dann Dein Programm starten.

nuts

Aber bei der Installation gibts ja die Basisdaten nur einmal.
Woher weiss das Programm jetzt, dass es Zeit ist für neue Basisdaten?

Die Idee von Oscar ist gut. Das werde ich ins Gesamtkonzept einbauen!

Cyberdyne

Bei der Installation gibst du halt Basisdaten mit, die schon "zu alt" sind.

Heute ist der 22.10.2010
1. Die ersten Basisdaten (bei der installation mitdabei), müssten dann das Verfallsdatum 01.10.2010 haben
2. Bei Programmstart weiß das Programm automatisch, dass die ersten Basisdaten, aufjedenfall veraltet sind und fordert auf neue Basisdaten zu installieren.
3. Neue Basisdaten haben das Verfallsdatum 01.11.2010
4. Das Programm hat jetzt 2 Daten:
===> Bitboy
===> Was ich jetzt nicht verstehe, wie kann das Programm aus diesen 2 Daten feststellen ob die Zeit abgelaufen ist?
===> Doch nur über die Systemzeit, oder?

PS:
Die Idee von Oscar gefällt mir.

Sen

4 kleine Tipps wenns wirklich sicher sein soll.

1. Nicht die Windowsuhr.
Warum? Weil eine Abfrage viel zu leicht zu knacken ist, da bringt auch die Abfrage nichts.
Warum die Uhr vorstellen wenn man sie einfach feststellen kann?

2. Timer wirken nicht.
Da man sie relativ leicht einfach über andere "Zugriffe" ändern kann.

3. Registry/WMI Einträge vermeiden.
Beide kann man vor Programmstart ändern (RegEdit) oder bei Abfrage den Return ändern (WMI etc).

4. ntSuspend Schutz
Das Problem wirst du (Dank Windoof) nicht umgehen können.
1 Zeile Script, bringt dein ganzes Script einfach zum stillstand

Ineluki

Timer wirken meiner Meinung nach doch! Der Timer speichert verschlüsselt die Uhrzeit --> Wenn die entschlüsselte Uhrzeit (z.B. aufgrund einer Änderung) nicht sein kann --> Block

Cyberdyne

Zitat von Ineluki

Timer wirken meiner Meinung nach doch!

Hmm...

Zitat von Ineluki

Der Timer speichert verschlüsselt die Uhrzeit

Ok du speicherst die Uhrzeit 01.01.2010 in "filename.fileextension"
==> Der user kopiert nach dem ersten Programmstart die Datei "filename.fileextension" und speichert sie in "filename_kopie.fileextension"

Zitat von Ineluki

Wenn die entschlüsselte Uhrzeit (z.B. aufgrund einer Änderung) nicht sein kann --> Block

1 Monat später wenn das Programm eigentlich nicht mehr funktionieren darf.
VOR Programmstart:
===> Der user überschreibt "filename.fileextension" mit "filename_kopie.fileextension"
===> Der user stellt die Systemzeit auf 01.01.2010 (Änderung!!!)
Programm wird gestartet
Programm schaut auf Systemzeit => 01.01.2010
Programm schaut auf die verschlüsselte Uhrzeit => 01.01.2010
Alles OK Programm starten.
(kein Block)

Redclaw

Hi
nimm doch einfach doch die Windows-Uhr nur speicher die Zeit bei der Installation nicht einfach in ner config datei sondern, im Programm selbst , also als anhang an die .exe oder bastel den TimeStamp in Header um, oder eine geeignete .dll glaube kaum das da jemand nach dem, Datum suchen würde. Das Problem welches allerdings immer besteht sofern du keine Registry-Einträge möchtest und wenn du das nicht willst nehm ich an, dass dein Prog auch sonst keine Spuren hinterlassen soll, ist folgendes, nach einer Neuinstallation kann man es wieder über den vollen Zeitraum nutzen. Da lässt sich glaub ich nix machen es sei denn du modifizierst auch die Install-Datei an sich, aber auch dann neuer Download und alles wieder im Eimer.

naja mfg
Redclaw

misterspeed

Man könnte ganz am Anfang vor allen anderen Prüfungen auch auf Manipulationen der Systemzeit prüfen. Dazu sollte es ausreichen eines der Windows Systemverzeichnisse nach der neuesten Datei abzusuchen und die "angebliche" Systemzeit damit zu vergleichen. Liegt das Datum der neuesten System-Datei in der Zukunft wurde die Systemzeit manipuliert. Dies sollte nur durch ein Komplettbackup der Windowsinstallation umgehbar sein. Achtung man müsste ggf. die Winter/Sommer Zeitumstellung berücksichtigen bzw. die Prüfung an diesen Tagen aussetzen.

Diese Prüfung kann auch mit einem fortlaufendem Counter kombiniert werden. Wie oben schon vorgeschlagen wurde könnte man in einer verschlüsselten Datei bei jedem Programmstart Informationen ergänzen. Hier wäre dann auch das hinterlegen des Datums einer bestimmten Systemdatei möglich welches sich bei jedem Windowsstart verändert. Sollte das gespeicherte Datum plötzlich in der Zukunft liegen wurde die Systemzeit zurückgestellt. Wenn das gespeicherte Datum deutlich veraltet ist und mehrere Tage vom realen Datum der Sytemdatei abweicht wurde ein Backup der verschlüsselten Datei verwendet.

Um es dem ein oder anderen noch schwerer und lästiger zumachen einen Kopierschutz zu umgehen kann man auch noch eine selfdelete Funktion einbauen die zusätzlich noch eine Datei "neverRunAgain.sys" in einem Systemverzeichnis versteckt. Spielt der User einfach ein Backup des Programms zurück könnte man im Kopierschutz auch auf die existenz der versteckten Datei prüfen. Wird diese gefunden weiss das Programm dass bereits in der Vergangenheit versucht wurde den Kopierschutz zu umgehen und führt die selfdelete Funktion aufs neue aus. Man müsste im Updater der die Laufzeit verlängert also die Löschung der versteckten Datei veranlassen, da sonst auch nach einem Update keine weitere Nutzung mehr möglich ist.

Wer noch andere Ideen hat immer her damit, ich arbeite selbst an einem Kopierschutz/Lizenzsystem um die Nutzdauer einzuschränken.

EDIT:

Hier ein kleines Script das ich mal aus langeweile geschrieben hatte und so wohl eher nicht Teil meines Kopierschutzes werden wird, sondern letzten Endes mehr der Vorgänger einer uninstall Routine war.
Achtung: Nur ausführen wenn sich im Scriptdir keine Datei namens "copyprotectV0.2.exe" befindet. Ansonsten vorher die Funktion selfdelete() auskommentieren.

Spoiler anzeigen

[autoit]

#Include <File.au3>
#Include <Array.au3>
#include <GUIConstantsEx.au3>
#include <WindowsConstants.au3>
#include <EditConstants.au3>
#include <StaticConstants.au3>