Generierung einer eindeutigen MachineID (Diskussion)

[Luckie]

Puh, wenn die Unit schon angehängt ist, dann musst du sie doch nicht noch mal posten mit ihren fast 900 Zeilen.

Wir hatten übrigens schon einige Threads zu dem Thema und sin bisher immer zu dem Ergebnis gekommen, dass dies nicht möglich ist.


[edit by Daniel]
Der von luckie angesprochene Thread: http://www.delphipraxis.net/internal...=438445#438445
[/edit by Daniel]

[edit=Admin]Link eingefügt. Mfg, Daniel[/edit]

[BenjaminH]

Und das Problem ist wohl, das ein MD5 Hash eben nicht einmalig ist, sondern so gedacht ist, dass Kollisionen gut möglich sind, also lässt sich ein PC dadurch wohl nicht wirklich eindeutig identifizieren.

[neuronet]

Also, ich nutze die Unit zusammen mit einer Online-Datenbank zur Softwarelizenzierung und hier hat sie bisher verdammt gute Dienste geleistet, insbesondere da der Hash-Wert auch zur Ver- und Entschlüsselung der in der Registry abgelegten Lizenzierungsdaten genutzt wird.

[Luckie]

Neuer Prozessor und/oder neue Festplatte und das war es dann gewesen.

[neuronet]

Dies ist den Kunden bekannt, und an den Systemem, auf denen die Software installiert wird, ändert sich sowieso nix (oder sehr sehr sehr selten, und dann kann nach Rücksprache eine Neulizenzierung erfolgen).

[neuronet]

@Luckie: Sorry, wegen des kompletten Postings... Werde mich nächstes Mal zurückhalten... :cry:

[brechi]

wirklich sicher ist das ding aber auch nicht oder? in nen paar minuten könnte ich ein programm schreiben was die ID faked.

Da bringt dann auch der DebuggerKiller usw. nichts ;)

[neuronet]

Wenn Du meine Software installiert hast, dann weisst Du nicht genau, welche Informationen ich zum Generieren des Hash-Wertes verwende.
Dann werden diese Informationen bei jedem Programmstart mit der Online-Datenbank abgeglichen.
Ist so eigentlich sicher genug...

[shmia]

Vorschlag: Bitte die Funktionen für die MD5-Berechnung und die Systeminformation in zwei getrennte Units verteilen.
So kann dann jede Unit unabhängig voneinander getestet und verwendet werden.

[neuronet]

@shmia: Wir gemacht...

[neuronet]

Hier nun die endgültige Fassung, ich der die Units hwid und md5 getrennt wurden.

Viel Spaß damit!!!

[omata]

Moin,

also bei mir klappt das überhaupt nicht. Ich bekomme nur Fehler.
Ich habe mir das mal genauer angesehen und festgestellt, dass ich kein BiosDatum in der Registry habe. Eigentlich wird das ja durch einen try ... except Block abgefangen, knallt aber trotzdem und so heftig das keine ID berechnet wird.

Ausserdem habe ich festgestellt, dass die Generierung ziemlich viele Speicherlecks hat. Als ich das sah, hatte ich keine Lust mehr mich weiter damit zu beschäftigen.

MfG
Thorsten

[negaH]

Zitat:

Wenn Du meine Software installiert hast, dann weisst Du nicht genau, welche Informationen ich zum Generieren des Hash-Wertes verwende.

Wie kommst du zu dieser Aussage ?
Sorry aber manchmal verstehe ich die Welt nicht mehr. DU bist ein Programmierer also müsstes ausgerechnet DU sehr genau wissen wie DEINE Sourcen durch den Compiler in einem Maschniencode übersetzt werden und wie DU diesen Code wieder durch einen Disassembler quasi lesbar machen kannst. Es entsteht zwar dann nicht 1 zu 1 der originale Source, aber das juckt einen erfahrenen Reverse Engineer überhaupt nicht.
Ergo, in dem Moment wo du deine Software auf einem unsicheren System kopierst musst du davon ausgehen das man sehr wohl weis aus welchen Werten sich deine Serial Nummer zusammensetzt.

