книги хакеры / журнал хакер / xa-278_Optimized

Сегод­ ня­ мы приступим­ к подробно­ му­ изучению­ условного­ хода выполнения­ программ­ . Без него невозможно­ предста­ ­ вить программи­ рова­ ние­ как таковое. Мы начнем­ наше пог ­ ружение с условных операто­ ров­ if — then — else и раз ­ беремся­ , как компилятор­ интерпре­ тиру­ ет­ подобные­ конс ­ трукции­ .

Пятнадцать­ лет назад эпичес­ ­кий труд Криса­ Каспер­ ­ски «Фундамен­ ­таль­ные основы­ хакерства­ » был настоль­ ­ной книгой­ каждого­ начинающе­ ­го исследова­ ­ теля в области компьютер­ ­ной безопасности­ . Однако­ время­ идет, и знания­ , опубликован­ ­ные Крисом­ , теряют­ актуаль­ ­ность. Редакторы­ «Хакера» попыта ­ лись обновить­ этот объемный­ труд и перенести­ его из времен­ Windows 2000 и Visual Studio 6.0 во времена­ Windows 10 и Visual Studio 2019.

Ссылки­ на другие­ статьи из этого­ цикла­ ищи на странице­ автора­ .

Раньше­ мы уже встречались­ с условным ходом выполнения­ программ­ , однако­ ограничи­ вались­ короткими­ описани­ ями­ команд и поверхностным­ разбором­ выполняемых­ ими операций­ . Управляемый­ ход выполнения­ , без сомнения­ , самая важная­ веха развития­ программи­ рова­ ния­ своего­ времени­ и затмева­ ет­ многие­ последу­ ющие­ , даже такие, как структурное­ программи­ рова­ ние­ или ООП. Только­ с высоты высокоуров­ невого­ языка­ кажется­ , что в условии­ if

— then — else нет ничего любопытного­ и оно лишено какого либо разнооб­ ­ разия. Но для компилято­ ра­ это простор­ для самодеятель­ нос­ ти­ ! И в близких­ по духу ситуациях­ он может постро­ ить­ кардиналь­ но­ различа­ ющий­ ся­ код.

В процес­ ­сорной архитек­ ­туре x86 предус­ ­мотрен весьма­ «оригиналь­ ­ный» набор команд для перенаправле­ ­ния хода выполнения­ програм­ ­мно­го кода. «Оригиналь­ ­ный» не значит­ хороший или плохой­ , это значит­ , что он отличает­ ­ся от набора микропро­ ­цес­соров других­ архитек­ ­тур и произво­ ­дите­лей: ARM, MIPS, SPARC и так далее. Как ты знаешь­ , первый­ процес­ ­сор этой серии соз ­ давался­ впопыхах­ для времен­ ­ной замены еще не готового­ iAPX-432, пос ­ ледний, в свою очередь­ , должен­ был уметь в многоза­ ­дач­ность и управление­ памятью на аппарат­ ­ном уровне­ . Чего в итоге­ не случилось­ . А x86 продол­ ­жил свое развитие­ . Поэтому­ сейчас­ , когда­ за годы эволюции­ процес­ ­соров серии x86 скопил­ ­ся набор инструк­ ­ций, хакерам приходит­ ­ся разгре­ ­бать весь этот хлам, дабы раскру­ ­тить порядок выполнения­ машинных­ инструк­ ­ций.

ИДЕНТИФИКАЦИЯ УСЛОВНЫХ ОПЕРАТОРОВ

Сущес­ ­тву­ет два вида алгорит­ ­мов — безусловные­ и условные. Порядок дей ­ ствий безусловно­ ­го алгорит­ ­ма всегда­ постоянен­ и не зависит от входных­ данных­ . Например­ , a = b + c. Порядок действий­ условных алгорит­ ­мов, нап ­ ротив, зависит от данных­ , поступа­ ­ющих «на вход». Например­ :

Обрати­ внимание­ на выделенные­ жирным­ шрифтом­ ключевые­ слова­ «если», «то» и «иначе­ », называемые­ операто­ ­рами условия­ или условными­ операто­ ­ рами. Без них не обходит­ ­ся ни одна программа­ (вырожденные­ примеры­ наподобие­ «Hello, World!» не в счет). Условные операто­ ­ры — сердце­ любого языка­ программи­ ­рова­ния. Поэтому­ чрезвычай­ ­но важно­ уметь их правиль­ ­но определять­ .

В общем виде (не углубляясь­ в синтакси­ ­чес­кие подробнос­ ­ти отдельных­ языков­ ) оператор­ условия­ схематич­ ­но изобража­ ­ется так:

«IF (условие­ ) THEN { оператор­ 1; оператор­ 2; } ELSE { оператор­ a; опе-­» раторb; }

Задача­ компилято­ ра­ — преобра­ зовать­ эту конструк­ цию­ в последова­ тель­ ­ ность машинных­ команд, выполняющих­ оператор­ 1, оператор­ 2, если условие­

истинно, и оператор­ a, оператор­ b — если оно ложно­ . Однако­ микропро­ цес­ ­

соры серии 80x86 поддержи­ ­вают весьма­ скромный­ набор условных команд, ограничен­ ­ный фактичес­ ­ки одними­ условными­ переходами­ . Программис­ ­там, знакомым­ лишь с IBM PC, такое ограниче­ ­ние не покажется­ чем то неестес­ ­ твенным­ , между­ тем существу­ ­ет масса­ процес­ ­соров, поддержи­ ­вающих пре ­ фикс условного­ выполнения­ инструк­ ­ции. То есть вместо­ того, чтобы­ писать

TEST ECX,ECX0

JNZ xxx0

MOV EAX,0x6660

там поступа­ ют­ так:

TEST ECX,ECX0

IFZ MOV EAX,0x6660

