книги хакеры / журнал хакер / 091_Optimized

`char*'

beta.cpp:356: error: `O_BINARY' undeclared (first use this function)

beta.cpp:361: error: `lseek' undeclared (first use this function)

beta.cpp:377: error: invalid conversion from `void*' to `char*'

beta.cpp:384: error: `read' undeclared (first use this function)

beta.cpp:398: error: `close' undeclared (first use this Попытка компиляции файла beta.cpp и результат function)

Сошибкой34 всепонятно — программаусиленно косит под форточки, прихватив с собой файл <windows.h>, но тут же использует стандартные POSIX-вызовы: open() со странным флагом

O_BINARY, lseek(), read() и close(), которых ни в самом Windows, ни в одном из win32-компиля- торов никогда не существовало (см. ошибки

356, 361, 384 и 398). Убираем строку «#include <windows.h>», меняя ее на «#include <unistd. h>», и удаляем глупый флаг O_BINARY, поскольку по умолчанию файл уже является двоичным (узнать, какие заголовочные файлы соответствуют данной функции, можно из man'а, например, «man 2 open»). Чтобы избавиться от пре-

дупреждения «this file include <malloc.h> which is deprecated, use <stdlib.h> instead», удаляем и «#include <malloc.h>».

Ошибки 245 и 250 устраняются подключением их «родного» заголовочного файла, в котором они были объявлены «#include <ctype.h>» (см. «man isalnum»). А вот функций stricmp()

и strnicmp() в gcc действительно нет, однако они могут быть заменены на аналогичные им strcmp() и strncmp() даже без коррекции аргументов!

Ошибки 339 и 377 исправляются еще проще: достаточно взять строку «buffer = malloc(MAX_ BUFFER_SIZE)» и добавить явное преобразование типов, также называемое кастингом

«buffer = (char *)malloc(MAX_BUFFER_SIZE)».

Исправленныйвариантлежитвфайлеbeta-fixed. cpp и компилируется без всяких нареканий. Будем считать, что с идентификацией трансляторамыразобрались, иexploit откомпилировался нормально, но... это еще не конец, а только начало. Ведь программный листинг — это только оболочка, образно говоря, «тетива», а разящее острие — загадочный и таинственный shell-код, помещенный в строковый «иерогли-

фический» массив вроде «\x29\xc9\x83...\xe9\ xb0\xd9». Что делать, если он не работает или работает не так, как нам этого хочется?

Доработка напильником

Shell-код имеет сложную структуру и обычно состоит из нескольких частей. Например, exploit milw0rm.com/exploits/1075, приложен-

ный в файле 1075.с, использует целых 6 «иероглифических» массивов: dce_rpc_header1, tag_private, dce_rpc_header2, dce_rpc_header3, offsets, bind_shellcode. Первые пять — это слу-

жебные структуры, атакующие жертву, срывающие буферу крышу и передающие управление на bind_shellcode. Последний представляет

собой «чистый» shell-код, который может быть беспрепятственно заменен любым другим. На самом деле, тут все не так просто, и произвола хоть отбавляй. Как минимум, необходимо убедиться, что мы используем shell-код, совместимый с атакуемой системой, и точки входа у них совпадают. Часто (но не всегда) точка входа расположена в самом начале shell-кода, реже — в конце или в середине. Гораздо хуже, если exploit написан «пионером», и все блоки идут одним большим кусом, внутри которого присутствует и shell-код.

Чтобы определить положение дел, необходимо преобразовать «иероглифический» текст в двоичный файл и дизассемблировать его. Разыскивать соответствующий конвертор совершенно не обязательно. Проще переложить эту задачу на плечи компилятору Си, написав простенькую программку из нескольких строк.

Простейший конвертор для преобразования строковых констант в двоичный код

#include <stdio.h>

int main(void)

{

FILE *f;

if (f = fopen("shellcode", "wb")) fwrite(shellcode, sizeof(shellcode), 1, f);

exit(0);

}

