Textdatei Human unreadable abspeichern

[izoards]

Hallo Zusammen,

ich möchte für mein bereits geschriebenes Programm, eine Demoversion erstellen, welche nach x - Durchläufen aufhört zu arbeiten.
ich habe mir nun überlegt, dass ich ein File unter ressources ablege, welches den Counter beinhaltet. Das File soll für ein Mensch unleserlich sein. Da ich bereits eine RSA Verschlüsselungsklasse verwende, dachte ich, ich verschlüssle die Info einfach und entschlüsse diese dann wieder. Da jedoch für die Entschlüsselung der private key verwendet werden muss, musste ich diese Idee wieder verwerfen.

Nun meine Frage, gibt es andere Möglichkeiten den Fileinhalt für ein Mensch unleserlich abzuspeichern?
Oder gibt es andere Ansätze, um eine Demoversion nach x - „Durchläufen“ zu sperren?

besten Dank für eure Hilfe

 

[izoards]

Ups, noch ein überlegungsfehler gemacht, ich kann das file in ressource ja gar nicht verändern…

 

[Robert Zenz]

Uff, soooo viele Ansaetze, und alle davon leicht auszuhebeln auf die ein oder andere Art und Weise. Also zuerst musst du dir ueberlegen was genau du verhindern willst, wieviel Arbeit du bereit bist hier zu investieren und wieviel moegliche Benutzeralptraeume du bereit bist zu akzeptieren.

Die einfachste Methode wird sein du legst eine Datei irgendwo im User-Configuration-Directory ab, das ist unter Linux zum Beispiel unter "$XDG_DATA_HOME". Dort kannst du dir eine Datei oder ein Verzeichnis erstellen und dort deine Infos ablegen. Wenn du die Datei verschluesseln willst, kannst du ja einfach einen hart-kodierten symmetrischen Schluessel verwenden, weil wie du ja bereits gemerkt hast, musst du den ohnehin mit ausliefern. Das waere eigentlich das einfachste. Wenn jemand die Datei loescht, funktioniert dein Programm halt wieder.

Das kannst du nach belieben ausbauen und noch komplizierter gestalten, mit mehr Orten wo du die Infos ablegst und so weiter, aber das grundlegende Problem, naemlich dass man es sehr einfach umgehen kann, wirst du nicht los. Der naechst beste Schritt waere dann schon eine komplette Lizen-Mechanik mit einer Demo Lizenz welche ablaeuft, und signiertem jar. Wieder, kann man relativ einfach umgehen, aber es wird schon schwieriger, aber ist relativ gut mehr Aufwand.

Am Ende musst du dich auch fragen ob all diese Anstrengungen Sinn machen. Ist die Demo oeffentlich im Internet zugaenglich, macht es schon Sinn einen gewissen Schutz zu haben, aber er wird dir am Ende nichts helfen. Hast du einen eingen Kundenkreis welche einfach nur die Software testen sollen, wuerde ich das eventuell nicht mal verhindern. Insbesondere wenn die Kunden Wartungsvertraege haben mit dir oder euch, dann wuerde ich denen einfach die Software geben und wenn sie sie brauchen bekommen sie dafuer dann Rechnungen.

Anders sieht es, auf zum Beispiel Android aus, wenn es um eine App geht. Ich glaube mich zu erinnern dass es da einige Mechanismen gibt, mit denen du die App ueber die Google Dienste sichern kannst, aber ich mache keien Android Entwicklung.

 

[EinNickname9]

Das, wonach du suchst, ist theoretisch und praktisch nicht realisierbar. Ein funktionierendes System kann sich nicht selber funktionsunfähig machen, wenn es dafür funktionieren muss, das ist ein Widerspruch... Mehr als etwas Obfuskation ("Vernebelung"), um es anderen zu erschweren, ist nicht möglich.

Zu deiner eigentlichen Frage: Das geht durchaus, wenn du den Text binär oder zum Beispiel als zip stream abspeicherst, kann ihn keiner mehr lesen.

 

[kneitzel]

Robert hat das sehr schön zusammen gefasst. Wirklich absichern kann man es nicht. Man kann es aber erschweren:
a) Online Checks - dann musst Du halt einen Service betreiben, der Checks durchführt.
b) Anpassung der Software erschweren - Native Images sind hier bestimmt nicht schlecht.
Bei heutigen Anwendungen wäre es sogar denkbar, dass der Applikations-Kern online geladen wird - nach einer Autorisierung....

Aber alles legt die Latte nur deutlich höher - um das zu verdeutlichen: Andere Hersteller geben extrem viel Geld für diese Thematik aus und dennoch sind entsprechend gehackte Pakete im Umlauf. Und da gab es deutlich mehr Ansätze incl. Hardware Dongles und co!

 

