Руби наотмашь

Ког­да‑то о Ruby было написа­но мно­жес­тво рек­ламных ста­тей. Для тех, кто хочет более деталь­но озна­комить­ся с его кон­цепци­ей и внут­ренней струк­турой, есть кни­га Ruby under a microscope. В общем, как ты уже понял, цель сегод­няшней статьи — не пос­тижение дзе­на прог­рамми­рова­ния на Ruby, а сухой прак­тичес­кий раз­бор осо­бен­ностей ревер­са при­ложе­ний, реали­зован­ных на этой экзо­тике.

Задача

Итак, дано при­ложе­ние, чита­ющее и валиди­рующее некий бинар­ный файл. Нам нуж­но разоб­рать­ся с алго­рит­мом валида­ции. Пер­вичный авто­мати­чес­кий ана­лиз при­ложе­ния при помощи Detect It Easy на этот раз нам тол­ком ничего не дает — при­ложе­ние детек­тится как соб­ранное из C++ в баналь­ном Microsoft Visual Studio 2015. Одна­ко в ком­плект динами­чес­ких биб­лиотек прог­раммы вхо­дит инте­рес­ный файл x64-msvcr100-ruby200.dll, на который пол­но ссы­лок из исполня­емо­го модуля. Файл позици­они­рует себя как интер­пре­татор Ruby за авторс­твом самого отца‑осно­вате­ля Юки­хиро Мацумо­то со ссыл­кой на со­ответс­тву­ющий сайт.

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

Исследуем программу

Дей­ству­ем по стан­дар­тной схе­ме, навер­няка уже зна­комой тебе по моим пре­дыду­щим стать­ям. Ста­вим точ­ку оста­нова на фун­кцию чте­ния фай­ла kernel32.dll.ReadFile. Конеч­но же, при заг­рузке прог­раммы будут тысячи подоб­ных обра­щений ко все­воз­можным фай­лам нас­тро­ек и биб­лиотек, вхо­дящих в пакет, но нам нем­ного облегчит задачу монито­ринг чте­ния фай­лов с помощью тоже извес­тной нам прог­раммы Process Monitor (ProcMon). Бла­года­ря ей мы замеча­ем, что чте­ние нашего иско­мого фай­ла, в отли­чие от всех осталь­ных, идет исклю­читель­но бло­ками по 0x10000 байт. Поэто­му, что­бы отсечь все ненуж­ные нам чте­ния, мож­но пос­тавить в качес­тве усло­вия для оста­нова Size==0x10000.

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

Вер­хние пять вызовов пред­став­ляют собой натив­ную обвязку чте­ния фай­ла и нам неин­терес­ны. А вот ниже явно идут два вло­жен­ных вызова интер­пре­тато­ра, до боли зна­комых нам по раз­бору вир­туаль­ных машин дру­гих скрип­товых язы­ков. Что­бы не отвле­кать­ся на пов­торение того, что я мно­гок­ратно писал в сво­их пре­дыду­щих стать­ях, пос­тара­юсь ска­зать в двух сло­вах. Любой, даже самый упо­ротый (вро­де питона) интер­пре­татор скрип­тового язы­ка никог­да не раз­бира­ет тек­сто­вую семан­тику во вре­мя выпол­нения. Для опти­миза­ции работы интер­пре­тато­ра во вре­мя заг­рузки модуля (клас­са, объ­екта, метода и так далее) про­исхо­дит ком­пиляция тек­ста в натив или шитый байт‑код, сам про­цесс называ­ется JIT-ком­пиляци­ей (just-in-time, в нуж­ное вре­мя) или поп­росту динами­чес­кой ком­пиляци­ей.

Ра­зуме­ется, нес­мотря на заяв­ленную экс­тра­ваган­тность, в точ­ности так же пос­тупа­ет и Ruby. Про осо­бен­ности JIT-ком­пиляции для раз­ных реали­заций Ruby мож­но почитать на сай­те patshaughnessy.net, а мы поп­робу­ем разоб­рать­ся с нашей вир­туаль­ной машиной. Нем­ного поизу­чав вло­жен­ные вызовы сте­ка с пре­дыду­щего скрин­шота, находим основной цикл выбор­ки команд шитого кода (выделе­ны стрел­ками). В IDA код этой про­цеду­ры (sub_18001B6E0, экспор­тиру­емая фун­кция — rb_vm_get_insns_address_table) выг­лядит так.