IFZ и есть префикс­ условного­ выполнения­ , разреша­ ющий­ выполнение­ сле ­ дующей команды­ только­ в том случае­ , если установ­ лен­ флаг нуля. В этом смысле­ микропро­ цес­ соры­ 80x86 можно­ сравнить­ с ранними­ диалектами­ язы ­ ка Basic, не разреша­ ющи­ ми­ использовать­ в условных выражениях­ никакой другой­ оператор­ , кроме­ GOTO. Сравни­ :

Старый­ диалект Basic:

10 IF A=B THEN GOTO 300

20 GOTO 400

30 PRINT "A=B"

40 ... // Прочий код программы0

Новый­ диалект Basic:

IF A=B THEN PRINT "A=B"

Если­ ты когда­ нибудь программи­ ­ровал на старых­ диалектах­ Basic, то, веро ­ ятно, помнишь­ , что гораздо­ выгоднее­ выполнять­ GOTO, если условие­ ложно­ , а в против­ ­ном случае­ продол­ ­жать нормаль­ ­ное выполнение­ программы­ . Как видишь, вопреки­ расхожему­ мнению­ , навыки программи­ ­рова­ния на Basic отнюдь не бесполез­ ­ны, особен­ ­но в дизассем­ ­бли­рова­нии программ­ .

Большинс­ ­тво компилято­ ­ров (даже не оптимизи­ ­рующих) инвертируют­ истинность условия­ , трансли­ ­руя конструк­ ­цию

в следующий­ псевдокод­ :

0

IF (NOT условие­ ) THEN continue0

оператор­ 1;0

оператор­ 2;0 continue:0

…

0

Следова­ ­тель­но, для восста­ ­нов­ления исходного­ текста­ программы­ нам при ­ дется­ вновь инвертировать­ условие­ и «подцепить­ » блок операто­ ­ров { опе ­ ратор1; оператор­ 2; } к ключево­ ­му слову­ THEN. Иначе­ говоря, если откомпи ­

лирован­ ­ный код выглядит­ так:

10 IF A<>B THEN 300

20 PRINT "A=B"

30 ...// Прочий код программы0

можно­ с уверен­ ностью­ утверждать­ , что в исходном тексте­ присутс­ тво­ вали­ строки­ IF A=B THEN PRINT "A=B". А если программист­ , наоборот­ , проверял­ переменные­ A и B на неравенство­ , то есть в коде присутс­ тво­ вала­ конструк­ ция­ IF A<>B THEN PRINT "A<>B"? Все равно­ компилятор­ инвертирует­ истинность условия­ и сгенери­ рует­ следующий­ код:

10 IF A=B THEN 300

20 PRINT "A<>B"

30 ... // Прочий код программы0

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

0

IF (условие­ ) THEN do0 GOTO continue0

do:0

оператор­ 1;0

оператор­ 2;0 continue:0

…

0

В таком случае­ инвертировать­ условие­ не нужно­ . Впрочем­ , если это сделать­ , ничего страшного­ не произой­ ­дет, разве­ что код программы­ станет­ менее понятным­ , да и то не всегда­ .

Рассмот­ ­рим теперь, как трансли­ ­рует­ся полная­ конструк­ ­ция

«IF (условие­ ) THEN { оператор­ 1; оператор­ 2; } ELSE { оператор­ a; опе-­» раторb; }

Одни­ компилято­ ры­ поступа­ ют­ так:

0

IF (условие­ ) THEN do_it0 // Ветка­ ELSE0

оператор­ a;0

оператор­ b;0 GOTO continue0 do_it:0

// Ветка­ IF0

оператор­ 1;0

оператор­ 2;0 continue: 0

А другие­ — так:

0

IF (NOT условие­ ) THEN else0 // Ветка­ IF0

оператор­ 1;0

оператор­ 2;0 GOTO continue0 else:0

// Ветка­ ELSE0

оператор­ a;0

оператор­ b0 continue: 0

И никаких гвоздей­ !

Продолжение статьи0 →

ОПРЕДЕЛЯЕМ КУРС ВЫПОЛНЕНИЯ ПРОГРАММ ПРИ РЕВЕРСИНГЕ

ТИПЫ УСЛОВИЙ

Условия­ делятся­ на простые­ (элемен­ ­тарные) и сложные­ (составные­ ). Пример­ первых­ : if (a==b) ..., вторых­ : if ((a==b) && (a!=0)) .... Очевид­ ­но,

что любое сложное­ условие­ можно­ разложить­ на ряд простых­ . Вот с простых­ условий­ мы и начнем­ .

Сущес­ ­тву­ют два основных типа элемен­ ­тарных условий­ : условия­ отно ­ шений («меньше­ », «равно­ », «больше­ », «меньше­ или равно­ », «не равно­ », «больше­ или равно­ », обознача­ ­ются как <, ==, >, <=, !=, >=) и логичес­ ­кие усло ­ вия («И», «ИЛИ», «НЕ», в С нотации обознача­ ­ются так: &&, ||, !). Еще в отдельную­ категорию­ можно­ выделить битовые­ провер­ ­ки. Их объеди­ ­няют с логичес­ ­кими, однако­ несколь­ ­ко некоррек­ ­тно смешивать­ в одну кучу людей и коней, даже если они чем то взаимос­ ­вязаны.

Если­ условие­ истинно, оно возвра­ щает­ булево значение­ TRUE, если лож ­ но — FALSE. Внутреннее­ (физическое­ ) представ­ ление­ булевых переменных­ зависит от конкрет­ ной­ реализации­ и может быть любым. По общепринято­ му­ соглашению­ FALSE равно­ нулю, а TRUE не равно­ нулю. Часто­ (но не всегда­ ) TRUE равно­ единице­ , но на это нельзя­ полагаться­ ! Так, код IF ((a>b)!=0) ..

. абсолют­ ­но корректен­ , а вот IF ((a>b)==1) ... привязан­ к конкрет­ ­ной реализации­ и потому нежелателен­ .