Jetzt, unter Deiner falschen Annahme, hast du ein Sicherheistsystem deren wahre Sicherheit garnicht existiert. Du GLAUBST also es wäre sicher defacto muß es unsicher sein. Und exakt solche Systeme sind es die heutzutage noch permanent geknackt werden. Denn der Angreifer kann nur Systeme knacken in denen der Entwickler grobe Designfehler eingebaut hat.

Du kannst jetzt die "Kriegs-Spirale" weiter drehen lassen und wiederum nach dem Konzept "Security by Obscurity" mit allen möglichen Programmiertricks dein Verfahren komplizierter und schwerer verständlich machen. Aber bedenke bitte eines: diese Arroganz ist tödlich da du in diesem Falle immer nur davon ausgehst das DU schlauer als eine Gruppe von vielen Hackern bist die es sportlich sehen so schnell wie möglich zu verstehen was du da programmiert hast.

Reale Sicherheit ist aber vom analytischen Konzept her gesehen absolut wasserdicht, dem Abgreifer darf nicht die geringste Chance für einen Angriff gegeben werden. Der einzigste Angriff der zum Schluß übrig bleibt ist die Brute Force Attacke, und deren Komplexität wird einfach durch große Passwörter soweit in die Höhe gechraubt das man Millionen Jahre an dem Problem zu knacken hat.

Wenn du dir also vorstellst das du jedem deinen Source 1 zu 1 geben kannst und dann in der Lage bist analytisch nachzuweisen das unter diesen Voraussetzung keiner in der Lage ist dein System zu knacken, erst dann ist es sicher.

Gruß Hagen

[alzaimar]

Wenn man aber mit einem solchen System Programme sicher macht, die sowieso kaum Einer haben bzw. kopieren will, dann ist das Verfahren auch wieder sicher. ;-) Aber dann kann man es auch ganz sein lassen.

Ich würde mal so sagen, das Du in deine SW eine kleine Hürde eingebaut hast, die es dem Frickelkopierer und Kazaasauger von Nebenan etwas schwerer macht, deine SW zu klauen. Das kann ausreichen, weil es den Prozentsatz der schwarzkopierten SW leicht verringert. Ob das dann zu Umsatzsteigerungen führt, sei mal dahingestellt.

