Updates und "Diebstahlschutz"

[Jan]

Ich mache mir gerade Gedanken darüber, wie ich Programme am besten unter die Leute bringe und bei denen dann auf dem aktuellen Stand halte. Mir geht es dabei hauptsächlich um die Punkte: Wie vermeide ich schwarzkopieren der Kunden, und wie bekommen die am besten Updates.

Gegen Kopieren gibt es ja u. a. Dongles (macht Tom das nicht damit?). Ich habe auch schon Key-Dateien gesehen, und personalisierte Kopien, wo dann auf den Ausdrucken unveränderbar z. B. der Kundenname drauf steht (was sich bei geklauten Kopien dann natürlich schlecht macht). Was gibt es sonst noch für Möglichkeiten? Was sind die Vor- und Nachteile jeweils?

Außerdem das Problem der Updates. Da gibt es für mich 2 unterschiedliche Dinge: Einmal das Programmupdate, und dann ein Update von grundlegenden Daten (Preislisten von Liefernaten, etc.). bei den Daten stelle ich mir das (relativ) einfach vor: Das Programm ruft im Internet eine Datei auf, kontrolliert das Datum, und wenn neuer als die gespeicherte Version runterladen.

Beim Programmupdate sehe ich das schwieriger. Ich kann ja nicht einfach das laufende Programm mit einer aktuelleren Exe überschreiben. Ich habe schon daran gedacht, eventuell die Exe als kleines Startprogemm zu gestalten, das nichts anderes macht als nach Updates zu prüfen, und der gesamte funktionale Programmcode ist einer dll steckt, die dann einfach updaten kann. Ginge das? Oder gibt es elegantere Möglichkeiten (gibt es bestimmt )?

Jan

[urbi]

Hallo Jan,

ich glaube Dongle ist nicht mehr Zeitgemäs
der Kunde erhält eine Verschlüsselte Registrierungs-Datei die nach Installation im Programm
eingelesen wird die Datei enthält Registriernummer, Kundenname und einen Schlüssel der einzelne
Programmmodule frei gibt. Beim einlesen wird auch gleichzeitig die Nummer der Festplatte ausgelesen. Das Ergebnis wird in die Registrierung-Datei zurück geschrieben und bei jedem Programmstart verglichen. Ohne diese Registrierung meldet sich das Programm als Testversion.

Bein Kopieren auf einen anderen Rechner wird die registrierte Festplattennummer dann nicht mehr erkannt. Hat sich bei mir schon zu Clipper Zeiten bewährt

Das Progrann-Update würde ich nicht aus dem laufenden Programm heraus ausführen, der Anwender
sollte automatisch Info über Update bekommen und dann Update ausführen.

Ich hänge an meine EXE einen String der Version und Compilierzeit enthält z.b Version xx.xx
Rev. DOY()+LEFT(TIME(),2) also Tag Stunde


Das Programm prüft beim Start auf dem Server ob aktuellres Update vorhanden und Bietet Update zum Download an

Gruss URBI

[Rolf Ramacher]

Hallo Jan,

Dongels würde ich auch nicht mehr machen. Wobei ich gar nicht weiß, ob die unter XP überhaupt noch funktionieren. Aber die Festplatten-ID abzufangen ist eine gute Idee. Aber aufpassen dabei mußt du, wenn das Programm im Netz läuft und Win98-Client vorhanden sind, der erkennt dann vom Festplatten-Laufwerk die ID nicht.

[Martin Altmann]

Hallo allerseits,
das ist nicht zuletzt auch eine Frage der Kosten. Wenn die Software nur einige 100 Euro kosten soll, würde ich auf den Dongle auch verzichten.
Wir nutzen jedoch Dongle (Window 98/ME/XP/2000/NT) und haben damit nur gute Erfahrungen gemacht....

Viele Grüße,
Martin

[Jan]

Hallo Martin,

Bank oder EasyDog?

Und war da nicht auf der DevCon auch ein Vortrag in die Richtung? Wenn das man bloß nicht mehr so lange hin wäre ...

Jan

[Jan]

Mal 'ne Frage wegen Festplatten-ID: Was macht man, wenn der User seinen Rechner plattenmäßig umrüstet oder sich einen komplett anderen Rechner zulegt? Muß er sich dann von mir einen neuen Schlüssel besorgen? Ist das nicht etwas umständlich für mich und den Kunden?

