Leggi la pila di un altro processo?

Sto cercando di leggere lo stack di un processo figlio ma senza fortuna. So che è possibile utilizzarlo ptrace, ma ptracel'interfaccia di ti permette di leggere solo una parola alla volta e sto cercando di scansionare porzioni più grandi dello stack.

Ho anche provato a leggere i /proc/$pid/memlimiti dello stack come estratto dal /proc/$pid/mapsfile dopo aver usato ptrace per collegarlo (come suggerito qui ) ma la lettura continua a fallire (anche quando viene eseguita come root) anche se lo stesso codice ha esito positivo quando provato lettura da diverse parti del processo (ad es. heap).

Che cosa sto facendo di sbagliato? C'è qualche altra opzione?

ptraceL'interfaccia ti permette di leggere solo una parola alla volta e sto cercando di scansionare porzioni più grandi dello stack

Bene, basta usare un loop, quindi. Onestamente non vedo come ciò costituisca un problema ptrace, lo uso sempre per accedere ai processi in remoto.

Uso qualcosa del genere:

static int memcpy_from_target(pid_t pid, char *dest, long src, size_t n)
{
    static int const align = sizeof(long) - 1;

    while (n)
    {
        size_t todo = MIN(n, sizeof(long) - (src & align));
        long data = ptrace(PTRACE_PEEKTEXT, pid, src - (src & align), 0);
        if (errno)
        {
            perror("ptrace_peektext (memcpy_from_target)");
            return -1;
        }
        memcpy(dest, (char *)&data + (src & align), todo);

        dest += todo; src += todo; n -= todo;
    }

    return 0;
}

Ecco un'altra strategia che potrebbe richiedere modifiche, ma dovrebbe essere più efficiente con grandi blocchi di dati. L'idea è di eseguire syscall nel processo remoto per recuperare i contenuti dello stack. Avrà bisogno di un codice di architettura specifico ma se scegli come target solo x86 / x86_64 non dovrebbe essere troppo seccante.

1. Creare una pipa denominata come "/tmp/fifo"nel processo di chiamata.
2. Passare al processo tracciato fino a quando non ritorna da una syscall, usando PTRACE_SYSCALLstep, waitpid()per attendere e PTRACE_GETREGS/ PTRACE_PEEKTEXTper verificare il codice operativo attualmente eseguito.
3. Eseguire il backup dei registri del processo remoto e di una piccola area del suo stack.
4. Esegui chiamate di sistema sul processo remoto sovrascrivendo il suo stack con i propri dati: open("/tmp/fifo"), write()il contenuto dello stack, close()il descrittore.
5. Ripristina lo stato del processo remoto.
6. Leggi i dati Fifo dal processo di chiamata.

Potrebbero esserci alternative più eleganti alla pipa nominata, ma non riesco a pensare a nessuna in questo momento. Il motivo per cui utilizzo solo syscalls è perché l'iniezione di codice in remoto è piuttosto inaffidabile sui sistemi moderni a causa di varie protezioni di sicurezza. Lo svantaggio è che si bloccherà fino a quando il processo remoto non esegue un syscall (che può essere un problema per alcuni programmi che eseguono principalmente calcoli).

Puoi vedere del codice gratuito che implementa la maggior parte del lavoro in questo file sorgente . Feedback sul codice è il benvenuto!

Un altro suggerimento.

Quando / se viene accettato nella struttura principale del kernel Linux, sarai in grado di usare la patch Cross Memory Attach di Christopher Yeoh . Vedere la documentazione per process_vm_readv per esempio.

Puoi facilmente leggere lo stack di un altro processo usando il file system proc (per questo avrai bisogno dell'accesso root). Prima di leggere arbitrariamente da / proc / pid / mem devi consultare / proc / pid / maps. Una semplice lettura in questo file mostra molte voci. Siamo interessati alla voce contrassegnata come pila. Una volta ottenuto questo, è necessario leggere i limiti inferiore e superiore della pila. Ora apri semplicemente il file / proc / pid / mem, cerca il limite inferiore dello stack e leggi la dimensione corretta dei dati.

Potresti provare lsstack . Usa ptrace, proprio come ogni altro programma "leggi lo stack di un altro processo" di successo. Non sono riuscito a ottenere un programma usando / proc / $ pid / mem per funzionare. Credo che non puoi farlo in questo modo, anche se, logicamente, dovresti.