Сам shell-код должен быть размещен в массиве, объявленном как «char shellcode[]» (см. прилагаемый файл hex2bin.c) и приведенным к синтаксису Си (то есть, если shell-код выдернут из perl'а, необходимо удалить точки в конце строковых констант). Компилируем наш импровизированный конвертор, запускаем его на выполнение — и тут же на диске образуется файл «shellcode», который можно загрузить в HTE, IDA Pro или любой другой дизассемблер повкусу, незабывая, конечно, переключитьего в 32-битный режим.

В данном случае мы получим следующий код:

Первые 16 байт shell-кода содержат осмысленный код расшифровщика

Ага! Вполне типичный расшифровщик. Значит, точка входа в shell-код действительно находится в начале массива, и он может быть беспрепятственно заменен любым таким же. Если же вместо осмысленного кода нас встречает мусор, то нужно последовательно отступать на один байт до тех пор, пока мы не получим что-то удобоваримое.Естественно,дляэтогонеобходимознать ассемблер и хотя бы в общих чертах представлять себе устройство операционной системы.

Правильно спроектированный shell-код работает на всех версиях операционных систем, для которых он предназначен, однако в последнее времявсечащеичащеприходитсясталкиваться с «пионерством», которое привязано к фиксированным адресам и функционирует только под определенной сборкой Linux-ядра или заранее заданным сервис-паком, наложенным на

Windows.

*nix-подобные системы в этом плане менее изменчивы, и проблема «фиксированных адресов»здесьпрактическисведенананет.Обычно shell-код вызывает необходимые ему функции через системные вызовы, интерфейс с которыми обеспечивается прерыванием INT 80h или дальним вызовом по адресу 0007h:00000000h, что позволяет shell-коду функционировать под всей линейкой осей, для которых он предназначен. Тем не менее, определенные системные вызовы в различных версиях ядер реализованы неодинаково, что порождает проблемы совместимости. К счастью, базовый набор системных вызовов остается единым для всех осей, и грамотно спроектированный exploit поражает как Linux, так и BSD.

Заключение

Последние версии *nix'ов оснащены довольно мощными защитными механизмами: неисполняемым стеком, рандомизатором адресного пространства и т.д. Обычным exploit'ом такую штуку уже не пробить, а потому техника написания shell-кодов в ближайшем будущем обещает круто измениться, но прежде чем бросаться на неисполняемый стек, необходимо разобраться в существующих exploit'ах, что мы сейчас и попытались сделать. z

mov eax, 666h ; число, которое необходимо вывести на экран

; // переводим число в hex, dec и oct системы исчисления в ASCII-представлении sub esp, 60h; резервируем память под буфер, куда пойдет результат

call ds:[CreateProcess] ; косвенный вызов функции без суффиксов

}

Ну что же, компилятор выбрал ASCII-вариант, что соответствует его настройкам по умолчанию:

При вызове функций типа system квадратные скобки ставить уже нельзя! Функция system является частью библиотеки времени исполнения (RTL — Run Time Library), линкуемой статическим образом, поэтому call system сработает, как и ожидалось, а вот call ds:[system] передаст управление по адресу 83EC8B55h, попытавшись проинтерпретировать начало функции system как указатель:

.text:0040100B 3E FF 15 1A 10 40 00 call dword ptr system

...

;косвенный вызов статически линкуемой функции

;приводит к тому, что первые 4 байта функции

;интерпретируются как указатель, и управление передается по адресу 83EC8B55h

...

Выбор конкретного инструментария - дело вкуса

В стек попадает такое значение регистра ESP, каким оно было до модификации, в результате чего указатель *x указывает на следующее двойное слово!

Но коварство Windows на этом не заканчивается. Многие APIфункции неявно закладываются на выравнивание стека, и, если нам, к примеру, требуется ровно 69h байт стековой памяти, ни в коем случае нельзя писать SUB ESP,69h, а то все рухнет! Следует округлить 69h по границе двойного слова и запросить 6Ch байт или... между актами выделения/освобождения памяти не вызывать никаких API-функций. Часто, в погоне за оптимизацией, программисты, борющиеся за каждый байт памяти, забывают о выравнивании и часами ищут причину, по которой оптимизированный вариант программы отказывается работать.

Заключение

Системное программирование хранит множество секретов, загадок и тайн, постепенно становясь уделом небольшой горстки профессионалов, в то время как мир дружно сходит с ума, подсаживаясь на языки высокого уровня. Об ассемблере вспоминают только тогда, когда требуется что-то очень сильно нестандартное, с чем компилятор уже не справляется или сгенерированный им код не отвечает требованиям производительности.

Вот тут-то и выясняется, что специалистов, владеющих ассемблерами, практически нет, а те, что есть, уже утратили свои навыки и оптимизируют намного хуже компиляторов, разработчики которых за последние несколько лет сделали качественный рывок вперед! Сам по себе ассемблер не обеспечивает ни компактности кода, ни высокой скорости. Все решают хитрые трюки и приемы программирования, находчивость и инженерная смекалка. Главное — выбрать верную стратегию поведения. Не пытаться сократить программу на пару байт, которые все равно будут потеряны при выравнивании, а реально оценивать свой творческий потенциал, сопоставляя его с целями и задачами операций. Алгоритмическая оптимизация зачастую ускоряет программу в десятки раз, в то время как перенос Сишного кода на ассемблере обычно дает 10%-15% выигрыша. Но это еще не значит, что ассемблер бесполезен. Просто, как и любой другой инструмент, он имеет границы своей применимости, с которыми следует считаться, чтобы не попасть впросак! z