Jan

[Martin Altmann]

Hallo Jan,
Easydog.
Thema DevCon: Soweit ich das sehe "nur" das Verteilen/Updaten, nicht jedoch das Schützen...

Viele Grüße,
Martin

[urbi]

die Registrierungs Datei ist bei mir Personalisiert und muss bei Wechsel
der Platte oder PC neu eingelesen werden. Notfalls fordert der Kunde eine neue Reg-Datei an.
Bin gerade am überlegen in solchen Fall die Registrierung online vorzunehmen, und welche Sicherungen da am besten greifen könnten. z.B vorhadene Registrierung zu Server senden prüfen und zurück zu neuregistrierung. läst sich mit WAA recht einfach und komfortabel lösen.
[/list][/list][/code]

[AUGE_OHR]

hi,

Mal 'ne Frage wegen Festplatten-ID: Was macht man, wenn der User seinen Rechner plattenmäßig umrüstet oder sich einen komplett anderen Rechner zulegt? Muß er sich dann von mir einen neuen Schlüssel besorgen? Ist das nicht etwas umständlich für mich und den Kunden?

Naja der User muss ja dann auch seine M$ Produkte neu aktivieren
also kann er das auch für seine Xbase++ Applicationen tun.

Ich schütze übrigens nicht mehr meine Application sondern meine Daten.
Eine Application kann man wechseln, die Daten wird man aber immer brauchen.
ohne eine passenden Schlüssel startet zwar scheinbar das Programm
aber irgendwann stellt man fest das die Daten nicht richtig entschlüsselt
werden und man somit nichts richtiges damit anfangen kann.

gruss by OHR
Jimmy

[Martin Altmann]

Hallo Jimmy,
ein interessanter Ansatzpunkt - nur leider stehst Du damit auf schwachen Beinen!
Es gibt bereits entsprechende Gerichtsurteile dazu: Auch wenn man Dein Programm gekauft hat und verwendet - die Daten gehören dem Nutzer! Will er zukünftig die Daten mit einem anderen Produkt verwalten, bist Du als Entwickler verflichtet, dem Nutzer Zugriff auf seine Daten zu geben - und zwar kostenfrei!

Viele Grüße,
Martin

[AUGE_OHR]

hi,

ein interessanter Ansatzpunkt - nur leider stehst Du damit auf schwachen Beinen!
Es gibt bereits entsprechende Gerichtsurteile dazu: Auch wenn man Dein Programm gekauft hat und verwendet - die Daten gehören dem Nutzer! Will er zukünftig die Daten mit einem anderen Produkt verwalten, bist Du als Entwickler verflichtet, dem Nutzer Zugriff auf seine Daten zu geben - und zwar kostenfrei!

Yup klar, aber es kommt auch auf die Lizenz Vereinbarung an.

Eine verschlüssellung ist für den Kunden, als Arbeitgeber, auch gegenüber
dritten incl. eigener Mitarbeiter wichtig. Nur eine "geschütze" Datei ist
auch Schutz würdig.

Zum verschlüsseln/entschlüsseln braucht man 2 Schlüssel. Während sich
1st. Schlüssel sich bei der Installation ergibt ist der 2st Schlüssel eine
Art Korrektur so wie bei GPS Daten. Beim ersten Start der Application
werden beide Schlüssel abgefragt und auf die verschlüsselung hinge-
wiesen und das die Daten "inkonsistent" werden wenn man nicht beide
Schlüssel eingibt.

Wenn der 2st Schüssel nicht stimmt dann "verändern" sich die Daten der
der Ausgabe "scheinbar" bei jedem Start der Application. Statt eines
Charakter Zeichen wird dann in einem String ein oder mehrere "*"
angezeigt.

Solange der User keine Änderrungen vornimmt ergibt sich für den User
auch kein Problem da ich die Daten nicht verändere. Wenn der User
dann die Daten "ändert" weil ich ihm eine "falsche" Anzeige mache so
wird der neue WYSIWYG "ist" Zustand ( mit "*" ) gespeichert.

Code: Alles auswählen

cName := Decrypt(Kunden->Name)
...
@ x,y SAY cName
...
@ x,y GET cName
...
REPLACE Kunden->Name WITH encrypt(cName)

