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

Помнишь, как на школьных уроках информатики тебя заставляли изучать Basic? Так вот: это был ненастоящий Basic. А настоящий, то есть REALbasic, теперь называется Mojo Xojo, и на нем до сих пор пишут приложения. Сегодня я расскажу тебе, как они устроены изнутри и как их можно взломать.

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

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

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

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

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

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

... .text:0000000141A85CF5 mov edx, 0F40h .text:0000000141A85CFA xor r8d, r8d .text:0000000141A85CFD lea rcx, sub_140D7D410 .text:0000000141A85D04 lea r9, aOBevelbutton_64 ; "%%o<BevelButton>" — похоже на класс нашего метода .text:0000000141A85D0B lea r10, aBvlmeaschartAc_0 ; "BvlMeasChart_Action" — похоже на его имя .text:0000000141A85D12 lea r11, sub_141A91350 ; Адрес нашего метода .text:0000000141A85D19 mov [rbp+8F0h+var_438], rax .text:0000000141A85D20 mov [rbp+8F0h+var_60], r11 .text:0000000141A85D27 mov rax, [rbp+8F0h+var_8E0] .text:0000000141A85D2B mov [rax+0F68h], r11 .text:0000000141A85D32 mov r11, [rbp+8F0h+var_68] .text:0000000141A85D39 mov [r11+0F40h], r10 .text:0000000141A85D40 mov r10, [rbp+8F0h+var_68] .text:0000000141A85D47 mov [r10+0F60h], r9 .text:0000000141A85D4E mov [rbp+8F0h+var_440], rcx .text:0000000141A85D55 mov r9, [rbp+8F0h+var_68] .text:0000000141A85D5C mov [r9+0F70h], rcx .text:0000000141A85D63 mov rcx, [rbp+8F0h+var_68] .text:0000000141A85D6A mov dword ptr [rcx+0F78h], 39h ; '9' .text:0000000141A85D74 mov rcx, [rbp+8F0h+var_68] .text:0000000141A85D7B mov dword ptr [rcx+0F48h], 101h .text:0000000141A85D85 mov rcx, [rbp+8F0h+var_68] .text:0000000141A85D8C mov [rbp+8F0h+var_8E8], rcx .text:0000000141A85D90 call RuntimeAllocateAttributeTable ...