Раздел: Документация
0 ... 19 20 21 22 23 24 25 ... 102 Заголовок таблицы секций, равно как и сами секции, имеет значение только для компо-неточных файлов, загрузчик исполняемых файлов их игнорирует, независимо от тог0 присутствуют они в файле или нет. 3.Просматривая Program Header Table, вирус находит сегмент, наиболее предпочтительный для заражения (то есть тот сегмент, в который указывает точка входа). 4.Длина найденного сегмента увеличивается на величину, равную размеру тель вируса. Это осуществляется путем синхронной коррекции полей pfilezr pjnemz. 5.Все остальные сегменты смещаются вниз, при этом ноле pof f set каждого и.ч них увеличивается на длину тела вируса. 6.Анализируя заголовок таблицы секций (если только он присутствует в файле), вирус находит секцию, наиболее предпочтительную для заражения (как правило, заражается секция, находящаяся в сегменте последней: это избавляет вирус от необходимости перемещения всех остальных секций вниз). 7.Размер заражаемой секции (ноле shsize) увеличивается на величину, равную размеру тела вируса. 8.Все хвостовые секции сегмента смещаются вниз, при этом поле shoffset каждой из них увеличивается на длину тела вируса (если вирус внедряется в последнюю секцию сегмента, этого делать не нужно). 9.Вирус дописывает себя к концу заражаемого сегмента, физически смешая содержимое всей остальной части файла вниз. 10. Для перехвата управления вирус корректирует точку входа в файл (eentry) либо же внедряет в истинную точку входа jmp на свое тело (впрочем, методика перехвата управления — тема отдельного большого разговора). Прежде чем приступить к обсуждению характерных «следов» вирусного внедрения, давайте посмотрим, какие секции в каких сегментах обычно бывают расположены. Оказывается, схема их распределения далеко не однозначна и возможны самые разнообразные вариации. В одних случаях секции кода и данные помещаются в отдельные сегменты, в других — секции данных, доступные толь ко для чтения, объединяются с секциями кода в единый сегмент. Соответствен но, и последняя секция кодового сегмента каждый раз будет иной. Большинство файлов включает в себя более одной кодовой секции, и распоЛ8 гаются эти секции приблизительно так, как показано в листинге 2.11. Листинг 2.11. Схема расположения кодовых секций типичного файла .initсодержи! инициаллзационный код .pitсодержит таблицу связки подпро: рамм .textсодержит основной коп программы .finiсодержит термирующий код программы Присутствие секции . f init делает секцию . text не последней секцией коДоВ° т сегмента файла, как чаще всего и происходит. Таким образом, в зависимое!11 в скриптах 73 стратегии распределения секций по сегментам, последней секцией файла обычно является либо секция . finit, либо . rodata. СекНИЯ .finit в большинстве своем — это такая крохотная секция, заражение которой трудно оставить незамеченным. Код, расположенный в секции .finit н непосредственно перехватывающий на себя пить выполнения программой, выглядит несколько странно, если не сказать подозрительно (обычно управление на .finit передается косвенным образом как аргумент функции atexit). Вторжение будет еще заметнее, если последней секцией в заражаемом сегменте окажется секция .rodata (машинный код при нормальном развитии событий к данные никогда не попадает). Не остается незамеченным и вторжение в конец первой секции кодового сегмента (в последнюю секцию сегмента, предшествующему кодовому сегменту), поскольку кодовый сегмент практически всегда начинается с секции .init, вызываемой из глубины стартового кода и по обыкновению содержащей пару-тройку машинных команд. Вирусу здесь будет просто негде затеряться, и его присутствие сразу же станет заметным! Более совершенные вирусы внедряются в конец секции .text, сдвигая все остальное содержимое файла вниз. Распознать такую заразу значительно сложнее, поскольку визуально структура файла выглядит неискаженной. Однако некоторые зацепки все-таки есть. Во-первых, оригинальная точка входа подавляющего большинства файлов расположена в начале кодовой секции, а не в ее конце. Во-вторых, зараженный файл имеет нетипичный стартовый код (подробнее об этом рассказывалось в предыдущей главе). И в-третьих, далеко не все вирусы заботятся о выравнивании сегментов (секций). Последний случай стоит рассмотреть особо. Системному загрузчику, ничего не знающему о существовании секций, степень их выравнивания но барабану (простите, я хотел сказать «...она для него некритична»). Тем не менее во всех нормальных исполняемых файлах секции тщательно выравнены на величину, указанную в поле shaddralign. При заражении файла вирусом последний далеко не всегда оказывается так аккуратен, и некоторые секции могут неожиданно Для себя очутиться но некратным адресам. Работоспособности программы это не нарушит, но вот факт вторжения вируса сразу же демаскирует. Сегменты выравнивать тоже не обязательно (при необходимости системный загрузчик сделает это самостоятельно), однако программистский этикет предписывает выравнивать секции, даже если ноле palign равно нулю (то есть выравнивания не требуется). Все нормальные линкеры выравнивают сегменты по фаиней мере на величину, кратную 32 байтам, хотя это происходит и не всеяла. Тем не менее, если сегменты, следующие за сегментом кода, выровнены на еньшую величину — к такому файлу следует присмотреться повнимательнее, м. ° ,,емаловажный момент: при внедрении вируса в начало кодового сег-И "Та°и м°жет создать свой собственный сегмент, предшествующий данному. ТУТ ш<рус неожиданно сталкивается с довольно интересной проблемой. Сдви-ь кодовый сегмент вниз он не может, так как тот обычно начинается с нуле-р 0 с,мещения в файле, перекрывая собой предшествующие ему сегменты. За-е1ная программа, в принципе, может и работать, но раскладка сегментов а,1°вится слишком уж необычной, чтобы ее не заметить.
B0R PR Pb В Pb flxQ $» * . - Ь 0S 0c В 0c BT * * , f /lib/ld-lmu x.so.l % > У. ~ * Рис. 2.6. Фрагмент файла, зараженного вирусом Lin/Vit. Поля, модифицированные вирусом, выделены траурной рамкой Многие вирусы (и, в частности, вирус Lin/Obsidan) выдают себя тем, что при в»1 дрении в середину файла «забывают» модифицировать заголовок таблицы С-* ций (либо же модифицируют его некорректно). Как уже отмечалось выше, в пр° цессе загрузки исполняемых файлов в память системный загрузчик гчитывя информацию о сегментах и проецирует их содержимое целиком. Внутрен1 структура сегментов его совершенно не интересует. Даже если заголовок Т;" лицы секций отсутствует или заполнен некорректно, запущенная на выпо-!1"1 Выравнивание функций внутри секций — это вообще вещь (в смысле: вещд0к вещественное доказательство). Кратность выравнивания функций нигде и Н]" как не декларируется, и всякий программист склонен выравнивать Функц по своему. Одни используют выравнивание на адреса, кратные 04h, друп,е 08h, 10h или даже 20h! Определить степень выравнивания без качествеццОГо дизассемблера практически невозможно. Требуется выписать стартовые адре са всех функций и найти наибольший делитель, на который все они делятся без остатка. Дописывая себя в конец кодового сегмента, вирус наверняка ошибется с выравниванием адреса пролога функции (если он вообще позаботится о со-здании функции в этом месте!), и он окажется отличным от степени выравнивания, принятой всеми остальными функциями. Попутно заметим, что опреде. лять степень выравнивания при помощи дизассемблера IDA PRO — плохая идея, так как она определяет ее неправильно, закладываюсь на наименьшее возможное значение, в результате чего вычисленная степень выравнивания от функции к функции будет варьироваться. Классическим примером вируса, внедряющегося в файл путем расширения кодового сегмента, является вирус Linux.Vit.4096. Любопытно, что различные авторы ио-разиому описывают стратегии, используемые вирусом для заражения. Так, Евгений Касперский почему-то считает, что вирус Vit записывается в начало кодовой секции заражаемого файла (http://www.viruslist.com/viruslist.html?id=3276), в то время как он размещает свое тело в конце кодового сегмента файла (http:// www.nai.com/common/media/vil/pdf/mvanvoers VB conf 202000.pdf). Далее приведен фрагмент ELF-файла, зараженного вирусом Vit (рис. 2.6). OELFOO0 В V 0 ? ИК , (U** V !! *4I*В (Daа* ♦ уттВ ▼ В" ! ♦ е о в 0 ... 19 20 21 22 23 24 25 ... 102
|