Dumm für dem "unregistrieten" User wenn er 1 Fehler korrigiert aber
einen weiteren "dreher" mit "*" nicht bemerkt da ja nun alles REPLACED
wird und er mehrfach beim abspeichern mit "JA" geantwortet hat.

Klar halte ich alle Änderungen im Logbuch fest damit ich a.) weiss wer /
wann/was geändert hat und b.) damit mein "Reparatur" Programm dann
die Daten wiederherstellen kann für "registriete" User als Service.

Ich (ver)ändere also keine Daten sondern zeige die bloss scheinbar
"falsch" an. Das selbe natürlich bei drucken und Export. Somit wird die
Application für einen richtigen Einsatz bedeutungslos, aber für eine Demo
reicht es und die Daten sind ja wie eingegeben unverändert vorhanden.

Allerdings mache ich das ganze nur bei Stammdaten wo ich nach dem
anlegen gewöhnlich nicht mehr soviel ändere gegenüber Bewegungsdaten.

gruss by OHR
Jimmy

[andreas]

Hallo Jan,

ich habe dafür auch mal eine Lösung ausgedacht, die zwar von dem Diebstahl vielleicht nicht 100% schützt, aber ..

1. Das Programm kann ganz normal kopiert und benutzt werden. Damit ist es eine Demo-Version, die beim Start eine Meldung raus gibt und nach 30 min sich beendet. D.h. alle 30 Minuten muss die Datei neu gestartet werden.
Im Demo-Modus kann überprüft werden, ob ein Update vorhanden ist, kann aber nicht automatisch Updates ziehen.

2. Die personalisierte Lizenz-Datei enthält verschlüsselte Daten. Diese Datei muss im Programm eingelesen werden. Damit ist der Demo-Modus deaktiviert. Die Updates funktionieren. Hier kann natürlich jetzt das Programm Raubkopiert werden. Interessant wird es aber beim Update.

3. Update. Update wird über das Internet abgewickelt und ist mit Hilfe von ASINET und Socks gelöst. Das Programm fragt bei meinem Server ab, ob es Updates gibt. Wenn JA, gibt mein Programm den FTP-Server mit Anmelde-Daten und Dateinamen zurück, die runtergeladen werden soll.
Dabei wird die Lizenznummer und Name des Kunden aus der Lizenz-Datei auf meinem Server hinterlassen. Hier wird auch ein Name aus den Einstellungen übergeben, der für alle Ausdrucke als Adresse hinterlegt ist.
Diese Log-Daten kann ich kontrollieren oder automatisch auswerten und bei der Lizenz die Updates sperren. Beim nächsten mal gibt es wohl keine Updates auch für den Kunden der die Lizenz gekauft hat. Damit wird der Kunde erstmal auch bestraft, wenn er seine Lizenz weitergibt oder unsicher aufbewahrt. Hier muss dann eine neue Lizenz ausgestellt werden, was vielleicht auch bezahlt werden muss.

Ich weiss nicht, ob das der richtige Weg ist, aber das habe ich mir erstmal so ausgedacht und umgesetzt, zumindest erstmal in meinem Testprogramm. Ob es funktioniert, kann noch nichts dazu sagen, da das Programm noch in Entwicklung ist.

[Jan]

Hallo Leute,

vielen Dank für die vielen Anregungen. Für mich kristallisiert sich da folgende Vorgehensweise heraus:

Ich denke, ich werde das mit einer Lizentdatei machen, in der die Kundendaten, die Seriennummer, und die sonstigen Einschränkungen/Freigaben (Staffelung max. Anzahl Datensätze) hinterlegt sind. Ohne diese Datei ist das Demo-Modus mit einer eingeschränkten Datensatzzahl, ausreichend zum Antesten.
Eine Weitergabe wird nicht möglich sein, weil auf jedem Ausdruck die hinterlegten Kundendaten (Name, Anschrift) in gefälliger Form mit angedruckt werden.

Soetwas ähnliches habe ich mal mit einem anderen Projekt gemacht, da hatte ich das allerdings in der exe hart codiert eingebaut. Was nicht besonders Wartungsfreundlich ist.

