SecureZeroMemory vermisst

[Frickeldrecktuxer_TM]

Zitat:

Zitat von Dax

Zitat:

Zitat von Frickeldrecktuxer_TM

Ich dachte Delphi2006 hat das inline-Schlüsselwort wieder eingeführt?

Das hat Delphi 2005 schon getan :)

Na, um so besser.

Zitat:

Zitat von Olli

könnte es vielleicht eine Bedeutung gehabt haben, daß ich

Deine Beiträge werden doch von niemandem mehr ernstgenommen :mrgreen:

[himitsu]

Welcher "nicht-C-ler" soll den sowas ahnen ... in Pascal/Basic/CCBasic/ASM... gib's sowas doch nicht -.-''

Und ja ... gefunden hatte ich es nicht.
Es gibt ja och nicht gerade viel dazu zu finden ... selbst Google spuckt nur eine mickrige Seite aus :shock:

INLINE: ohhh, es ist wieder da :shock: ... arbeite doch mit D7 und dann eventuell wieder mit D2008 :zwinker:

Frickeldrecktuxer_TM: nicht den Code ... wenn es 'ne WinAPI-Funktion gewesen wär, dann hätte Windows das SpeicherManagement optimieren können ;)

[Frickeldrecktuxer_TM]

Zitat:

Zitat von himitsu

Welcher "nicht-C-ler" soll den sowas ahnen ... in Pascal/Basic/CCBasic/ASM... gib's sowas doch nicht -.-''

Deswegen empfiehlt es sich, bei systemnaher Programmierung auch die Sprache zu beherrschen, in der das System entwickelt wurde. Wenn ich an meinem Auto rumschrauben will, reicht es mir auch nicht, wenn ich weiß, wie ich meinen Fahrradreifen flicke und die Kette wieder einspanne.

Zitat:

Zitat von himitsu

Frickeldrecktuxer_TM: nicht den Code ... wenn es 'ne WinAPI-Funktion gewesen wär, dann hätte Windows das SpeicherManagement optimieren können ;)

Da gibt es diesbezüglich nichts zu optimieren. Die Prozessorcaches sind nicht beeinflussbar, und ein Caching von RAM innerhalb des RAM ist irgendwie... nicht sinnvoll.

[himitsu]

Na etwas C kann ich och, so isses ja nicht ;)

Aber vom Namen und der "groben" Beschreibung her sah es halt so aus, als wenn man damit "sicherstellen" kann, daß die Daten wirklich im Speicher überschrieben werden und somit wirklich weg sind ... tja, aus der Traum :cry:

[Frickeldrecktuxer_TM]

Zitat:

Zitat von himitsu

als wenn man damit "sicherstellen" kann, daß die Daten wirklich im Speicher überschrieben werden und somit wirklich weg sind...

Genau das ist doch auch der Fall.

[himitsu]

Eben nicht, denn wenn ich jetzt die ganzen Erklärungen zusammenfasse, dann wird nur sichergestellt, das der Code nicht wegoptimiert und somit ausgeführt wird, aber da die Cache nicht beeinflußt wird, wird eben nicht sichergestellt, daß der Inhalt auch aus dem Ram raus ist.

Wenn man z.B. etwas damit löscht und danach den Speicherblock freigibt, dann kann es eben vorkommen, das im RAM, oder der PageFile was zurück bleibt.

Zumindestens kenn ich jetzt 'nen Trick, wie man zumindestens verhindert, das Speicher immer im RAM bleibt und nicht in die PageFile ausgelagert wird ... zumindestens das werd' ich erstmal implementieren ... ein Sicherheitsloch weniger :stupid:

[Frickeldrecktuxer_TM]

Zitat:

Zitat von himitsu

Eben nicht, denn wenn ich jetzt die ganzen Erklärungen zusammenfasse, dann wird nur sichergestellt, das der Code nicht wegoptimiert und somit ausgeführt wird, aber da die Cache nicht beeinflußt wird, wird eben nicht sichergestellt, daß der Inhalt auch aus dem Ram raus ist.

*seufz* Doch, genau das stellt die Architektur bereits sicher. Und zwar abhängig von ebenjener über Write-Through instantan oder über Write-Back verzögert.
Wenn der Prozessor den Speicherbereich mit Nullen füllt, tut er das im Cache. Wenn jetzt jemand anderes (Prozess) gerne auf die Seite zugreifen möchte und das Passwort auslesen will, geschieht die Read-Operation ebenfalls im Cache, es sei denn die Cache-Line wurde in der Zwischenzeit aus anderen Gründen geleert (spätestens dann ist auch im RAM der Bereich mit Nullen und nicht mit dem Klartextpasswort). Das Szenario einer rein softwaregestützten Spionage ist also abgedeckt. Hardwaregestützt könnte man mit einem weiteren Prozessor (und der DMA-Controller ist im Prinzip nichts anderes), der sich nicht den Cache teilt (also geht das nichtmal unbedingt mit allen Multi-Core-Architekturen) die gleiche Adresse aus dem RAM auslesen. Da das auch aus anderen Gründen vollkommen legitim geschehen kann, muss ebenfalls durch die Architektur sichergestellt sein, daß auch der zweite Prozessor die Nullen sieht und nicht das Klartextpasswort. Das geschieht über Cache-Kohärenz-Protokolle, die dafür sorgen, daß alle Caches in sich stimmig sind.
Das einzige Problem, das existieren kann, ist, daß die Seite ausgelagert wurde, nachdem das Passwort in sie geschrieben wurde aber bevor der Speicherbereich wieder genullt wurde. Für diesen (je nach Anwendungsfall unwahrscheinlichen) Fall musst du für die entsprechende Seite das Paging verhindern. Ob und wie das unter Windows geht, weiß ich nicht, aber das weißt du ja anscheinend.

[Olli]

himitsu, sei dir versichert, daß jegliche Usermode-Implementation in Sachen Speicher keinen Einfluß auf die von dir genannten Dinge hat ;)

[himitsu]

OK, wenn das mit der 'Cache stimmt, dann kann man also einen Bereich sicher löschen ... und das es nicht in die PageFile ausgelagert wird ist möglich, jedenfalls sollte es möglich sein (laut MSDN) werd' dafür mal entsprechende Funktionen in die Klasse "Memory" aus http://www.delphipraxis.net/internal...=551192#551192 einfügen und's bei Zeiten testen ._.

Das ReadProcessMemory konnte man ja auch noch sperren, da dieses ja anscheinend nur lesen kann, wenn man die nötigen Rechte für den Prozess hat (irgendwo stand dazu hier mal was ... weiß aber nicht mehr wo -.- )

[add]
Ohh, da isses ja ... http://www.delphipraxis.net/internal...=539309#539309

man muß also nur verhindern, daß andere Prozesse an ein Handle mit PROCESS_VM_WRITE und PROCESS_VM_OPERATION für WriteProcessMemory/ReadProcessMemory rannkommt -.-''

[Frickeldrecktuxer_TM]

Zitat:

man muß also nur verhindern, daß andere Prozesse an ein Handle mit PROCESS_VM_WRITE und PROCESS_VM_OPERATION für WriteProcessMemory/ReadProcessMemory rannkommt -.-''

Du möchtest verhindern, daß dein Prozess debuggt wird: http://luckie-online.de/Developer/Ar...acking_1.shtml