Get your Xojo. Реверсим приложение на REALbasic

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

Это один из пионе­ров кросс‑плат­формен­ного прог­рамми­рова­ния. REALbasic неод­нократ­но менял наз­вание, архи­тек­туру и хозя­ев и в пос­леднее вре­мя серь­езно рас­терял как свои рыноч­ные позиции, так и акту­аль­ность. Написан­ные на нем при­ложе­ния встре­чают­ся все реже и реже, в основном в таких узкоспе­циали­зиро­ван­ных областях, как колори­мет­рия. Из‑за малой рас­простра­нен­ности для него, в отли­чие от извес­тных сред раз­работ­ки (вро­де Delphi, .NET или VBS), прак­тичес­ки отсутс­тву­ют спе­циали­зиро­ван­ные инс­тру­мен­ты для ревер­са. Поэто­му мы, как обыч­но, на при­мере кон­крет­ных при­ложе­ний раз­берем прин­ципы и лай­фха­ки для изу­чения кода таких при­ложе­ний.

Нач­нем с самого прос­того слу­чая. Как ни стран­но, лег­че все­го иссле­довать при­ложе­ние, соз­данное в сов­ремен­ных акту­аль­ных вер­сиях Xojo (да‑да, он мало того что еще под­держи­вает­ся, вдо­бавок стал 64-бит­ным, Ви­кипе­дия врет).

Итак, нам попалось гра­фичес­кое при­ложе­ние, при ана­лизе которо­го наш безот­казный Detect It Easy (DIE) утвер­жда­ет, что это Xojo (x64).

Нам понадо­бит­ся самая малость: вклю­чить фун­кции при­ложе­ния, которые отка­зыва­ются работать в незаре­гис­три­рован­ной вер­сии, выдавая вмес­то это­го окош­ки с тре­бова­нием регис­тра­ции. Заг­рузив прог­рамму в отладчик x64dbg и при­тор­мозив ее в этом мес­те, мы с облегче­нием замеча­ем, что прог­рамма не зашиф­рована, не упа­кова­на и лишена средств анти­отладки. Она даже сооб­щение выда­ет стан­дар­тным MessageBoxA, при этом прог­рамма прек­расно дизас­сем­бли­рует­ся при помощи IDA. Получен­ный код, прав­да, как и сле­дова­ло ожи­дать от кросс‑плат­формен­ного бей­сика, чудовищ­но неук­люж и сло­жен для понима­ния.

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

Бег­ло прос­мотрев код, обна­ружи­ваем великое мно­жес­тво подоб­ных конс­трук­ций по все­му дизас­сем­бли­рован­ному при­ложе­нию. Оче­вид­но, что это ини­циали­зация каких‑то внут­ренних REALbasic-овских таб­лиц методов. Веро­ятнее все­го, за это ответс­твен­на фун­кция RuntimeAllocateAttributeTable из модуля XojoGUIFramework64.dll, вызыва­ет сом­нение толь­ко спо­соб переда­чи парамет­ров. Вро­де как стро­ки и адре­са перед вызовом RuntimeAllocateAttributeTable записы­вают­ся в стек, одна­ко не в область парамет­ров, а в область локаль­ных перемен­ных, при­чем по совер­шенно раз­ным адре­сам. Поп­робу­ем про­ана­лизи­ровать еще пару подоб­ных конс­трук­ций:

Вот еще один при­мер:

Нем­ного порас­кинув моз­гами, мы при­ходим к выводу, что на вхо­де в RuntimeAllocateAttributeTable в регис­тре RCX находит­ся ука­затель на некую таб­лицу, каж­дый эле­мент которой занима­ет 0x40 байт и име­ет при­мер­но сле­дующую струк­туру:

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

Итак, ста­вим условную точ­ку оста­нова на фун­кцию RuntimeAllocateAttributeTable со сле­дующим тек­стом жур­нала:

ClassName: {s:[rcx+rdx+0x20]} MethodName: {s:[rcx+rdx]} Address: {[rcx+rdx+0x28]} called at {[rsp]}

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

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

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

Что­бы нем­ного усложнить себе жизнь, рас­смот­рим чуть более ста­рый, 32-бит­ный вари­ант REALbasic. Итак, у нас есть дру­гая прог­рамма, заг­рузка которой в DIE показы­вает сле­дующее окош­ко.

Ка­залось бы, 32-бит­ная вер­сия Xojo дол­жна быть про­ще, ан нет. Заг­рузив при­ложе­ние в IDA, мы с удив­лени­ем обна­ружи­ваем прак­тичес­ки пол­ное отсутс­твие кода и импорта при вну­шитель­ном раз­мере EXE-модуля.

Раз­гадка прос­та: прак­тичес­ки весь EXE-модуль сос­тоит из огромно­го овер­лея, который под­гру­жает­ся на про­изволь­ные адре­са во вре­мя заг­рузки прог­раммы. А зна­чит, даже дам­пить для изу­чения уже заг­ружен­ный модуль осо­бого смыс­ла нет, хотя сама прог­рамма не меша­ет ни отладке, ни дам­пу. Погуг­лив, обна­ружи­ваем, что более ста­рую вер­сию нашего фрей­мвор­ка на­род уже изу­чал и даже запилил на ее осно­ве пи­тонов­ский скрипт под IDA, который пар­сит овер­лей.

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

Пом­нишь, как мы вык­рутились в слу­чае 64-бит­ной вер­сии? Повеси­ли бряк на фун­кцию RuntimeAllocateAttributeTable из модуля XojoGUIFramework64.dll и ловили им ини­циали­зацию каж­дого метода. Разуме­ется, при заг­рузке в отладчик прог­раммы в ней нет никако­го импорта, кро­ме нес­коль­ких базовых фун­кций kernel32, необ­ходимых для заг­рузки овер­лея. Одна­ко, прер­вавшись в отладчи­ке внут­ри уже заг­ружен­ной прог­раммы, мы видим необ­ходимый модуль в спис­ке — здесь он называ­ется XojoGUIFramework32.dll, и необ­ходимая фун­кция RuntimeAllocateAttributeTable там есть.

Ста­вим на нее бряк и перезаг­ружа­ем прог­рамму в отладчи­ке. Бряк сто­пит­ся уже при вызове из заг­ружен­ного овер­лея, код вызова RuntimeAllocateAttributeTable до боли похож на ана­логич­ный из 64-бит­ного модуля. Пос­коль­ку мы уже в кур­се, как все было устро­ено там, нам не сос­тавит боль­шого тру­да при­думать ана­логию для каж­дого нуж­ного нам поля:

Су­дя по все­му, эта струк­тура в 32-бит­ном исполне­нии занима­ет 0x28 байт и сос­тоит из десяти полей. Нес­ложно переде­лать текст жур­нала в условной точ­ке оста­нова под новую информа­цию. Что я и пред­лагаю читате­лю сде­лать самос­тоятель­но.

Наши проекты:

- Кибер новости: the Matrix
- Хакинг: /me Hacker
- Кодинг: Minor Code
👁 Пробить человека? Легко через нашего бота: Мистер Пробиватор