Mit den Updates werde ich mir etwas überlegen in der Richtung, wie Andreas das vorgeschlagen hat. Da muss ich mich aber noch reinfummeln, denn mit Asinet und Konsorten habe ich mich überhaupt noch nicht beschäftigt. Vielleicht ein Thema für unser XUG-Treffen?

Wo ich noch nicht ganz einig bin ist die Geschichte mit den Programmupdates. Wie ich das Überschreiben der alten Versionen managen kann. Da muß ich noch mal ein wenig Gehirnschmalz und Teststunden investieren, um da eine brauchbare und elegante Lösung zu finden.

Aber wenigstens habe ich schon mal eine Richtung bekommen, wo das langgehen muss.

Jan

[brandelh]

Hallo,

Früher gab es häufig Programme, in die der Entwickler den Lizenznamen und die Lizenznummer eingebrannt hatte. Bald fand man heraus, dass per Hexeditor der Name oder die Nummer leicht zu finden und zu ändern war.

Das liegt daran, dass Strings genauso gespeichert werden wie man sie sieht. Somit sollte man entweder die Strings zerhacken ("Egon" -> "E*g*o*n") oder insgesamt eine Prüfziffer darauf legen. Ich selbst habe sowas schon als 3 Gruppen des ASCII Codes gespeichert:
A -> "065".

[brandelh]

Nochwas zum Update ...

ich nutze ZIP Archive auf dem Webserver, die ich per LoadFromUrl() downloade. Diese werden dann mit der Funktion von Phils Homepage entpackt. Das hat 2 Vorteile:

1. weniger Daten
2. ZIP Archive bemerken Übertragungsfehler (CRC Prüfung beim Entpacken).

[Jan]

Hubert,

Das liegt daran, dass Strings genauso gespeichert werden wie man sie sieht

Deswegen hatte ich dafür Arrays angelegt. Alle Kunden waren immer in jedem Programm gespeichert, und zur Freigabe musste ich nur den Punkt im Array vor dem Kompilieren entsprechend ändern. Da gab es dann 1 Array für den ersten Buchstaben, eines für den 2., usw. Und in den kodierten Text habe ich dann reingeschrieben Array1 + Array2+... Da war mit Hexeditor rein garnichts mehr nachvollziehbar. Das hatte den Vorteil, daß ich die Kundendaten nicht jedesmal neu eintippen musste, einfach in einer LOCAL die Nummer ändern, das wars. Aber das war auch alles überschaubar. Bei dutzenden oder gar hunderten von Kunden wird das ganz schnell unübersichtlich und bläht die Exe maßlos auf.

Deswegen war mein Gedanke, die Geschichte mit der Lizenzdatei aufzugreifen. Die kann ich ganz schnell mit einem kleinen Kunden-Verwaltungsprogramm erstellen und dann dem Kunden zukommen lassen, und er kann einfach mit seiner Demo-Exe weiterarbeiten. Auch eine spätere Änderung der maximalen Satzzahl lässt sich so sehr unkompliziert bewerkstelligen durch einfaches Zusenden der geänderten kleinen Lizenzdatei.

Das mit dem LoadFromUrl(): Wie machst Du da die Kontrolle, ob der das überhaupt darf? Vielleicht ist ja seine Lizenz inzwischen abgelaufen. Dann darf der natürlich auch keine Updates mehr ziehen.

Jan

[Koverhage]

auch wir benutzen Dongles (WIBU-KEY) und haben damit keine Probleme.
Das Ding macht ja noch mehr. Ab einem gewissen Warentwert macht es auch Sinn, einen zeitlichen Ablauf (z.B. für Demos, oder dem Zahlungsziel der Rechnung) zu setzen. All diese Dinge sind richtig wirksam nur mit einem Dongle zu erreichen.
Fast jeder User ist heute in der Lage die Einträge in der Registry zu verändern, sodass dies keinen wirklichen Schutz darstellt.

[brandelh]

Das mit dem LoadFromUrl(): Wie machst Du da die Kontrolle, ob der das überhaupt darf? Vielleicht ist ja seine Lizenz inzwischen abgelaufen. Dann darf der natürlich auch keine Updates mehr ziehen.
Jan

Ich verkaufe nichts. Das Programm ist für eine Person frei, der Rest kommt nicht auf die Website (KW)

