Lokale Variablen im Speicher

[AHT]

Hier ein Bild vom Prozessspeicher der EXE:



Ich hoffe, das reicht.

[AHT]

Das Gänseblümchen blüht aber nicht nur da, sondern noch an drei weiteren Adressen im Speicher:

Die markierte dürfte die interessanteste sein.
Um an deine Passwörter zu kommen, reicht also unter Umständen ein einfaches Suchen nach Strings im Speicher aus. Auch wenn du die eine Adresse überschreibst, heißt das nicht, dass das Passwort nicht noch woanders steht.

[RGH]

Ähem .... :
Clear pw$ setzt natürlich NICHT die Adresse der Variablen auf 0, sondern ist identisch mit pw$ = ""!

Gruß
Roland

[AHT]

 
PROC Test
 Declare Adresse$
 Adresse$ = "Gänseblümchen"
 Print addr(Adresse$)
 Clear Adresse$
 Print addr(Adresse$)
endproc
Test
While 1
 Waitkey
wend

Kommt glaube ich drauf an, wie man das sieht.

[JörgG]

alles Klar - Danke,

Auch wenn du die eine Adresse überschreibst, heißt das nicht, dass das Passwort nicht noch woanders steht.

die Adresse ändert sich auch, wenn ich die Variable mit exakt der gleichen Anzahl Leerzeichen fülle
Ich habe den Code wie folgt geändert:

PROC Test
 Declare Adresse$, ad&
 Adresse$ = "Gänseblümchen"
 Print addr(adresse$)
  '   Adresse$ = " "
  '   Adresse$ = Space$(Len(Adresse$))
 
 ad& = Addr(Adresse$)
 String ad&, 0 , Space$(Len(Adresse$))
 
 Print addr(adresse$)
endproc
Test
WaitKey

Ich lad das mal hoch, könntest du das dann nochmal testen?

[AHT]

Hatte das noch nicht getestet - scheinst Recht zu haben.
Hier:

PROC Test
 Declare Adresse$, ad&
 Adresse$ = "Gänseblümchen"
 Print addr(adresse$)
  'Adresse$ = " "
  'Adresse$ = Space$(Len(Adresse$))
 External("kernel32", "RtlZeroMemory", addr(adresse$), Len(Adresse$))
 
 Print addr(adresse$)
endproc
Test
WaitKey
Test
While 1
 Waitkey
wend

Aber auch das bringt nicht viel - siehe oben.

[JörgG]

Download:
File-Upload.net - speichertest.zip
entfernen:
File-Upload.net - Delete

ich habe jetzt den Speicherbereich direkt überschrieben, allerdings werden wohl die anderen beiden Speicherbereiche trotzdem noch weiterblühen?

[RGH]

Hallo,

nicht das wir hier etwas durcheinander bringen (so wie ich es eben tat):
Die Adresse des Strings, also des Inhalts der Variablen und die Adresse der Stringvariablen sind zwei verschiedene Adressen. Die Adresse der Stringvariablen ändert sich nicht durch ein CLEAR oder durch Zuweisung eines Leerstrings. Aber die mit Addr() ermittelte Adresse des Inhaltes, also des Zeigers auf das erste Zeichen, ist bei einem Leerstring, aufgrund des nicht existierenden erstens Zeichens eben 0.
Sorry, das hatte ich in meinem Post nicht berücksichtigt.

Gruß
Roland

[AHT]

XProfan interpretiert den Code ja. Das Ganseblümchen blüht also in dem Beispielfall erst mal im Quelltext, den Profan ja interpretieren muss, desweiteren unter Umständen in Delphi Variablen (je nachdem, was mit dem Passwort noch gemacht wird).
Wie gesagt - in dem kurzen Beispielcode taucht das Passwort dreimal im Speicher auf.

@Roland: Ich sagte ja, es hängt davon ab, wie man das sieht.

[JörgG]

Das Ganseblümchen blüht also in dem Beispielfall erst mal im Quelltext...

OK, das kann ich ja mit der Compiler-Direktive $P* verhindern.

Ich versuche mal in der Phase, wenn mein Passwort noch unverschlüsselt ist, nur mit Bereichsvariablen bzw. den Inhalt nur über Longint-Adressen zu schreiben. Das ist genau der Moment, wenn ich mein PW eingebe/editiere & es der Verschlüsselungs-proc übergebe. Danach kann es ja ruhig im Speicher stehen (ist ja dann verschlüsselt). Der nächste kritische Moment ist dann, wenn ich mein PW benötige und es entschlüssele & in das entsprechende Eingabefeld per sendstring einfüge - aber soweit isses noch nicht

[JörgG]

Andreas, könntest du das noch mal mit deinem Super-Programm testen?
Download:
http://www.file-upload.net/download-...rtest.zip.html
entfernen:
http://www.file-upload.net/delete-3738378/lw69ap.html
Danke

[AHT]

Konnte gestern leider nicht mehr. Das Gänseblümchen blüht (wie erwartet) immer noch:

[JörgG]

Das Gänseblümchen blüht (wie erwartet) immer noch

Jo! Aber nicht mehr so oft, oder?
Danke fürs Testen. Ich bin grade dabei, mir was zusammenzuschrauben, daß auf direkte Speicherzugriffe basiert. Mal sehen, 100%-tige Sicherheit werd ich wohl nicht schaffen (gibts die überhaupt?), aber ich will versuchen die kritischen Phasen so kurz & verwirrend wie möglich machen.
Wär nett, wenn du dann mal mein Prog. einen Sicherheits-Härtetest unterziehst, wenn es AlphaStatus erreicht hat - ich denke, du bist für solche Sachen genau der Richtige
Also bis denne...

[Frabbing]

Ich empfehle einen global definierten Bereich. Den kannst du löschen, sobald du den Inhalt nicht mehr benötigst. Ich denke, die Bereiche sind nicht moveable. Ansonsten kannst du unverschiebbaren Speicher reservieren mit der API GlobalAlloc().

[AHT]

Wie gesagt: Es kommt drauf an, was noch weiter mit dem Passwort gemacht wid. Landet es zischenduch in einer Delphi Variablen, bekommt man es von dort unter Umständen nicht mehr ohne weiteres weg und es bleibt unverschlüsselt über längere Zeit im Speicher stehen.
Um mal zu Testen, wann das Passwort in Reinform im Speicher steht und wie lange, bieten sich Programme wie OllyDebug und den HxD Hexeditor an (mit dem man auch sehr gut virtuellen Prozessspeicher durchsuchen kann).
Es gibt auch Methoden, um Debugger abzuschalten, wenn sie versuchen, sich in einen Prozess einzuklinken. Ich habe vor einer Zeit auch mal eine PCU dafür geschrieben, die man bei Bedarf noch verbessern kann (zum Beispiel den Debugger alle 300ms aus dem Programm werfen). Wenn du Bedarf an so was hast, mal melden.