Спецвыпуск журнала «Хакер» 47, октябрь 2004 г.
Шрифт:
Нельзя объявлять главную функцию программы как main: встретив такую, линкер внедрит в файл start-up код, который вирусу не нужен. Нельзя использовать глобальные или статические переменные: компилятор принудительно размещает их в сегменте данных, но у вирусного кода не может быть сегмента данных! Даже если вирус захочет воспользоваться сегментом пораженной программы, он будет должен, во-первых, самостоятельно определить адрес его «хвоста», а, во-вторых, растянуть сегмент до необходимых размера. Все это тривиально реализуется на Ассемблере, но для компилятора оказывается чересчур сложной задачей. Кроме того, нужно хранить все данные только в локальных переменных, задавая строковые константы в числовом виде. Если написать char x[] = «hello, world»,
Нельзя использовать никакие библиотечные функции, если только не уверен в том, что они полностью удовлетворяют всем вышеперечисленным требованиям. Системные функции обычно вызываются через интерфейс native-API, также известный под именем sys-call (в Linux-подобных системах за это отвечает прерывание INT 80h, другие системы обычно используют дальний вызов по селектору семь, смещение ноль). Поскольку системные вызовы варьируются от одной системы к другой, это ограничивает среду обитания вируса и при желании он может прибегнуть к внедрению в таблицу импорта.
Откомпилировав полученный файл, мы получим объектник и ругательство компилятора по поводу отсутствия main. Остается только слинковать его в двоичный 32.64-разрядный файл. Естественно, внедрять его в жертву придется вручную, так как системный загрузчик откажется обрабатывать такой файл.
Какой вирусмэйкер удержится от соблазна пополнить свой заплечный рюкзак за чужой счет, выдирая идеи и алгоритмы из тел попавших к нему вирусов? Чаще всего вирусами обмениваются тет-а-тет. Коллекции, найденные в сети, для опытных хакеров не представляют никакого интереса, поскольку набираются из открытых источников, но для начинающих исследователей это – настоящий клад.
Если исходные тексты вируса отсутствуют (кривые дизассемблерные листинги, выдаваемые за божественное откровение, мы в расчет не берем), препарировать двоичный код вируса приходится самостоятельно. Тут-то нас и поджидает одна большая проблема. Дизассемблер всех времен и народов IDA PRO не приспособлен для работы с ELF-вирусами, поскольку отказывается загружать файлы с искаженным section header'ом (а большинство вирусов никак не корректируют его после заражения!). Других достойных дизассемблеров, переваривающих ELF-формат, мне обнаружить так и не удалось (а самому писать лень). За неимением лучших идей приходится возиться с HEX-редакторами (например, с тем же HIEW'ом), разбираясь со служебными структурами файла вручную.
С отладчиками дело обстоит еще хуже. Фактически под *nix существует всего один более или менее самостоятельный отладчик прикладного уровня – gdb (GNU Debugger), являющийся фундаментом для большинства остальных. Простейшие антиотладочные приемы, нарытые в хакерских мануалах времен первой молодости MS-DOS, пускают gdb в разнос или позволяют вирусу вырваться из-под его контроля, поэтому отлаживать вирусный код на рабочей машине категорически недопустимо и лучше использовать для этой цели эмулятор, такой, как BOCHS. Особенно предпочтительны эмуляторы, содержащие интегрированный отладчик, обойти который вирусу будет очень тяжело, а, в идеале, вообще невозможно (BOCHS такой отладчик содержит). Кстати говоря, совершенно необязательно для исследования ELF-вирусов устанавливать *nix. Эмулятора для этих целей будет более чем достаточно.
Структура ELF-файлов (ELF – Execution & Linkable Format) имеет много общих черт с PE (Portable Execution) – основным исполняемым форматом платформы Windows 9x и NT, концепции их заражения весьма схожи, хотя и реализуются различным образом.
ELF-файл состоит из ELF-заголовка (ELF-header), описывающего основные особенности поведения файла, заголовка программной таблицы (program header table) и одного или нескольких сегментов (segment), содержащих код, инициализированные/неинициализированные данные и прочие структуры.
Листинг
Структура исполняемого ELF-файла
ELF Header
Program header table
Segment 1
Segment 2
Section header table (optional)
Каждый сегмент представляет собой непрерывную область памяти со своими атрибутами доступа (кодовый сегмент обычно доступен только на исполнение, сегменты данных как минимум доступны на чтение, а при необходимости еще и на запись). Пусть слово «сегмент» не вводит тебя в заблуждение: ничего общего с сегментной моделью памяти тут нет. Большинство 32-битных реализаций UNIX'а помещают все сегменты ELF-файла в один 4-гигабайтный «процессорный» сегмент (т.н. плоская (flat) модель памяти – прим. ред.). В памяти все ELF-сегменты должны выравниваться по величине страницы (на x86, равной 4 Кб), но непосредственно в самом ELF-файле хранятся в невыравненном виде, вплотную прижимаясь друг к другу. Сам ELF-заголовок и program header в первый сегмент не входят (ну, формально не входят), но совместно грузятся в память, при этом начало сегмента следует непосредственно за концом program header'а и по границе страницы не выравнивается!
Последним из всех идет заголовок таблицы секций (section header table). Для исполняемых файлов он необязателен и реально используется только в объектниках. Еще в нем нуждаются отладчики – исполняемый файл с изуродованным section header table не отлаживается ни gdb, ни производными от него отладчиками, хотя нормально обрабатывается операционной системой.
Сегменты естественным образом делятся на секции. Типичный кодовый сегмент состоит из секций .init (процедуры инициализации), .plt (секция связок), .text (основой код программы) и .finit (процедуры финализации), атрибуты которых описываются в section header'e. Загрузчик операционной системы ничего не знает о секциях, игнорируя их атрибуты и загружая весь сегмент целиком. Тем не менее, для сохранения работоспособности зараженного файла под отладчиком вирус должен корректировать оба заголовка сразу – как program header, так и section header.
Основные структуры ELF находятся в файле /usr/include/elf.h.
За более подробной информацией обращайся к оригинальной спецификации на ELF-файл «Executable and Linkable Format – Portable Format Specification», составленной, естественно, на английском языке.
Простейший и наиболее универсальный метод заражения сводится к поглощению оригинального файла вирусом. Вирус просто дописывает оригинальный файл к своему телу как оверлей, а для передачи управления жертве проделывает обратный процесс: пропускает первые virus_size байт своего тела (что обычно осуществляется функцией seek), считывает оставшийся «хвост» и записывает его во временный файл. Присваивает атрибут исполняемого и делает ему exec, предварительно расщепив материнский процесс функцией fork. После завершения работы файла-жертвы вирус удаляет временный файл с диска.
Описанный алгоритм элементарно реализуется на любом языке программирования вплоть до Бейсика и пригоден как для исполняемых файлов, так и для скриптов. Однако ему присущи и недостатки. Он медлителен и неэлегантен, требует возможности записи на диск и прав установки атрибута «исполняемый». Кроме того, появление посторонних файлов на диске не может долго оставаться незамеченным, и участь вируса заранее предрешена. Поэтому большинство вирусов не используют такую методику, а предпочитают внедряться в конец последнего сегмента файла, расширяя его на необходимую величину.