Aber wenn würde ich in den Updates z.B. eine 'Versionsnummer' einführen oder ein Updatedatum ... Das Programm würde dann prüfen ob die neue Versionsnummer bzw. Versionsdatum noch durch die Lizenzdatei abgedeckt ist:

2007010120073112+Prüfziffer ...

Updateversion 20080303 ... oh Lizenzdatei abgelaufen ....

Aber wie gesagt, das Problem habe ich nicht.

[Jan]

Hubert,

mir ist klar, daß Du nichts verkaufst. So war das auch nicht wirklich gemeint. Statt "Du" wäre vermutlich "man" oder "ich" besser gewesen. Ist aber letzendlich auch vollkommen egal.

Die Idee mit dem "Auslaufdatum" ist gut. Das ließe sich in der Programmlogik vermutlich auch relativ einfach umsetzen. Da muß ich mir mal LoadFromUrl() ansehen, in wie weit das Parameter verträgt für eine Prävalidierung. Ansonsten gibt es eben eine Postvalidierung nach dem Runterladen. Nicht so elegant, aber der Kunde soll sich ruhig schwarzärgern, daß er seine Lizenz nicht verlängert hat

Insgesamt habe ich ja noch überhaupt nichts entsprechendes umgesetzt. Mir ging es darum mal zu sehen, was überhaupt machbar ist und was so allgemein eingesetzt wird. Und da bin ich jetzt doch ein ganz großes Stück weiter. Aber ab nächster Woche habe ich Urlaub, und meine Frau ist schon vorgewarnt, daß ich einen Großteil der Zeit mit meinem Laptop auf der Terrasse sitzen werde . Da werde ich mich dann auch an die Umsetzung dieser ganzen Problematik machen. Mal sehen, wie das klappt

Jan

[Rolf Ramacher]

Hallo Jan,

na wenn deine Frau sich das gefallen läßt, daß du auf der Terasse sitzt und programmierst. Da solltest du lieber die Terasse säubern.

[Jan]

Da solltest du lieber die Terasse säubern.

Das mach ich doch sowieso regelmäßig. Dafür brauch ich keinen Urlaub.

Jan

[Jan]

Hallo noch mal,

wegen der 2. Frage mit dem Update: Ich hab mich mal mit LoadFromUrl() beschäftigt und einen guten Weg gefunden, das einzusetzen. Außerdem habe ich ja das ganze Projekt in einzelne .dll augeteilt weil ich dachte, damit laufen die Updates reibungsloser. Das stimmt auch soweit, als ich nur noch Teilstücke der Gesamtapplikation runterladen muß. Aber ich bekomme die Updates nicht in das Programmverzeichnis kopiert. Windows lässt ein Löschen der vorhandenen älteren .dll nicht zu.

Hat da jemand eine gute Idee zu?

Jan

[Martin Altmann]

Hallo Jan,
soweit ich das von Anderen gehört habe, soll ein Umbenennen der alten DLL-Dateien, die in Benutzung sind, gehen!
Also umbenennen und die neue reinkopieren.

Viele Grüße,
Martin

[Jan]

Moin Martin,

jawoll, das funktioniert. Ist ja lustig: Löschen ist nicht, aber umbenennen schon. Was soll denn das? Weg ist die doch für das Programm so oder so.

Aber da gibt es prompt die nächste Frage. Wenn ich die .dll runterlade, wird automatisch das Datum der Datei verändert, auf das Erstelldatum auf dem lokalen Rechner. Das lässt sich bei LoadFromUrl() anscheinend auch nicht ändern, weil nicht die Datei als ganzes zurückgegeben wird sondern deren inhalt. Ich mach das jetzt so: Runterladen, neue Datei erstellen, Inhalt reinschreiben, Datei schließen. Jetzt müsste ich eigenlich nur noch das Datum und die Uhrzeit der Datei ändern. Unter Linux gibt es da nette Bordmitel, aber DOS/Windows scheint sowas nicht zu bieten.

Jan

[Wolfgang Ciriack]

Hallo Jan,
warum erstellst du nicht auch mit InnoSetup eine Updateversion mit den benötigten Daten und installierst das Update mit beenden deines Programms, dann hast du keine Probleme mit dem Austauschen von Dateien.

Code: Alles auswählen

if lUpdate
   Runshell("", "downloads\myupdate.exe",.T.")
endif
QUIT