Фундаментальные основы хакерства. Соглашение о быстрых вызовах — fastcall

Как сле­дует из наз­вания, fastcall пред­полага­ет быс­трый вызов фун­кции. Дру­гими сло­вами, при его исполь­зовании парамет­ры переда­ются через регис­тры про­цес­сора, что отра­жает­ся на ско­рос­ти работы под­прог­рамм. Меж­ду тем во вре­мена x86 fastcall не был стан­дарти­зиро­ван, что соз­давало немало труд­ностей прог­раммис­ту.

В ори­гиналь­ном изда­нии кни­ги «Фун­дамен­таль­ные осно­вы хакерс­тва» Крис в свой­ствен­ной ему манере очень под­робно опи­сал механиз­мы переда­чи парамет­ров с помощью регис­тров для 32-бит­ных ком­пилято­ров. Он упо­мянул C/C++ и Turbo Pascal от раз­личных фирм‑раз­работ­чиков, таких как Microsoft, Borland, Watcom (эта ком­пания ныне ско­рее мер­тва, чем жива, одна­ко откры­тый про­ект их ком­пилято­ра мож­но най­ти на GitHub). Крис под­робно опи­сал переда­чу как целых, так и вещес­твен­ных типов дан­ных: int, long, float, single, double, extended, real, etc.

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

Бла­года­ря воз­росше­му количес­тву регис­тров на плат­форме x64 для ком­пилято­ров C/C++ име­ется толь­ко одно сог­лашение вызова. Пер­вые четыре целочис­ленных парамет­ра или ука­зате­ля переда­ются в регис­трах RCX, RDX, R8, R9. Для C++ в подав­ляющем боль­шинс­тве вызовов методов пер­вый целочис­ленный параметр занима­ет ука­затель this. Пер­вые четыре парамет­ра, пред­став­ленные зна­чени­ями с пла­вающей запятой (вещес­твен­ные зна­чения), переда­ются в регис­трах XMM0, XMM1, XMM2, XMM3 рас­ширения SSE. На 64-бит­ной плат­форме набор это­го рас­ширения был уве­личен с 8 до 16 регис­тров.

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

Идентификация передачи и приема регистров

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

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

Есть ли сре­ди оставших­ся такие, содер­жимое которых исполь­зует­ся без явной ини­циали­зации? В пер­вом приб­лижении фун­кция при­нима­ет парамет­ры имен­но через эти регис­тры. При деталь­ном же рас­смот­рении проб­лемы всплы­вает нес­коль­ко ого­ворок. Во‑пер­вых, через регис­тры могут переда­вать­ся (и очень час­то переда­ются) неяв­ные парамет­ры фун­кции — ука­затель this, ука­зате­ли на вир­туаль­ные таб­лицы объ­екта и так далее. Во‑вто­рых, если кри­вору­кий прог­раммист, наде­ясь, что зна­чение перемен­ной пос­ле объ­явле­ния дол­жно быть рав­но нулю, забыва­ет об ини­циали­зации, а ком­пилятор помеща­ет перемен­ную в регистр, то при ана­лизе прог­раммы она может быть при­нята за переда­ваемый через регистр параметр фун­кции.

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

Практическое исследование механизма передачи аргументов через регистры

Для зак­репле­ния все­го ска­зан­ного давай рас­смот­рим сле­дующий при­мер:

Пе­ред пос­тро­ением это­го при­мера отклю­чи опти­миза­цию. Резуль­тат его обра­бот­ки ком­пилято­ром Microsoft Visual C++ 2019 дол­жен выг­лядеть так:

Все аргу­мен­ты помеща­ются в регис­тры. Судя по их зна­чени­ям, в обратном поряд­ке. Ради нез­начитель­ной опти­миза­ции ком­пилятор решил не задей­ство­вать регис­тры пол­ностью, а, зная типы дан­ных наперед, исполь­зовать толь­ко необ­ходимое прос­транс­тво. Таким обра­зом, вмес­то того, что­бы выделять регис­тры целиком: R9, R8, RDX, RCX, были отда­ны толь­ко полови­ны пер­вых трех (R9D, R8D, EDX) и лишь вось­мая часть пос­ледне­го — регистр CL.

В ито­ге IDA без нашей помощи вос­ста­нови­ла про­тотип вызыва­емой фун­кции. Но если бы у нее не получи­лось это сде­лать? Тог­да бы мы гадали: Long, как и int, занима­ет 32 бита, char — единс­твен­ный тип дан­ных, занима­ющий один байт.

