Speicher ändern

[vlees91]

Ich denke zwar, dass die lösung schon im forum steht, ich habe es aber nicht gefunden.
also ich habe eine speicheradresse (Hex: 26A1FF1, Dez: 40509425), aber wie kann ich die jetzt ändern. wie kann man das z.B. WriteProcessMemory machen, oder geht das auch anders???

[Mephistopheles]

Adressen sind doch nur Schall und Rauch. Denn deren Gültigkeit hängt stark von deren Kontext (auch Prozess genannt) ab.

Und ja, mit der genannten Funktion geht so einiges. Aber das ist alles wundervoll bei MSDN oder im Platform SDK dokumentiert.

[Karlson]

Das du WriteProcessMemory nicht im Forum findest halte ich für eine Lüge

Das Problem an den Speicheradressen ist vielseitig. Es kann sein das die Adressen durch DMA geschützt sind. Das bedeutet dass sich die Adresse bei jedem Neustart des Prozesses dynamisch neu zusammensetzt. Durch einen Debugger wie z.B. SoftIce lässt sich das bei manchen Prozessen allerdings noch hinbiegen.

Wenn kein DMA benutzt wird, wird die Adresse auf deinem PC immer gleich bleiben. Es kann aber gut sein dass die Adresse im Speicher einer DLL Datei liegt. Der Speicher ein DLL Datei wird aber über eine API Funktion reserviert (siehe Virtualalloc), und wird deshalb von PC zu PC verschieden liegen.

Die Materie in die duch dich einarbeiten willst ist extrem vielschichtig und auch relativ kompliziert. Meistens sind umfangreiche Assemblerkenntnisse Grundvoraussetzung.

[Mephistopheles]

Zitat von Karlson:

Das Problem an den Speicheradressen ist vielseitig. Es kann sein das die Adressen durch DMA geschützt sind. Das bedeutet dass sich die Adresse bei jedem Neustart des Prozesses dynamisch neu zusammensetzt. Durch einen Debugger wie z.B. SoftIce lässt sich das bei manchen Prozessen allerdings noch hinbiegen.

Wenn du "Dynamic Memory Allocation" meinst (üblicherweise wird auch heute noch DMA für Direct Memory Access, z.B. in U-DMA 100 usw. verwendet), dann ist das ja kein bewußter Schutz, sondern einfach ein Zufall, daß sich Adressen gleichen. Genau wie wenn eine DLL reloziert wird.

Zitat von Karlson:

Wenn kein DMA benutzt wird, wird die Adresse auf deinem PC immer gleich bleiben. Es kann aber gut sein dass die Adresse im Speicher einer DLL Datei liegt. Der Speicher ein DLL Datei wird aber über eine API Funktion reserviert (siehe Virtualalloc), und wird deshalb von PC zu PC verschieden liegen.

Halte ich für ein Gerücht. Der DLL-Loader benutzt jedenfalls kein VirtualAlloc() - und was die DLL selber benutzt, bleibt ihr überlassen.

Zitat von Karlson:

Die Materie in die duch dich einarbeiten willst ist extrem vielschichtig und auch relativ kompliziert. Meistens sind umfangreiche Assemblerkenntnisse Grundvoraussetzung.

Wozu man Assemblerkenntnisse braucht, wenn man über Adressierung und gegeneinander abgegrenzte Prozesse bescheidwissen soll, bleibt dir überlassen.
Und so kompliziert ist das garnicht, wenn man sich die abgegrenzten Prozesse irgendwie versinnbildlicht und immer daran denkt, daß jeder Prozess seinen eigenen Adressraum hat.

[Luckie]

Seit 32 Bit Windows ist ein direkter Speicherzugriff auf den Adressraum eines anderen Prozess nicht mehr so einfach möglich. Auch mit WriteProcessMemory kannst du nur auf Speicher zugreifen, den du im fremden Adressraum alloziiert hast. Und das auch nur mit VitualAllocEx unter NT basierenden Systemen. Für Consumer Windows braucht es da schon einen Hack.

[Mephistopheles]

Luckie meint (Hervorhebung Mephisto):

