Приключения «Электрона». Отлаживаем JSC-код любой версии Electron без декомпилятора

Се­год­ня мы погово­рим о при­ложе­ниях, соз­данных при помощи сре­ды Electron. Этот фрей­мворк — клас­сичес­кий при­мер инс­тру­мен­та, с помощью которо­го любой прод­винутый вер­сталь­щик может почувс­тво­вать себя пол­ноцен­ным раз­работ­чиком кросс‑плат­формен­ных прог­рам­мных пакетов. То есть Electron может скон­верти­ровать сайт в самодос­таточ­ное (хотя и нес­коль­ко неук­люжее) при­ложе­ние. Надо ли говорить, что тех­нология получи­ла дос­таточ­но широкое рас­простра­нение. Если верить статье на Хаб­ре, на этой плат­форме реали­зова­но мно­жес­тво популяр­ных при­ложе­ний — мес­сен­дже­ры Skype и Discord, редак­торы для кода Visual Studio Code и Atom и дру­гие.

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

Итак, у нас име­ется при­ложе­ние, при откры­тии исполня­емо­го модуля которо­го (надо ска­зать, весь­ма упи­тан­ного — боль­ше сот­ни мегабайт) Detect It Easy выда­ет сле­дующую информа­цию.

Ес­ли ты уже слег­ка зна­ком с пакетом Electron или успел бег­ло про­читать пред­ложен­ные выше статьи, то чудовищ­ный раз­мер исполня­емо­го фай­ла тебя не уди­вит — ведь, по сути, исполня­емый модуль пред­став­ляет собой слег­ка опти­мизи­рован­ную вер­сию бра­узе­ра Chromium + Node. В ней запус­кает­ся код JavaScript, на котором, собс­твен­но, и написа­на основная логика при­ложе­ния. Этот код и про­чие HTML-пот­роха могут лежать в откры­том и проз­рачном для иссле­дова­ния виде (этот слу­чай нам неин­тересен, как три­виаль­ный). Так­же они могут быть соб­раны или упа­кова­ны в отдель­ный ресурс спе­циаль­ного вида asar — тут воз­можны слож­ности, но мы пока не будем их касать­ся. Еще ресур­сы могут быть час­тично откомпи­лиро­ваны в натив в исполня­емом фай­ле (обыч­но так и есть). А иног­да они откомпи­лиро­ваны целиком, сей­час мы этот вари­ант так­же под­робно рас­смат­ривать не будем. Мы нач­нем с прос­того слу­чая: ядро Node ском­пилиро­вано в натив, а JS-скрип­ты интер­пре­тиру­ются ядром в виде байт‑кода.

Ос­тановим­ся попод­робнее на этом момен­те. Для тех, кто не читал мои пре­дыду­щие статьи (нап­ример, «Ре­вер­синг .NET. Как искать JIT-ком­пилятор в при­ложе­ниях» или «Без­защит­ная Java. Лома­ем Java bytecode encryption»), пояс­ню, что акту­аль­ные скрип­товые плат­формы (Java, .NET и дру­гие) работа­ют по такому основно­му алго­рит­му. Для удобс­тва и ско­рос­ти скрипт ком­пилиру­ется в про­межу­точ­ный кросс‑плат­формен­ный байт‑код, который уже при работе прог­раммы, по мере вызова методов и клас­сов, или интер­пре­тиру­ется интер­пре­тато­ром, или кон­верти­рует­ся в исполня­емый натив­ный код встро­енным JIT-ком­пилято­ром. Это спра­вед­ливо и для JavaScript, для которо­го при­дума­но мно­жес­тво интер­пре­тато­ров: V8, SpiderMonkey, Chakra, Rhino, KJS, Nashorn и дру­гие. Даже в Adobe соз­дали свой собс­твен­ный дви­жок, про который я тоже в свое вре­мя на­писал статью.