[temi]

Wenn jemand die Datei loescht, funktioniert dein Programm halt wieder.

Das kannst du allerdings auch so machen, dass die Datei auf jeden Fall vorhanden sein muss, damit das Programm funktioniert. Der Inhalt ist dann entweder ein Counter für den Demozeitraum oder die gültige "Lizenz" für den normalen Betrieb.

Viel mehr Mühe würde ich mir wohl nicht machen, denn geknackt werden kann alles. Die Frage stellt sich, wie versiert dein Kundenkreis ist und das dann auch macht.

 

[kneitzel]

Bei einer Offline Lösung ist das eh immer möglich. Du kannst ja gar nicht wissen, ob ein System etwas schon gemacht hat oder nicht:
- Ich habe eine VM und auf der mache ich das. Da kann ich dann problemlos immer auf den Snapshot zurück gehen vor der ersten Installation. Damit kann auch ein zurücksetzen der Zeit verbunden sein. Also trivialer Einsatz vorhandener Technologie und es ist vollkommen egal, was du als offline Lösung gebaut hast.
- Das mit der "VM" gibt es teilweise auch mit Windows Board-Mitteln. AppV bildet einen Layer über dem System und Änderungen an den Layern beeinflussen das Basissystem nicht. Ist ganz schön - da kann Deine App sogar mit Adminrechten das System32 Verzeichnis löschen und es passiert nichts außer eben für Deine App. Also einmal die App entsprechend in ein AppV Container packen und dann kann man mit einem Befehl die "User Änderungen" weglöschen.

 

[izoards]

Besten Dank für all eure Infos und Bemerkungen.
Es ist nicht mein Anspruch etwas unknackbares zu erstellen. Auch der Kundenkreis wird sich nicht mal die Mühe machen, im Installationspfad die Dateien anzuschauen. Trotzdem finde ich, es macht einen professionelleren Eindruck, wenn das Programm erst mit einer "Lizenz" läuft.
Dies habe ich bereits umgesetzt mit einer digitalen Signatur eines Lizenz-Files, das Programm läuft dann halt nur auf dem einen PC, das ist auch o.k. so. (Ich weiss, die Kunden werden keine Freude haben, Sie sind jedoch überschaubar, daher sehe ich hier kein Problem)

Jetzt habe ich mir überlegt, ich könnte ja beim ersten Start des Programms, zwei Files erstellen. (Irgendwo in einem Pfad und den Inhalt Binär abspeichern (Danke für diesen Hinweis)). Das eine File beinhaltet den Durchlaufscounter, der andere einfach nur, dass das Programm schon gestartet wurde.
Anstatt das Lizenz File direkt beim Start zu prüfen, würde das dann erst nach dem x-ten Durchlauf geschehen. Somit wäre ich wieder im Normalablauf.
Ich denke nicht, dass sich jemand die Mühe macht, diese Files zu finden. Im "Schlimmsten" Fall könnte er diese dann löschen, und das Programm würde wieder x - Mal laufen... .
Klar, kann man auch den Quellcode lesbar machen mit Programmen und dann dort direkt diesen Mechanismus umgehen, aber so versiert ist mein Kundenkreis nicht.

Von daher, glaube ich dass ist die einfachste Idee....
Die Software läuft auf Windows OS, so wie ich das sehe, kann ich diese beiden Files irgendwo beliebig ablegen?

 

[temi]

kann ich diese beiden Files irgendwo beliebig ablegen?

Naja, auch Windows hat ein Berechtigungssystem, was das u. U. verhindert.

In der Regel legt man Programmdaten unter C:/User/NameDesUsers/... ab. Oder so ähnlich.

 

[kneitzel]

Naja, auch Windows hat ein Berechtigungssystem, was das u. U. verhindert.

In der Regel legt man Programmdaten unter C:/User/NameDesUsers/... ab. Oder so ähnlich.

Also wenn es darum geht, wo Daten liegen sollten: Es gibt die Umgebungsvariable APPDATA.

Bezüglich AppData findet sich etwas mehr Beschreibung z.B. auf https://docs.microsoft.com/en-us/windows/apps/design/app-settings/store-and-retrieve-app-data
Der C# basierte Code ist natürlich uninteressant, aber da findet sich halt etwas Erklärung bezüglich local, roaming, u.s.w.

 

[izoards]

@kneitzel Danke für den Hinweis Das werde ich mir heute Abend mal anschauen und es versuchen über die Umgebungsvariable APPDATA umzusetzen.

EDIT: Also kann ich in diese APPDATA meine nötigen Daten schreiben und wieder lesen? (Ohne ein File erstellen zu müssen?)

 

[kneitzel]

