Quelltext schützen

l'abra d'or

Eine mögliche Lösung wäre doch, dass du die Strings schon verschlüsselt in den Quelltext reinschreibst, wenn du sie brauchst entschlüsselst du sie wieder.
Du kannst das auch in den Buildprozess integrieren: Aus einem TextFile werden die Strings samt späterem Bezeichner eingelesen, verschlüsselt und in ein c(++)-file geschrieben. Diese Quelldatei wird kompiliert (oder als .h eingebunden). Bei Benutzung eben nach Bedarf entschlüsseln.
Ich hab das selber noch nicht gemacht, sollte aber theoretisch funktionieren.

jd

Nein nicht das ich wüste. Aber was ist an den SQL-Strings so schlimm? Um daraus eine DB-Struktur ab zu bilden brauch man schon eine Weile und um dann noch Unfug damit zu machen, müsstest du in deinem Programm schon derbe Fehler gemacht haben (SQL-Injection), oder der DB-Server ist nicht sicher. Das hier ist nie eine Lösung: http://de.wikipedia.org/wiki/Security_through_obscurity Ich würde ehr die Vorgehensweise ändern:

- SQL Statements nicht einfach an den DB-Server schicken
- Mit Prepared Statements arbeiten
- Eventuell eine Beschreibungs-Sprache verwenden (XML)
- SQL-Server sicher machen...
- SQL-Injections vermeiden
- Input Parameter müssen validiert werden

Somit deckst du schon mal eine menge Sachen ab. Was du natürlich auch machen kannst ist die Tabellen-namen als MD5-Hash anlegen... jedoch wären wir dann wieder beim Thema "Security through Obsecurity"

DocShoe

Arghs, Posting nicht sorgfältig genug gelesen

Unter Windows könnte man Folgendes machen:
Du erzeugst für jedes deiner SQL Statements eine Textdatei, die du mit einem Verschlüsselungsalgorithmus, den du auch in deinem Programm einsetzen kannst, verschlüsselst. Die so verschlüsselte Binärdatei fügst du als Resource in dein Projekt ein.
In deinem Programm lädst du dann diese Resource, entschlüsselst sie und hast damit wieder deine Plaintext SQL Abfrage.
Ob das allerdings ausreicht musst du selbst abschätzen, diese Methode hat im Wesentlichen zwei Schwachstellen:

Das Kennwort zum Entschlüsseln liegt im Programmcode vor und lässt sich prinzipiell nicht verstecken. Du kannst es natürlich noch ein Mal verschlüsseln, aber dazu brauchst du wiederum ein Kennwort, das im Programmcode vorliegen muss...
Wenn jemand einen Packetsniffer installiert und alle Pakete auf Port 5432 mitschneidet kommt er auch an die Daten heran. Es sei denn, die pgSQL TCP/IP Verbindung verschlüsselt von Haus aus.

Edit:
Typos fixed

jd

Ich stimme DocShoe zu.

Aber mal eine andere Sicht, warum kann deine Anwendung sich eigentlich direkt mit der DB verbinden, da die SQL-Statements geschützt werden müssen, würde ich einfach vermeiden welche zu nutzen. Sprich ich würde eine Meta-Schicht einbauen mit der deine Software kommunizieren kann, das kann ein Webservice sein oder sonst was. Somit hast du in deiner Applikation lediglich einen Service Aufruf. Und der eigentlich Service führt dann das SQL aus und gibt dir das Resultat zurück. Somit ist deine Application DB-Free, SQL-Free und du brauchst nicht mit einer Verschlüsselung rum zu eiern, deren Passwort hinterlegt ist, das ist wie Schlüssel unter der Fußmatte.

Wenn du jetzt deine Software an 3. verteilst, sehen die lediglich Service aufrufe, somit ist es nahezu unmöglich auf den DB-Struktur zu schließen, noch wo der DB Server ist, oder was es für eine DB ist, geschweige denn an SQLs ran zu kommen.

Falls das alles nicht möglich ist, würde ich auch zu DocShoe's Methode tendieren.