Обрати­ внимание­ : IF ((a>b)!=0) ... проверя­ ет­ на неравенство­ нулю отнюдь не значения­ самих переменных­ a и b, а именно­ результат­ их срав ­ нения. Рассмот­ рим­ следующий­ пример­ :

IF ((666==777)==0) printf("Woozl!");

Как ты думаешь­ , что отобразит­ ся­ на экране­ , если его запустить­ ? Правиль­ ­ но — Woozl! Почему? Ведь ни 666, ни 777 не равно­ нулю! Да, но ведь 666 !=

IF a != b THEN continue

IF a == 0 THEN continue

... // Код условия0

:continue0

... // Прочий код0

Порядок­ вычисления­ элемен­ тарных­ условий­ в сложном­ выражении­ зависит от прихотей­ компилято­ ра­ , гарантиру­ ется­ лишь, что условия­ , «связан­ ные­ » опе ­ рацией­ логического­ «И», проверя­ ются­ слева­ направо­ в порядке­ их объявле­ ­ ния в программе­ . Причем­ если первое­ условие­ ложно­ , то следующее­ за ним вычислено­ не будет! Это дает возможность­ писать код наподобие­ сле ­

дующего­ : if ((filename) && (f=fopen(&filename[0],"rw")))... — если указатель­ filename указыва­ ет­ на невыделен­ ную­ область памяти (то есть, попросту­ говоря, содержит­ ноль — логическое­ FALSE), функция­ fopen не вызывается­ и ее краха­ не происхо­ дит­ . Такой способ­ вычислений­ получил название­ быстрых­ булевых операций­ (теперь то ты знаешь­ , что подразуме­ ­ вается­ под «быстро­ той­ »).

Перей­ ­дем теперь к вопросу­ идентифика­ ­ции логических­ условий­ и анализу­ сложных­ выражений­ . Вернемся­ к уже облюбован­ ­ному нами выражению­ if (( a==b) && (a!=0)) ... и вглядим­ ­ся в результат­ его трансля­ ­ции.

Легко­ видеть — он выдает­ себя серией­ условных переходов­ к одной и той же метке­ , причем­ , обрати­ внимание­ , выполняет­ ­ся провер­ ­ка на неравенство­ каж ­ дого из элемен­ ­тарных условий­ , а сама метка­ расположе­ ­на позади кода усло ­ вия.

Идентифика­ ­ция логической­ операции­ «ИЛИ» намного­ сложнее­ в силу неоднознач­ ­ности ее трансля­ ­ции. Рассмот­ ­рим это на примере­ выражения­ if ((a==b) || (a!=0)) ... Его можно­ разбить­ на элемен­ ­тарные операции­

так.

И так.

Первый­ вариант­ обладает­ весьма­ запоминающей­ ­ся внешностью­ — серия проверок­ (без инверсии условия­ ) на одну и ту же метку­ , расположен­ ­ную перед кодом условия­ , а в конце­ этой серии — безусловный­ переход на метку­ , расположен­ ­ную позади кода условия­ .

Однако­ оптимизи­ ­рующие компилято­ ­ры выкидывают­ безусловный­ переход, инвертируя­ провер­ ­ку последне­ ­го условия­ в цепочке­ и соответс­ ­твен­но меняя адрес перехода­ . По неопытности­ эту конструк­ ­цию часто­ принима­ ­ют за смесь

OR и AND.

Кстати­ , о смешан­ ­ных операци­ ­ях. Рассмот­ ­рим результат­ трансля­ ­ции сле ­

дующего­ выражения­ : if ((a==b) || (a==c) && (a!=0)) ...:

IF a==b THEN check_null0

IF a!=c THEN continue

check_null:0

IF a==0 THEN continue

... // Код условия0

continue:0

... // Прочий код0

Наглядное представление сложных условий в виде дерева

Конструк­ цию­ , состоящую­ из трех четырех элемен­ тарных­ условий­ , можно­ про ­ анализи­ ровать­ и в уме (если есть соответс­ тву­ ющие­ навыки), но хитрос­ пле­ ­ тения пяти и более условий­ образуют­ самый настоящий­ лабиринт — его с ходу не возьмешь­ . Неоднознач­ ность­ трансля­ ции­ сложных­ условий­ порож ­ дает неоднознач­ ность­ интерпре­ тации­ , что приводит­ к многова­ риан­ тно­ му­ ана ­ лизу, причем­ с каждым­ шагом в голове приходит­ ся­ держать­ все больше­ и больше­ информации­ . Так недолго­ и крышей­ поехать или окончатель­ но­ запутаться­ и получить неверный­ результат­ .

Выход­ в использовании­ двухуров­ ­невой системы­ ретран­ ­сля­ции. На первом­ этапе­ элемен­ ­тарные условия­ приводят­ ­ся к некоторой­ промежу­ ­точ­ной форме­ записи, наглядно­ и непротиво­ ­речи­во отобража­ ­ющей взаимос­ ­вязь элемен­ ­ тарных операций­ . Затем выполняет­ ­ся окончатель­ ­ная трансля­ ­ция в любую подходящую­ нотацию (например­ , С, Basic или Pascal).

Единствен­ ная­ проблема­ — выбрать­ удачную­ промежу­ точ­ ную­ форму­ . Существу­ ет­ множес­ тво­ решений, но по соображени­ ям­ экономии­ пространс­ ­ тва мы рассмот­ рим­ только­ одно — деревья.

Изобразим­ каждое­ элемен­ ­тарное условие­ в виде узла с двумя­ ветвями­ , соответс­ ­тву­ющи­ми состояниям­ : условие­ истинно и условие­ ложно­ . Для наг ­ лядности­ обозначим­ «ложь» равнобед­ ­ренным треуголь­ ­ником, а «истину­ » — квадратом­ и условим­ ­ся всегда­ располагать­ ложь на левой, а истину­ — на пра ­ вой ветке­ . Получившуюся­ конструк­ ­цию назовем гнездом­ (nest).

