Theoretische Frage zu DEC 5.2

[Dino3]

Hallo zusammen,

ich habe mich neu angemeldet, verfolge aber die Beiträge schon eine ganze Weile.

Erstmal Hutab am Hagen und alle, die das Thema Verschlüsselung beherrschen. Die
Beiträge im Thread aus 2008 sind meisterlich. Dazu habe ich jetzt eine Frage:

Ist DEC hauptsächlich nur dafür gedacht Daten zu ent-/verschlüsseln?
Ich habe bei mir folgendes Scenario:

ich möchte mein Programm an Lizenznehmern verteilen. Um es vor Raub zu schützen
suchte ich nach einer Idee und mit DEC habe ich eigentlich ein gutes Werkzeug
gefunden.

Ich würde jetzt hingehen, ein kleines Programm schreiben mit
Lizenznamen, MAC-ID, Ablaufdatum und Passwort. ( Würdet Ihr noch etwas hinzufügen? )
Das schicke ich verschlüsselt als Key an den Lizenznehmer. Mein Programm liest
die Daten aus und alles klappt.

Jetzt zur eigentlichen Frage:

Was ist, wenn ein mittelbegabter Crack in meinem Programm nach dem Passwort sucht.
Damit kann er doch einfach das Key-File aushebeln, oder?

Und was ist, wenn er die verräterische Einsprugadresse zum encrypten und damit das
Passwort findet?

Oder mache ich mir zu viele Sorgen?


Eins zum Schluß: die Daten sind absolut sicher, keine Frage, jedoch finde ich den
Schwachpunkt beim Passwort. Wie macht Ihr das dort sicher?

Ich wünsche jedem einen guten Rutsch. Und danke für Antworten.

[Aphton]

Die Art deiner Frage wird wieder eine Riesendiskussion verursachen, wo jeder seinen Senf darüber gibt, wie oder ob soetwas überhaupt machbar ist (verschiedene Philosphien).
Letzendlich wirst du eine ähnliche Antwort bekommen:
1. Es wird schlussendlich knackbar bleiben.
2. Was du tun kannst, ist, es zu erschweren.

Meines Erachtens nach ist es am besten, das ganze serverseitig zu lösen indem die Anwendung jedesmal beim Start nen kurzen Check bei nem Server macht.

[BUG]

Zitat:

Zitat von Dino3 (Beitrag 1197249)

Damit kann er doch einfach das Key-File aushebeln, oder?

Das stimmt. Dieses Problem ließe sich mit asymmetrischer Verschlüsselung umgehen.
Damit hättest du erreicht, dass ein Crack das Programm selbst manipulieren muss und nicht einfach gültige Keyfiles erzeugen kann. Das ist schon einmal gut :stupid:


Dann bleibt das Problem das dein Cracker deine ganze Lizenzverwaltung wegpatchen kann. Das kann man nur erschweren.
Suche im Forum mal nach Kopierschutz, Anticrack,Seriennummer, crackme oder keygen, das Thema wurde schon oft diskutiert.

Und dann gibt es noch die uralten Seiten:

• http://www.inner-smile.com/nocrack.phtml
• http://www.s-a-ve.com/faq/Anti-Cracking-Tips-2.htm

[dunningkruger]

Gegenfrage: Was passiert mit einem lediglich durchschnittlich begabten Anwender deines Programms, wenn er sich nur eine neue Netzwerkkarte einbaut, die eine andere MAC-ID hat?

Im Prinzip erschwerst du *NUR* den legalen Käufern das Update, den illegalen Rest kümmert das herzlich wenig...

Solchen "Verteilungsschutz" liebe ich über alles, da nur die legalen Käufer gequält werden :evil::twisted:

[Aphton]

Heutzutage geht der Trend übrigens in Richtung DLC - zumindest bei Spielen - siehe LoL.. Wollte es nur mal anmerken

[cookie22]

Hallo,

frohes Neues Jahr. :)

Du sollest dich als erstes fragen, ob sich der Aufwand überhaupt ansatzweise lohnt. Ist dein Programm so gut, dass es jemand cracken will. Wenn "Ja", dann passiert das sowieso, egal was du dagegen unternimmst. Wenn "Nein", brauchst du dir die Arbeit garnicht zu machen.

Auf keinen Fall sollest du deine Lizensierungsmethode an hardware festmachen, denn so erschwerst du dem User die flexible Nutzung ungemein. Vielleicht möchte er das ganze ja auf unterschiedlichen Rechnern nutzen und installieren.

Wenn dein Programm wirklich sehr "wertvoll" ist, solltest du ein Dongle-System in betracht ziehen.

Ich persönlich halte jedoch jede Sekunde die man in sowas steckt für verschwendete Zeil. Ich kenne kein bekanntes Programm, dass nicht spätestens eine Woche nach Release gecrackt worden wäre. Die arbeit hätten sich die Leute sparen können.