Entweder, man setzt auf die Ehrlichkeit der Kunden oder man sichert eine SW richtig. Wir branden jede SW, erzählen es dem Kunden aber nicht. Das ist zwar überhaupt nicht sicher, aber wir sind wenigstens in der Lage, eine unzulässigerweise kopierte Version zuverlässig der Quelle zuzuordnen bzw. eindeutig zu belegen, das das Branding gefaked ist (einfach, weil wir gar nicht so viele Versionen im Umlauf haben. Das reicht schon, um diesem 'Kunden' mal ins Gewissen zu reden. Man muss dazu sagen, das es sich hier nicht um Massenware handelt, sondern um Software, die einfach nicht an andere Abteilungen weitergegeben werden soll.

Nebenbei kann uns nichts Besseres passieren, als das ein blöder Kunde unsere SW massenhaft verbreitet. Dann schnappt die 'Falle' zu, wir verklagen ihn auf X mal Wert der Software und müssen dann nie wieder arbeiten. Wir haben aber keine blöden Kunden.

Ich persönlich bin übrigens kein Verfechter von Dongleware oder anderen Schutzmechanismen, ausgenommen einer passwortgestützten Installation. Damit sind die Fronten nämlich geklärt: Der pöse Purche, der die Software verbotenerweise installiert, gesteht mit Eingabe des geklauten Passwortes und Annahme der Eula, das er sich seiner 'Tat' bewusst ist.

Wir unterstellen unseren Kunden gnadenlose Ehrlichkeit, was man ruhig machen kann, wenn man ein gutes Produkt zu einem vernünftigen Preis anbietet. Wichtiger als die Kohle ist uns auch unser Ruf: Da ist es kontraproduktiv, mit irgendwelchen Seriennummern und Warnungen zu kommen, das die SW nicht läuft, wenn man die HD wechselt.

Merke: Ein Schutzmechanismus macht aus einer SW noch keine Killerapplikation. Das muss die SW alleine können.

In diesem Sinne,

viel Spass beim hacken und knacken.

Der Alz

[mschaefer]

Zitat:

Zitat von neuronet

Wenn Du meine Software installiert hast, dann weisst Du nicht genau, welche Informationen ich zum Generieren des Hash-Wertes verwende.
Dann werden diese Informationen bei jedem Programmstart mit der Online-Datenbank abgeglichen.
Ist so eigentlich sicher genug...

Da ist als Vorraussetzung, die Onlineverbindung. Das ist sicher nicht selbverständlich. Letzlich sicher wird Software ehedem nicht zu machen sein, deshalb ist die Lösung zumindest besser als nicht. Bin sogar der Auffassung, das Microsoft ohne die unsichere Software nie diesen Erfolg gehabt hätte.

Eigentlich wäre ich schon froh, wenn man Software so herrichten ´könnte, dass Sie nur von einem bestimmten Installationsmedium (USB-Stick mit Ident) installiert werden kann. Sonst sehe ich das eher wie Borland. Eine läuffähige Notsicherung gewährt den reibungslosen Weiterlauf der Arbeit und das kann man als Entwickler tolerieren.

Grüße // Martin

[neuronet]

@mschaefer:

Zitat:

Da ist als Vorraussetzung, die Onlineverbindung. Das ist sicher nicht selbverständlich.

Da es sich bei meiner Software um eine Lösung für Internet- und Telecafés handelt kann man wohl von einer vorhandenen Onlineverbindung ausgehen...

[alzaimar]

Neuronet: Deine Lösung ist ganz nett, aber sie ist eben nicht *sicher* im Sinne einer "Unhackbarkeit". Natürlich, nur sicher ist der Tod, aber ein anständiges Kryptoverfahren ist, praktisch gesehen, als sicher anzusehen.
Dein Verfahren ist unter diesem Gesichtspunkt nicht sicher. Punkt. Dessen musst Du Dir einfach bewusst sein. Solange Du mit deiner Lösung leben kannst, ist doch alles ok, aber hör doch auf die Spezialisten, die Dir einfach mal erzählen, das Du auf dem Holzweg bist, wenn Du meinst, Du hättest das tollste Verfahren. Hast Du nicht. Unknackbar ist es nicht, sicher ist es nicht und Spezialisten lachen Dich aus, wenn Du was anderes behauptest.

Aber eins muss man eben auch sagen: Es funktioniert und ist imho völlig ausreichend. Aber sichere damit keine Massenware. Denn dann kriegst Du sofort Cracks um die Ohren geballert, das dir Hören und Sehen vergeht.

Kann man eigentlich immer die Serien# einer HD auslesen? Geht das mit jedem Modell? Lustig. Kann man das nicht faken? Mit einem kleinen Service? Ich frag nur so, aus Interesse.

[negaH]

Sorry das ich mich nochmal melde:

Delphi-Quellcode:

procedure AntiProcDump;assembler;
procedure antidebug;assembler;

Sind echt alte Hüte und jeder Hacker wird diese Codestückchen sofort rausfischen. Besonders AntiDebug mit seinem "verstecketen" INT 3 OpCode ist sehr leicht für moderne Dissassembler auszumachen. Dies disassemblieren nämlich gleich mehrere möglich Programmpfade man muß es diesen nur sagen. Naja, bisher hast du sie ja auch noch nciht benutzt.

Delphi-Quellcode:

function GetHDSerialNumber: LongInt;

Benutzt GetVolumeInformation() und bekommt die LOGISCHE Serialnummer zurückgeben, NICHT die physikalische Serialnummer. Die Logische Serialnummer lässt sich auf DOS Ebene sehr leicht verändert, oder eine Formatierung reicht schon aus.

Ok dafür hast du ja gleich anschließend

Delphi-Quellcode:

function GetIdeSerialNumber ():string;

Diese benutzt den S.M.A.R.T Treiber, und wer aber weis das dieser Treiber nur statistische Aufgaben in einem System erledigt wird diese so wie ich löschen. Dieser Treiber erledigt keine für das OS wichtigen Aufgaben, sondern wird immer wieder gerne nur für den Softwareschutz benutzt.

Delphi-Quellcode:

function gethardwareid: string;

Nur ganz wenige Intel CPUs kennen eine CPU-ID. Mit speziellen Tools kann man diese extern deaktivieren und beim Ausführen des CPU-ID Befehles kommt es dann zu einer Hardwareexception. Desweiteren kann der CPU-ID Befehl komplett für Ring 3 Anwendungen gesperrt werden, auch dafür wird es wohl Tools geben. Dies führt zu einer Hardware Exception. Wo ist dein TRY EXCEPT Block eigentlich ? Naja und den Rest machst du über die Registry die ja jeder selber abändern kann.

Du solltest mal den MD5 so erzeugen das er auf Basis der Annahme das KEINE deiner Funktionen mit dem Datensammeln Erfolg gehabt haben, und dir diesen MD5 Digest dann wirklich merken. Es könnte durchaus sein das mit der Zeit immer mehr Registrationen reinflattern mit solchen MD5 Digest.

Erfreulich ist aber die Anwendung des MD5 Hashs da diese bei einer bekannten Serial verhindert das man die nötigen Werte für die Registry ermitteln kann. Man muß also schon Zugriff auf den Rechner haben den man kompromittieren möchte um dann alle Infos auslesen zu können und somit einen zweiten Rechner mit den Werten für die gleiche Serial versehen zu können. Das IST eine Notwendigket die ein Hacker in einem solchen Falle NICHT umgehen kann, das ist also sicher, und liegt am MD5. Bekommt also ein Hacker eine Serial in die Hände so nützt diese ihm wenig wenn er nicht weis von welchem Rechner sie stammt und er keinen Zugriff auf diesen Rechner bekommt.

Du hast also eine echte kryptographische Funktion an einer Stelle eingesetzt wo sie kryptographisch sehr sinnvoll ist und dies führte dann auch tatsächlich zu einer Erhöhung der Sicherheit indem bestimmte Angriffe definitiv ausgeschlossen werden. Dies zeigt sehr schön den Unterschied zu den anderen Funktionen.

Gruß Hagen

[negaH]

Um die MD5 noch sicherer zu machen schlage ich vor das du in der Registry zb. in hKey_Classes_Root\CLSID eine Zufalls CLSID anlegst und diese in die MD5 Berechnung mit einfließen lässt.Dein Setup erzeugt also einen dir bekannten CLSID Schlüssel und legt dadrunter einen Zufallswert mit 128 Bit Länge ab.
In deiner Serial Routine berechnest du diesen Wert dann ein.

Warum?
Weil es nur eine sehr begrenzte Anzahl von verschiednenen CPUs und Betriebssystemen gibt. Gehen wir davon aus das einige deiner Funktionen scheitern, eben VolumeID und SMARTVSD dann stützt sich deine Serial Berechnung nur noch auf die CPUID und den Werten in der Registry. Sagen wir mal das es nur ca. 10000 verschiedene Kombinationsmöglichkeiten gibt und ein Angreifer diese alle berchnen kann. Somit kann ein Angreifer bei deiner Methode anhand der MD5 Serial per Dictionary Angriff ermitteln was für ein Rechner zur Serial gehört. Im Endeffekt also unsicher da es nicht soviele verschiedene CPUs und Betriebssysteme auf dem Markt gibt.

Der Zufallswert in der Registry randomisiert nun dieses Verfahren und er werden garantiert zu unterschiedliche Serials erzeugt. Ein Angreifer müsste also wiederum Zugriff auf den jeweiligen Rechner haben um diesen ZUfallswert auslesen zu können.

Denken wir mal weiter: Du installiert in \WinNT\SYSTEM32\ eine eigene DLL an die du hintenan an die Datei dran während des Setups einen Zufallswert speicherst. Diesen kannst du sogar mit der gleichen DLL wieder auslesen wenn du möchtest (was keine verdächtige Aktion darstellt, da es normal ist das in diesem Ordner Haufen von DLLs liegen, das diese natürlich auch geladen werden und das innerhalb der DLL es durchaus üblich ist Resourcen aus der DLL am Ende der Datei zu laden).
Naja, auf alle Fälle fließt dieser Zufallswert ebenfalls in deine MD5 mit ein.

Gruß Hagen

[neuronet]

Vielleicht sollte ich mir doch mal 'ne Kiste Dongles oder SmartCards bestellen... :cry:

[negaH]

Und während du die Registry nach deiner CLSID ausliest oder du deine DLL lädst machst du folgendes:

Scheiße den Angreifer im wahrsten Sinne des Wortes zu !

D.h. starte mehrere Threads die die Registry scannen, alle Pfade und Werte öffenet und ausliest. Du produziertst damit eine rießige Menge an Zugriffen auf die Registry. Das dauert normalerweise nur par Sekunden, aber ein Angreifer der seinen RegMON laufen lässt wird damit Millionen von Registryzugriffen beobachten. Das geht soweit das er enerviert das Ding erstmal abschaltet und er eben nicht frei Haus alles gechenkt bekommt.

So, das gleiche machst du mit der DLL im SYSTEM32 Folder. Starte mehrer Threads die diesen Ordner scannen, öffne jede DLL und lade die Bytes am Ende der DLL. Auch hier wird der FileMON des Angreifers zugesch..en.

Gruß Hagen

[neuronet]

@negaH:

Erst mal danke für Deine Kommentare und Anregungen. Werde sie mir mal durch die Rübe sausen lassen.

Das hier noch jede Menge Try/Except Blöcke fehlen, ist mir auch klar (werden auch noch eingearbeitet).

Die Frage ist eben nur, ob der Aufwand, den ein Hacker betreiben muss, um das Ganze zu umgehen sich überhaupt für ihn rechnet.

Mal ganz davon abgesehen werden die MD5-Hashes nicht auf dem Kundenrechner, sondern bei mir in der zentralen Lizenzdatenbank gespeichert, und die Übertragung der Daten erfolgt PGP-Verschlüsselt...

[negaH]

Zitat:

Vielleicht sollte ich mir doch mal 'ne Kiste Dongles oder SmartCards bestellen...

Das nützt nur was wenn diese Teile "intelligent" sind, heist du musst auf diesen ein eigenes Program laufen lassen können. Eine einfache Abfrage einer Serialnummer aus diesen Systemen ist nicht sicher zu bekommen, da zwischen Dir und deinem Server hin zur SmartCard/Dongle wiederum ein unsicheres System liegt.

Das kann nur funktionieren wenn die SmartCard direkt online mit deinem Server kommunizieren kann. Im schlechtesten Falle weist du dann das auf der anderen Seite eine von dir zertifizierte SmartCard sitzt. Du weist aber längst noch nicht ob der Rechner noch der gleiche ist oder der Benutzer tatsächlich berechtigt wurde.

Die Schwierigkeit liegt nun darin die SmartCard so mit der eigenen Software zu verköpfen das es für einen Angreifer keine Möglichkeit gibt diese Verknüpfung zu umgehen.

Man könnte zb. die Software so konstruieren das sie nur mit Daten von deinen Server erst richtig nutzbar wird. Diese Daten sind verschlüsselt und nur mit und DURCH eine zertifizierten SmartCard werden sie entschlüsselt.
Die Nutzbarkeit der Software wird also eingeschränkt ohne die Daten vom Server und den SmartCards.

Gruß Hagen

[Neotracer64]

Nur mal so als Frage: Was bringen denn diese ganzen Abkenkungsmanöver? Ein Cracker der ganz normal im Kopf ist wird doch da ganz anders an die Sache gehen oder nicht? Er erstellt einfach einen Patch, der das Programm nur auf seine Funktionalität runterkürzt ohne irgendwelche komplizierten Checks und Aufrufe zu analysieren um vlt. n Keygen zu schreiben.

[neuronet]

Die Software verweigert eh die Arbeit, wenn die Daten, die auf dem Server liegen nicht mit denen übereinstimmen, die die Software liefert.

Und wie gesagt, die Kommunikation mit der Datenbank läuft über https und ist PGP-verschlüsselt...

[negaH]

Zitat:

Die Frage ist eben nur, ob der Aufwand, den ein Hacker betreiben muss, um das Ganze zu umgehen sich überhaupt für ihn rechnet.

;) das musst du den Hacker fragen. Will er dich schädigen ? kostet deine Sofwtare viel geld ? macht deine Software irgednwas was keine andere kann ? Hat der Hacker heute mal Lust&Laune, also Spaß an der Freude, deine für ihn sinnlose und uninteressante Software zu analysieren ?