so long
jd

Ciatronical

Ich denke dass ich die Methode von DocShoe wähle und die verschlüsselten Strings
aus einer externen Datei lade und danach entschlüssle.
Kennt jemand einen Codebeispiel zur Verschlüsselung??
DAnk und Gruß

Ronny

SeppJ

Einfach einen beliebig gewählten Wert zu jedem Zeichen XORen und zum Entschlüsseln das gleiche machen. Da du ohnehin nur security through obscurity machst lohnt sich mehr nicht. Woraufhin sich wiederum die Frage stellt, wieso du dann nicht eine der vorgeschlagenen funktionierenden Methoden wählst. Jemand der die Energie hat in deinem Quelltext nach den Datenbankabfragen zu suchen, der hat auch die Energie deinen Schlüssel aus dem Quelltext zu extrahieren. Du hängst bloß einen Vorhang vor dein Geheimnis mit der Aufschrift "Bitte nicht angucken".

berniebutt

Ciatronical schrieb:

Öffne ich das Executable mit einem Hexeditor so erkenne ich deutlich sämtliche Strings.

Ja das ist so möglich - man kann das auslesen selbst mit einem Texteditor!
Einfache - schon genannte - Abhilfe: kritische Strings mit Verschlüsselung in eine Datei packen und im Programm entschlüsseln. Algorithmen zur Verschlüsselung gibt es viele, manche top sicher, andere nicht. Wenn es nur um wenige feste Strings geht, empfiehlt es sich, diese in einer aufgeblähten Datei an nur dem Programm bekannten Stellen zu verstecken. Noch einige Manipulationen der Zeichen könnte das Ausspionieren verbessern.

jd

Irgendwie finde ich das komisch, wenn die SQL-Statements so unheimlich kritisch und Top-Secret sind, dann haben die in dem Programm einfach nichts verloren... Falls du das Programm + DB vertreibst, sind die Statements eh überflüssig denn mit der DB kann ich die auch selber schreiben, aber das wurde ja schon in den andere Postings durch gekaut

Ansonsten mach es wie die beiden über mir es beschrieben haben und hoffe einfach das keiner genug Energie hat das zu umgehen.

so long
jd

http://www.raptorfactor.com/compile-time-string-hashing-with-c0x/

Als Ansatz

zeusosc

ich verstehe nicht warum die meisten die kompletten SQL-Requests incl. Keys oder Tabellen name als string vorbauen müssen,...

Es würde doch reichen die Keys vereinzelt (verschlüsselt oder nicht) dynamisch zu laden, das gesamtliteral zur Laufzeit zu bauen und dann zu versenden,...

Diese dynamik verhilft zur Anpassbarkeit und sicherheit sowie, trotz höheren anfangsaufwand, zu verbesserten verwaltung,...

..
Vorhin meinte jemand das, wenn strings verschlüsselt in der executable liegen, der key auch darin ist. Das ist bedingt richtig. Wenn ich eine fixe permutation und/oder substitution evtl. noch einen filter hinzufüge findet man keinen char array in dem steht "[]{P.A.S.S.W.O.R.D.ö}][..."

Mir ist klar das in bezug einer festen Basisadresse des Progs ziemlich bald eine Bijektive Abbildung gefunden werden könne die mir dann sagt wie die encodeten literale aussehen könnten und nach denen ich suchen könnte,....

Davon ausgehend das man erstmalig keinen man in the midlle attacke erwartet und die Literale verschlüsseln will, sind doch eigentlich nur die tabellennamen und die keys von relevanz. D.h.:
Zerlege die REQUEST's in einzelne wörter, um sie zur laufzeit zusammenfügen zu können.
Verschlüssele nur die einzelnen wörter in abhängigkeit ihrer Länge, z.b. Multiplikation der Bildmatrizen mit Stringmatrizen um das decodierte wort zu bilden. (2^2,32,4^2,52,... immer auffüllen..)
Effektiv wäre einfach zb. ne LU-Zerlegung der Original"string"matrizen,...

najagut genug gelabert,...

mfg