String in Exe ändern

[jacky213]

Moin,

ich habe in meiner Anwendung einen String gespeichert. Dieser String hat einen festen wert. Allerdings muss genau dieser String auch mal erneuert werden, sodass er aber auch nach einen Neustart den neuen wert besitzt.

Mir ist klar, dass dies zur Laufzeit nicht möglich ist, also wollte ich euch fragen wie ich die Änderung des Strings mit einem zweiten Programm bewerkstelligen kann, während die Hauptanwendung geschlossen ist.

Die zweite kleine Anwendung soll also meine Haupt Exe datei durchsuchen und den String finden, mit dem neuen wert beschreiben und alles speichern, sodass mein Hauptprogramm beim nächsten start den neuen String nutzt.

[Luckie]

Warum speicherst du ihn nicht in einer Datei oder der Registry?

[PeterPanino]

Zitat:

Zitat von jacky213 (Beitrag 1426026)

... wie ich die Änderung des Strings mit einem zweiten Programm bewerkstelligen kann, während die Hauptanwendung geschlossen ist.

Da wird dein AntiViren-Programm möglicherweise etwas dagegen haben ...

Es gibt zwar eine Möglichkeit, die aber etwas aufwendig ist: Erstelle eine eigene Signatur, welche den gewünschten String enthält und signiere das Programm damit. Zum Ändern des Strings musst du dann nur das Programm neu signieren.

[Alallart]

Zitat:

Zitat von jacky213 (Beitrag 1426026)

...

Also den String in der Registry oder Ini speichern ist der einfachste Weg die Aufgabe zu lösen.

Allerdings gibt es auch die Möglichkeit einen String als Ressource zu speichern. Diese Ressource kann man dann ändern. Ich weiß, dass das geht, hab es mal gemacht, weiß aber aktuell nicht wie das geht. Da findet sich aber vermutlich irgendwo ein Tipp zu dem Thema.

Aber wie gesagt - Registry ist einfacher.

[hoika]

Hallo,

Zitat:

Allerdings muss genau dieser String auch mal erneuert werden, sodass er aber auch nach einen Neustart den neuen Wert besitzt.

Wie man das hinbekommt, weiss ich, aber deine Intentition ist nicht schlüssig.

Erzähl mal mehr über Dein Problem.

[PeterPanino]

Zitat:

Zitat von hoika (Beitrag 1426035)

Erzähl mal mehr über Dein Problem.

Ich bin sicher, dass er schon selber auf die Idee gekommen ist, den String in der Reg. oder sonstwo zu speichern. Er muss also einen Grund haben, die Information direkt mit dem Programm zu verbinden. Aus dieser Sicht ist eine Signatur ideal.

[hoika]

Hallo,
oder man packt den String als Ressource in die Exe (siehe Alallart).
Windows bietet dann Funktionen an, den Wert zu ändern.
siehe dazu
https://docs.microsoft.com/de-de/win...ting_Resources

Dann darf die Exe allerdings nicht signiert werden/sein,
weil das Ändern der Exe die Signatur zerschießt.

[Uwe Raabe]

Sollte die EXE nicht sowieso schreibgeschützt sein? Da könnte sonst ja jede Malware dran basteln.

Ich kenne jetzt die Hintergründe für diese Entscheidung nicht, aber ich würde auch in jedem Fall ein externes Setting (Registry, File, Ressource) vorziehen.

[PeterPanino]

Zitat:

Zitat von Uwe Raabe (Beitrag 1426055)

Sollte die EXE nicht sowieso schreibgeschützt sein? Da könnte sonst ja jede Malware dran basteln.

Völlig richtig. Also kommt nur das Prinzip der Metadaten in Frage, wenn die Anforderung lautet, die Information direkt mit der Exe zu verbinden. Und die einzig erlaubte Form von direkt verbundenen intrinsischen Exe-Metadaten ist eine Signatur.

[pesi]

Hmmm.... ist das ein "geheimer" String? Wenn nicht, wie wäre es denn wenn man dem Programm diesen String einfach als Startparameter übergibt?

[hoika]

Hallo,

Zitat:

Da könnte sonst ja jede Malware dran basteln.

Nicht, wenn die Exe signiert ist und die Signatur auch geprüft wird.

[jacky213]

In dem String befindet sich ein verschlüsselter Text. Der Text wird beim starten des Programms via Passwort abfrage entschlüsselt, sollte der Nutzer das Passwort nicht kennen, kommt er nicht weiter. Die Idee dahinter ist Simpel, wer das Passwort nicht kennt, der wird das Passwort auch nicht im Quelltext finden.

Ich wollte eine Funktion einbauen welche es dem Nutzer ermöglicht das Passwort zu ändern (Natürlich nur wenn er das alte Passwort kennt) und hierfür muss dieser String dann auch geändert werden.