Alles zuviele WENN und ABERS. Und alle obigen Tricks machen das System eben nicht wirklich sicher, es geht nämlich heutzutage garnicht sicher zu machen. Du und dein Server sind sicher aber deinen Käufern musst du immer als Feinde betrachten da deren Systeme heutzutage nicht sicher sind.

Einzigste Lösung ist es in Zukunft einbruchsichere Hardware zu verkaufen und darauf basierend einbruchsichere Betriebsysteme laufen zu lassen. Dann gewährleistet diese Endstelle die Sicherheit an Stelle des Benutzers. Klar, der Benutzer wird quasi entrechtet. WIR können jetzt noch wählen, haben wir uns aber einmal für ein solches System entscheiden werden wir es höchstwahrscheinlich nicht mehr los.

Die Alternative ? Baue doch erstmal eine wirklich gute Software die ihre Aufgabe aus Sicht der Anwedner ordentlich und preiswert erledigt. Dann mixt du noch einen guten Support dazu und deine Kunden werden freiwillig einsehen das du auch leben mußt.

Gruß Hagen

[Neotracer64]

Zitat:

Hat der Hacker heute mal Lust&Laune, also Spaß an der Freude, deine für ihn sinnlose und uninteressante Software zu analysieren ?

Nochmal meine Frage (sry): Muss er das denn überhaupt so genau machen? Er kann doch (ja ist etwas einfach gesagt) die Stelle mit den Checks rauschneiden und das Programm auf seine Funktionalität runterkürzen. Weil der Code muss ja vorhanden sein.

