/basename(copyinstr(arg1))=="motd" /

{

        printf("Execname: %s, pid=%d ", execname, pid);

}

Детектив оставил скрипт сидеть в засаде и стал ждать результатов наблюдений. Через некоторое время датчик сработал, но запуск из консоли команды ptree с выловленным pid в качестве аргумента ничего не дал – такого идентификатора процесса в системе уже не было. Злодей успел сделать своё грязное дело и смылся.

Поэтому следующая версия ловушки выглядела более хитроумно:

!#/usr/sbin/dtrace -wqs

syscall::symlink:entry

/basename(copyinstr(arg1))=="motd" /

{

        printf("Execname: %s, pid=%d ", execname, pid);

        copyoutstr("/tmp/motd",arg1,9);

        stop();

        system("ptree %d",pid);

        system("prun %d",pid);

        system("rm /tmp/motd");

}

Что поменялось? Во-первых, исполнение процесса, на котором сработал датчик, приостанавливалось действием stop(). Во-вторых, аргумент вызова symlink подменялся на /tmp/motd вместо /etc/motd (это, кстати, примеры деструктивных действий, для того чтобы разрешить их, необходимо было снабдить вызов dtrace(1M) ключиком -w). Ну и, наконец, действием system() запускалась команда ptree на полученом pid, затем prun возобновлял прежде приостановленное выполнение процесса, и напоследок удалялась ссылка /tmp/motd. Можно было бы обойтись чуть меньшим количеством действий, но несложно догадаться, почему не лишенный чувства юмора детектив не уничтожил процесс, а позволил ему выполняться дальше, не причиняя вреда системе.

Провайдер fbt (function boundary tracing)

Провайдер трассировки границ функции (fbt) создаёт датчики для момента входа-в и выхода-из всех функций ядра Solaris. Хотя механизм реализации fbt сильно привязан к конкретной архитектуре набора команд, fbt присутствует и на SPARC, и на x86, и на amd64. Фактически мы уже успели посмотреть и понять, каким образом fbt модифицирует код на архитектуре x86 в примере, где использовался mdb для дизассемблирования функции ufs_lookup().