Warning: Use of undefined constant ipaddress - assumed 'ipaddress' (this will throw an Error in a future version of PHP) in /home/www/acp/lib/session.php on line 98

Warning: Use of undefined constant useragent - assumed 'useragent' (this will throw an Error in a future version of PHP) in /home/www/acp/lib/session.php on line 98

Warning: Use of undefined constant request_uri - assumed 'request_uri' (this will throw an Error in a future version of PHP) in /home/www/acp/lib/session.php on line 98

Warning: Cannot modify header information - headers already sent by (output started at /home/www/acp/lib/session.php:98) in /home/www/acp/lib/functions.php on line 82

Warning: Cannot modify header information - headers already sent by (output started at /home/www/acp/lib/session.php:98) in /home/www/acp/lib/functions.php on line 82

Warning: Cannot modify header information - headers already sent by (output started at /home/www/acp/lib/session.php:98) in /home/www/acp/lib/functions.php on line 82

Warning: Cannot modify header information - headers already sent by (output started at /home/www/acp/lib/session.php:98) in /home/www/acp/lib/functions.php on line 82
Forum www.Kopierschutzsysteme.de - Hier findet Ihr Informationen rund um das Thema Kopierschutz - Kopierschutz Systeme ( DONGLES )
Registrierung Mitgliederliste Administratoren und Moderatoren Suche Häufig gestellte Fragen Stellen Sie hier Ihre spezielle Kopierschutzanfrage Zur Startseite  

Forum www.Kopierschutzsysteme.de - Hier findet Ihr Informationen rund um das Thema Kopierschutz » Kopierschutzsysteme » Erfahrungs-/Testberichte » Kopierschutz Systeme ( DONGLES ) » Hallo Gast [anmelden|registrieren]
Druckvorschau | An Freund senden | Thema zu Favoriten hinzufügen
Seiten (3): « vorherige 1 [2] 3 nächste » Neues Thema erstellen Antwort erstellen
Autor
Beitrag « Vorheriges Thema | Nächstes Thema »
S. Goers
Grünschnabel


Dabei seit: 11.06.2008
Beiträge: 5

Zitatantwort auf diesen Beitrag erstellen Diesen Beitrag editieren/löschen Diesen Beitrag einem Moderator melden       IP Information Zum Anfang der Seite springen

Hallo im Forum,

um es gleich vorweg zu sagen: Ich komme von SG-Intec (SG-Lock).

Ich habe aufmerksam und mit Interesse die Diskussion im Forum verfolgt und würde nun gerne auch etwas dazu beitragen.

Zunächst kann ich aus eigener Erfahrung sagen, dass die Ansprüche der Rechteinhaber an einen Kopierschutz SEHR breit gefächert bzw. unterschiedlich sind.

Somit ist es eigentlich fast unmöglich das "perfekte" Produkt anzubieten.
Neben möglichst hoher Sicherheit ist die einfache Einbindung durch den Programmierer und die problemlose Handhabung durch den Endbenutzer ein wichtiges Kriterium (weshalb SG-Lock treiberlos konzipiert wurde). Speziell die ersten 2 Punkte können schnell in Widerspruch geraten.

An dieser Stelle möchte ich auf die Einbindung des APIs per DLL kommen. Dass dies nicht der Stand der Technik sein soll, sehe ich anders.


Zitat:
Original von Michael Bauer
Danke für Deinen kurzen Bericht zu Matrixlock :-)

SG-Lock bietet zwar die Möglichkeit mehrere Keys für die interne Dongleverschlüsselung zu speichern, folgende Funktionen werden aber im Vergleich zu Matrixlock nicht geboten:

1) Keinen automatischen Schutz mittels eines Wrapper Tools wie z.B. MxCrypt
2) Keine Unterstützung für statische DLL Einbindung
3) Keine Donglesperre bei Hackversuchen
4) Kein Obfuscator für .Net Anwendungen
5) Keine Netzwerkunterstützung
6) Keine Remote Update-Fähigkeit

SG-Lock bietet zum Einbinden des Schutzes nur die dynamische DLL Einbindung, was meiner Ansicht nach heute nicht mehr Stand der Technik ist, siehe andere Hersteller.

Augrund der Schwächen 1-4 würde ich im Vergleich Matrixlock <-> SG-Lock, Matrixlock als stärkeren Schutz ansehen.


Die Einbindung der DLL bei SG-Lock ist nämlich kein normales Laden infolge dessen sofort alle API-Funktionen zur Verfügung stehen. Bis auf eine Freischaltfunktion sind nämlich nach dem Laden der DLL alle anderen Funktion noch nicht freigeschaltet. Dies wird erst nach einer erfolgreichen Authentifizierung der EXE durch die DLL vorgenommen.

