Programm und Bilder schützen! Methoden?

[DelphiSecurity]

Hallo Delphi-Praxiser!

Jeder kennt das Problem, man will eine Software ausliefern, verkaufen oder weitergeben, aber man hat ein schlechtes Gefühl. Liegt es an der fehlenden Aktivierung? Ja. Auch eine Thema über das man nachdenken sollte ist das Mitliefern von Grafiken. "Roh" in .bmp, .img oder .png Dateien? Oder doch eher in einer wunderschönen imgres.dll?

Machen oder nicht machen, das ist hier die Frage.

Wir schützt ihr eure Software (Aktivierung?)?
Wie speichert ihr Bilder/Musik/Videos?

Postet eure Meinung und Vorschläage für mich, bin in diesem Thema Anfänger. (Aber keine Niedermachung andere Methoden!)

Gibt es Tutorials? (Beide)


DANKE schon mal.

[mkinzler]

Vielleicht solltest du den Betreff so ändern, dass man versteht, dass dies eine Frage sein soll

[himitsu]

Bilder als Bitmap mitliefern ... ihr habt wohl zuviel freien Speicher? (PNG, JPEG oder eventuell GIF)

Wie man Bilder mitliefert ist vollkommen egal, da man sowas eh nicht schützen kann. (1)

Als Ressourcen in einer DLL oder gar in der EXE macht es sich diesbezüglich schöner, da dann nicht Unmassen an Dateien einzeln mit ausgeliefert werden müssen und dann auf den PCs rumgammeln.




1:
- Ein Screenshot, abspeichern und schon hat man das Bild, egal wie/wo es gespeichert war.
- Genauso verhält es sich mit Texten ... spätestens, wenn man sowas anzeigt, ist der Schutz hinüber.
- Aus den Ressourcen holt jeder billige Res-Editor alles raus.
- Man könnte Verschlüsseln, aber zum Anzeigen muß man es entschlüsseln und schon liegt es ungeschützt im Speicher (wo man es auslesen kann) und es verschlüsselt anzuzeigen macht eh keinen Sinn.
- Man könnte es Komprimieren, was quasi einer Verschlüsselung gleich kommt, also keinen Schutz bietet, aber wenigstens Speicher spart.

[blackfin]

Es gilt der erste Grundsatz der IT-Sicherheit: Sobald der Benutzer volle lokale Kontrolle (root- / Admin-Zugriff) über den Rechner hat , auf dem die zu schützenden Dateien liegen, ist alles mit entsprechendem Aufwand crackbar.
Man kann das ganze durch Verschlüsselung nur erschweren.

Wenn es nur darum geht, den direkten Zugriff auf die Dateien zu verhindern, könntest du z.B. ein virtuelles Dateisystem für die Dateien einbauen.
Heisst, du lieferst die Dateien in einem selbstgeschriebenen Paketformat aus, aus dem die Anwendung liest.
(muss ja nicht die imgres.dll sein, sondern ein eigenes, propietäres Format, wie es z.B. fast alle Spiele-Hersteller machen)

Aktivierungsmöglichkeiten gibt es viele...Seriennummern-Eingabe, Online-Challenge-Response-Authentication usw....nur eine Frage, wie sehr man den Aufwand auf die Spitze treiben will
Das aufwändigste diesbezüglich, was ich mal gemacht habe, was eine Online-Aktivierung, bei der die Seriennummer der Festplatte, auf dem das Programm installiert wurde, durch eine eigene Hash-Routine geschickt wurde, das wiederum an einen Server übergeben wurde, der daraus den Aktivierungs-Key errechnet und zurücksendet.
Damit hält man schon mal viele normale Benutzer von der einfachen Weitergabe / Kopieren des Programms ab, echte "Cracker" wird man aber nie aufhalten

[DelphiSecurity]

Zitat von blackfin:

Es gilt der erste Grundsatz der IT-Sicherheit: Sobald der Benutzer volle lokale Kontrolle (root- / Admin-Zugriff) über den Rechner hat , auf dem die zu schützenden Dateien liegen, ist alles mit entsprechendem Aufwand crackbar.
Man kann das ganze durch Verschlüsselung nur erschweren.

Wenn es nur darum geht, den direkten Zugriff auf die Dateien zu verhindern, könntest du z.B. ein virtuelles Dateisystem für die Dateien einbauen.
Heisst, du lieferst die Dateien in einem selbstgeschriebenen Paketformat aus, aus dem die Anwendung liest.
(muss ja nicht die imgres.dll sein, sondern ein eigenes, propietäres Format, wie es z.B. fast alle Spiele-Hersteller machen)

Aktivierungsmöglichkeiten gibt es viele...Seriennummern-Eingabe, Online-Challenge-Response-Authentication usw....nur eine Frage, wie sehr man den Aufwand auf die Spitze treiben will
Das aufwändigste diesbezüglich, was ich mal gemacht habe, was eine Online-Aktivierung, bei der die Seriennummer der Festplatte, auf dem das Programm installiert wurde, durch eine eigene Hash-Routine geschickt wurde, das wiederum an einen Server übergeben wurde, der daraus den Aktivierungs-Key errechnet und zurücksendet.
Damit hält man schon mal viele normale Benutzer von der einfachen Weitergabe / Kopieren des Programms ab, echte "Cracker" wird man aber nie aufhalten

Bingo.
Gibt es eine Anleitung Tutorial wie man: Ein eigenes Packetformat erstellt |und| gibt es eine Anleitung wie man Grob Aktiviereungen gestalten könnte?

DANKE

[Phoenix]

Ich würde an der Stelle nichts selber machen. Man kann es nur falsch machen und damit steckt man Zeit in eine nicht ordentlich funktionierende Lösung und wiegt sich in falscher Sicherheit.

Ich würde an der Stelle ausschliesslich auf externe Lösungen setzen, z.B. die von WiBu oder wie hiess die Software nochmal die IBExpert schützt?

[DelphiSecurity]

OK, sonst noch Ideen (externe Sachen)?

[jaenicke]

Ich hätte da noch eine Lizenz von ExeStealth Unlimited herumzuliegen. Da ich es für wenig sinnvoll halte meine Open Source damit zu schützen, ist die bisher noch unbenutzt.

[turboPASCAL]

Zitat:

...Da ich es für wenig sinnvoll halte meine Open Source damit zu schützen ...

Hm, wäre ja mal 'ne Idee.

Also man könnte ja Beispielsweise einen Zip-Algo. anwenden und die Kennzeichnung ändern, dann das ganze "Geschnulle" in die Exe
und oder eine Resource *.DLL, *.DAT, *.BIN oder *.MACH_MICH_NICHT_AUF Datei Packen. Das hält dann schon den ein oder
anderen Möchtegernhäcker auf.


Wer an die Daten will kommt auch dran. (wenn man genug Ahnung von dem Kram hat, ist das kein Problem...)

[himitsu]

OpenSource:

Alle Variablen-, Konstanten, Klassen-, Methoden- und Prozedurnamen umbenennen ... jeweils ein/zwei Zeichen aus'm Unicode und die Strings+Zahlen als Resourcestring oder Konstanten auslagern.
Dann noch Codeteile wild in Includedateien verfrachten und keiner sieht mehr durch.

Seit D2009 kann man ja eine Variable "Hülfe" oder "櫔" anlegen.