Speicher eines anderen Prozesses in OS X lesen?

Ich habe versucht zu verstehen, wie man den Speicher anderer Prozesse unter Mac OS X liest, aber ich habe nicht viel Glück. Ich habe viele Beispiele online mit gesehen ptrace mit PEEKDATA und so, aber es hat diese Option nicht auf BSD ^{[man ptrace]}.

int pid = fork();
if (pid > 0) {
    // mess around with child-process's memory
}

Wie ist es möglich, unter Mac OS X aus dem Speicher eines anderen Prozesses zu lesen und zu schreiben?

Verwenden task_for_pid() oder andere Methoden, um den Task-Port des Zielprozesses zu erhalten. Danach können Sie den Adressraum des Prozesses direkt mit manipulieren vm_read(), vm_write()und andere.

Matasano Chargen hatte vor einiger Zeit einen guten Beitrag über die Portierung von Debugging-Code auf OS X, der unter anderem das Lesen und Schreiben von Speicher in einem anderen Prozess beinhaltete.

Es muss funktionieren, sonst würde GDB nicht funktionieren:

Es stellte sich heraus, dass Apple in seiner unendlichen Weisheit ausgeweidet hatte ptrace(). Die OS X-Manpage listet die folgenden Anforderungscodes auf:

• PT_ATTACH — um einen Prozess zum Debuggen auszuwählen
• PT_DENY_ATTACH – damit Prozesse sich selbst daran hindern können, debuggt zu werden
  […]

Keine Erwähnung des Lesens oder Schreibens von Speicher oder Registern. Was entmutigend gewesen wäre, wenn die Manpage nicht auch erwähnt hätte PT_GETREGS, PT_SETREGS, PT_GETFPREGSund PT_SETFPREGS im Abschnitt Fehlercodes. Also, ich habe es überprüft ptrace.h. Dort fand ich:

• PT_READ_I — Anweisungswörter lesen
• PT_READ_D — um Datenworte zu lesen
• PT_READ_U — um U-Bereichsdaten zu lesen, wenn Sie alt genug sind, um sich daran zu erinnern, was der U-Bereich ist
  […]

Ein Problem ist gelöst. Ich kann Speicher für Breakpoints lesen und schreiben. Aber ich kann immer noch nicht auf Register zugreifen, und ich muss in der Lage sein, mit EIP herumzuspielen.

Ich weiß, dass dieser Thread 100 Jahre alt ist, aber für Leute, die von einer Suchmaschine hierher kommen:

xnum macht genau das, wonach Sie suchen, manipuliert und liest den Interprozessspeicher.

// Create new xnu_proc instance
xnu_proc *Process = new xnu_proc();

// Attach to pid (or process name)
Process->Attach(getpid());

// Manipulate memory
int i = 1337, i2 = 0;
i2 = process->memory().Read<int>((uintptr_t)&i);

// Detach from process
Process->Detach();

Wenn Sie Speicherblöcke zwischen Prozessen teilen möchten, sollten Sie sich shm_open(2) und mmap(2) ansehen. Es ist ziemlich einfach, in einem Prozess einen Teil des Speichers zuzuweisen und den Pfad (für shm_open) an einen anderen weiterzugeben, und beide können dann zusammen verrückt werden. Dies ist viel sicherer, als im Adressraum eines anderen Prozesses herumzustöbern, wie Chris Hanson erwähnt. Wenn Sie beide Prozesse nicht unter Kontrolle haben, wird Ihnen das natürlich nicht viel nützen.

(Beachten Sie, dass die maximale Pfadlänge für shm_open 26 Bytes zu sein scheint, obwohl dies nirgendwo dokumentiert zu sein scheint.)

// Create shared memory block
void* sharedMemory = NULL;
size_t shmemSize = 123456;
const char* shmName = "mySharedMemPath";        
int shFD = shm_open(shmName, (O_CREAT | O_EXCL | O_RDWR), 0600);
if (shFD >= 0) {
    if (ftruncate(shFD, shmemSize) == 0) {
        sharedMemory = mmap(NULL, shmemSize, (PROT_READ | PROT_WRITE), MAP_SHARED, shFD, 0);
        if (sharedMemory != MAP_FAILED) {
            // Initialize shared memory if needed
            // Send 'shmemSize' & 'shmemSize' to other process(es)
        } else handle error
    } else handle error
    close(shFD);        // Note: sharedMemory still valid until munmap() called
} else handle error