Das mit der Signierung klingt sehr interessant. Danke für die ganze Ansätze ich mach mich mal an die Arbeit.

[Klaus01]

.. ist ja schön und gut wenn das Passwort verschlüsselt abgelegt wird.
Nur bei einer Passwort Authentifizierung wird normalerweise nicht das Passwort verglichen
sondern nur ein Hash (sha1, sha256 o.ä.) davon.
Natürlich muss auch der Hash geändert werden, wenn das Password geändert wird.

Vorteil des Hashes ist, dass man vom Hash nicht auf das Passwort rückschliessen kann.
Es spricht also erstmal nicht viel dagegen den Hash in der Registry oder in einer Datei abzulegen.

Grüße
Klaus

[Delphi.Narium]

Man kann an eine Exe beliebig viele Daten anhängen.

Nach dem Erstellen der Exe diese zum Schreiben öffenen. Ans Ende der Exe gehen und dort den Hash (z. B. MD5) des Passwortes ablegen. Die Exe wird dadurch um die Länge des Hashes größer.

Soll das Passwort geprüft werden, so öffnet man die Exe zum Lesen geht ans Ende minus Länge des Hashes Byte und liest der Länge des Hashes entsprechend viele Bytes. Der gelesene Wert muss mit dem Hash des Passwortes übereinstimmen.

[Klaus01]

.. nun wenn der User aber selber ein Passwort ändern will,
an die laufende EXE kann es nicht angehangen werden.
Dazu würde dann ein Hilfsprogramm benötigt, welches die EXE schließt
den Hash ändert und die EXE wieder startet.
Ob Virescanner von dem Vorgang begeistert sein werden - wage ich zu bezweifeln.

Wir wären damit dann wieder am Anfang des Threads
mit dem Unterschied das wir nun den Zweck wissen.

Grüße
Klaus

[Delphi.Narium]

Threadersteller sagt ja schon im Eingangspost, dass klar ist, dass eine derartige Lösung nicht zur Laufzeit funktioniert. Somit sehe ich da zuerst mal kein Problem.

Meine Exen erhalten alle (mit Hilfe eines AfterCompile-Experten) bei der Erstellung 'nen Hash verpasst und prüfen diesen beim Programmstart. Das funktioniert seit Jahren und Virenscanner haben da nix einzuwenden. In extrem seltenen Fällen scheitert diese Prüfung. Dann ist garantiert die Exe kaputt. Passiert bei Laufwerksfehlern oder fehlerhafter Datenübertragung im Netz. (In zwanzig Jahren so zwei- oder dreimal.)

Und ja: Virenscanner könnten bei soeiner Lösung durchaus Einwand erheben.

[dummzeuch]

Zitat:

Zitat von Delphi.Narium (Beitrag 1426157)

Man kann an eine Exe beliebig viele Daten anhängen.

Nach dem Erstellen der Exe diese zum Schreiben öffenen. Ans Ende der Exe gehen und dort den Hash (z. B. MD5) des Passwortes ablegen. Die Exe wird dadurch um die Länge des Hashes größer.

Soll das Passwort geprüft werden, so öffnet man die Exe zum Lesen geht ans Ende minus Länge des Hashes Byte und liest der Länge des Hashes entsprechend viele Bytes. Der gelesene Wert muss mit dem Hash des Passwortes übereinstimmen.

Nur, falls das jemand so implementieren will:
Man sollte zusätzlich zu den Nutzdaten einen möglichst eindeutigen Marker (vor und hinter den Daten) schreiben und diesen auch jedes Mal vor dem Zugriff überprüfen. Eine einfache Prüfsumme über diese Daten hat auch was. Sonst kommt nämlich irgendwann ein anderes Programm und hängt ebenfalls Daten an (z.B. gnugettext oder jcldebug) und schon knallt es und man sucht ewig den Fehler an der falschen Stelle.

[Delphi.Narium]

Ja, stimmt schon irgendwie. Mein Intention war halt mal 'ne Prüfsumme für meine Programme zu haben, die ich selbst verifizieren kann.

Da kam dann die Idee mit dem AfterCompile-Experten, der die MD5-Checksumme an die Exe hängt. Das lässt sich einfach überprüfen. Sinn war es ja, jede Änderung der Exe zu erkennen.

Wenn nun andere Routinen ebenfalls Daten an die Exe hängen kann das so nicht mehr funktionieren. In meinem Fall soll es auch nicht funktionieren ;-)

[stOrM]

Irgendwie erschließt sich mir der Sinn nicht ganz...
Solche Sachen wurden früher mal gerne eingesetzt um die Server diverser Trojaner nachträglich komfortable zu editieren...