Нас же инте­ресу­ет встро­енный в Electron дви­жок Chrome V8. В нем име­ется пакет bytenote, поз­воля­ющий сох­ранить исходный скрипт в виде сери­али­зован­ного пред­став­ления байт‑кода V8, которое выпол­няет­ся так же, как и сам скрипт. Этот фор­мат име­ет рас­ширение .JSC и час­тень­ко исполь­зует­ся для обфуска­ции как в самом пакете Electron, так и в дру­гих сер­верных при­ложе­ниях, написан­ных на язы­ке JavaScript.

Упо­мяну­тый фор­мат мало­изу­чен: три года назад груп­па Positive Technologies оза­боти­лась его ревер­сом и про­вела иссле­дова­ние байт‑кода вер­сии 8.16.0, резуль­татом чего ста­ли нес­коль­ко ста­тей. Я рекомен­дую озна­комить­ся с ними самос­тоятель­но для пущего понима­ния пред­метной области.

Еще одним резуль­татом иссле­дова­ния ста­ло появ­ление пла­гина для деком­пилято­ра Ghidra, спо­соб­ного работать с JSC-фай­лами вер­сии 8.16.0. К сожале­нию, пос­ле это­го инте­рес к теме у иссле­дова­телей угас. Нес­мотря на то что с тех пор было выпуще­но еще нес­коль­ко про­ектов для ревер­са бинар­ного кода JS (нап­ример, jsc-decompile-mozjs-34 или cocos2d-jsc-decompiler), вер­сии Node.js меня­ются с такой быс­тро­той, что на текущий момент все эти про­екты без­надеж­но уста­рели. Поэто­му я на при­мере байт‑кода вер­сии 10.2.154.26 (JSC-сиг­натура A905 DEC0 866CEBA8) попыта­юсь рас­ска­зать, как самос­тоятель­но без деком­пилято­ра иссле­довать и отла­живать бинар­ный JS-байт‑код про­изволь­ной вер­сии при помощи отладчи­ка x64dbg и IDA.

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

Как мы вык­ручива­лись из подоб­ного зат­рудне­ния в прош­лые разы? Тупо атта­чились ко всем копи­ям прог­раммы (в при­ори­тете про­цес­сы с заголов­ком активно­го окна или Chrome_Widget) и про­веря­ли, какая копия исполня­ет нуж­ный нам код, оста­нав­лива­ясь на бря­ках. Или же вар­вар­ски оста­нав­ливали код в нуж­ной точ­ке, вби­вая туда корот­кий jmp self (0xEB,0xFE), тем самым зацик­ливая прог­рамму в дан­ном мес­те.

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

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

Итак, у нас получи­лось оста­новить­ся в нуж­ном мес­те прог­раммы. Открыв стек вызовов, мы обна­ружи­ваем, что отла­жива­емый нами EXE-модуль, нес­мотря на всю свою раз­дутость, явля­ется весь­ма неболь­шой частью прог­раммы (откомпи­лиро­ван­ным в натив ядром V8), которая вызыва­ется из JIT-ком­пилиро­ван­ного кода.

Ад­рес перехо­да меж­ду интер­пре­тато­ром (выделе­но крас­ным) и ском­пилиро­ван­ными в натив биб­лиоте­ками ядра Node (выделе­но синим) мы видим на сте­ке вызовов. Интер­пре­татор ском­пилиро­ван­ного байт‑кода выг­лядит при­мер­но так:

Как видишь, отсю­да мож­но получить дли­ны всех обра­баты­ваемых интер­пре­тато­ром опко­дов. Для начала чуть про­ясню, что такое пре­фик­сы Wide и ExtraWide и почему на опко­ды с ними положе­ны раз­ные таб­лицы. Как ска­зано в упо­мяну­той мной статье, в зависи­мос­ти от дли­ны опе­ран­дов каж­дая инс­трук­ция име­ет три вари­анта — обыч­ный (1-бай­товые опе­ран­ды), Wide (2-бай­товые опе­ран­ды) и ExtraWide (4-бай­товые опе­ран­ды). В новой вер­сии добави­лось еще два пре­фик­са — отла­доч­ные, соот­ветс­твен­но, тоже в вари­антах Wide и ExtraWide.

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