Auf keinen Fall sollest du dich zu "Cripware" hinreissen lassen und zum Testen etwas ausliefern, das irgendwie von den Features her beschnitten ist. So etwas verkauft sich nicht gut.

Sperr dein Programm mit einer einfachen Shareware-Komponente, mehr Aufwand zu betreiben ist nur Zeitverschwendung. Investiere die gewonnene Zeit lieber ins Programm selbst oder in die Vermarktung.

[Delphi-Laie]

Zitat:

Zitat von Dino3 (Beitrag 1197249)

ich möchte mein Programm an Lizenznehmern verteilen. Um es vor Raub zu schützen
suchte ich nach einer Idee und mit DEC habe ich eigentlich ein gutes Werkzeug
gefunden.

Das ist Ansichtssache. Zwar mag das DEC schnell, sicher und zuverlässig sein, jedoch ist für mich fehlender Quelltext ein Auschlußkriterium, weshalb man von den erstgenannt vermuteten Eigenschaften leider nur die erste prüfen kann. Natürlich efordern auch die beiden anderen letztlich Expertenwissen, das die allermeisten (mich eingeschlossen) nicht vorweisen können, jedoch ist es schon eine erhebliche Beruhigung, wenn nicht nur eine Person Herrscher über die Quelltexte ist.

[BUG]

Zitat:

Zitat von Delphi-Laie (Beitrag 1197308)

Das ist Ansichtssache. Zwar mag das DEC schnell, sicher und zuverlässig sein, jedoch ist für mich fehlender Quelltext ein Auschlußkriterium, weshalb man von den erstgenannt vermuteten Eigenschaften leider nur die erste prüfen kann.

Zitat:

Zitat von DEC 5.2 README

Part I is freeware shipping with the sources.

Part II (also known as DECMath) is not available as freeware and it's distribution is
only allowed for noncommercial or academical use. Please check back with the original
author regarding any commercial use. Part II is only available in the archives for
compatibility reasons. It is distributed as precompiled Delphi unit binaries
for D5, D6 and D7.

Soweit ich weiß, war der Grund für die nicht-Offenlegung von Teil 2 die Vermeidung von Softwarepatentproblemen. [EDIT]Erklärung von Hagen gibt es hier.[/EDIT]
Teil eins sollte für Anwendungen eh der interessantere sein.

Insgesamt soll der DEC-Quelltext ja etwas umständlich / schwer verständlich sein, da einige Teile auf spezielle Anwendungsfälle angepasst sind und kräftig optimiert wurde.
Ich hab aber noch nicht reingeschaut.

[Dino3]

Zitat:

Zitat von BUG (Beitrag 1197255)

Zitat:

Zitat von Dino3 (Beitrag 1197249)

Damit kann er doch einfach das Key-File aushebeln, oder?

Das stimmt. Dieses Problem ließe sich mit asymmetrischer Verschlüsselung umgehen.
Damit hättest du erreicht, dass ein Crack das Programm selbst manipulieren muss und nicht einfach gültige Keyfiles erzeugen kann. Das ist schon einmal gut :stupid:


Dann bleibt das Problem das dein Cracker deine ganze Lizenzverwaltung wegpatchen kann. Das kann man nur erschweren.
Suche im Forum mal nach Kopierschutz, Anticrack,Seriennummer, crackme oder keygen, das Thema wurde schon oft diskutiert.

Und dann gibt es noch die uralten Seiten:

• http://www.inner-smile.com/nocrack.phtml
• http://www.s-a-ve.com/faq/Anti-Cracking-Tips-2.htm

Danke für die schnelle Antwort.
Habe mir mal die Seiten angesehen, und wie ich es auch drehe, es hängt an der Schnittstelle für den Check.
Ich werde wohl an verschiedenen Orten und Zeiten Prüfungen einbauen und dann reicht es. Das ganze soll ja
nicht ausarten und nur für den 'gewöhnlichen' Hacker reichen.

Danke nochmals.

[Dino3]

Zitat:

Zitat von dunningkruger (Beitrag 1197256)

Gegenfrage: Was passiert mit einem lediglich durchschnittlich begabten Anwender deines Programms, wenn er sich nur eine neue Netzwerkkarte einbaut, die eine andere MAC-ID hat?

Im Prinzip erschwerst du *NUR* den legalen Käufern das Update, den illegalen Rest kümmert das herzlich wenig...

Solchen "Verteilungsschutz" liebe ich über alles, da nur die legalen Käufer gequält werden :evil::twisted:

Dachte zuerst, wer ändert schon eine Netzwerkkarte (gibs die überhaupt noch?) ?
Doch dann hab ich weiter gedacht: ich will mein Programm einem User übergeben, der es dann aber auf verschiedene Rechner installieren kann.
Somit lasse ich die MAC-Prüfung weg.

Danke.