Ansonsten würde ich wie Lucky schon schrieb eine zusätzliche Datei oder eben den Weg über die Registry nehmen.

Eine weitere Möglichkeit die ich mal genutzt habe, wäre der Windows Credential Manager.
Die Vorgehensweise war da z.B. mittels BCrypt (gibt es für Delphi, siehe Github MD5 kann ich nicht empfehlen...) das Passwort quasi Pre-hashed dort zu speichern.

Später im Hauptprogramm dann über einen Login Dialog das eingegebene Passwort hashen und diesen Hash mit dem aus dem Windows Credential Manager vergleichen, wäre der meiner Meinung nach eleganterer Weg.

[Delphi.Narium]

Irgendwas an 'ne Exe zu hängen oder gar 'ne Exe zu patchen ist für mich nix weiter als Spielerei.

Für 'nen professionellen Einsatz vollkommen ungeeignet.

Ein Passwort verschlüsselt in der Exe und die dann bei 'ner Passwortänderung (ohne sie neu zu kompilieren) zu ändern, ist schon etwas außergewöhnlich.

Aber es geht ;-)

[jacky213]

Erstmal vielen dank für die ausführliche Diskussion,

Zum einen habe ich auf den Einsatz von beispielsweise MD5 Hashes verzichtet, weil es Online schon einige sehr umfangreiche MD5 Datenbanken gibt. Sollte also ein User mal auf die Idee kommen und es für ratsam halten ein Passwort aus den Top 10 der beliebtesten Passwörter zu wählen, so währe auch der Hash im nu überwunden.

Zum anderen habe ich mich dazu entschlossen nun auch den Prüf String in einer Datei abzulegen. Die Sicherheit bleibt ja gleich. Da kann man meiner Meinung nach nur mit Brute Force ran und bei einer AES 128 Bit Verschlüsselung kann es eine weile dauern.

[CCRDude]

MD5 ist dafür ungeeignet, mindestens SHA-2 würde ich empfehlen.

Das Gegenmittel gegen Rainbow Tables sind schon seit Ewigkeiten Salts. Hashes ohne Salts sind genau so nachlässig wie MD5.

Ich weiß nicht recht, was AES 128 bei einer Speicherung des Passworts helfen soll. Da nehme ich einen Debugger und debugge das Programm bis zu der Stelle, an der der String Compare stattfindet, dann lese ich das Passwort trotzdem im Klartext.

[Sherlock]

Im Ernst und ganz konkret:
- Passwort nach einem Hashverfahren der letzten Dekade hashen und nur den Hash speichern
- Nach Drei Fehlversuchen das Konto sperren
--> Überhaupt kein Sicherheitsproblem, mit niemandem.

Und in einer Exe speichert niemand mit Sicherheitsanspruch irgendetwas. Sämtliche Sicherheitsprobleme der Gegenwart fußen auf einer irrigen Auffassung von Bequemlichkeit. Seit wann ist es bequem, dem User vierunddröflzig Fehleingaben zu erlauben? Seit wann ist es bequem eine Exe zur Laufzeit selbst zu patchen und damit alle Sicherheitsvorkehrungen zu alarmieren, die zum einen direkt Manipulationen von Exen überwachen und zum anderen nur Exen ausführen lassen, deren Hash einmalig abgenickt wurde.

Sherlock

[PeterPanino]

Zitat:

Zitat von pesi (Beitrag 1426107)

Hmmm.... ist das ein "geheimer" String? Wenn nicht, wie wäre es denn wenn man dem Programm diesen String einfach als Startparameter übergibt?

Gute Idee! Obwohl man die Startparameter aus den Prozessdaten auslesen kann. Der übergebene String müsste dann schon verschlüsselt sein.

[Moombas]

Also ich habe es immer so gemacht, das Programm-Passwörter als Parameter zu übergeben sind (jetzt mal vollkommen ab davon ob nun verschlüsselt oder nicht) und diese werden dann nicht mit einem fix einprogrammierten Wert verglichen, sondern mit einem Wert der in einer Datei im Netzwerk liegt.

Dadurch kannst du das Passwort jederzeit Zentral ändern, falls nötig und wenn du eine Logik (Verschlüsselung) hinterlegst mit der die beiden Werte abgeglichen werden, bist du schon auf einem guten Weg. Und(/Aber): Wenn kein Zugang zum Netzwerk besteht, kann die Anwendung (bei mir) daher nicht gestartet/ genutzt werden.

Natürlich ist dabei zu empfehlen eine Verschlüsselung zu nutzen, da der Wert ja im Netzwerk in einer Datei steht, weshalb ich selber auch nur den SHA2-Hash ablege.

[DieDolly]

Zitat:

sollte der Nutzer das Passwort nicht kennen, kommt er nicht weiter.

