Снаружи ядра
Существуют по меньшей мере методики поиска багов, но обе они порочные и неправильные. Одни хакеры предпочитают просматривать исходные коды ядра, анализируя строку за строкой, другие— дизассемблируют готовое ядро. Вот неполный перечень недостатков первого способа:
а) вместо фактического значения переменной в Си сплошь и рядом используются макросы, определяемые неизвестно где, причем макрос может переопределяться многократно или, что еще хуже, различные включаемые файлы содержат несколько независимых макросов с одинаковым именем, так что глобальный контекстный поиск, практикуемый многими исследователями, не помогает (можно, правда, прогнать исходный текст через препроцессор — cpp имя_файла.c –, но от этого его объем, а, значит, и время анализа только возрастет);
б) ни одна известная мне IDE, не способна отображать перекрестные ссылки на функции/данные, трассировать поток управления и делать множество других полезных вещей с которыми легко справляется любой приличный дизассемблер;
в) в процессе компиляции могут "маскироваться" одни ошибки и добавляться другие, к тому же никогда нельзя сказать наперед по каким адресам и в каком порядке компилятор расположит переменные и буфера в памяти, а для написания shell-кода это критично!
С другой стороны, дизассемблерный листинг ядра не просто велик. Он огромен! Это миллионы строк ассемблерного кода, и даже если на каждую команду потратить всего несколько секунд, даже поверхностный анализ растянется как минимум на сезон. Но ведь нам и не нужно дизассемблировать все ядро целиком! Ошибки не размазаны тонким слоем по машинному коду, а гнездятся во вполне предсказуемых местах. Никто не говорит, что ловить багов это просто. Зато интересно! Сознайтесь, разве вам никогда не хотелось заглянуть в ядро, потрогать машинный код руками и посмотреть как все это выглядит в живую (то есть "на самом деле"), а не в исходных текстах, которые любой "чиста хакер" может сказать из сети? И эта возможность сейчас представится!