Der Code zur Authentifizierung muss als Source-Code zusätzlich in den Quellcode der geschützten Anwendung "included" werden - dieser befindet sich nach dem compilieren in der EXE-Datei (wie bei einer statisch hinzugelinkten Lib). Ganz nebenbei wird hierbei auch noch die DLL von der EXE authentifiziert (die andere Variante).

Eine Dummy-DLL, die lediglich das API emuliert ist damit nicht so einfach möglich erzustellen, wie vielleicht an dieser Stelle vermutet wurde. Zusätzlich ist es auch nicht einfach möglich mit einer eigenen Anwendung über das API auf die Dongle Hardware zuzugreifen (um viellecht Werte im Dongle zu ändern) , was mit einer rein statischen Lib (wie hier favorisiert) ersteinmal nicht ausgeschlossen ist, deren API ist ja i.d.R. offen (das eine hat nämlich nichts mit dem anderen - die Art der Bindung - zu tun) - ein Vorteil der bei SG-Lock angewandten Methode gegenüber einer statischen Lib. Das alles wird mit einem API-Aufruf erledigt.

Insofern halte ich dieser Art der Einbindung gerade nicht für veraltet - im Gegenteil - es verbindet die Vorteile der beiden Methoden ohne, dass die Nachteile von beiden zu tragen kommen.

Zu der oben genannten Liste möchte ich gerne auch Stellung beziehen.
Zu 1: Envelope -Tools werden meiner Meinung nach in der Sicherheitswirkung überschätzt. Häufig bieten Sie die Möglichkeit mit sogn. "Generischen Hacks" ausgehebelt werden zu können, die sogar fast jeder nicht-Programmierer durch einfaches Herunterladen aus den Internet nutzen kann.
Zu 2: siehe oben
Zu 3: Die Authentifizierung beruht bei SG-Lock auf Schlüsseln mit 128-Bit Länge. Der verwendet Algorithmus hat aus kryptographischer Sicht eine effektive Länge von ca. 126 Bits. Hierbei ist ein Brute Force Angriff weitgehend sinnlos (2^126 Möglichkeiten) und damit ist ein "Hacker-Lock", dass die Versuche begrenzt, überflüssig. Ein solcher Schutz wäre dann notwendig, wenn die Anzahl der Möglichkeiten aufgrund der gewählten Methode sehr klein sind, um diesen prinzipiellen Nachteil der Methode abzuschwächen.
Zu4: Es gibt sehr gute .net Obfuscator-Tools am Markt von Herstellern, die sich darauf spezialsiert haben. Softwarehersteller, die Ihr Know-How und Urheberrechte effektiv schützen möchten, werden sicherlich nicht unbedingt ein kostenlos mitgeliefertes anwenden sondern versuchen das beste Tool, das am Markt verfügbar ist, auszuwählen. Das kann dann selbstverständlich auch mit SG-Lock kombiniert werden.
Zu 5: Das stimmt. SG-Lock ist nicht als Netzwerk-Version erhältlich.
Zu6: Selbstverständlich ist SG-Lock remote-update-fähig. Es wird z.Zt. von unserer Seite nur kein fertiges Tool dafür angeboten, da dies i.d.R. schöner in die geschützte Anwendung integriert werden (Menüpunkt).


Mit freundlichen Grüßen
S. Görs

11.06.2008 13:02 S. Goers ist offline Email an S. Goers senden Beiträge von S. Goers suchen Nehmen Sie S. Goers in Ihre Freundesliste auf
uhabber uhabber ist männlich
Mitglied


Dabei seit: 02.02.2008
Beiträge: 37

Zitatantwort auf diesen Beitrag erstellen Diesen Beitrag editieren/löschen Diesen Beitrag einem Moderator melden       IP Information Zum Anfang der Seite springen

ich besitze auch einen SG-Lock Dongle ich kann nur sagen dieser Dongle ist besser als Matrixlock.
Ich selber setze Wibu Key ein.SG-Lock Auth.methode ist gut
der Bytecode ist der Schlüssel zum Dongle und liegt dann dem User offen und man kann den Dongle schön editieren

Meiner Meinung nach muss der Dongle effektiv gegen verändern gesichert sein durch Wissen und Besitz (Password und Masterkey).
Die stärke der Verschlüsselung ob Feal , AES , DES , XTEA spielt keine grosse Rolle.Wenn der Schlüssel uberreichbar ist im Dongle.
Keypro II ist nur ein EEprom Dongle solche Modelle waren 1984 - 1993 im gebrauch.

Die sicherste Dongleklasse ist für mich Megalock, Rockey 6,Senselock -Nachteil sehr aufwendige Einbindung in den Quellcode.

Bei mir stehe ein flexibler Dongle Netzwerk / Client an erster Stelle.
Netzwerkserver ist auch wichtig da ich plane meinen Betatest von vielen Personen machern zu lassen die nur einen Internetzugang brauchen um meine Applikation zu starten ohne das ich meine Sicherheit verliehre.