Dann kennst du einige Profis aus diesem Forum hier nicht. Denen ist das Passwort vollkommen egal. Die wechseln in der Binary einfach ein if <> then mit if not <> then aus und schon sind sie drin.

[Moombas]

Zitat:

Zitat von DieDolly (Beitrag 1426395)

Zitat:

sollte der Nutzer das Passwort nicht kennen, kommt er nicht weiter.

Dann kennst du einige Profis aus diesem Forum hier nicht. Denen ist das Passwort vollkommen egal. Die wechseln in der Binary einfach ein if <> then mit if not <> then aus und schon sind sie drin.

Das kommt drauf an wie gut man es verschachtelt bzw. welche Abhängigkeiten es noch gibt.
Bei meinem Beispiel z.B.:
1. Prüfen ob der Passwort-Parameter (mit der erwarteten Logik z.B. "/PasswordSecure XXXXX") übergeben wurde, wenn nicht z.B. Programm beenden (wenn es um die "Sicherung" des Programms geht). Wenn ja nächste Prüfung
1.b. Prüfen ob noch z.B. Versuche des Windoofbenutzers möglich sind, wenn nicht z.B. Programm beenden (wenn es um die "Sicherung" des Programms geht). Wenn ja nächste Prüfung
2. Prüfen ob die Datei mit dem Hash gefunden wird, wenn nein: z.B. Programm beenden (wenn es um die "Sicherung" des Programms geht). Wenn ja, nächste Prüfung.
3. Versuchen diese Datei auszulesen, wenn nicht möglich (oder kein Wert): z.B. Programm beenden (wenn es um die "Sicherung" des Programms geht). Wenn ja, nächste Prüfung
4. Den Passwort-Parameter hashen und mit dem hash aus der Datei vergleichen. Ist dieser nicht gleich: z.B. Programm beenden (wenn es um die "Sicherung" des Programms geht). Wenn ja: Freigabe erteilen.

Da reicht ein "einfaches" Ersetzen eines if then durch ein if not then nicht aus.

Das es auch dafür natürlich Mittel und Wege gibt das zu umgehen, ist sicherlich klar.

[TurboMagic]

Es scheint mir, dass du den Unterschied von hash- und Verschlüsselungsfunktionen noch nicht ganz verstanden hast. Du solltest das Passwort nicht verschglüsselt sondern gehashed ablegen, wenn du es nur prüfen muss. Verschlüsseln wäre nur dann richtig, wenn du auch den Klartext des Passwortes wieder zurückgewinnen müsstest.

Zur Sicherheitsthematik: ja, MD5 gilt nicht mehr als sicher. Wie schon von jemandem vorgeschlagen BCrypt als Algorithmus nehmen und zusätzlich das Passwort versalzen! Was bedeutet das? Einen zufälligen Wert an das Passwort anhängen vor dem berechnen des Hash Wertes. Dein Programm muss diesen Wert kennen und wenn ein eingegebenes Passwort geprüft wird auch vor der Hash berechnung wieder dran hängen. Damit werden vorberechnete Hash Tabellen nutzlos.

Im Falle des Hashes kannst du den dann auch ruhig in der Registry oder einer Datei ablegen, da man ihn nicht zurück in das Klartextpasswort verwandeln kann.

[DieDolly]

Das Thema ist schon alt aber ich habe im Prinzip eine ähnliche Frage rein aus Prinzip wie die die im Titel steht:
wie kann man einen String in einer Exe nachträglich ändern?

Ich dachte da grob an Datei in TBytesStream laden, die Bytes in einen String S schieben, Anfangsposition des Strings Needle in S finden und dann mit

Delphi-Quellcode:

Move(Needle[1], BS.Bytes[PosNeedle - 1], NeedleLengthInBytes);

danach die Bytes speichern.

[jaenicke]

Zitat:

Zitat von DieDolly (Beitrag 1519146)

Das Thema ist schon alt aber ich habe im Prinzip eine ähnliche Frage rein aus Prinzip wie die die im Titel steht:
wie kann man einen String in einer Exe nachträglich ändern?

Hier gibt es eine Demo zu einer solchen Problemstellung:
https://www.delphipraxis.net/134855-...anhaengen.html

Zitat:

Zitat von DieDolly (Beitrag 1519146)

Ich dachte da grob an Datei in TBytesStream laden, die Bytes in einen String S schieben, Anfangsposition des Strings Needle in S finden und dann mit

Delphi-Quellcode:

Move(Needle[1], BS.Bytes[PosNeedle - 1], NeedleLengthInBytes);

danach die Bytes speichern.

Das würde zwar gehen, aber ich würde eher anhängen, manuell oder als Ressource, als die Exe anderswo zu ändern. (Unter anderem weil ich mir die Suche spare.)