Издательский дом ООО "Гейм Лэнд"ЖУРНАЛ ХАКЕР 116, АВГУСТ 2008 г.

Трюки от Криса

Крис Касперски

Хакер, номер #116, стр. 116-104-1

Вольности, допускаемые Си/Си++ в отношении указателей (что отличает их от Java/.NET и других «правильных» языков), обеспечивают гибкость, компактность и высокое быстродействие целевого кода. Но подобная демократия таит в себе скрытую угрозу, и всякий указатель становится источником непредсказуемых побочных эффектов!

В одну реку нельзя войти дважды?

Статический анализ отдельно взятой функции (неважно — представленный в виде исходного кода или дизассемблерного листинга) справляется только с локальными переменными и обламывается на указателях, значение которых невозможно вычислить на стадии трансляции (указатель — не константа) и которые обрабатываются уже в run-time.

Всякий неконстантный указатель способен менять логику работы не только отдельно взятой анализируемой функции, но даже и всей программы в целом! Разобраться, что же действительно делает тот или иной указатель, можно только с помощью отладчика или… статической трассировки всего исходного текста – а это фактически равносильно исполнению программы на эмулирующем отладчике.

Начинающие хакеры недооценивают коварство указателей, за что потом расплачиваются изматывающей отладкой, отнимающей намного больше времени, чем кодирование. Хотите наглядный пример? Пожалуйста!

Исходный код загадочной функции

foo(int *arg_a, int *arg_b)

{

printf("1:-> %08Xh:%08Xh\n", *arg_a, *arg_b);

*arg_a = *arg_b;// (1)

printf("2:-> %08Xh:%08Xh\n", *arg_a, *arg_b);

*arg_a = *arg_b;

// (2) - может иметь другое действие, чем (1)

printf("3:-> %08Xh:%08Xh\n", *arg_a, *arg_b);

*arg_a = *arg_b;

// (3) - может иметь другое действие,

чем (1, 2)

printf("4:-> %08Xh:%08Xh\n", *arg_a, *arg_b);

*arg_a = *arg_b;

// (4) - может иметь другое действие,

чем (1, 2, 3)

printf("5:-> %08Xh:%08Xh\n", *arg_a, *arg_b);

}

Казалось бы, такая простая функция foo() — всего четыре команды *arg_a = *arg_b (отладочные вызовы printf не в счет). Разве не очевидно, что здесь происходит копирование ячейки *arg_b в ячейку *arg_a, для «надежности» повторяемое четыре раза? Тогда почему оптимизирующие компиляторы (например, MS VC) даже на максимальном уровне оптимизации не выкидывают вторую и все последующие операции присвоения – в чем легко убедиться, заглянув в дизассемблерный листинг?

Предположение, что все команды "*arg_a = *arg_b" идентичны — ошибочно. Оно базируется на неявном допущении, что arg_a и arg_b указывают на различные ячейки, чего нам никто не гарантирует. И что никаким боком не вытекает из анализа самой функции foo(), принимающей указатели arg_a и arg_b как аргументы. Понять, что же действительно здесь происходит, можно, только обратившись к материнской функции, которая в данном случае выглядит так:

Хитрый вызов функции foo() в программе overlapped-pointers.c

int buf[3]={0, -1, 0};

main()

{

foo(buf, (int*)(((char*)buf) + 1));

}

Компилируем программу из командной строки, как обычно (cl.exe overlapped-pointers.c), запускаем и смотрим результат. По многочисленным просьбам читателей, не осиливших readme к Microsoft Visual Studio или запускающих vcvars32.bat из FAR'а, а не из отдельного cmd.exe, мыщъх решил снабжать каждый приводимый листинг .dsw/.dsp-проектами, упрощающими сборку программы до предела (клавиша <F7> в Студии).

Но вернемся к обсуждению полученного вывода. Он намного интереснее, чем это можно предположить из анализа исходного текста:

Результат работы программы overlapped-pointers.c

1:-> 00000000h:FF000000h

2:-> FF000000h:FFFF0000h

3:-> FFFF0000h:FFFFFF00h

4:-> FFFFFF00h:FFFFFFFFh

5:-> FFFFFFFFh:FFFFFFFFh