...
Do stuff with shared memory
...

// Tear down shared memory
if (sharedMemory != NULL) munmap(sharedMemory, shmemSize);
if (shFD >= 0) shm_unlink(shmName);





// Get the shared memory block from another process
void* sharedMemory = NULL;
size_t shmemSize = 123456;              // Or fetched via some other form of IPC
const char* shmName = "mySharedMemPath";// Or fetched via some other form of IPC
int shFD = shm_open(shmName, (O_RDONLY), 0600); // Can be R/W if you want
if (shFD >= 0) {
    data = mmap(NULL, shmemSize, PROT_READ, MAP_SHARED, shFD, 0);
    if (data != MAP_FAILED) {
        // Check shared memory for validity
    } else handle error
    close(shFD);        // Note: sharedMemory still valid until munmap() called
} else handle error


...
Do stuff with shared memory
...

// Tear down shared memory
if (sharedMemory != NULL) munmap(sharedMemory, shmemSize);
// Only the creator should shm_unlink()

Sie möchten Inter-Process-Communication mit dem Shared-Memory-Verfahren durchführen. Eine Zusammenfassung anderer Commons-Methoden finden Sie unter hier

Ich habe nicht lange gebraucht, um das zu finden, was Sie brauchen Buchen das alle APIs enthält, die heute allen UNIXen gemeinsam sind (viel mehr als ich dachte). Sie sollten es in Zukunft kaufen. Dieses Buch besteht aus (mehreren hundert) gedruckten Handbuchseiten, die selten auf modernen Maschinen installiert werden. Jede Handbuchseite beschreibt eine C-Funktion.

Ich brauchte nicht lange, um es zu finden schmat () shmctl(); shmdt() und shmget() drin. Ich habe nicht lange gesucht, vielleicht gibt es noch mehr.

Es sah ein bisschen veraltet aus, aber: JA, die grundlegende Benutzerbereichs-API des modernen UNIX-Betriebssystems zurück in die alten 80er Jahre.

Update: Die meisten im Buch beschriebenen Funktionen sind Teil der POSIX-C-Header, Sie müssen nichts installieren. Es gibt wenige Ausnahmen, wie bei “curses”, der ursprünglichen Bibliothek.

Ich habe definitiv eine kurze Implementierung dessen gefunden, was Sie brauchen (nur eine Quelldatei (main.c)). Es wurde speziell für XNU entwickelt.

Es ist unter den Top-Ten-Ergebnissen der Google-Suche mit den folgenden Schlüsselwörtern «dump process memory os x»

Der Quellcode ist hier

aber aus einem strengen Punkt des virtuellen Adressraums sollten Sie sich mehr für diese Frage interessieren: OS X: Generieren Sie einen Core-Dump, ohne den Prozess herunterzufahren? (siehe auch Dies)

Wenn Sie sich den gcore-Quellcode ansehen, ist dies ziemlich komplex, da Sie sich mit Laufflächen und ihrem Zustand befassen müssen …

Bei den meisten Linux-Distributionen ist das gcore-Programm jetzt Teil des GDB-Pakets. Ich denke, die OSX-Version wird mit xcode/den Entwicklungstools installiert.

UPDATE: wxHexEditor ist ein Editor, der Geräte bearbeiten kann. IT KANN auch den Prozessspeicher auf die gleiche Weise bearbeiten wie normale Dateien. Es funktioniert auf allen UNIX-Rechnern.

Das Gedächtnis eines Prozesses hinter seinem Rücken zu manipulieren, ist eine schlechte Sache und voller Gefahren. Aus diesem Grund hat Mac OS X (wie jedes Unix-System) einen geschützten Speicher und hält Prozesse voneinander isoliert.

Natürlich geht das: Es gibt Einrichtungen für Shared Memory zwischen explizit kooperierenden Prozessen. Es gibt auch Möglichkeiten, die Adressräume anderer Prozesse zu manipulieren, solange der Prozess, der dies tut, das ausdrückliche Recht dazu hat (wie vom Sicherheitsframework gewährt). Aber das ist für Leute da, die Debugging-Tools schreiben. Es sollte kein normales – oder sogar seltenes – Ereignis für die überwiegende Mehrheit der Entwicklung unter Mac OS X sein.