APPDATA ist eine Umgebungsvariable, die auf ein Verzeichnis zeigt.

Und da ist es üblich, mit Unterverzeichnissen zu arbeiten:
%APPDATA%\<vendor>\<product>\xxxx

So finden sich Dateien zu IntelliJ Idea 2021.1 bei mir auf dem Windows System unter

%APPDATA%\JetBrains\IntelliJIdea2021.1\
Und in dem Verzeichnis sind dann ganz viele Dateien (Halt die User-basierte Konfiguration)

 

[mihe7]

Alternativ könntest Du auch die Preferences API verwenden. Unter Windows wird der Spaß dann in der Regel in der Registry abgelegt.

 

[izoards]

Hat soweit alles geklappt Die Demoversion läuft. Habe es mit APPDATA und der Preferences API umgesetzt.
Danke @kneitzel & @mihe7 🙏

Jetzt wollte ich ProGuard für die Code Verschleierung benutzen. Ich benutze das GUI. Leider kommen hier haufenweise Fehlermeldungen und ich kriege es nicht hin. Gibt es da irgendein Trick, den ich beachten muss?

 

[Robert Zenz]

Gibt es da irgendein Trick, den ich beachten muss?

Ja, uns die Fehlermeldungen sagen.

 

[izoards]

Gerne, hier die Fehlermeldungen am Schluss:

-> Haufenweise von diesen Meldungen:

Maybe this is library method 'sun.text.normalizer.UnicodeSet { UnicodeSet(java.lang.String); }'
Maybe this is library method 'sun.tools.jar.JarException { JarException(java.lang.String); }'
Maybe this is library method 'sun.util.locale.LocaleSyntaxException { LocaleSyntaxException(java.lang.String); }'
Maybe this is library method 'sun.util.logging.PlatformLogger$LoggerProxy { PlatformLogger$LoggerProxy(java.lang.String); }'

        
Dann am Schluss diese Fehlermeldungen:         
        
Note: there were 11 classes trying to access annotations using reflection.
      You should consider keeping the annotation attributes
      (using '-keepattributes *Annotation*').
      (https://www.guardsquare.com/proguard/manual/troubleshooting#attributes)
Note: there were 6 classes trying to access generic signatures using reflection.
      You should consider keeping the signature attributes
      (using '-keepattributes Signature').
      (https://www.guardsquare.com/proguard/manual/troubleshooting#attributes)
Note: there were 1 classes trying to access enclosing classes using reflection.
      You should consider keeping the inner classes attributes
      (using '-keepattributes InnerClasses').
      (https://www.guardsquare.com/proguard/manual/troubleshooting#attributes)
Note: there were 13 unresolved dynamic references to classes or interfaces.
      You should check if you need to specify additional program jars.
      (https://www.guardsquare.com/proguard/manual/troubleshooting#dynamicalclass)
Note: there were 66 accesses to class members by means of reflection.
      You should consider explicitly keeping the mentioned class members
      (using '-keep' or '-keepclassmembers').
      (https://www.guardsquare.com/proguard/manual/troubleshooting#dynamicalclassmember)
Warning: there were 1375 unresolved references to classes or interfaces.
         You may need to add missing library jars or update their versions.
         If your code works fine without the missing classes, you can suppress
         the warnings with '-dontwarn' options.
         (https://www.guardsquare.com/proguard/manual/troubleshooting#unresolvedclass)
Warning: there were 121 unresolved references to program class members.
         Your input classes appear to be inconsistent.
         You may need to recompile the code.
         (https://www.guardsquare.com/proguard/manual/troubleshooting#unresolvedprogramclassmember)
Warning: there were 73 unresolved references to library class members.
         You probably need to update the library versions.
         (https://www.guardsquare.com/proguard/manual/troubleshooting#unresolvedlibraryclassmember)
Please correct the above warnings first.

 

[Robert Zenz]

You may need to add missing library jars or update their versions.

Genau das. Der Klassenpfad welchen du ProGuard angegeben hast ist unvollstaendig, es koennen nicht alle Referenzen beziehungsweise verwendete Klassen und Schnittstellen aufgeloest werden, daher kann ProGuard auch nicht weiter machen weil es nicht alles aufleosen kann. Wenn du dir sicher bist dass der Klassenpfad aber so stimmt, kanns tu du mit "-ignorewarnings"/"-dontwarn" die Warnungen ignorieren lassen.

...das steht aber alles in dem Link in der Fehlermeldung.

 

[izoards]

Hm, ich habe einfach das JAR, welches ich über Maven generiert habe in ProGuard angegeben.
Dachte dort sind die nötigen Referenzen vorhanden...
Ich verstehe nicht was wie, oder wo ich den Klassenpfad angeben muss...