Дельфийские игры. Реверсим 64-разрядные приложения на Delphi

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

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

Итак, сфор­мулиру­ем задачу. Име­ется 64-бит­ное при­ложе­ние, пер­вичный ана­лиз которо­го при помощи DIE выда­ет его родс­тво с Delphi.

Вро­де бы все хорошо, одна­ко на при­веден­ном выше скрин­шоте нет­рудно заметить вза­имоис­клю­чающие парамет­ры: пред­лага­емый ана­лиза­тором Delphi не может быть 64-бит­ным. Перек­лючив режим ска­ниро­вания с авто­мати­чес­кого на Nauz File Detector, про­ясня­ем воз­никшее недора­зуме­ние.

Ко­неч­но же, это гораз­до более поз­дняя вер­сия Embarcadero Delphi 35.0 (28.0.44500.8973). Естес­твен­но, перед нами не XE7+, а целый XE11+. Дан­ное откры­тие сов­сем нас не раду­ет — обще­извес­тные инс­тру­мен­ты DeDe и IDR не то что столь све­жую вер­сию не понима­ют, они вооб­ще не уме­ют работать с 64-бит­ным Delphi.

Есть роб­кая надеж­да на зачаточ­ную бе­та‑вер­сию IDR64, одна­ко и она не приз­нает наш модуль род­ным. Не откла­дыва­ем ее далеко, она нам еще при­годит­ся, гуг­лим даль­ше.

На­ходим занят­ный про­ект пи­тонов­ско­го скрип­та под IDA. Его авто­ры обна­ружи­ли в Delphi и успешно экс­плу­ати­руют инте­рес­ную фичу. При выходе из внут­ренне­го метода (Event Constructor) регистр EDX будет содер­жать ссыл­ку на имя обра­бот­чика события. Адрес обо­абот­чика будет находить­ся в регис­тре EAX, при­мер­но так, как показа­но на сле­дующем скрин­шоте.

Про­ана­лизи­ровав код 32-бит­ных хен­дле­ров, они выдели­ли общий пат­терн для поис­ка 80 E3 DF 75 ?? 49 75 ?? 8B 46 02 ?? ?? 5B C3 (соот­ветс­тву­ющие ему бай­ты помече­ны плю­сиком):

Ана­логич­ный код хен­дле­ра для 64-бит­ной вер­сии находит­ся по пат­терну 80 ?? ?? 00 74 ?? E8 ?? ?? ?? ?? 48 8B ?? ?? 48 8D ?? ?? ?? ?? ?? ?? C3. Нап­ример, вот как это выг­лядит для вер­сии 31 (10.1).

Код будет таким (соот­ветс­тву­ющие пат­терну бай­ты тоже помече­ны плю­сиком):

Лег­ко убе­дить­ся, что при оста­нове в кон­це этой фун­кции адре­су метода в регис­тре RAX соот­ветс­тву­ет его имя в регис­тре RDI (да‑да, в коде скрип­та ошиб­ка, не RDX, а RDI).

Рекомендуем почитать:

Xakep #304. IP-камеры на пентестах

• Содержание выпуска
• Подписка на «Хакер»-60%

Но это мелочь, пос­коль­ку недос­татки дан­ного метода вид­ны нево­ору­жен­ным гла­зом. Трас­сировать прог­рамму ради того, что­бы получить весь­ма огра­ничен­ный спи­сок методов, доволь­но тос­кли­во, да и вооб­ще если прог­рамма под­лежит запус­ку и трас­сиров­ке, то это боль­шое везение. И наконец, самая глав­ная беда — в нашей целевой вер­сии XE11 ана­логич­ного кода нет и быть не может, пос­коль­ку там весь этот про­цесс, судя по все­му, про­ходит в нед­рах биб­лиоте­ки rtl280.dll.

По­дума­ем, чем еще нам может при­годить­ся IDR64. Я нем­ного пок­ривил душой, упо­мянув ее отказ от родс­тва с нашим модулем. Конеч­но, у нее отсутс­тву­ет база зна­ний по XE11. По сути, она толь­ко три вер­сии и зна­ет. Поэто­му при откры­тии в режиме авто­детек­та сом­нева­ется в «дель­фовос­ти» нашей прог­раммы. Одна­ко если нем­ного схит­рить и поп­робовать открыть ее как Delphi XE4, а затем сог­ласить­ся с native knowledge base, то IDR64 вов­се не про­тивит­ся это­му и пос­ле очень дол­гих раз­думий кое‑как заг­ружа­ет прог­рамму в себя.

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

И в зак­лючение я, как и обе­щал, нем­ного рас­ска­жу о при­мер­ной внут­ренней струк­туре дель­фов­ско­го кода и прин­ципах его ана­лиза «голыми руками». Ког­да мы ана­лизи­рова­ли дель­фов­ские при­ложе­ния при помощи IDR, то замети­ли, что для каж­дого ском­пилиро­ван­ного клас­са при­сутс­тву­ет своя харак­терная струк­тура дан­ных, называ­емая VMT. Струк­тура не докумен­тирова­на, одна­ко, погуг­лив, мож­но най­ти ста­рую статью с ее опи­сани­ем. В ней эта струк­тура опи­сыва­ется (как тип в син­такси­се дель­фи) сле­дующим обра­зом:

Как видишь, она содер­жит исчерпы­вающую информа­цию о клас­се, в которой нас в пер­вую оче­редь инте­ресу­ют его методы. Для понима­ния это­го покурим нем­ного исходни­ки IDR64. Бег­ло прос­мотрев их, находим два основных модуля, ответс­твен­ных за раз­бор кода на клас­сы: Threads.cpp и Misc.cpp. Пер­вый содер­жит методы для поис­ка таб­лиц VMT в ском­пилиро­ван­ном коде, вто­рой слу­жит для извле­чения информа­ции из них. В двух сло­вах кос­нусь реали­зации этих про­цес­сов. В модуле Threads.cpp есть метод с соот­ветс­тву­ющим наз­вани­ем:

Фак­тичес­ки он переби­рает все 64-бит­ные сло­ва в фай­ле, про­веряя, ука­зыва­ет ли каж­дое на самое себя (если его интер­пре­тиро­вать как адрес со сме­щени­ем + Vmt.SelfPtr (-0xBO)+ Adjustment (-24)). Нап­ример, на рисун­ке выделен­ный крас­ным длин­ный ука­затель по адре­су 0x3A806F48 пол­ностью про­ходит дан­ный магичес­кий тест, пос­коль­ку его содер­жимое име­ет вид 0x3A807010=0x3A806F48+0xB0+0x18.

Этой осо­бен­ностью, в час­тнос­ти, объ­ясня­ется весь­ма неп­рият­ное тор­можение IDR при заг­рузке боль­ших фай­лов.

Итак, най­дя начало таб­лицы VMT, мож­но начинать раз­бирать ее содер­жимое. Модуль Misc.cpp содер­жит мно­жес­тво методов для это­го: GetParentAdr, GetChildAdr, GetClassSize, GetClsName и так далее. Устро­ены они, в общем‑то, одно­тип­но: в них выпол­няет­ся обра­щение к соот­ветс­тву­ющим полям струк­туры VMT отно­ситель­но ука­зате­ля Vmt.SelfPtr:

Vmt.SelfPtr, Vmt.ClassName — это кон­стан­ты отно­ситель­ных сме­щений до полей дан­ной струк­туры, ини­циали­зиру­ющих­ся в методах DelphiVmt::SetVmtConsts и DelphiVmt::AdjustVmtConsts. Они зависят от вер­сии Delphi, и нам силь­но повез­ло, что они не менялись с 2014 года. Про­ана­лизи­ровав их, сос­тавим схе­му бло­ка VMT для клас­са, при­веден­ного на пре­дыду­щем скрин­шоте:

Как видим, рас­клад­ка 64-бит­ной струк­туры впол­не соот­ветс­тву­ет при­веден­ному выше опи­санию. Не буду утом­лять читате­лей под­робным раз­бором струк­туры вся­ких полез­ных таб­лиц, ссыл­ки на которые мож­но получить из содер­жимого полей. При желании ты можешь разоб­рать­ся в этом сам, изу­чив исходни­ки IDR. Тем более что в реаль­ной жиз­ни столь под­робный раз­бор кода обыч­но и не нужен, если толь­ко поль­зователь не жела­ет написать свой собс­твен­ный деком­пилятор пок­руче IDR. Рас­смот­рим прак­тичес­кий спо­соб при­мене­ния этой информа­ции для ана­лиза дель­фов­ско­го кода без спе­циаль­ных инс­тру­мен­тов, пря­мо во вре­мя отладки при­ложе­ния в нашем любимом отладчи­ке x64dbg.

Итак, ковыряя при­ложе­ние в этом отладчи­ке, мы наб­рели на некий класс TMkManager, ответс­твен­ный за связь при­ложе­ния с клю­чом MetroKey. Для наг­ляднос­ти: в classwiever IDR64 спи­сок методов дан­ного клас­са выг­лядят при­мер­но так.

Рас­смот­рим орга­низа­цию это­го клас­са в памяти заг­ружен­ного в отладчик про­цес­са на осно­ве ана­лиза таб­лицы MethodTable.

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

Ра­бота­ет это так: допус­тим, в какой‑то момент мы при отладке про­цес­са заш­ли в про­цеду­ру по адре­су 5E4AB020, и она нас так заин­тересо­вала, что мы решили узнать о ней под­робнос­ти. Для это­го мы ищем ссыл­ку на нее. Прос­той референс навер­няка не най­дет­ся, а вот если искать его как пос­ледова­тель­ность бай­тов 20,B0,4A,5E,00,00,00,00, то будет най­ден ука­затель по адре­су 5E4A72E6 (выделе­но синим).

За ним сле­дует стро­ка со счет­чиком, имя это­го метода — GetKeyServerIP. Если получен­ная информа­ция заин­тересо­вала нас еще силь­нее, то сле­дующий ука­затель 5E4B3958 (выделе­но оран­жевым) ссы­лает­ся на дру­гой ука­затель (в нашем при­мере по стрел­ке 59913С0), который, в свою оче­редь, ука­зыва­ет на имя типа воз­вра­щаемо­го зна­чения — string.

Дви­гаясь даль­ше, мы обна­ружи­ваем выделен­ное фиоле­товым имя пер­вого парамет­ра это­го метода Self и ука­затель на его тип — 5E4A7A08. Так же как и в пре­дыду­щем слу­чае, через два пере­име­нова­ния мы выходим на имя типа, точ­нее, клас­са — иско­мый TMkManager, который по понят­ным при­чинам явля­ется родитель­ским клас­сом и для нашего метода.

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