[negaH]

Zitat:

Nur mal so als Frage: Was bringen denn diese ganzen Abkenkungsmanöver? Ein Cracker der ganz normal im Kopf ist wird doch da ganz anders an die Sache gehen oder nicht? Er erstellt einfach einen Patch, der das Programm nur auf seine Funktionalität runterkürzt ohne irgendwelche komplizierten Checks und Aufrufe zu analysieren um vlt. n Keygen zu schreiben.

Hast du schonmal deine eigene Sofwtare aus Sicht eines Hackers/Crackers analysiert ? Nein, nehme ich an denn dann wüsstest du das ein Compiler eine Maschine ist die aus für uns wenigen Informationen -> Source eine ganze Menge an Machinencode erzeugt. Da durchzublicken und nun von den vielen Zeilen Opcodes ausgerechnet die Opcodes zu finden die NICHT zur Funktionalität der Sofwtare beitragen ist nicht so leicht. Desweiteren wissen wir auf der anderen Seite das natürlich und sind natürlich immer bestrebt in die echte Funktionalität der Sofwtare den Schutz der Software einzubauen. D.h. entfernst du den Schutz so muß auch die Funktionalität der Sofwtare zerstört werden, das ist UNSER Ziel.

Aber die Frage ist schon richtig. Sie bringen in Wahrheit nur sehr wenig wenn man sie mit echten mathematisch fundierten Sicherheitssystemen vergleicht. Deshalb meine obige "Warnung", zukünftige PC mit einbruchsicherer Hardware und OS snd defakto mathematisch fundiert konstruierte Systeme und ergo nicht merh zu knacken. Haben wir uns einmal für diesen Weg entschieden so bestimmen die PC und deren Hersteller was wir machen dürfen und was nicht.

