2 # Taint-анализ средсвтами Natch
3 # Знакомство с инструментом на небанальных примерах
7 В данной статье приведен мой опыт освоения инструмента полносистемного Taint-анализа Natch созданного Институтом Системного Программирования РАН.
8 Главным фундаментальным недостатком этого инструмента является закрытость кода, ситуация с которой вряд-ли когда либо изменится.
9 Однако сам факт закрытости кода не мешает освоению принципов taint-анализа, и есть надежда по мере роста популярности этого метода (а именно популяризации и посвящена эта статья) будут развиваться и свободные инструменты. Использование несвободного инструмента для освоения новых технологий для которых еще нет свободных решений - не грех.
11 Данная статья не является руководством по использованию Natch, но инструкцией по тому как собрать ряд свободных проектов для последующего taint-анализа и как правильно поставить эксперимент.
12 Саму инструкцию по использованию Natch вы можете найти [здесь](https://github.com/ispras/natch/tree/release/docs)
14 В качестве проектов для исследования мной были выбраны два проекта внутреннее устройство которых мне было мало что известно, а именно PowerDNS и интерпретатор Perl, а о внутреннем устройстве третьего проекта PostgreSQL я кое что знаю.
15 Задача исследования состояла в том, чтобы в первых двух случаях используя помеченные данные быстро и просто узнать о внутренней структуре проекта и иерархии вызовов, в третьем же случае, был выбран более сложный заранее известный data-flow, и цель была убедиться, что natch успешно справляется с анализом сложной траекторией движения помеченных данных
17 Примеры в данных статьях даны с детализацией достаточной для самостоятельного быстрого воспроизведения, при условии предварительного знакомства с инструментом Natch, объяснено почему были выбраны те или иные условия эксперимента, и продемонстрированы результаты экспериментов и даны пояснения к ним.
19 ### Приборы и материалы
21 Эксперимент проводился на ноутбуке с Ubuntu 24.04 и виртуальной машиной с Debian 12 внутри.
23 В настройки сети виртуальной машины по сравнению с рекомендованной в документации была добавлена опция `hostfwd=tcp::2222-:22` которая пробрасывает 2222й порт с хост-машины на 22й порт виртуалки, что позволяет работать внутри виртуальной машины, подключившись к ней привычным терминалом, полноценно пользоваться буфером обмена хост-машины в процессе настройки и т.п. Настоятельно рекомендую.