Как видим, опкод занима­ет 8 байт, вир­туаль­ная машина содер­жит 83 коман­ды ассем­бле­ра, реали­зация каж­дой из которых пред­став­лена в этой фун­кции. Ока­зыва­ется, биб­лиоте­ка интер­пре­тато­ра даже содер­жит в себе дизас­сем­блер для ком­пилиро­ван­ного байт‑кода (экспор­ты rb_iseq_disasm_insn, rb_iseq_disasm). Ана­лизи­руя эти фун­кции, мож­но най­ти таб­лицу мне­моник команд, находя­щуюся по адре­су 180200500:

При вни­матель­ном рас­смот­рении иден­тифици­рует­ся и сам тип интер­пре­тато­ра байт‑кода, это раз­новид­ность YARV.

Генерируем ошибку

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

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

Поп­робу­ем смо­дели­ровать эту ситу­ацию самос­тоятель­но. Сра­зу пос­ле дос­тижения точ­ки оста­нова на чте­нии бло­ка 0x10000 отклю­чаем эту точ­ку и ста­вим точ­ки оста­нова на выбор­ку сле­дующей коман­ды шитого кода (на позап­рошлом скрин­шоте это выделен­ный адрес 18001B722) и фун­кции printf, через которую ведет­ся отла­доч­ная печать сте­ка. При дос­тижении сле­дующей коман­ды мы меня­ем ее на невалид­ную (нап­ример, 84) и ждем, что имен­но будет печатать printf. И дей­стви­тель­но, помимо кучи малопо­нят­ной отла­доч­ной информа­ции о бло­ках и фрей­мах в момент воз­никно­вения ошиб­ки, он выда­ет бли­жай­ший класс и метод.

Од­нако это не дает нам прак­тичес­ки ничего: судя по все­му, чте­ние про­исхо­дит при вызове eval из клас­са HTMLExportDialog, а по закону наиболь­шей под­лости этот класс в откры­том коде отсутс­тву­ет.

Ищем альтернативу

Поп­робу­ем подой­ти к решению воп­роса с дру­гой сто­роны — еще раз про­ана­лизи­руем стек вызовов со скрин­шота в начале статьи. Иссле­дуемый нами поток сни­зу упи­рает­ся в вызов из ntdll и явно запущен каким‑то дру­гим потоком. Переби­рая сосед­ние потоки, мы находим похоже­го кан­дидата — этот поток спо­кой­но ждет в сто­рон­ке окон­чания вызова фун­кции rb_eval_string_protect("PM::RubyBridge.run").

На пер­вый взгляд, нам это тоже поч­ти ничего не дает — как ты, веро­ятно, уже догадал­ся, и PM, и RubyBridge в откры­том коде тоже отсутс­тву­ют. Одна­ко теперь у нас есть рабочая гипоте­за (и за эту гипоте­зу час­тично говорит ана­лиз кода при­ложе­ния в IDA), что обще­ние при­ложе­ния с интер­пре­тато­ром Ruby идет имен­но через вызов rb_eval_string_protect.

По­это­му уби­раем все пре­дыду­щие точ­ки оста­нова и ста­вим новую точ­ку на вход этой фун­кции. Переза­пус­тив прог­рамму, с ходу узна­ём мно­го инте­рес­ного: очень мно­го вызовов вида PM.evx(URI.decode( %{./ruby/script/<ModuleName>.rbx} )), где ModuleName — фай­лы с рас­ширени­ем *.rbx, явно зашиф­рован­ные, сре­ди которых есть и RubyBridge, и HTMLExportDialog, и мно­гие дру­гие. А глав­ное — таким обра­зом нашел­ся и код реали­зации PM.evx, который эти фай­лы рас­шифро­выва­ет.

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

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

На пре­дыду­щем скрин­шоте вид­но, что evx реали­зован через eval, поэто­му мы ста­вим точ­ку оста­нова на фун­кцию x64-msvcr100-ruby200.dll.rb_f_eval и на вхо­де ее получа­ем рас­шифро­ван­ный код модулей пря­мо на блю­деч­ке. Путем нес­ложных манипу­ляций находим и конеч­ную цель нашего квес­та — валида­цию фай­ла.

Выводы

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