Gruß Hagen

[omata]

Sorry, das ich mich nochmal melde.

Ich finde es schade, dass hier keiner auf die Speicherlecks eingegangen ist.

Wenn das übrige Programm so geschrieben ist, na dann gute Nacht.

Entschuldigung, dass ich darauf aufmerksam machen wollte.

[Neotracer64]

Zitat:

Hast du schonmal deine eigene Sofwtare aus Sicht eines Hackers/Crackers analysiert ?

Njain. Richtige Software nicht,..aber jetzt erkenne ich das problem. Ist natürlich war, dass in den kleinen Crackmes in denen ich bisher reingeschnuppert habe es ja noch ging, da diese ja keine komplexe Funktionalität aufweisen.
ich habe aus Interesse mal andere Software in den Debugger geladen...kurz gesagt: Da wird einem ja übel... :wink:

Ich denke jetzt mittlerweile auch, dass man den "Mainstream" der GelegenheitsCracker damit aufjedenfall in die Knie zwingt und das ist immerhin schon ein kleiner Erfolg.

[mschaefer]

Mensch Hagen,

langsam bekomme ich vor Deinen Programmen doch etwas Schlottern, denn die müssen ja inzwischen geradezu ein Hochsicherheitstrackt auf Algorithmenebene sein. Wahrscheinlich gibt es ncoh CD-Weitwurf (scharf rotierend) aus dem Fach, wenn ein Dissassembler entdeckt wird. :P

