Lectura de memoria de otro proceso en OS X?

Question

He estado tratando de entender cómo leer la memoria de otros procesos en Mac OS X, pero no estoy teniendo mucha suerte. He visto muchos ejemplos en línea usando ptrace con PEEKDATA y tal, sin embargo, no tiene esa opción en BSD ^{[man ptrace]}.

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

¿Cómo es posible leer y escribir en la memoria de otro proceso en Mac OS X?

Answer 1

Matasano Chargen tuvo un buen post un tiempo atrás al portar algún código de depuración a OS X, que incluía aprender a leer y escribir memoria en otro proceso (entre otras cosas).

It has to work, otherwise GDB wouldn't:

Resulta Apple, en su infinita sabiduría, había destripado ptrace(). La página de OS X recopila los siguientes códigos de solicitud:

• PT_ATTACH - para recoger un proceso para depurar
• PT_DENY_ATTACH - por lo que los procesos pueden dejar de ser depurado
  [...]

Sin mención de lectura o escritura de memoria o registros. Lo cual hubiera sido desalentador si la página man no hubiera mencionado también PT_GETREGS, PT_SETREGS, PT_GETFPREGS y PT_SETFPREGS en la sección de códigos de error. Entonces, revisé ptrace.h. Allí encontré:

• PT_READ_I - para leer palabras de instrucción
• PT_READ_D - leer las palabras de datos
• PT_READ_U - para leer datos del área de U si eres lo suficientemente mayor como para recordar lo que la zona T es
  [...]

Ha resuelto un problema. Puedo leer y escribir memoria para puntos de interrupción. Pero todavía no puedo acceder a los registros, y necesito poder jugar con EIP.

Answer 2

Manipular la memoria de un proceso detrás de su espalda es una cosa mala y está lleno de peligros. Es por eso que Mac OS X (como cualquier sistema Unix) tiene memoria protegida y mantiene los procesos aislados entre sí.

Por supuesto que se puede hacer: hay instalaciones para memoria compartida entre procesos que cooperan explícitamente. También hay formas de manipular los espacios de direcciones de otros procesos siempre que el proceso tenga el derecho explícito de hacerlo (como lo otorga el marco de seguridad). Pero eso está ahí para las personas que están escribiendo herramientas de depuración para usar. No es algo que debería ser una ocurrencia normal, o incluso rara, para la gran mayoría del desarrollo en Mac OS X.

Answer 3

Use task_for_pid() u otros métodos para obtener el puerto de tareas del proceso de destino. A partir de entonces, puede manipular directamente el espacio de direcciones del proceso usando vm_read(), vm_write() y otros.

Answer 4

Si desea poder compartir fragmentos de memoria entre procesos, debe consultar shm_open (2) y mmap (2). Es bastante fácil asignar un trozo de memoria en un proceso y pasar la ruta (para shm_open) a otro y ambos pueden volverse locos. Esto es mucho más seguro que hurgar en el espacio de direcciones de otro proceso como menciona Chris Hanson. Por supuesto, si no tiene control sobre ambos procesos, esto no le servirá de mucho.

(Tenga en cuenta que la longitud del recorrido máximo para shm_open parece ser 26 bytes, aunque esto no parece no ser documentada en cualquier lugar.)

// 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() 

Answer 5

En general, yo recomendaría que el uso regular abierto() para abrir un archivo temporal. Una vez que está abierto en ambos procesos, puede desvincularlo() del sistema de archivos y se configurará de manera similar a como lo haría si hubiera usado shm_open. El procedimiento es extremadamente similar al especificado por Scott Marcy para shm_open.

La desventaja de este enfoque es que si el proceso que hará el desvinculación() se bloquea, terminará con un archivo no utilizado y ningún proceso tiene la responsabilidad de limpiarlo. Esta desventaja se comparte con shm_open, porque si nada shm_unlinks un nombre dado, el nombre permanece en el espacio de memoria compartida, disponible para ser shm_opened por procesos futuros.

Answer 6

Quiere hacer comunicación entre procesos con el método de memoria compartida. Para un resumen de otro método bienes comunes, ver here

No me tomó mucho tiempo para encontrar lo que necesita en este book que contiene todas las API que son comunes a todos los UNIXes hoy (que muchos más de lo que pensaba). Deberías comprarlo en el futuro. Este libro es un conjunto de (varios cientos) páginas man impresas que rara vez se instalan en máquinas modernas. Cada página man detalla una función C.

No me llevó mucho tiempo tomó para encontrar shmat()shmctl(); shmdt() y shmget() en él. No busqué mucho, tal vez haya más.

Parecía un poco desactualizado, pero: SÍ, la API de espacio de usuario base del sistema operativo UNIX moderno vuelve a los años 80.

Actualización: la mayoría de las funciones descritas en el libro son parte de los encabezados POSIX C, no necesita instalar nada. Hay algunas excepciones, como con "maldiciones", la biblioteca original.

Answer 7

Definitivamente he encontrado una implementación corta de lo que necesita (solo un archivo fuente (main.c)). Está especialmente diseñado para XNU.

Es en los diez primer resultado de la búsqueda de Google con las siguientes palabras clave «os memoria proceso de volcado x»

El código fuente es here

pero desde un estricto punto de dirección virtual space Punto de vue , usted debe estar más interesado con esta pregunta: OS X: Generate core dump without bringing down the process? (mirar también this)

Cuando nos fijamos en el código fuente gcore, es bastante complejo para hacerlo ya que se necesita para hacer frente a las pisadas y su estado ...

En la mayoría de las distribuciones de Linux, el programa gcore ahora es parte del paquete GDB. Creo que la versión de OSX está instalada con xcode/las herramientas de desarrollo.

ACTUALIZACIÓN: wxHexEditor es un editor que puede editar dispositivos. IT PUEDE también editar la memoria del proceso de la misma forma que lo hace para los archivos normales. Funciona en todas las máquinas UNIX.

Answer 8

Sé que este hilo es de 100 años, pero para la gente que viene aquí desde un motor de búsqueda:

xnumem hace exactamente lo que está buscando, manipular y leer la memoria entre procesos.

// 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();