Вот тебе и раз! Значение ячеек *arg_a и *arg_b меняется во всех четырех итерациях, образуя узор наподобие «елочки». А все потому, – что функции foo() переданы указатели на перекрывающиеся (overlapped) ячейки памяти, и операция присвоения меняет не только приемник (target), но и source (источник)! Теперь понятно, почему возникает «елочка»: раз присвоение меняет источник, то повторное присвоение даст иной результат. Точнее, может дать, но может и не дать. Тут все от содержимого источника/приемника зависит.

Вот потому статический анализ на указателях и «отдыхает».

Хардкорные извраты с адресом возврата

Оправившись после «культурного шока», рассмотрим более сложный пример, – функцию baz(), состоящую из операции «*ret_addr = arg_a» (задействует один-единственный указатель). Ну и какого подвоха от нее ожидать? Да любого! Это же указатель! И писать он способен в абсолютно любую ячейку памяти, куда только разрешена запись. Может подменять адрес возврата из функции. Это используется для скрытой передачи управления многими защитными механизмами или представляет собой грязный «хак», вставленный сотрудником, который не хочет, чтобы коллеги понимали, как работает написанный им код.

Собственно говоря, сама функция baz() не делает ничего интересного. Все трюкачество сосредоточено в вызывающем коде, который в простейшем случае выглядит так – смотри «хитрый вызов функции foo() в программе overlapped-pointers.c». Вопрос: что выводит эта программа на экран? Даже динамический анализ с отладчиком в руках требует напряжения мозговых извилин и знания особенностей языка. Хинт: данный пример не закладывается на конкретный компилятор и сохраняет свою работоспособность даже при портировании на другие 32-битные системы. С формальной точки зрения, это не такой уж и грязный хак (примечание: для упрощения кода, в программе использована ассемблерная вставка, но при желании, можно реализовать и на чистом Си).

Исходный код программы со скрытой подменой адреса возврата

// stdcall, since we need to blow up the args

__stdcall bar (int arg_a)