Не­важ­но, ког­да ты будешь читать этот текст, воз­можно, во вре­мена Windows 17 и Intel Core i9, одна­ко сис­темные прог­раммис­ты могут изме­нить раз­меры базовых типов дан­ных в соот­ветс­твии с архи­тек­турой вычис­литель­ных сис­тем. Что­бы узнать их раз­мер кон­крет­но на тво­ей машине, мож­но вос­поль­зовать­ся такой незамыс­ловатой прог­раммой:

По­лучен­ный при выпол­нении фун­кции MyFunc резуль­тат (сум­ма парамет­ров) переда­ется фун­кции printf для вывода на кон­соль в шес­тнад­цатерич­ном виде:

Ди­зас­сем­блер­ный лис­тинг фун­кции MyFunc выг­лядит сле­дующим обра­зом:

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

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

А теперь пос­мотрим, что сге­нери­ровал C++Builder 10.3. Сна­чала main:

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

Пос­ле это­го, по сути, мож­но вызывать сле­дующую фун­кцию, переда­вая парамет­ры в регис­трах. Имен­но это Visual C++ и делал. Тем не менее C++Builder нагоро­дил допол­нитель­ного кода: он заг­ружа­ет зна­чения регис­тров в стек, как бы обме­нивая их зна­чения, но в ито­ге все рав­но вызыва­ет MyFunc и переда­ет четыре парамет­ра в регис­трах. Как же это неоп­тималь­но!

За­тем MyFunc:

И тут C++Builder нагоро­дил лиш­ний код. Пос­ле ини­циали­зации сте­ка зна­чение 8-бит­ного регис­тра CL копиру­ется в AL. Понят­но, что 8-бит­ным явля­ется пер­вый переда­ваемый параметр типа char. Но если мы заг­лянем в main, то обна­ружим, что отту­да не переда­ется 8-бит­ный параметр. Меж­ду тем переда­ется 32-бит­ный ECX: mov ecx, eax. И уже в MyFunc берет­ся толь­ко чет­вертая часть от ECX и помеща­ется в AL.

Те­перь, узнав раз­меры парамет­ров, можем вывес­ти про­тотип (сов­ремен­ная IDA справ­ляет­ся с этим без нашей помощи, но нам ведь тоже это надо уметь):

Од­нако порядок сле­дова­ния трех пос­ледних аргу­мен­тов может быть иным, так­же сто­ит учи­тывать, что в Windows тип Long тоже 32-бит­ный и он тоже пред­назна­чен для обра­бот­ки целочис­ленных зна­чений. Сле­дова­тель­но, исполь­зует те же регис­тры про­цес­сора.

Да­лее к находя­щему­ся в регис­тре ECX зна­чению пос­тепен­но при­бав­ляет­ся каж­дое зна­чение аргу­мен­та, ранее помещен­ное в стек:

К сло­ву, ком­пиляция выпол­нена из‑под све­жень­кой Windows 11, одна­ко это никак не пов­лияло на дизас­сем­блер­ный лис­тинг.

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

Ре­зуль­тат его ком­пиляции в Visual C++ 2019 дол­жен выг­лядеть так:

Эге‑гей! Даже с отклю­чен­ной опти­миза­цией ком­пилятор не стал дваж­ды вызывать фун­кцию strlen, а сра­зу под­ста­вил вычис­ленные резуль­таты:

Па­рамет­ры фун­кции, как и положе­но, переда­ются в обратном поряд­ке. По име­ющей­ся информа­ции, даже без помощи IDA мы можем зап­росто вос­ста­новить про­тотип фун­кции: MyFunc(char,int *,int).

Пос­ле заряд­ки фор­матной стро­ки резуль­тат отправ­ляет­ся на печать. Затем регистр EAX обну­ляет­ся. Стек вос­ста­нав­лива­ется и деини­циали­зиру­ется.

Оз­накомим­ся с дизас­сем­блер­ным лис­тингом фун­кции MyFunc:

Фун­кция при­нима­ет три аргу­мен­та в регис­трах по пра­вилам fastcall и раз­меща­ет их в сте­ке.

Бе­рем зна­чение из ячей­ки по адре­су [rdx+rcx] и скла­дыва­ем с содер­жимым регис­тра EAX, в котором было сох­ранено зна­чение перемен­ной arg_0. Затем переза­писы­ваем этот регистр.

Прос­то? Прос­то! Тог­да рас­смот­рим резуль­тат твор­чес­тва C++Builder (обновлен­ного до 10.4.2 Sydney — это пос­ледняя на вре­мя написа­ния дан­ных строк вер­сия). Код дол­жен выг­лядеть так: