Byte in Speicher schreiben

[Luckie]

Jetzt erklär mir mal bitte jemand eins: Bisher dsachte ich unter Windows NT ff kjönnte man nicht mehr so einbfach in dem Speicher anderer Anwendungen runfuschen. Warum geht das doch so einfach? Oder war mit der Aussage, dass man nicht mehr so einfach im fremden Adressraum schreiben kann ein anderer Sachverhalt gemeint? Wenn ja, welcher?

[Daniel G]

Zitat von Luckie:

Bisher dsachte ich unter Windows NT ff kjönnte man nicht mehr so einbfach in dem Speicher anderer Anwendungen runfuschen. Warum geht das doch so einfach?

Hey Luckie,
vor ein paar Stunden hier angeschnitten:

http://www.delphipraxis.net/internal...=539290#539290

Es dreht sich alles um den virtuellen Adressraum...

[Luckie]

Ja, das ist mir klar, nur gehört der auch der virtuelle Adressraum ja auch einem fremden Prozess.

[Daniel G]

Jupp, und mit den beiden Funktionen "WriteProcessMemory" und "ReadProcessMemory" kann man darauf zugreifen, sofern man ein Handle mit PROCESS_VM_WRITE und PROCESS_VM_OPERATION zu dem Prozess bekommt. Geht von Win95 bis XP. So steht es zumindestens im PSDK.

Ich hab's allerdings noch nicht ausprobiert. Im Prinzip muss es ja auch irgendwie gehen, sonst würde ja kein Debugger funktionieren.

[Luckie]

Das muss ich mir noch mal durch den Kopf gehen lassen. Aber nicht mehr heute.

[brechi]

Wenn man ein gültiges Handle mit OpenProcess erhalten hat (und mit ensprechenden Rechten) dann kann man die Zielapplikation ohne Probleme mit Write/ReadProcessmemory ändern.
Was sich im Gegensatz zu 9x geändert hat, ist dass man nicht mehr so leicht auf den Speicher > 0x80000000 zugreifen kann. Unter 9x konnte man diesen noch ohne Probleme auslesen aber nicht modifizieren. Unter XP braucht man dazu schon speziellere Rechte

[Frickeldrecktuxer_TM]

Zitat von Luckie:

Jetzt erklär mir mal bitte jemand eins: Bisher dsachte ich unter Windows NT ff kjönnte man nicht mehr so einbfach in dem Speicher anderer Anwendungen runfuschen. Warum geht das doch so einfach?

Definiere "so einfach". Der Prozess, der debuggt, benötigt immer noch das SeDebugPrivilege Privileg, und das ist ein Privileg, daß man Prozessen entziehen kann Falsch ausgedrückt: Wenn der Prozess die entsprechenden Zugriffsarten nicht erlaubt, benötigt man immer noch das SeDebugPrivilege Privileg, um die ACL zu umgehen, und das ist ein Privileg, das man Prozessen (und Usern) entziehen kann.

Anscheinend kennst du deinen eigenen Code nicht Schau dir mal dein LuckieDIPS an, dort schreibst du auch ungefragt in den Explorer-Prozess

[Luckie]

Nein tue ich nicht. Ich reserviere mir Speicher im Explorer Prozess, kopiere etwas hinein und lese es aus. Ich ändere nichts im Speicher des fremden Prozesses! Das ist ein großer Unterschied.

[Frickeldrecktuxer_TM]

Zitat von Luckie:

Das ist ein großer Unterschied.

Nicht wirklich. Du schreibst in den fremden Adressraum. Auf Page-Ebene gibt es keine weiteren Einschränkungen. Würde mich sehr wundern, wenn Windows hier eine Tabelle enlegen würden "Adresse $a bis $b ist vom geladenen Modul, hier nicht schreiben, Adresse $c bis $d ist von diesem Prozess allokiert worden, der darf hier schreiben, Adresse $e bis $f ist von jenem Prozess allokiert worden, der darf hier schreiben, usw". Unter Strich veränderst du vielleicht nicht die .data-Section des Explorer-Prozesses, aber du bearbeitest seinen Adressbereich. Und dann könntest du auch direkt die .data-Section bearbeiten. Sämtliche In-Memory-Patches und -Hacks funktionieren nicht anders.