{

static int count;

printf("%X:-> %08Xh:hello bar

\n",++count, arg_a);

}

// cdecl, since we don't want to blow up the args

__cdecl baz (int arg_a, int *ret_addr)

{

*ret_addr = arg_a;

}

main()

{

foo(buf, (int*)(((char*)buf) + 1));

__asm

{

push eax

; for bar.RETN 4 (second pass, dummy arg)

push offset next

; for bar.RETN 4 (second pass, jump to next)

moveax, esp

; calculate the pointer to...

subeax, 0Ch

..the return address of baz

push eax

; for baz.ret_addr AND bar.RET 4 (dummy arg)

push offset bar

; for baz.arg_aAND bar.RET 4

(jump to itself)

call baz

; go-go bar baz :-)

next:

; don't need SUB ESP,XX - stack is ok due to RET4

}

Компилируем программу так же, как и раньше (для экономии места она реализована все в том же файле overlapped-pointers.c), и смотрим на результат ее выполнения:

1:-> 0012FF60h:hello bar

2:-> 00000019h:hello bar

Мы морально подготовлены к тому, что после завершения baz() вызывается функция bar() (это вытекает из названия указателя ret_addr и явной засылке адреса bar командой push offset bar). Но тот факт, что bar() вызывается дважды — уже сюрприз! Говорю же, здесь не баг, а заранее просчитанный ход, который очень трудно распознать даже матерым программистам.

Отладчик покажет полную картину происходящего, а чтобы не сбиться с пути, мыщъх даст несколько хинтов. Функция main() готовит стек, засовывая в него незначимый аргумент-пустышку (dummy arg), за которым следует адрес выхода из функции (смещение метки next). Далее засылается тщательно рассчитанное смещение адреса возврата из baz(), передаваемое как аргумент ret_addr и указатель на bar (аргумент arg_a).

И происходит вызов функции baz() с форсированной спецификацией cdecl-соглашения, определяющего порядок засылки аргументов в стек и снимающего с baz() обязанности по вычистке аргументов из стека после завершения. Команда «*ret_addr = arg_a;» подменяет адрес возврата из baz(), заменяя его указателем на функцию bar(), которая и вызывается при завершении baz(). Причем, стек остается в том же состоянии, в каком он был на момент вызова baz() – то есть с двумя аргументами: указателем на адрес возврата из baz(), ну теперь уже bar(), и адресом самой функции bar(), которая (это очень важно!) форсирована на stdcall-соглашение, что обязывает ее вычищать аргументы из стека по завершению.

При первом выполнении функции bar() она выводит аргумент arg_a (указатель на адрес возврата). Второй аргумент трактуется как адрес возврата в материнскую функцию. В данном случае таковой является сама bar(), указатель на которую следует за arg_a. Следовательно, при выходе из функции bar() она выталкивает arg_a из стека вместе с адресом возврата на саму себя. В результате происходит ее повторный вызов, но теперь на вершине стека — фиктивный аргумент-пустышка и указатель на метку next, куда и передается управление.

Такая вот замысловатая арабская вязь кода. Что тут сложного? После объяснения, конечно, ничего. Но сколько людей способны сказать, что делает эта программа по одним лишь исходным текстам без запуска ее на выполнение?

Содержание
загрузка...
Журнал Хакер #151Журнал Хакер #150Журнал Хакер #149Журнал Хакер #148Журнал Хакер #147Журнал Хакер #146Журнал Хакер #145Журнал Хакер #144Журнал Хакер #143Журнал Хакер #142Журнал Хакер #141Журнал Хакер #140Журнал Хакер #139Журнал Хакер #138Журнал Хакер #137Журнал Хакер #136Журнал Хакер #135Журнал Хакер #134Журнал Хакер #133Журнал Хакер #132Журнал Хакер #131Журнал Хакер #130Журнал Хакер #129Журнал Хакер #128Журнал Хакер #127Журнал Хакер #126Журнал Хакер #125Журнал Хакер #124Журнал Хакер #123Журнал Хакер #122Журнал Хакер #121Журнал Хакер #120Журнал Хакер #119Журнал Хакер #118Журнал Хакер #117Журнал Хакер #116Журнал Хакер #115Журнал Хакер #114Журнал Хакер #113Журнал Хакер #112Журнал Хакер #111Журнал Хакер #110Журнал Хакер #109Журнал Хакер #108Журнал Хакер #107Журнал Хакер #106Журнал Хакер #105Журнал Хакер #104Журнал Хакер #103Журнал Хакер #102Журнал Хакер #101Журнал Хакер #100Журнал Хакер #099Журнал Хакер #098Журнал Хакер #097Журнал Хакер #096Журнал Хакер #095Журнал Хакер #094Журнал Хакер #093Журнал Хакер #092Журнал Хакер #091Журнал Хакер #090Журнал Хакер #089Журнал Хакер #088Журнал Хакер #087Журнал Хакер #086Журнал Хакер #085Журнал Хакер #084Журнал Хакер #083Журнал Хакер #082Журнал Хакер #081Журнал Хакер #080Журнал Хакер #079Журнал Хакер #078Журнал Хакер #077Журнал Хакер #076Журнал Хакер #075Журнал Хакер #074Журнал Хакер #073Журнал Хакер #072Журнал Хакер #071Журнал Хакер #070Журнал Хакер #069Журнал Хакер #068Журнал Хакер #067Журнал Хакер #066Журнал Хакер #065Журнал Хакер #064Журнал Хакер #063Журнал Хакер #062Журнал Хакер #061Журнал Хакер #060Журнал Хакер #059Журнал Хакер #058Журнал Хакер #057Журнал Хакер #056Журнал Хакер #055Журнал Хакер #054Журнал Хакер #053Журнал Хакер #052Журнал Хакер #051Журнал Хакер #050Журнал Хакер #049Журнал Хакер #048Журнал Хакер #047Журнал Хакер #046Журнал Хакер #045Журнал Хакер #044Журнал Хакер #043Журнал Хакер #042Журнал Хакер #041Журнал Хакер #040Журнал Хакер #039Журнал Хакер #038Журнал Хакер #037Журнал Хакер #036Журнал Хакер #035Журнал Хакер #034Журнал Хакер #033Журнал Хакер #032Журнал Хакер #031Журнал Хакер #030Журнал Хакер #029Журнал Хакер #028Журнал Хакер #027Журнал Хакер #026Журнал Хакер #025Журнал Хакер #024Журнал Хакер #023Журнал Хакер #022Журнал Хакер #021Журнал Хакер #020Журнал Хакер #019Журнал Хакер #018Журнал Хакер #017Журнал Хакер #016Журнал Хакер #015Журнал Хакер #014Журнал Хакер #013Журнал Хакер #012Журнал Хакер #011Журнал Хакер #010Журнал Хакер #009Журнал Хакер #008Журнал Хакер #007Журнал Хакер #006Журнал Хакер #005Журнал Хакер #004Журнал Хакер #003Журнал Хакер #002Журнал Хакер #001