Wibukey ist nicht der billigste Dongle auf dem Markt.

Bietet aber alles was ein sehr flexibler Softwareschutz braucht.

Axan oder Wupi Technik sind sehr flexible.

Remote Control ist kostenlos (kostet bei anderen Herstellern Aufpreis)

Ich kann verschiedene Programmmodule durch andere Verschlüsselung schützen
HLM und Firmenmaster Eintrag im Dongle

Andere Herstellet haben Nur Speicher wo man Werte hinterlegen kann.

Ist der Programmcode verschlüsselt so hat ein Hacker in der Regel keine Aussicht der Programmcode zu entschlüsseln

Sg-LOCK ist ein Single PC Dongle welcher bis zu 15 Verschlüsselungen kann.
Verfügt aber über keinen festprogramierte Schlüssel der einzigartig für jeden Kunden ist ausser U2 Modell

Wenn jemand den Schlüssel auslesen kann so kann er dann den Dongle kopieren gegen seinen eigenen muss nur den Auth code patchen.

Test Packete gibt es ja zu kaufen.

Dongle Emulatoren gibt es ja auch noch im Internet zum Download oder Kauf.

11.06.2008 22:11 uhabber ist offline Email an uhabber senden Homepage von uhabber Beiträge von uhabber suchen Nehmen Sie uhabber in Ihre Freundesliste auf
uhabber uhabber ist männlich
Mitglied


Dabei seit: 02.02.2008
Beiträge: 37

Zitatantwort auf diesen Beitrag erstellen Diesen Beitrag editieren/löschen Diesen Beitrag einem Moderator melden       IP Information Zum Anfang der Seite springen

zu .net von Microsoft

ich zahle sehr viel Geld für Visual Studio und brauche nochmal sehr viel Geld um meine Quellcode zu schützen. großes Grinsen

Ich sage Microsoft BYE und habe Purebasic 4.2 zur Zeit Windows und Linux.
Nachteil muss sehr viel Quellcode umschreiben das er in Purebasic läuft das ist aber sehr schnell gemacht
Inline Assembler und das Einbringen von Assembler ist auch kein grosses Problem.

.Net ist die grosse Welle von Microsoft.

Ich spreche hier nur für mich und nicht für andere Softwareentwickler.
Augenzwinkern

Auto Exe Crypter von Dongle Herstellern bringen Schutz
denn die meisten Donglehersteller verbessern ihren automatischen Schutz ,so ist der Entwickler immer auf dem neusten Stand. Die Donglehersteller sind den Hackern immer einen Schritt voraus.
Ist der Hacker mal vorne macht er seinen erfolg public.
Der Donglehersteller weiss es dann,und kontert mit einer neuen Version des Exe-Schutzes.

.Net Verschleierungs-Software ist gut und schön
man liest im Internet nur gutes über den Schutz von .Net Software.
Freude

11.06.2008 22:31 uhabber ist offline Email an uhabber senden Homepage von uhabber Beiträge von uhabber suchen Nehmen Sie uhabber in Ihre Freundesliste auf
S. Goers
Grünschnabel


Dabei seit: 11.06.2008
Beiträge: 5

Zitatantwort auf diesen Beitrag erstellen Diesen Beitrag editieren/löschen Diesen Beitrag einem Moderator melden       IP Information Zum Anfang der Seite springen

Hallo uhabber,

ich möchte gerne auch hierzu etwas beitragen.

Zitat:
Original von uhabber
ich besitze auch einen SG-Lock Dongle ich kann nur sagen dieser Dongle ist besser als Matrixlock.
Ich selber setze Wibu Key ein.SG-Lock Auth.methode ist gut
der Bytecode ist der Schlüssel zum Dongle und liegt dann dem User offen und man kann den Dongle schön editieren


Ja, die Prüfung der DLL erfolgt mit der Methode SglAuthent(). Ein kundenspezifischer Bytecode schaltet der Dongle frei. Wobei dazuzusagen ist, dass hierbei nur stark verschlüsselte Informationen über die Schnittstelle laufen. Um Missverständnissen vorzubeugen: Der oben genannte User, der Dongle editieren kann, ist der Softwarehersteller/Rechteinhaber und natürlich nicht der Softwareanwender (auch User genannt).


Zitat:
Original von uhabber
Meiner Meinung nach muss der Dongle effektiv gegen verändern gesichert sein durch Wissen und Besitz (Password und Masterkey).
Die stärke der Verschlüsselung ob Feal , AES , DES , XTEA spielt keine grosse Rolle.Wenn der Schlüssel uberreichbar ist im Dongle.