Схемати­ чес­ кое­ представ­ ление­ гнезда­

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

Рассмот­ ­рим объеди­ ­нение двух элемен­ ­тарных условий­ логической­ опе ­ рацией­ AND на примере­ выражения­ ((a==b) && (a!=0)). Извлекаем­ первое­ слева­ условие­ (a==b), «усажива­ ­ем» его в гнездо­ с двумя­ ветвями­ : левая соответс­ ­тву­ет случаю­ , когда­ a!=b (то есть условие­ a==b ложно­ ), а правая­ , соответс­ ­твен­но, наоборот­ . Затем то же самое делаем­ и со вторым­ условием­

(a!=0).

У нас получаются­ два очень симпатич­ ­ных гнездышка­ , остается­ лишь свя ­ зать их меж собой операци­ ­ей логического­ AND. Как известно­ , AND выполняет­ второе­ условие­ только­ в том случае­ , если истинно первое­ . Значит­ , гнездо­ (a! =0) следует­ прицепить­ к правой­ ветке­ гнезда­ (a==b). Тогда­ правая­ ветка­ гнезда­ (a!=0) будет соответс­ ­тво­вать истинности­ выражения­ ((a==b) && ( a!=0)), а обе левые ветки­ — его ложности­ . Обозначим­ первую­ ситуацию­ мет ­ кой do_it, а вторую­ — continue. В результате­ дерево должно­ принять­ сле ­ дующий вид.

Графичес­ кое­ представ­ ление­ операции­ AND в виде двоично­ го­ дерева

Для нагляднос­ ти­ отметим­ маршрут­ из вершины­ дерева к метке­ do_it жирной­ стрелкой­ . Как видишь, в пункт do_it можно­ попасть только­ одним путем. Вот так графичес­ ки­ выглядит­ операция­ AND.

Теперь­ перейдем­ к операции­ логического­ OR. Рассмот­ рим­ конструк­ цию­ (( a==b) || (a!=0)). Если условие­ (a==b) истинно, то и все выражение­ счи ­ тается­ истинным. Следова­ тель­ но­ , правая­ ветка­ гнезда­ (a==b) связана­ с мет ­ кой do_it. Если же условие­ (a==b) ложно­ , то выполняет­ ся­ провер­ ка­ сле ­ дующего­ условия­ . Значит­ , левая ветка­ гнезда­ (a==b) связана­ с гнездом­ (a!

=0).

Очевид­ но­ , если условие­ (a!=0) истинно, то истинно и все выражение­ (( a==b) || (a!=0)). Напротив­ , если условие­ (a!=0) ложно­ , то ложно­ и все выражение­ , так как провер­ ка­ условия­ (a!=0) выполняет­ ся­ только­ в том слу ­ чае, если условие­ (a==b) ложно­ . Отсюда­ мы заключа­ ем­ , что левая ветка­ гнез ­ да (a!=0) связана­ с меткой­ continue, а правая­ — с do_it. Обрати­ внимание­ , в пункт do_it можно­ попасть двумя­ различны­ ми­ путями! Вот так графичес­ ки­ выглядит­ операция­ OR.

Графичес­ кое­ представ­ ление­ операции­ OR в виде двоично­ го­ дерева

До сих пор мы отображали­ логические­ операции­ на деревья, но ведь деревья создавались­ как раз для противо­ полож­ ной­ цели — преобра­ зова­ ния­ пос ­ ледователь­ нос­ ти­ элемен­ тарных­ условий­ в интуитив­ но­ понятное­ представ­ ­ ление. Давай займем­ ся­ этим. Пусть в тексте­ программы­ встретит­ ся­ сле ­ дующий код:

IF a==b THEN check_null0

IF a!=c THEN continue

check_null:0

IF a==0 THEN continue

... // Код условия0

continue:0

... // Прочий код0

Извле­ каем­ условие­ (a==b) и сажаем­ его в «гнездо­ », смотрим­ : если оно лож ­ но, то выполняет­ ся­ провер­ ка­ (a!=c), значит­ , гнездо­ (a!=c) связано­ с левой веткой­ гнезда­ (a==b). Если же условие­ (a==b) истинно, то управление­ передается­ метке­ check_null, проверя­ ющей­ истинность условия­ (a==0). Следова­ тель­ но­ , гнездо­ (a==0) связано­ с правой­ веткой­ гнезда­ (a==b). В свою очередь­ , если условие­ (a!=с) истинно, управление­ получает­ метка­ continue, в против­ ном­ случае­ — check_null. Значит­ , гнездо­ (a==0) связано­ одновремен­ но­ и с правой­ веткой­ гнезда­ (a==b), и с левой веткой­ гнезда­ (a!

=c).

Конеч­ ­но, это проще­ рисовать, чем описывать­ ! У тебя должно­ получиться­ дерево, очень похожее на следующее­ изображение­ .

Графичес­ ­кое представ­ ­ление сложного­ выражения­