Aber mal im Ernst, dann kommt man doch zu dem Schluss, dass letzlich die regelmäßige Zwangskontaktaufnahme über Internet mit Datenbanksicherung systemspezifischer Daten dass einzige Mittel sind um eine Weitergabe und das Arbeiten damit zu unterbinden.
Oder man kauft doch eine kommerzielle Lösung, da man selbst kaum die Zeit hat sich auch noch darum intensiv zu kümmern.

Viele Grüße in die Runde // Martin

[neuronet]

@omata: Daran wird noch gearbeitet...

[neuronet]

@mschaefer: Kommerzielle Lösungen gibt's ja einige, aber wer soll das zahlen???

[negaH]

Oh, du wirst es kaum glauben, ich bin ein Verfechter des sozialen Verhaltens und benutze demzufolge keine Verschlüsselungen privat. Einfach weil ich nichts zu verbergen habe, keine Millionen Schwarzgeld zu verheimlichen habe oder andere Leute permanent ausspioniere oder kontrollieren möchte. Noch verkaufe ich schlechte Software zu überteuerten Preisen oder habe das Ziel meine Kunden durch technische Tricks und/oder Marketingtricks zu zwingen beim mir kaufen zu müssen um meinen Profit ins unterträgliche steigern zu können.

Letzendlich läuft jede Sicherheitslösung immer wieder auf Vertrauen hinaus und reales, echtes Vertrauen wird nur funktionieren wenn wir uns ALLE gegenseitig vertrauen WOLLEN !

Das heist aber nicht das ich nicht neugierig bin und nicht wissen möchte wie mein Leben an meinem PC in 10 oder 20 Jahren aussehen wird.

Anders ausgedrückt: ich bin ein Pazifist und denoch kann ich mit Waffen umgehen um eventuell meine Freiheit verteidigen zu können !

Zitat:

Aber mal im Ernst, dann kommt man doch zu dem Schluss, dass letzlich die regelmäßige Zwangskontaktaufnahme über Internet mit Datenbanksicherung systemspezifischer Daten dass einzige Mittel sind um eine Weitergabe und das Arbeiten damit zu unterbinden.

Jo heutzutage das einzigste Mittel, und frage dich doch mal wie schwer es für einen PC Laien ist die ständigen Kontaktaufnahmen der MS Software bei jedem kleinen Fehler zu deaktivieren ! Klar, dort werden zur Zeit noch keine relevanten Daten übertragen, aber der Anwender wird wie ein kleines Kind schon mal langfristig darauf vorbereitet. Haben wir uns erstmal daran gewöhnt kann man still und leise ja anfangen auch relevante Informationen zu übertragen.

Ich persönlich tendiere rein analytisch betrachtet ebenfalls zu der Ansicht das nur ein solches System, indem also der User teilweise seine Daten im WEB auf Severn der Firmen ablegen muß, sicher zu bekommen ist. Moralisch sehe ich diesen Trend aber als bedenklich. Und praktisch gesehen machen es die Big Player doch schon längst so. Wenn du wichtige Dokumente benötigst für neue Standards, dann musst du in einen Club eintreten und NDAs unterzeichnen. Damit das nicht jeder macht sind jählich 1000'ende Dollar Mitgliedsbeitrag fällig. Wenn du Softwareupdates haben möchtest die dir zustehen, dann musst du im WEB online sein, eine ferngesteuertes Setup ausführen das durch die Firewall ja nicht blockiert sein darf. Erst nachdem DU die Hose runtergelassen hast darfst du updaten.
Also wer diesen Trend nicht selber beobachtet hat der muß blind sein. Es ist aber auch ein logischer Schritt, aus Sicht der analytischen Kryptographie solange es nichts besseres gibt.

Ach übrigens die Aussagen "die Firmen hätten kein Interesse daran ihre Kundendaten mißbräuchlich zu verwenden". Das ist Schwachsinn und ein immerwiederkehrendes Argument eben dieser Interessengruppen, sie sind GEIL auf unsere Daten, sie verkaufen schon längst unsere Addressen, Telefonnummer etc.pp. und der Staat mischt da unberechtigter weise selber mit.