Auch mit WriteProcessMemory kannst du nur auf Speicher zugreifen, den du im fremden Adressraum alloziiert hast.

Irgendwie haben wir wohl verschiedene Ausgaben des Platform SDK. Bei mir steht, daß ich beliebig mit dieser Funktion im Zielprozess rumschreiben kann, solange er mir überhaupt die entsprechenden Rechte zugesteht: PROCESS_VM_WRITE und PROCESS_VM_OPERATION lt. Platform SDK.

[Luckie]

Das stimmt, nur ist die Frage, welche Prozesse diese Rechte bekommen können. Ich befürchte das sind nur Prozesse unter dem Administrator Konto mit Debuggrechten.

[Mephistopheles]

Zitat von Luckie:

Das stimmt, nur ist die Frage, welche Prozesse diese Rechte bekommen können. Ich befürchte das sind nur Prozesse unter dem Administrator Konto mit Debuggrechten.

Ähem, ja. Und? Wo war jetzt der Widerspruch zu meiner Aussage und der Dokumentation?

Auch über VirtualAllocEx() heißt es:

Im Platform SDK steht:

You must have PROCESS_VM_OPERATION access to the process. If you do not, the function fails.

... was für mich danach klingt, daß man auch durch das von dir vorgebrachte Allozieren im fremden Speicherraum nicht mehr Rechte bekommt, sondern etwa die gleichen braucht (Debug- oder Administratorprivilegien nämlich).

Wo war also der Bezug? Ich stehe wohl aktuell auf der Leitung ...

[Luckie]

Folgendes:
Wenn man mit VirtualAllocEx sich Speicher im fremden Prozess alloziiert, dann sind diese Rechte nicht nötig, um in diesen Speicherbercih mit WrteProcessMemory zu schreiben. Da es VirtualAllocEx aber nur unter NT basierenden Systemen gibt, ist unter Win9x ein Hack nötig.

Und wenn man doch mit WriteProcessMemory wild in fremden Adressräumen rumschreiben könnte, dann würde ich vom Glauben abfallen. Ich hege immer noch die Hoffnung, dass nur ganz spezielle Prozesse die sich die nötigen Rechte (PROCESS_VM_WRITE und PROCESS_VM_OPERATION) beschaffen können. Ich dachte da an so was wie Dienste oder Treiber. Wobei mir Dienste schon wieder unheimlich wären.

[w3seek]

Zitat von Luckie:

Wenn man mit VirtualAllocEx sich Speicher im fremden Prozess alloziiert, dann sind diese Rechte nicht nötig, um in diesen Speicherbercih mit WrteProcessMemory zu schreiben.

Dazu braucht man erst einmal einen handle zu diesem fremden Prozess der die genau gleichen Rechte benoetigt wie WriteProcessMemory. Somit funktioniert auch das nicht wenn man die benoetigten Rechte nicht hat.

Zitat von Luckie:

Und wenn man doch mit WriteProcessMemory wild in fremden Adressräumen rumschreiben könnte, dann würde ich vom Glauben abfallen. Ich hege immer noch die Hoffnung, dass nur ganz spezielle Prozesse die sich die nötigen Rechte (PROCESS_VM_WRITE und PROCESS_VM_OPERATION) beschaffen können. Ich dachte da an so was wie Dienste oder Treiber. Wobei mir Dienste schon wieder unheimlich wären.

Wenn man die benoetigten Rechte fuer einen handle auf einen prozess hat, kann man beliebig im addressraum eines prozesses beliebig herumspielen. Da Dienste im SYSTEM account laufen, haben diese in aller Regel die gleichen Rechte diesbezueglich wie ein Administrator. Treiber interessieren diese ganzen Rechte prinzipiell nicht, denn sie haben vollen und uneingeschraenkten Zugriff auf das System, und damit auch auf den adressraum jedes beliebigen prozesses. Mit treibern lassen sich auch saemtliche Schutz- und Sicherheitsmechanismen umgehen und auch selbstverstaendlich das Betriebssystem zum Absturz bringen.

Fuer alle diejenigen die jetzt schon wieder auf dumme gedanken kommen, einen Treiber/Dienst zu laden/installieren erfordert auch erst mal bestimmte rechte