Strings maskieren

Auf die Art der Verbindung habe ich keinen Einfluß. Pro Applikation gibt es ein BN+PW. Die muß ich nun irgendwie ausliefern. Mir geht es nur darum sie vor einen RessourcenGrabber zu schützen. (Diese Programme listen ja zB. alles Strings aus die in einer Exe vorhanden sind)
Und wenn ich schonmal dabei bin kann ich auch einige andere Daten verstecken...

Ich dachte da mehr an sowas:
// Anstatt:
AccessServer("benutzer", "Passwort");
// Dieses:
AccessServer(encrypt("flseofhjae"), encrypt("gtesrgsed"));

Es muß kein High End sein. Notfalls mache ich in encrypt() einfach nur ein XOR... vielleicht habt Ihr auch eine bessere Idee.

Äh anstatt encrypt meinte ich natürlich decrypt:

frenki

Seichere doch einfach den MD5-Hash des Passwortes. Beim Login prüftst du einfach den Hash des Passwortes mit dem gespeicherten.

Im ersten Posting habe ich mich zu ungenau ausgedrückt. Es geht mir nur um das erscheinen sensibler Strings in der kompilierten Exe. (Ressourcen Grabber)

Mit der Login Routine habe ich nichts zu tun. Ich binde nur vorgefertigte Module ein. Bei einem der Funktionen muß ich Nutzername (mein AppName) und Passwort (auch schon vorgegeben) angeben. Ich MUß dieser Funktion die echten Werte übergeben. Ich wollte aber nicht das sie einfach mit einem Ressourcen Grabber auslesbar sind... ich habe die XOR Lösung bereits implementiert.

PS: Gibt es wirklich keinen XOR Operator? *tze*

#define XOR(X, Y) (X & ~Y) | (~X & Y)

thordk

jo, den gibs: ^

Tatsache, es funktioniert. Im Web stand es anders.
Auf der anderen Seite schon komisch das 7^2=5 gilt

rüdiger

Martin L schrieb:

Tatsache, es funktioniert. Im Web stand es anders.
Auf der anderen Seite schon komisch das 7^2=5 gilt

Was ist daran komisch? So funktioniert XOR. Schreib es dir doch mal binär hin :p

AccessServer(encrypt("flseofhjae"), encrypt("gtesrgsed"));

Das ist ja kein wirklicher Schutz.

Hast Recht. Hätte man XOR einfach als Schlüsselwort definiert, könnte ja jeder Bäckergeselle Programme schreiben

Die ersten beiden Treffer sagen man solle XOR nachbilden:
http://www.google.de/search?hl=de&client=firefox-a&rls=org.mozilla%3Ade%3Aofficial&hs=R0e&q=c%2B%2B+xor&btnG=Suche&meta=lr%3Dlang_de
Der Operator scheint nicht allzu bekannt zu sein...

Wie man sieht kann man mit dem Wissen um den ^ Operator kann sogar

Selbstständiger Diplom-Informatiker

übertrumpfen:

C++ stellt keinen eigenen Operator für die Entweder-Oder-Verknüpfung zur Verfügung. Eine solche Verknüpfung wird oft auch XOR genannt. Natürlich ist es möglich, mit Hilfe von UND und ODER...

Quelle:
http://www.willemer.de/informatik/cpp/boolexpr.htm

Schutz: Ich habe mal gehört das man Api Calls abfangen kann. (Hooks). Gilt das nur für die WinApi oder auch für normal Funktionen in DLLs? Wie würdest Du meinen "Schutz" knacken? Außer den Assemblercode Schrittchen für Schrittchen nachzuvollziehen. (Unter der Vorraussetzung das ein optimierender Kompiler mir keinen Strich durch die Rechnung macht.)

Ach ja, und den Netzverkehr sniffen auch mal ausgenommen, weil das nicht mehr unter meiner Verantwortung fällt, bzw ich gar nicht weiß ob da was verschlüsselt wird.

rüdiger

Der Willemer Typ schreibt eh viel scheiße. Ignorier ihn einfach!

Das zu knacken ist doch kinder leicht. Einfach einen Debugger nehmen und das war's schon.

Er hat sogar diese Bücher geschrieben:
2002: Wie werde ich UNIX-Guru? Galileo-Press
2003: Einstieg in C++. Galileo-Press
2004: Wie werde ich UNIX-Guru? Galileo-Press. Zweite Auflage.

Komische Sache. Vielleicht ein Fundamentalist der meint das das alte C Zeugs nicht mehr unter C++ verwendet werden soll.

Du würdest also auf die Assembler Ebene runter und so an das Password? Dummerweise muß ich dieser Funktion einen plain Text übergeben. Ich kann also nicht viel mehr machen. Zumal ich eine DLL einbinde und keine Lib... auf der anderen Seite ist die Funktion nicht so wichtig und am Server kann er nicht viel kaputt machen. Und wenn es dennoch Ärger gibt... regnet sie auf den Dev der DLL runter.