Dem kann ich zustimmen - die sichere Schlüsselverwahrung ist ein wichtiger Sicherheitsfaktor, deshalb werden alle Daten im SG-Lock mit einer internen 128-Bit Verschlüsselung im Donglespeicher abgelegt, so auch die 128-Bit Schlüssel selbst. Dabei benutzt jeder SG-Lock einen anderen internen Schlüssel - dies ist allerdings transparent für den Programmier gelöst, d.h. nicht jeder SG-lock muss anders angesprochen werden.

Zitat:
Original von uhabber
Sg-LOCK ist ein Single PC Dongle welcher bis zu 15 Verschlüsselungen kann.
Verfügt aber über keinen festprogramierte Schlüssel der einzigartig für jeden Kunden ist ausser U2 Modell

Wenn jemand den Schlüssel auslesen kann so kann er dann den Dongle kopieren gegen seinen eigenen muss nur den Auth code patchen.


Es sind bis zu 16 Schlüssel mit 128-Bit Länge, die im SG-Lock gespeichert werden können. Eine Auslesefunktion gibt es nicht - man muss dann an die Hardware, was wenig Sinn macht, da der Speicher - wie oben beschrieben - mit individuellen, d.h. von SG-Lock zu SG-Lock unterschiedlichen 128-Bit Schlüsseln voll-verschlüsselt ist.

Es gibt deshalb mehr als einen Schlüssel, weil neben der Nutzung für
1. Daten-Verschlüsselung
2. Daten-Signierung
3. Challenge-Response-Authentifizierung

man auch sehr gut
4. Informationen im Schlüssel selbst verstecken kann, z.b. eine Lizenznummer.
Es handelt sich schließlich dabei um 16 Bytes (128 Bit) Informationen. Falls man nur ein paar Bits braucht (aber eigentlich immer) sollte man diese nocheimal überverschlüsseln, damit die Information im Datenblock diffundiert.

Bei einer Überprüfung wird dann nicht die Lizenznummer über die Schnittstellen DLL/USB übertragen sondern lediglich Verschlüsselungergebnisse davon und diese jedesmal anders da man hierfür sehr gut Zufallszahlen nehmen kann und sollte.

Dabei ist dann die Frage, ob eine statische LIB oder eine DLL benutzt wird, gar nicht mehr so wichtig, weil die gesamte Information zwischen EXE und USB Hardware quasi getunnelt wird. Dabei ist die Information sogar nur "Sekundär-Information", da es ja nur um Verschlüsselungsergebnisse handelt und nicht um den Schlüssel (in diesem Fall die Lizenznummer) selbst.

Ich hoffe ich habe in die Ideen, die hinter der Konzeption von SG-Lock stehen, etwas Licht bringen können ...


Mit freundlichen Grüßen
S. Goers

12.06.2008 09:44 S. Goers ist offline Email an S. Goers senden Beiträge von S. Goers suchen Nehmen Sie S. Goers in Ihre Freundesliste auf
uhabber uhabber ist männlich
Mitglied


Dabei seit: 02.02.2008
Beiträge: 37

Zitatantwort auf diesen Beitrag erstellen Diesen Beitrag editieren/löschen Diesen Beitrag einem Moderator melden       IP Information Zum Anfang der Seite springen

Zitat:
Original von S. Goers

Es gibt deshalb mehr als einen Schlüssel, weil neben der Nutzung für
1. Daten-Verschlüsselung
2. Daten-Signierung
3. Challenge-Response-Authentifizierung

man auch sehr gut
4. Informationen im Schlüssel selbst verstecken kann, z.b. eine Lizenznummer.
Es handelt sich schließlich dabei um 16 Bytes (128 Bit) Informationen. Falls man nur ein paar Bits braucht (aber eigentlich immer) sollte man diese nocheimal überverschlüsseln, damit die Information im Datenblock diffundiert.

Bei einer Überprüfung wird dann nicht die Lizenznummer über die Schnittstellen DLL/USB übertragen sondern lediglich Verschlüsselungergebnisse davon und diese jedesmal anders da man hierfür sehr gut Zufallszahlen nehmen kann und sollte.

Dabei ist dann die Frage, ob eine statische LIB oder eine DLL benutzt wird, gar nicht mehr so wichtig, weil die gesamte Information zwischen EXE und USB Hardware quasi getunnelt wird. Dabei ist die Information sogar nur "Sekundär-Information", da es ja nur um Verschlüsselungsergebnisse handelt und nicht um den Schlüssel (in diesem Fall die Lizenznummer) selbst.

Ich hoffe ich habe in die Ideen, die hinter der Konzeption von SG-Lock stehen, etwas Licht bringen können ...


Mit freundlichen Grüßen
S. Goers


Schauen wir in das Handbuch da steht auf Seite 16 kap.4.2

Sg-Auth....

