Eigenes Lizenzierungssystem (Server <--> Client)

  • VB.NET

Es gibt 21 Antworten in diesem Thema. Der letzte Beitrag () ist von BiedermannS.

    Eigenes Lizenzierungssystem (Server <--> Client)

    Da hier in letzter Zeit ein paar mal die Frage nach Lizenzierungssystem gekommen ist, möchte ich euch hier mal meine Idee vorstellen und schauen was Ihr davon haltet.

    Man erstellt über RSA zwei Schlüssel-Paare. Das eine verschlüsselt die Kommunikation zum Server, das andere verschlüsselt die Kommunikation zum Client.

    Nun fügt man dem Client drei Schlüssel als Ressource hinzu. Den öffentlichen Schlüssel des Servers sowie den privaten und öffentlichen Schlüssel des Clients.


    Die Überprüfung, ob ein Produkt Lizenziert wurde erfolgt über ein Key-File, welches mit dem Öffentlichen Schlüssel des Clients verschlüsselt wird.

    Ist dieses KeyFile nicht vorhanden, wird eine verschlüsselte Verbindung zum Server hergestellt, über die man den Lizenzkey und evtl. noch andere Informationen überträgt. Der Server meldet dann verschlüsselt zurück, ob die Aktivierung gültig ist oder nicht.

    Ist die Aktivierung gültig, werden Systeminformationen verschlüsselt in die Keyfile eingetragen. Nur wenn diese mit den aktuellen Werten übereinstimmen, kann das Programm gestartet werden.


    Zum Schutz der Ressourcen, sowie der Prüflogik, habe ich das Programm Confuser verwendet.

    Im Anhang gibt es ein Demo-Projekt. RemotingVB.7z
    Vorkompilierter Server: .\RemotingServer\bin\Debug\LoggingServer.exe
    Vorkompilierter und geschützter Client: .\RemotingClient\bin\Debug\Confused\TestClient.exe

    Test-Activation Key = ACTIVATE

    Was sagt Ihr dazu? Gibt es noch Schwächen, die ich nicht beachtet habe?

    Edit: Eine Kopie vom Confuser liegt in dem Archiv bei. Confuser-Projektdatei liegt im Hauptordner des RemotingClient.
    SWYgeW91IGNhbiByZWFkIHRoaXMsIHlvdSdyZSBhIGdlZWsgOkQ=

    Weil einfach, einfach zu einfach ist! :D

    habs noch nicht recht verstanden

    BiedermannS schrieb:

    ... wird eine verschlüsselte Verbindung zum Server hergestellt, über die man den Lizenzkey und evtl. noch andere Informationen überträgt. Der Server meldet dann verschlüsselt zurück, ob die Aktivierung gültig ist oder nicht.

    Ist die Aktivierung gültig, werden Systeminformationen verschlüsselt in die Keyfile eingetragen. Nur wenn diese mit den aktuellen Werten übereinstimmen, kann das Programm gestartet werden.
    Das klingt so, als ob der Client selbst die SystemInfos ins Keyfile einträgt.
    Aber wennerdas kann, dann kann er das File ja auch sonstwie manipulieren.

    ErfinderDesRades schrieb:

    Das klingt so, als ob der Client selbst die SystemInfos ins Keyfile einträgt.

    Ist auch tatsächlich so. Der Client speichert einfach verschlüsselte Informationen zu dem System auf dem er sich befindet, die beim nächsten Start wieder überprüft werden, um sicherzustellen dass man das Programm nicht einfach mit dem Key-File weiterkopiert.

    Die Funktion zum Entschlüsseln bzw. Verschlüsseln sowie die Keys die zum Verschlüsseln notwendig sind, sind jedoch vom Obfuscator verschlüsselt und somit auch nicht für andere zugänglich. (Confuser macht hier saubere Arbeit)

    Dadurch kann nur der vom Programmierer bereitgestellte Client, das KeyFile auslesen bzw. ändern. Von ausserhalb ist das Ganze nicht (ohne erheblichen Aufwand) möglich.
    SWYgeW91IGNhbiByZWFkIHRoaXMsIHlvdSdyZSBhIGdlZWsgOkQ=

    Weil einfach, einfach zu einfach ist! :D

    @ThuCommix: Es gibt auch noch ander Obfuscatoren, die bessere Möglichkeiten bieten.

    Edit: Ich bin zwar schlecht im Umgang mit Fluss-Diagrammen, aber ich hab mal versucht eines zu erstellen.
    SWYgeW91IGNhbiByZWFkIHRoaXMsIHlvdSdyZSBhIGdlZWsgOkQ=

    Weil einfach, einfach zu einfach ist! :D

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „BiedermannS“ ()

    also ich seh 3 Möglichkeiten, das zu cracken - alle im Zusammenhang mit Dekompilierung:
    1. iwie einen alternative Sever hinterlegen, der immer "TRUE" antwortet.
    2. den Algo auspuhlen, mit dem das KeyFile generiert wird, und ein ebensolches KeyFile für den illegalen Rechner erstellen
    3. Die Abfrage(n) nach dem KeyFile abklemmen
    Mir scheint, das KeyFile muß niemals jemals entschlüsselt werden - es reicht, wenn der Client aus seinen SystemDaten Werte generiert, die identisch sind mit denen, die im KeyFile vorliegen.
    In diesem Sinne handelt es sich eher um eine Art "Schlüssel-Ableitung" aus den SystemDaten. (Gugge auch "Authentifizierung" in Verschlüsseln + Autentifizieren)

    Damit ist nur noch Punkt 2 und 3 gültig. Keines von beiden bekommt der standard User hin. Wir müssen ja schon längst nicht mehr diskutieren, das irgendwas sicher ist. Es geht nurnoch darum, das es nicht jeder kann ;)


    Täusche ich mich da?


    Ja, der Tauschserver hat den Private Key nicht.

    ErfinderDesRades schrieb:

    iwie einen alternative Sever hinterlegen, der immer "TRUE" antwortet.

    Hierfür würde der alternative Server, den Public Key des Client brauchen, um das "TRUE" so zu verschlüsseln, dass der Client das auch entschlüsseln kann, sonst gibts keine Aktivierung.

    ErfinderDesRades schrieb:

    den Algo auspuhlen, mit dem das KeyFile generiert wird, und ein ebensolches KeyFile für den illegalen Rechner erstellen

    Dazu müsstest du alle Schutzmechanismen des Obfuscators umgehen, damit du an das KeyFile und an die Methode kommst mit der das File generiert wird.

    ErfinderDesRades schrieb:

    Die Abfrage(n) nach dem KeyFile abklemmen

    Dazu müsstest du alle Schutzmechanismen des Obfuscators umgehen. Hier kommt es halt auf die Qualität des Obfuscators an. (z.B.: Themida. Kostet zwar, aber das bekommt so schnell keiner auf...)

    ThuCommix schrieb:

    Ja, der Tauschserver hat den Private Key nicht.

    Hier werden keine Schlüssel zwischen Server und Client ausgetauscht. Die Key's sind immer gleich.

    Was vl noch gemacht werden sollte, wäre das Austauschen der Key-Files, alle paar Versionen. Die Update Routine muss sich halt darum kümmern, dass das Key-File mit dem alten Key entschlüsselt wird und mit dem neuen wieder verschlüsselt wird, sonst müsste der Kunde die Aktivierung erneut durchführen...
    SWYgeW91IGNhbiByZWFkIHRoaXMsIHlvdSdyZSBhIGdlZWsgOkQ=

    Weil einfach, einfach zu einfach ist! :D

    Eigentlich eine gute Idee, den benötigten Client-Public-Key mit dem Server-Public-Key verschlüsselt zu senden...
    Aber bindet dich natürlich an einen festes Key-Paar auf der Serverseite, sonst müsstest du ja eine Option einbauen,
    einen "eigenen" öffentlichen Schlüssel zu verwenden und sprengst dir damit wieder die Sicherheit.

    Grundsätzlich musst du also schon das Einschleusen eines feindlichen Schlüssels unterbinden, sonst kriegt der mein Paar und mein Server sagt dann Guten Tag ;)

    ThuCommix schrieb:

    kommt da auch jeder ran

    In diesem Fall nicht. Am Server sind alle Keys gespeichert, aber nicht öffentlich zugänglich.

    Beim Client sind drei Keys gespeichert:
    Client-Private
    Client-Public
    Server-Public

    Diese drei Keys sind als Resource in die EXE eingebettet. Und die Resourcen werden vom Obfuscator verschlüsselt.

    Um also an einen der Keys zu kommen, müsste man entweder die Obfuscation rückgängig machen oder den Server (Nicht die Server Applikation, sondern den Ganzen ^^) hacken.

    Im Server ist bereits eingebaut, dass bei fehlerhaftem Input (Unverschlüsselte oder falsch verschlüsselte Strings bzw. Allgemein Exceptions während der Übertragung) ein leerer String zurückgesendet wird.

    noBlubb schrieb:

    Eigentlich eine gute Idee, den benötigten Client-Public-Key mit dem Server-Public-Key verschlüsselt zu senden...

    Könnte man auch machen, bringt aber in diesem Fall nicht mehr Sicherheit.

    Das einzige was gesendet wird ist, der Verschlüsselte Lizenzkey an den Server. Diesen kann auch nur der Server entschlüsseln. Und die verschlüsselte Bestätigung vom Server an den Client, welche nur der Client entschlüsseln kann...


    Edit: Für alle die es testen, cracken, whatever.. möchten.
    Diese Dateien liegen am Server Server.7z
    Diese bekommt der Client Client.7z

    Momentan liegen die Key-Files noch offen beim Server, diese können allerdings auch ganz leicht als Ressource eingebunden und per Obfuscator verschlüsselt werden. Das erstellen der Key-Files ist momentan auch im Server eingebaut. Wenn keine Key-Files vorhanden sind, erzeugt der Server neue. Diese müssen allerdings in den Client einkompiliert werden.
    SWYgeW91IGNhbiByZWFkIHRoaXMsIHlvdSdyZSBhIGdlZWsgOkQ=

    Weil einfach, einfach zu einfach ist! :D

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „BiedermannS“ ()

    BiedermannS schrieb:

    Hierfür würde der alternative Server, den Public Key des Client brauchen, um das "TRUE" so zu verschlüsseln, dass der Client das auch entschlüsseln kann, sonst gibts keine Aktivierung.

    also ich kenne mich mit sniffen ühaupt nicht aus, stelle mir aber vor, man snifft mal sone Aktivierung mit, insbesondere die Byte-Folge, die dein Server antwortet.
    Jo, und dann einen Server aufsetzen, der genau dasselbe antwortet :D



    Also ich täte vorschlagen, der Client hat den PublicKey vom Server. Und zur Aktivierung generiert er ein RSA-Schlüsselpaar (Private-/Public Key). Dann verschlüsselter mit dem PublicKey des Servers den Lizenzschlüssel und seinen eigenen PublicKey, schickt beides dem Server, und der Server verschlüsselt sein Ok mit dem mitgelieferten Client-PublicKey.

    So hat mans in einem Hin-Her abgehandelt - eine richtige TLS-Kommunitkation zu verknüppern geht über meinen geistigen Horizont (weil ich mit die Zertifikate nicht klarkomme :()



    Wassich bei deim Ansatz nicht verstehe, wozu der Client ein festverdrahtetes RSA-Schlüsselpaar braucht. Wie gesagt: sonKeyFile muss niemals jemals entschlüsselt werden.


    Edit: Wichtig wäre auch, dass der Server immer iwas zurückschickt - egal welches Fail eintritt. Damit ein Angreifer auch aus den Fails keine Schlüsse ziehen kann.

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „ErfinderDesRades“ ()

    ErfinderDesRades schrieb:

    und dann einen Server aufsetzen, der genau dasselbe antwortet

    Das ist allerdings richtig.

    Mann könnte nun eine einfaches System bauen, welche die HardwareID des Prozessors mitsendet, diese wird in der Antwort einfach wieder zurückgesendet und der Client gleicht diese dann mit der tatsächlichen HardwareID ab.

    Somit kann man die Aktivierung nur auf dem gerät umgehen, auf dem man den Netzwerkverkehr mitgesnifft hat.
    SWYgeW91IGNhbiByZWFkIHRoaXMsIHlvdSdyZSBhIGdlZWsgOkQ=

    Weil einfach, einfach zu einfach ist! :D

    Nur die Prozessor-ID auslesen ist ein weniger unsicher!
    Gibt so viele Rechner mit den Selben Prozi!

    Würde da eher was ausn Bios auslesen und vllt MAC-Adresse noch und dann bei allen zusammen nen Hash generieren lassen:)

    Naja, trotzdem wird eine UniqueID gebraucht, sonst könnten alle die die selbe ID haben, das selbe Keyfile nutzen.

    Aber dass jemand all dass gleich hat wie ein anderer ist glaub ich sehr unwahrscheinlich:
    Spoiler anzeigen

    VB.NET-Quellcode

    1. Dim strProcessor As New System.Text.StringBuilder()
    2. Dim query As New SelectQuery("Win32_BaseBoard")
    3. Dim search As New ManagementObjectSearcher(query)
    4. Dim info As ManagementObject
    5. For Each info In search.Get()
    6. strProcessor.Append(String.Concat(info("Product").ToString(), info("SerialNumber").ToString()))
    7. Next
    8. query = New SelectQuery("Win32_Processor")
    9. search = New ManagementObjectSearcher(query)
    10. For Each info In search.Get()
    11. strProcessor.Append(info("processorID").ToString())
    12. Next
    13. query = New SelectQuery("Win32_BIOS")
    14. search = New ManagementObjectSearcher(query)
    15. For Each info In search.Get()
    16. strProcessor.Append(info("SerialNumber").ToString())
    17. Next
    18. query = New SelectQuery("Win32_DiskDrive")
    19. search = New ManagementObjectSearcher(query)
    20. For Each info In search.Get()
    21. strProcessor.Append(info("PNPDeviceID").ToString())
    22. Next
    23. query = New SelectQuery("Win32_IDEController")
    24. search = New ManagementObjectSearcher(query)
    25. For Each info In search.Get()
    26. strProcessor.Append(info("DeviceID").ToString())
    27. strProcessor.Append(info("PNPDeviceID").ToString())
    28. Next
    29. '
    30. sha.Initialize()
    31. Dim UniqueID As String = String.Empty
    32. UniqueID = Convert.ToBase64String((sha.ComputeHash(System.Text.Encoding.Default.GetBytes(strProcessor.ToString))))

    :D

    Hab nun einen Zeitstempel auch mit angefügt.
    Link
    SWYgeW91IGNhbiByZWFkIHRoaXMsIHlvdSdyZSBhIGdlZWsgOkQ=

    Weil einfach, einfach zu einfach ist! :D

Facebook
Telefonspende