Um so wichtger ist es sich mit Kryptographie zu beschäfftigen, denn im Gegensatz zu Menschen besteht die Kryptographie nur aus Mathematik und es hängt nur von UNS ab ob die Kryptographie gegen uns oder für uns konstruiert wird. Tja, und das ist der Grund warum mich das Ganze so interessiert.

Gruß Hagen

[Daniel G]

Zitat:

Zitat von mschaefer

Aber mal im Ernst, dann kommt man doch zu dem Schluss, dass letzlich die regelmäßige Zwangskontaktaufnahme über Internet mit Datenbanksicherung systemspezifischer Daten dass einzige Mittel sind um eine Weitergabe und das Arbeiten damit zu unterbinden.

Und wenn ich - sit venia verbo - einfach keinen Bock habe, dein Programm mit dem Internet in Kontakt treten zu lassen? Oder wg. technischen Problemen mein Internetzugang nciht funktioniert?

Letzendlich ist es am Sichersten, seine Software für sich zu behalten... Wobei nichtmal das sicher ist....

[neuronet]

@Daniel G: Dann kaufst Du das Produkt der Konkurrenz und zahlst für die gleiche Leistung 4 mal so viel... :-)

[mschaefer]

Einen schönen guten Morgen,

Eigentlich geht Andreas schon in die richtige Richtung in dem er den Wagenschlüssel nicht gleich im Auto stecken läßt und zumindest eine Art Vorhängeschloss anbaut. Warhscheinlich sind Hagens Hinweise gut zu verwenden und seine Faszination für Algorithmen kann ich zum Teil auch Nachvollziehen.

Das Grundproblem bekommt man halt nicht in den Griff. Die Lizenz zum Anwenden ist an den Anwender gebunden und nicht an die Maschine. Wenn er beschließt das Programm nun auf einem anderen Rechner laufen zu lassen ist das Legitim.


@Daniel, bisher habe ich diese Methodik nicht angewendet, da ich mich mit WaWi und Auftragsbearbeitung beschäftige und die meist kein Internetanschluss haben. Allerdings ist der Hinweis die Software für sich zu behalten eine Bankrotterklärung. Eigentlich hast Du das Dilemma auf den Punkt gebracht.


Selbst denke ich derzeit über ein Installationdongle nach. Wenn es dann zweimal installiert ist würde ich das tolerieren, nicht aber, wenn eine zweite Firma damit arbeitet und Hardware ist zumindest nicht mehr ganz so leicht zu kopieren.

Grüße // Martin

[neuronet]

Morgen, Martin!

Über die Tatsache, daß die Lizenz maschinengebunden ist, weiss der Käufer Bescheid.
Da ein Rechnerwechsel in dieser Branche sehr unüblich ist, kommt es auch sehr selten (ca. 10 mal pro Jahr) vor, dass eine Umlizenzierung beantragt wird (solange das nicht täglich geschieht, reicht eine kurze SMS oder eMail oder auch ein Anruf).

Gruß Andy

[torud]

Hallo Wissende,

ich schreibe in diesem Thread, weil ich denke, dass er der Richtige ist und das Thema eigentlich immer aktuell ist.

Ich habe also mal den BeispielCode in mein Projekt eingebunden und muss leider feststellen, dass auf meinem Laptop und auch auf meinem PC nicht immer die gleiche MaschinenID generiert wird. Es sind auf beiden Systemen 2 verschiedene ID´s.

Warum nur?
Und gibt es denn mitlerweile einen Code, auf den man sich verlassen kann???

Folgende 2 sind es auf meinem Laptop:
3f30c764dbb8cc59b9c3fe0414ee497f
06fdfa1dd26fb21bf6ad850e36ef78ae

Zitat:

Zitat von mschaefer

Das Grundproblem bekommt man halt nicht in den Griff. Die Lizenz zum Anwenden ist an den Anwender gebunden und nicht an die Maschine. Wenn er beschließt das Programm nun auf einem anderen Rechner laufen zu lassen ist das Legitim.

@mschaefer
Das der Kunde das Programm auch auf nem anderen Rechner laufen lässt, mag ja noch ok sein. Was aber wenn er das Tool auf 20 anderen Rechnern seiner Kollegen installiert, die eigentlich bezahlen müssten???