Смотри­ : к гнезду­ (a==0) можно­ попасть двумя­ путями — либо через гнездо­ (

Исследование конкретных реализаций

Прежде­ чем приступать­ к отображению­ конструк­ ­ции

«IF (сложное­ условие­ ) THEN оператор­ 1;оператор­ 2; ELSE оператор­ а;опе-­»

раторb

•SSE — Intel Pentium III (начало 1999 года). SSE может выполнять­ 70 новых инструк­ ­ций, которые используют­ 128-разрядные­ регистры­ ХММ0-ХММ7, MMX и даже обычные­ 32-битные­ регистры­ .

•SSE2 — Intel Pentium IV (июнь 2000 года). SSE2-инструк­ ­ции значитель­ ­но усовер­ ­шенс­тво­вали SSE первого­ поколения­ , добавив 144 новые инструк­ ­ ции.

•SSE3 — Intel Pentium 4 на базе 90-нм (февраль­ 2004 года). Добавлены­

дополнитель­ ­ные 13 инструк­ ­ций, которые расширя­ ­ют математичес­ ­кие воз ­ можности­ DSP, и поток управления­ инструк­ ­циями.

• SSSE3 — дополнитель­ ­ное обновление­ для SSE3, которое вклю ­ чает 16 новых инструк­ ­ций. Позволя­ ­ет работать как с 64-битными­ (MMX), так и с 128-битными­ (XMM) регистра­ ­ми, вносить­ слова­ в инструк­ ­ции

и переставлять­ байты­ в них.

•SSE 4 — Intel Core 2 Duo (середина­ 2007 года). Добавлены­ 54 инструк­ ­ции.

•С середины­ 2008 года Intel занимается­ разработ­ ­кой и развити­ ­ем AVX — расширения­ системы­ команд для x86-совмести­ ­мых микропро­ ­цес­соров. Впоследс­ ­твии вышли­ расширения­ AVX-2, AVX-512. Эти расширения­ добавили­ к архитек­ ­туре процес­ ­сора шестнад­ ­цать 256-битных­ регистров­ YMM0 — YMM15. Обсуждение­ AVX выходит за рамки­ рассмат­ ­рива­емо­го материала­ .

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

•CMP — эта команда­ эквивален­ ­тна операции­ целочисленно­ ­го вычитания­ SUB, за одним исключени­ ­ем — в отличие­ от SUB, CMP не изменяет­ операн­ ­ дов, а воздей­ ­ству­ет лишь на флаги­ основного­ процес­ ­сора: флаг нуля, флаг переноса­ , флаг знака­ и флаг переполнения­ .

•Флаг нуля — ZF устанав­ ­лива­ется в единицу­ , если результат­ вычитания­ равен нулю, то есть операн­ ­ды равны­ друг другу­ .

•Флаг переноса­ — CF устанав­ ­лива­ется в единицу­ , если при вычитании­ произо­ ­шел заем из старшего­ бита уменьшаемо­ ­го операн­ ­да, то есть уменьшаемое­ меньше­ вычитаемо­ ­го.

•Флаг знака­ — SF равен старшему­ , знаково­ ­му биту результата­ вычис ­ лений, то есть результат­ вычислений­ — отрицатель­ ­ное число­ .

•Флаг переполнения­ — OF устанав­ ­лива­ется в единицу­ , если результат­ вычислений­ «залез» в старший­ бит, приводя­ к потере знака­ числа­ .

Редко­ используемые­ :

•Флаг полуперено­ ­са — AF устанав­ ­лива­ется в единицу­ , если в результате­ предыду­ ­щей операции­ произо­ ­шел перенос (или заем) из третьего­ бита в четвертый­ . Этот флаг использует­ ­ся автомати­ ­чес­ки командами­ дво ­ ично десятичной­ коррекции­ (BCD).

•Флаг четности­ — PF устанав­ ­лива­ется в единицу­ , если младший­ байт результата­ предыду­ ­щей команды­ содержит­ четное­ количество­ битов, рав ­ ных 1. Если количество­ единиц­ в младшем­ байте­ нечетное­ , то этот флаг устанав­ ­лива­ется в 0.

•64-разрядный­ регистр флагов­ — RFLAGS (начиная с Pentium 4 на ядре Prescott) добавил 32 новых флага­ , каждый­ из которых зарезервирован­

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

Для провер­ ки­ состояния­ флагов­ существу­ ет­ множес­ тво­ команд условных переходов­ , выполняющих­ ся­ в случае­ , если определен­ ный­ флаг (набор фла ­ гов) установ­ лен­ (или сброшен­ ). Инструк­ ции­ , использующиеся­ для анализа­ результата­ сравнения­ целых чисел, приведе­ ны­ в таблице­ 1.

Таблица­ 1: соответс­ твие­ операций­ отношения­ командам­ процес­ сора­

Обрати­ внимание­ , что флаг OF предназна­ ­чен обнаружи­ ­вать переполнение­

при работе со знаковы­ ­ми операн­ ­дами; когда­ вычисления­ ведутся­ с беззна­ ­ ковыми­ числами­ , эта работа возлага­ ­ется на флаг CF.

В общем случае­ конструк­ ция­ IF (элемен­ тарное­ условие­ отношения­ ) THEN do_it трансли­ рует­ ся­ в следующие­ команды­ процес­ сора­ :

CMP A,B0

Jxx do_it0

continue:0

Между­ инструк­ циями­ CMP и Jxx могут находиться­ и другие­ команды­ , не изме ­ няющие флагов­ процес­ сора­ , например­ MOV, LEA.

Продолжение статьи0 →

ОПРЕДЕЛЯЕМ КУРС ВЫПОЛНЕНИЯ ПРОГРАММ ПРИ РЕВЕРСИНГЕ

СРАВНЕНИЕ ВЕЩЕСТВЕННЫХ ЧИСЕЛ

Таблица­ 2: команды­ сравнения­ веществен­ ных­ значений­

Коман­ ­ды сравнения­ веществен­ ­ных чисел из набора SSE2, такие как COMISD (полный­ их набор см. на рисунке­ выше), равно­ как команды­ целочисленно­ ­го сравнения­ , воздей­ ­ству­ют на регистры­ основного­ процес­ ­сора. Это отличает­ их от команд расширения­ х87, которые воздей­ ­ству­ют на регистры­ сопроцес­ ­ сора.

Главная­ проблема­ заключа­ ­ется в том, что в природе­ не существу­ ­ет инс ­ трукций­ условного­ перехода­ , управляемых­ флагами­ сопроцес­ ­сора! К тому же флаги­ сопроцес­ ­сора непосредс­ ­твен­но недоступны­ , и, чтобы­ прочитать­ их статус­ , необходимо­ было выгрузить­ регистр состояния­ сопроцес­ ­сора SW в память или регистр общего­ назначения­ основного­ процес­ ­сора. Хуже все ­ го — анализи­ ­ровать флаги­ придет­ ­ся «вручную­ »! Если при сравнении­ целых чисел можно­ и не задумывать­ ­ся, какими именно­ флагами­ управляется­ условный переход, достаточ­ ­но написать:

CMP A,B0

JGE do_it; (Jump [if] Great [or] Equal — прыжок, если A больше или

равно B)

то с сопроцес­ ­сором этот номер не пройдет­ ! Правда­ , можно­ схитрить­ и ско ­ пировать­ флаги­ сопроцес­ ­сора в регистр флагов­ основного­ процес­ ­сора, а затем использовать­ родные­ инструк­ ­ции условного­ перехода­ из серии Jxx.

Конеч­ ­но, непосредс­ твен­ но­ скопиро­ вать­ флаги­ из сопроцес­ сора­

восновной процес­ ­сор было нельзя­ , и эту операцию­ приходи­ ­лось выполнять­

вдва этапа­ . Сначала­ флаги­ FPU выгрузить­ в память или регистр общего­ наз ­

начения, а уже оттуда­ заталкивать­ в регистр флагов­ CPU. Непосредс­ ­твен­но модифициро­ ­вать регистр флагов­ CPU умеет­ только­ одна команда­ — POPF. Остается­ только­ выяснить­ , каким флагам­ сопроцес­ ­сора какие флаги­ основного­ процес­ ­сора соответс­ ­тву­ют. А это отдельная­ наука! Ей надо было заниматься­ всякий­ раз при сравнении­ веществен­ ­ных чисел! Хорошо, что тех ­ нологии не стоят­ на месте­ и теперь мы можем использовать­ команды­ из рас ­ ширения SSE и забыть про сопроцес­ ­сор, как про страшный­ сон!

Давай­ рассмот­ ­рим следующий­ крайне­ простой­ пример­ (compare_double), откомпилиро­ ­ван­ный в Visual Studio 2022 в режиме Release и с отключен­ ­ной оптимиза­ ­цией:

#include <iostream>

int main() {

double num1 = 0.0001;

double num2 = 0.0002;

if (num1 < num2)

std::cout << "num1 меньше, чем num2" << "\n";

else

std::cout << "num1 больше либо равно num2" << "\n";

}

Ключевая­ активность здесь — это сравнение­ веществен­ ных­ чисел двойной­ точности­ . Загрузим­ результиру­ ющий­ экзешник в IDA и посмотрим­ , какую инс ­ трукцию­ для сравнения­ выбрал­ наш компилятор­ :

; int __cdecl main(int argc, const char **argv, const char **envp)

main proc near ; CODE XREF:

__scrt_common_main_seh+107↓p

; DATA XREF: .pdata:

ExceptionDir↓o

; Две локальные переменные

Копиру­ ем­ веществен­ ное­ число­ двойной­ точности­ из сегмента­ данных­ только­ для чтения­ :0

.rdata:0000000140003330 __real@3f1a36e2eb1c432d dq 0.0001 ; DATA XREF: main+4↑r в регистр XMM0.

movsd xmm0, cs:__real@3f1a36e2eb1c432d

; Из регистра копируем значение в локальную переменную var_10

movsd [rsp+38h+var_10], xmm0

Копиру­ ем­ веществен­ ное­ число­ двойной­ точности­ из сегмента­ данных­ только­ для чтения­ :0

.rdata:0000000140003338 __real@3f2a36e2eb1c432d dq 0.0002 ; DATA XREF: main+12↑r в регистр XMM0.

Ага! Для сравнения­ двух веществен­ ­ных значений­ компилятор­ выбрал­ инструк­ ­ цию COMISD! Заглянем­ в таблицу­ 2, чтобы­ узнать, присутс­ ­тву­ет ли она там. Действи­ ­тель­но, она тут как тут! Из этого­ следует­ , что данная­ инструк­ ­ция вхо ­

дит в SSE2.

Обрати­ внимание­ : к моменту­ сравнения­ в XMM0 находится­ второе­ , боль ­ шее число­ — 0.0002. А в переменной­ var_10 — первое­ , меньшее­ , — 0.0001. Когда­ первый­ операнд­ больше­ второго­ , инструк­ ция­ COMISD устанав­ лива­ ет­ флаги­ следующим­ образом­ : ZF = 0; PF = 0; CF = 0.

comisd xmm0, [rsp+38h+var_10]

Инструк­ ция­ JBE делает­ переход по метке­ , когда­ флаги­ CF либо ZF установ­ ­ лены в единицу­ . Иными­ словами­ , когда­ первый­ операнд­ меньше­ второго­ или равен ему. В нашем случае­ ни одно из перечисленных­ условий­ не соб ­ людено, поэтому­ переход на метку­ не выполняет­ ся­ .

Изначаль­ но­ в этом дизассем­ блер­ ном­ листинге­ строки­ в сегменте­ данных­ были представ­ лены­ набором неопределен­ ных­ байтов­ . Как придать­ им удо ­ бочитаемый­ вид, мы уже проходи­ ли­ .

; В регистр RDX грузим указатель на строку

; Вызываем функцию вывода строки на консоль, передавая ей параметры

---------------------------------------------------------------------

------

В результате­ , как и ожидалось­ , будет такой вывод.

Любопыт­ но­ увидеть­ , какой бинарник­ приведен­ ного­ выше кода пригото­ вит­ C++Builder. Итак, дизассем­ блер­ ный­ листинг­ , постро­ енный­ с отключен­ ной­ оптимиза­ цией­ программы­ , должен­ выглядеть­ пример­ но­ следующим­ образом­ :

; int __cdecl main(int argc, const char **argv, const char **envp)

public main

В регистры­ XMM0 и XMM1 из сегмента­ данных­ только­ для чтения­ загружа­ ­ем зна ­ чения веществен­ ­ных констант­ :

Для представ­ ления­ веществен­ ных­ (в нашем случае­ сверхма­ лых­ ) значений­ C++Builder применил­ сверхболь­ шие­ числа­ .

; Числа из памяти возвращаются в регистры, меняясь начальными

местами дислокации

movsd xmm0, [rbp+var_18]

movsd xmm1, [rbp+var_20]

Ага! C++Builder восполь­ зовал­ ся­ немного­ другой­ инструк­ цией­ сравнения­ веществен­ ных­ значений­ ! Команда­ неупорядо­ чен­ ного­ сравнения­ UCOMISD отличает­ ся­ от команды­ COMISD только­ тем, что она возвра­ щает­ ошибку­ , если операнд­ источник равен значению­ SNaN. Тогда­ как COMISD выдает­ исклю ­ чение, если операнд­ источник равен SNaN либо QNaN.

Тем не менее с флагами­ процес­ соров­ она поступа­ ет­ точно­ так же, как команда­ упорядо­ чен­ ного­ сравнения­ .

ucomisd xmm1, xmm0

Инструк­ цию­ JBE мы уже проходи­ ли­ , останав­ ливать­ ся­ на ней не будем. В дан ­ ном случае­ , как и в прошлый­ раз, переход на метку­ не выполняет­ ся­ .

num2"

; ...и вызываем оператор вывода строки на экран

---------------------------------------------------------------------

------

; ...затем перекладываем его в регистр

; Обрати внимание, сколько ненужных операций делает C++Builder

; Возвращаем ноль

Было­ интерес­ но­ увидеть­ , что даже такой крохот­ ный­ пример­ чик­ двумя­ лидиру ­ ющими­ компилято­ рами­ превраща­ ется­ в разный­ бинарный­ код!

УСЛОВНЫЕ КОМАНДЫ БУЛЕВОЙ УСТАНОВКИ

Начиная­ с чипа 80386, язык микропро­ цес­ соров­ Intel обогатил­ ся­ командой­ условной установ­ ки­ бита — SETxx, которая устанав­ лива­ ет­ свой единствен­ ный­ операнд­ в единицу­ (булево TRUE), если в условии­ xx равенство­ , и сбрасыва­ ет­ его в ноль (булево FALSE), если условие­ xx ложно­ .

Коман­ ­да SETxx широко использует­ ­ся оптимизи­ ­рующи­ми компилято­ ­рами, чтобы­ устранить­ ветвле­ ­ния, то есть избавить­ ­ся от условных переходов­ , так как последние­ очищают­ конвей­ ­ер процес­ ­сора, чем серьезно­ снижают­ про ­ изводитель­ ­ность программы­ .

Таблица­ 3: условные команды­ булевой установ­ ки­

Идентификация типов с помощью условий

Условные­ команды­ — ключ к идентифика­ ции­ типов. Посколь­ ку­ результат­ сравнения­ знаковых­ и беззна­ ковых­ переменных­ анализи­ руют­ разные­ группы­ инструк­ ций­ , можно­ уверен­ но­ и однозначно­ отличить­ signed int (знаковые­ )

от unsigned int (беззна­ ­ковых).

ПРОЧИЕ УСЛОВНЫЕ КОМАНДЫ

Микропро­ ­цес­соры серии 80x86 поддержи­ ­вают множес­ ­тво условных команд, которые в общем случае­ не отобража­ ­ются на операции­ отношения­ , а потому и редко­ используют­ ­ся компилято­ ­рами (можно­ даже сказать­ — вообще­ не используют­ ­ся), но зато часто­ встречают­ ­ся в ассемблер­ ­ных вставках­ . Сло ­ вом, они заслужива­ ­ют хотя бы беглого­ упомина­ ­ния.

Команды условного перехода

Помимо­ описан­ ­ных в табл. 1, существу­ ­ют другие­ условные переходы­ , среди­ них: JCXZ, JECXZ, JO, JNO, JP (он же JPE), JNP (он же JPO), JS и JNS. Из них только­ JCXZ и JECXZ имеют­ непосредс­ ­твен­ное отношение­ к операци­ ­ям срав ­ нения. Оптимизи­ ­рующие компилято­ ­ры могут заменять конструк­ ­цию

CMP [E]CX, 00

JZ do_it0

более­ коротким­ эквивален­ том­ :

J[E]CX do_it0

Однако­ чаще всего­ они (из за ограничен­ ­ности интеллекта­ и лени своих­ раз ­ работчиков­ ) этого­ не делают­ .

Условные­ переходы­ JO и JNS используют­ ­ся в основном в математичес­ ­ких библиоте­ ­ках для обработ­ ­ки чисел большой­ разряднос­ ­ти (например­ , 1024битных­ целых).

Условные­ переходы­ JS и JNS, помимо основного­ своего­ предназна­ чения­ , часто­ используют­ ся­ для быстрой­ провер­ ки­ значения­ старшего­ бита.

Условные­ переходы­ JP и JNP вообще­ практичес­ ­ки не используют­ ­ся, ну разве­ что в экзотич­ ­ных ассемблер­ ­ных вставках­ .

Таблица­ 4: вспомога­ тель­ ные­ условные переходы­

Команды условной пересылки

Начиная­ с Pentium, процес­ ­соры поддержи­ ­вают команду­ условной пересылки­ CMOVxx, пересылающей­ значение­ из источника­ в приемник­ , если условие­ xx истинно. Это позволя­ ­ет писать намного­ более эффективный­ код, не содер ­ жащий ветвле­ ­ний и укладыва­ ­ющий­ся в меньшее­ число­ инструк­ ­ций.

Рассмот­ рим­ конструк­ цию­ IF a<b THEN a=b. Сравни­ , как она трансли­ рует­ ­ ся с использовани­ ем­ условных переходов­ (1) и команды­ условной пересылки­

(2):

В табл. 5 дано краткое­ , но вполне­ достаточ­ ное­ для дизассем­ бли­ рова­ ния­ программ­ описание­ команд семейства­ CMOVxx. За более подробны­ ми­ разъ ­ яснениями­ обращай­ ся­ к с. 251 справоч­ ного­ руководства­ от Intel.

Таблица­ 5: основные команды­ условной пересылки­

Булевы сравнения

Логичес­ кой­ лжи (FALSE) соответс­ тву­ ет­ значение­ ноль, а логической­ истине­ (TRUE) — любое ненулевое­ значение­ . Таким образом­ , булевы отношения­ сво ­ дятся­ к операции­ сравнения­ значения­ переменной­ с нулем. Конструк­ ция­ IF ( a) THEN do_it трансли­ рует­ ся­ в IF (a!=0) THEN do_it.

Практичес­ ­ки все компилято­ ­ры заменяют­ инструк­ ­цию CMP A, 0 более короткой­ командой­ TEST A,A или OR A,A. Во всех случаях­ , если A==0, уста ­ навлива­ ­ется флаг нуля и наоборот­ .

Поэто­ му­ , встретив­ в дизассем­ блер­ ном­ тексте­ конструк­ цию­

TEST EAX, EAX0

JZ do_it0

можно­ с уверен­ ностью­ утверждать­ , что мы имеем­ дело с булевым сравнени­ ­ ем.

ИТОГИ

В сегодняшней­ статье мы научились­ применять­ и выявлять­ ряд ассемблер­ ­ных команд, постепен­ ­но добавляемых­ в язык сборки­ на протяже­ ­нии многих­ десятилетий­ — за время­ непрекра­ ­щающе­гося развития­ микропро­ ­цес­соров серии x86. Таким образом­ мы не только­ рассмот­ ­рели состояние­ микропро­ ­ цессора­ настояще­ ­го времени­ , но и, вернувшись­ к его истокам­ , взглянули­ на его прароди­ ­теля с сопроцес­ ­сором и устарев­ ­шей системой­ команд.

Мы научились­ разбирать­ сложные­ условия­ на отдельные­ компонен­ ты­ , тем самым облегчая себе жизнь при анализе­ программ­ , изучили­ различия­ бинар ­ ного кода, генерируемо­ го­ разными­ компилято­ рами­ на основе­ одного­ и того же исходника­ , увидели­ , как с помощью условий­ можно­ определять­ типы чисел. Острой темой стали­ различные­ механизмы­ работы с целыми и вещес ­ твенными­ значени­ ями­ .

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

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

Пятнадцать­ лет назад эпичес­ ­кий труд Криса­ Каспер­ ­ски «Фундамен­ ­таль­ные основы­ хакерства­ » был настоль­ ­ной книгой­ каждого­ начинающе­ ­го исследова­ ­ теля в области компьютер­ ­ной безопасности­ . Однако­ время­ идет, и знания­ , опубликован­ ­ные Крисом­ , теряют­ актуаль­ ­ность. Редакторы­ «Хакера» попыта ­ лись обновить­ этот объемный­ труд и перенести­ его из времен­ Windows 2000 и Visual Studio 6.0 во времена­ Windows 10 и Visual Studio 2019.

Ссылки­ на другие­ статьи из этого­ цикла­ ищи на странице­ автора­ .

Сегод­ няшняя­ статья — продол­ жение­ предыду­ щей­ , если ее не прочитать­ , разобрать­ ся­ в коде будет трудновато­ . Что ж, продол­ жим­ наш заплыв­ в океан­ условий­ , ветвле­ ний­ , отношений­ и компро­ мис­ сов­ .

ИДЕНТИФИКАЦИЯ ТЕРНАРНОГО ОПЕРАТОРА

Конструк­ ция­ a=(условие)?do_it:continue языка­ C в общем случае­ тран ­

слирует­ ­ся так: IF (условие) THEN a=do_it ELSE a=continue, однако­ результат­ компиляции­ обеих­ конструк­ ­ций, вопреки­ распростра­ ­нен­ному мне ­ нию, не всегда­ идентичен­ . Оператор­ ?: значитель­ ­но легче­ поддает­ ­ся опти ­ мизации­ , чем ветвле­ ­ние IF — THEN — ELSE. Покажем это на следующем­ при ­ мере:

#include <iostream>

int main() {

int a = -2;

int b = 2;

a = (a > 0) ? 1 : -1; // Тернарный оператор0

if (b > 0) // Ветвление0

b = 1;

else

b = -1;

std::cout << "a + b = " << a + b;

}

Если­ пропус­ ­тить эту программу­ сквозь компилятор­ Microsoft Visual C++ 2022 с отключен­ ­ной оптимиза­ ­цией, на выходе получим такой код:

; int __cdecl main(int argc, const char **argv, const char **envp)

Во дела! Компилятор­ оба условных операто­ ­ра скомпилил­ в одинако­ ­вый код! Теперь переведем­ компилятор­ в режим максималь­ ­ной оптимиза­ ­ции с при ­ оритетом­ по скорос­ ­ти — /O2, произве­ ­дем компиляцию­ , откроем­ результат­

в дизассем­ ­бле­ре и посмотрим­ на результат­ :

Что за чертовщи­ ­на?! Здесь не осталось­ никаких условностей­ ! Даже если включить­ режим оптимиза­ ­ции с приори­ ­тетом размера­ — /O1, ничего не изме ­ нится­ . Компилятор­ заоптимизи­ ­ровал все что можно­ !

Ачто нам продемонс­ ­три­рует C++Builder? Сначала­ без оптимиза­ ­ции:

;int __cdecl main(int argc, const char **argv, const char **envp)

public main