recuperacion - restaurar mac sin time machine

¿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

Si desea 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 máxima de la ruta para shm_open parece ser de 26 bytes, aunque esto no parece documentarse en ninguna parte).

// 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 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 objetivo. A partir de entonces, puede manipular directamente el espacio de direcciones del proceso utilizando vm_read() , vm_write() y otros.

Answer 4

En general, recomendaría que use regularmente open () 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 () falla, usted termina 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 5

Sé que este hilo tiene 100 años, pero para las personas que vienen desde un motor de búsqueda:

xnumem hace exactamente lo que está buscando, manipula y lee 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();

Answer 6

Desea hacer Inter-Process-Communication con el método de memoria compartida. Para un resumen del otro método de uso común, ver aquí

No tardé mucho en encontrar lo que necesita en este libro que contiene todas las API que son comunes a todos los UNIX hoy (que muchos más de lo que pensé). 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 tardé mucho en 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

Hace un tiempo, Matasano Chargen hizo una buena publicación sobre cómo 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).

Tiene que funcionar; de lo contrario, GDB no :

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

• PT_ATTACH - para elegir un proceso para depurar
• PT_DENY_ATTACH - por lo que los procesos pueden evitar que se los depure
  [...]

No se menciona la 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 . Ahí encontré:

• PT_READ_I - para leer palabras de instrucción
• PT_READ_D - para leer palabras de datos
• PT_READ_U : para leer los datos del área U si tienes la edad suficiente para recordar cuál es el área U
  [...]

Hay un problema resuelto. 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 8

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

Está entre los diez primeros resultados de la búsqueda de Google con las siguientes palabras clave «dump process memory os x»

El código fuente está aquí

pero desde un punto estricto de espacio de direcciones virtuales point de vue, debería estar más interesado con esta pregunta: OS X: ¿Generar un volcado del núcleo sin que se reduzca el proceso? (mira también esto )

Cuando miras el código fuente de Gcore, es bastante complejo hacerlo ya que debes ocuparte de las bandas de rodamiento 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.