Diese Funktion muss man als erstes aufrufen und die 48 byte Auth.Code übergeben
(habe ich diese 48 Byte kann ich mit dem SG-Lock Manager Arbeiten
Ram Editieren.... usw

Challenge-Response-Authentifizierung Freude Klasse dann weiss jeder den TeA KEY 128 Bit und DAS U2 Lock Währe wertlos U3 / U4 Haben mehere Schlüssel auf Reserve

Sgl-Writekey ok
aber EEPROM IST EEPROM
ich kann den Speicher lesen den normalen RAM

der Schlüsselspeicher wird im selben RAM stehen

EEPROM bei regenbogen im obj (DOS ASSEMBLER OBJ) geschützt 1992 2 Byte patchen und los geht es keine Hiddendatawords alles frei lesbar und beschreibbar

Bei der Zauberfirma mit hardware against Software Pirates.
das selbe (Serial nummer (DEED BEEF) kann man überall nach lesen.

Bei Matrixlock denke ich da kann man mit ASSEMBLER auch sehr viel anfangen EMULATOR IN DEN OBJ-CODE könnte gut Platz finden .wie es beim Dongle der Zauberfirma (hardware against Software Pirates 3) war.

smile

12.06.2008 11:36 uhabber ist offline Email an uhabber senden Homepage von uhabber Beiträge von uhabber suchen Nehmen Sie uhabber in Ihre Freundesliste auf
S. Goers
Grünschnabel


Dabei seit: 11.06.2008
Beiträge: 5

Zitatantwort auf diesen Beitrag erstellen Diesen Beitrag editieren/löschen Diesen Beitrag einem Moderator melden       IP Information Zum Anfang der Seite springen

Hallo uhabber,

ich denke es ist notwendig hier in die Deatils zu gehen ...

Zitat:
Original von uhabber
Schauen wir in das Handbuch da steht auf Seite 16 kap.4.2

Sg-Auth....

Dise Funktion muss man als erstes aufrufen und die 48 byte Auth.Code übergeben
(habe ich diese 48 Byte kann ich mit dem SG-Lock Manager Arbeiten
Ram Editieren.... usw


Wenn SglAuthent() eine Funktion der DLL wäre, wäre die Aussage richtig - ist sie aber nicht. Vielmehr ist SglAuthent() eine Funktion, die included wird und damit in der EXE ist (bitte in den Header-Dateien nachsehen). SglAuthent() ihrerseits ruft andere Funktionen in der DLL auf, denen entscheidene Informationen nicht übergeben werden. Somit ist die Annahme man könne einfach den Aufruf von SglAuthent() mit eine Dummy-DLL auffangen nicht richtig (das wäre bei weitem zu einfach).


Zitat:
Original von uhabber
Challenge-Response-Authentifizierung Freude Klasse dann weiss jeder den TeA KEY 128 Bit und DAS U2 Lock Währe wertlos U3 / U4 Haben mehere Schlüssel auf Reserve


Ich glaube hier besteht ein Verständnisproblem. Der interne 128-Bit Schlüssel (egal ob bei U2 oder U3,U4) hat nichts mit der Funktion SglAuthent() zu tun.
Selbst wenn ich Zugang zum SG-Lock-API hätte, weil mir auf irgend eine Weise der 48-Byte Authentcode bekannt geworden ist, bin ich eigentlich kein Stück weitergekommen den internen 128-Bit Schlüssel zu ermitteln, denn es gibt keine Lese-Funktion für den 128-Bit Schlüssel.
Insofern ist die Challenge-Response-Authentifizierung eine gute Methode, die den Angreifer entweder per reverse engineering in die EXE-Datei zwingt oder an die SG-Lock Hardware, was beides einen erheblichen Aufwand darstellt. Die DLL mit ihrem API ist nicht mehr beteiligt, da sie nur die Daten vermittelt, aber nicht mehr verändert und ist somit für Angriffe uninteressant bzw. nutzlos.


Zitat:
Original von uhabber
Sgl-Writekey ok
aber EEPROM IST EEPROM
ich kann den Speicher lesen den normalen RAM

der Schlüsselspeicher wird im selben RAM stehen


Sicherlich kann man EEPROMs auslesen, aber was hat man gewonnen, wenn man nur verschlüsselte Daten findet? Selbst wenn mir bekannt ist wo im EEPROM ein 128-Bit Schlüssel steht oder ich das gesamte EEPROM kopiere und mir sage "Ich muss garnicht wissen wie die Daten genau ausehen - ich kopiere sie einfach von einem SG-Lock in mein Demo SG-Lock und ich habe diesen dubliziert" - das geht leider nicht, weil jedes SG-Lock die EEPROM Daten aufgrund des unterschiedlichen internen 128-Bit Schlüssel anders entschlüsselt. Dies würde der SG-Lock im übrigen selbst erkennen und sich passiv schalten.



Mit freundlichen Grüßen,
S. Goers

12.06.2008 15:36 S. Goers ist offline Email an S. Goers senden Beiträge von S. Goers suchen Nehmen Sie S. Goers in Ihre Freundesliste auf
Michael Bauer Michael Bauer ist männlich
Administrator


Dabei seit: 03.02.2007
Beiträge: 127

statische/dynamische Einbindung Zitatantwort auf diesen Beitrag erstellen Diesen Beitrag editieren/löschen Diesen Beitrag einem Moderator melden       IP Information Zum Anfang der Seite springen

Hallo Herr Goers,

vielen Dank für Ihre Beiträge und dass Sie mich korrigiert haben was Ihren Schutz anbetrifft.

Ich möchte mich nochmals kurz zum Thema statische oder dynamische DLL äussern.

Ob die statische oder die dynamische DLL mehr Schutz bietet lässt sich so pauschal nicht beantworten. In beiden Fällen kann man die Sache geschickt oder ungeschickt angehen. Meine bisherigen Erfahrungen haben mir aber gezeigt, dass die dynamische DLL Einbindung für einen Hacker einen schnelleren Einstieg in das Programm ermöglicht. Wenn dann noch so selbstprechende Namen wie "LeseDongleSeriennummer" oder "VerschlüsselungViaDongle" im Spiel sind, weiss ein Hacker sofort auf welche DLL-Funktionen er seine Breakpoints setzen muss. Wurde dann noch eine User-Integration nach folgendem Schema gemacht – diese Art ist leider sehr oft vorzufinden:

Ergebnis = Aufruf Dongle-Funktion()
If (Ergebnis)
{
/* Funktion erfolgreich ausgeführt */
}
Else
{
/* Fehler bei der Ausführung */
}

hat ein Hacker die Sache in Null-Komma-Nix gehackt.

Aufgrund der arglosen Integration vieler User, meine ich bietet die statische DLL-Einbindung mehr Schutz, denn einem Hacker fehlt im ersten Moment die ersichtliche Dongle-Schnittstelle und somit kann er nicht so einfach einen Breakpoint auf irgendwelche Dongle-Funktionen setzen. Natürlich weiss sich ein geübter Hacker auch hier zu helfen aber hier muss er schon ein bisschen mehr suchen um an die eigentlichen Dongle-Funktionen zu gelangen.

Natürlich gehören neben der statischen wie auch dynamischen DLL Einbindung noch weitere Schutz-Mechanismen um es einem Hacker so schwer wie möglich zu machen, hier ist aber auch die Kreativität desjenigen gefragt, der den Schutz integriert.

Gruß
Michael Bauer

12.06.2008 17:31 Michael Bauer ist offline Email an Michael Bauer senden Homepage von Michael Bauer Beiträge von Michael Bauer suchen Nehmen Sie Michael Bauer in Ihre Freundesliste auf
uhabber uhabber ist männlich
Mitglied


Dabei seit: 02.02.2008
Beiträge: 37

Zitatantwort auf diesen Beitrag erstellen Diesen Beitrag editieren/löschen Diesen Beitrag einem Moderator melden       IP Information Zum Anfang der Seite springen

Hallo Herr Goers

Sg-lock ist nicht der schlechteste Dongle

Augenzwinkern

Ich vertrete die Meinung Programmierung des Dongles nur mit Hardware und wenn es an CRYPT KEYS geht die Bestandteil der Sicherheit sind.DA sage ich nur sichern Mit Hardware gegen Veränderung und verschlüsselt für remoteupdate.

dynamische DLL oder Statische OBJ

ich denke statisches Linken ist besser

nur dann haben ich ein genaues Auge auf die Dongle kommunikation.

Alle Hersteller von Schutzhardware sagen unsere Hardware ist die beste
und der Softwareentwickler ist der Schwachpunkt.
das stimmt in der Regel auch weil Zeit ist Geld

ich "Teste" gerade Zeitaufwand und Schutzaufwand von einigen Hardwareteilen

dieses umfasst .
Handbuchlesen

Sampleproggi ansehen....

Da ich in Purebasic schreibe und Teste muss ich mir alles selber schreiben weil kein Hersteller Purebasic direkt unterstützt.
(Dll anbinden , Crypt-tool...USW)

Dieser Beitrag wurde schon 1 mal editiert, zum letzten mal von uhabber am 12.06.2008 22:22.

12.06.2008 22:06 uhabber ist offline Email an uhabber senden Homepage von uhabber Beiträge von uhabber suchen Nehmen Sie uhabber in Ihre Freundesliste auf
S. Goers
Grünschnabel


Dabei seit: 11.06.2008
Beiträge: 5

RE: statische/dynamische Einbindung Zitatantwort auf diesen Beitrag erstellen Diesen Beitrag editieren/löschen Diesen Beitrag einem Moderator melden       IP Information Zum Anfang der Seite springen

Hallo Herr Bauer,

gerne möchte ich hierzu noch etwas ergänzen.

Zitat:
Original von Michael Bauer
Hallo Herr Goers,

vielen Dank für Ihren Beiträge und dass Sie mich korrigiert haben was Ihren Schutz anbetrifft.

Ich möchte mich nochmals kurz zum Thema statische oder dynamische DLL äussern.

Ob die statische oder die dynamische DLL mehr Schutz bietet lässt sich so pauschal nicht beantworten. In beiden Fällen kann man die Sache geschickt oder ungeschickt angehen. Meine bisherigen Erfahrungen haben mir aber gezeigt, dass die dynamische DLL Einbindung für einen Hacker einen schnelleren Einstieg in das Programm ermöglicht. Wenn dann noch so selbstprechende Namen wie "LeseDongleSeriennummer" oder "VerschlüsselungViaDongle" im Spiel sind, weiss ein Hacker sofort auf welche DLL-Funktionen er seine Breakpoints setzen muss.


Sie haben natürlich recht, dass wenn die Progammausführung in eine DLL verzweigt, dies im Maschinencode einfacher zu finden ist, als wenn eine interne Funktion aufgerufen wird. Aber auch eine statische Lib wird irgendwann (meist recht schnell) auf die Treiberebene wechseln und ist damit auch nicht immun gegen diese Analysemethode des Maschinencodes.


Zitat:
Original von Michael Bauer
Wurde dann noch eine User-Integration nach folgendem Schema gemacht – diese Art ist leider sehr oft vorzufinden:

Ergebnis = Aufruf Dongle-Funktion()
If (Ergebnis)
{
/* Funktion erfolgreich ausgeführt */
}
Else
{
/* Fehler bei der Ausführung */
}



Mit einer Einbindung in der oben beschriebenen Form hat man sicherlich nicht alle Möglichkeiten genutzt.

Hier kann man mit einer zweiten weit verzögerten Prüfung z.B. einer Challenge-Response-Authentfizierung (gerne auch mit verdecktem vorherigen Umkopieren von relevanten Daten in größerem Rahmen und in andere Programmteile), die nicht regelmäßig sondern sporadische, unklare Fehler erzeugt, viel erreichen.

Andererseits muss man im Auge behalten, was der Softwarehersteller tatsächlich erreichen will. Nicht jede Software ist wirklich interessant für "high-skilled hackers". Und nicht jeder Hacker empfindet das dringende Bedürfnis, seinen Hack weiterzugeben oder gleich ins Internet zu stellen. Ich habe die Erfahrung gemacht, dass Softwarehersteller recht realistisch einschätzen können, wie groß die Bedrohung durch illegale Nutzung Ihrer Software tatsächlich ist.

Nicht wenigen Softwareherstellern ist zunächst das einfache Kopieren unter Kollegen, die nie zu einem Disassambler greifen würden, ein Dorn im Auge. Genauso die Mehrfachnutzung - ein Kunde kauft und betreibt eine legale Version, hat aber zusätzlich 3 andere Installationen in Betrieb (Support kann er damit u.U. auch noch erhalten, da er ja als legaler Nutzer auftreten kann).

Viele Softwarehersteller sind sich der Tatsache bewußt, dass es keinen 100%-igen Schutz gibt und sie Missbrauch nicht überall und zu jedem Zeitpunkt zu 100% unterbinden können - wenn sie aber 90% potenzieller illegaler Kopien unterbinden können ist das ein deutlicher Gewinn für sie.


Mit freundlichen Grüßen
S. Goers

13.06.2008 10:24 S. Goers ist offline Email an S. Goers senden Beiträge von S. Goers suchen Nehmen Sie S. Goers in Ihre Freundesliste auf
S. Goers
Grünschnabel


Dabei seit: 11.06.2008
Beiträge: 5

Zitatantwort auf diesen Beitrag erstellen Diesen Beitrag editieren/löschen Diesen Beitrag einem Moderator melden       IP Information Zum Anfang der Seite springen

Hallo uhabber,

Zitat:
Original von uhabber
Da ich in Purebasic schreibe und Teste muss ich mir alles selber schreiben weil kein Hersteller Purebasic direkt unterstützt.
(Dll anbinden , Crypt-tool...USW)




SG-Lock unterstützt Purebasic seit 2005.
Auf der beiliegenden SDK-CDROM finden Sie diese im Verzeichnis /Includes (wo auch die Unterstützung aller anderen Sprachen bzw. Entwicklungumgebungen zu finden ist).


Mit freundlichen Grüßen,
S. Goers

13.06.2008 10:31 S. Goers ist offline Email an S. Goers senden Beiträge von S. Goers suchen Nehmen Sie S. Goers in Ihre Freundesliste auf
uhabber uhabber ist männlich
Mitglied


Dabei seit: 02.02.2008
Beiträge: 37

Zitatantwort auf diesen Beitrag erstellen Diesen Beitrag editieren/löschen Diesen Beitrag einem Moderator melden       IP Information Zum Anfang der Seite springen

ja Sg-lock

ich habe mir Sg-lock angesehen da hatte ich noch kein interesse an purebasic

das was ich jetzt schreibe ist mein erstes Purebasic Projekt

hätte ich purebasic vor 5 jahren schon gehabt dann wäre ich schneller fertig geworden mit dem Programmieren

aber man lernt ja nie aus

leider hat SG-lock keine Netzwerk Version
also kommt SG-Lock nicht für mich in Frage da ich auf Netzwerk angewiesen bin.


sorry

13.06.2008 11:24 uhabber ist offline Email an uhabber senden Homepage von uhabber Beiträge von uhabber suchen Nehmen Sie uhabber in Ihre Freundesliste auf
uhabber uhabber ist männlich
Mitglied


Dabei seit: 02.02.2008
Beiträge: 37

Zitatantwort auf diesen Beitrag erstellen Diesen Beitrag editieren/löschen Diesen Beitrag einem Moderator melden       IP Information Zum Anfang der Seite springen

Was macht dann den Sg-Lock kundenkodiert (OTP) nur die 48 Byte Auth Code oder noch andere Daten das geht aus der Dokumentation nicht hervor?

16.06.2008 14:10 uhabber ist offline Email an uhabber senden Homepage von uhabber Beiträge von uhabber suchen Nehmen Sie uhabber in Ihre Freundesliste auf
Michael Bauer Michael Bauer ist männlich
Administrator


Dabei seit: 03.02.2007
Beiträge: 127

Zitatantwort auf diesen Beitrag erstellen Diesen Beitrag editieren/löschen Diesen Beitrag einem Moderator melden       IP Information Zum Anfang der Seite springen

Hallo uhabber,

anhand der Doku ist nur zu entnehmen, dass der Auth.-Code kundenspezifisch ist. Ich denke jedoch, dass jeder Dongle noch kundenspezifische Informationen enthält, die aus dem Auth.-Code abgeleitet sind. Somit ist ein Dongle-Zugriff nur mit richtigem Auth.-Code möglich. Wäre dies nicht so, dann könnte ja jeder der im Besitz eines Auth.-Code ist auf jeden x-beliebigen Dongle zugreifen.

Gruß
Michael

17.06.2008 18:56 Michael Bauer ist offline Email an Michael Bauer senden Homepage von Michael Bauer Beiträge von Michael Bauer suchen Nehmen Sie Michael Bauer in Ihre Freundesliste auf
uhabber uhabber ist männlich
Mitglied


Dabei seit: 02.02.2008
Beiträge: 37

Zitatantwort auf diesen Beitrag erstellen Diesen Beitrag editieren/löschen Diesen Beitrag einem Moderator melden       IP Information Zum Anfang der Seite springen

Wenn das so ist wie ich auch vermute.
und man könnte die TEA-Schlüssel lesen

ZUKUNFT NICHT FÜR U2 MODELL

so braucht man nur den Authcode tauschen gegen einen anderen und die gelesensen TEA-Schlüssel Programmieren

und durch eigene Dongle tauschen fertig.

man könnte ja den auth-Code zur Berechnung von Variablen benutzen und so mit dem Programm verschweissen als Schutz.

REALITÄT

Dongle als Schutzhardware muss immer kundenspezifische Daten haben welche in die Verschlüsselung oder Sicherheits-Marken (Random SEEDS) einfliessen sollten

das ist meine Meinung.

18.06.2008 06:28 uhabber ist offline Email an uhabber senden Homepage von uhabber Beiträge von uhabber suchen Nehmen Sie uhabber in Ihre Freundesliste auf
ganser
Grünschnabel


Dabei seit: 07.02.2010
Beiträge: 1

SEC-Dongle Zitatantwort auf diesen Beitrag erstellen Diesen Beitrag editieren/löschen Diesen Beitrag einem Moderator melden       IP Information Zum Anfang der Seite springen

gibt es eigentlich für die dongles der firma SEC Hannover halbwegs aktuelle treiber um den dongle zu nutzen? ich habe nur nt-treiber stand 1999. damit wird der dongle leider nicht mehr erkannt (xp alle versionen mit und ohne sp's)

07.02.2010 15:41 ganser ist offline Email an ganser senden Beiträge von ganser suchen Nehmen Sie ganser in Ihre Freundesliste auf
Seiten (3): « vorherige 1 [2] 3 nächste »  
Neues Thema erstellen Antwort erstellen
Gehe zu:

Links / Impressum
Powered by Burning Board © 2001-2004 WoltLab GmbH
Partnerseiten: virenschutz.info | Hakin9.org