Суровая жаба. Изучаем защиту Excelsior JET для программ на Java

Ав­торы одной прог­раммы, суровые сибир­ские прог­раммис­ты, решили пос­тупить сов­сем радикаль­ным спо­собом: ском­пилиро­вали Java-код в натив, при­чем (по их собс­твен­ному утвер­жде­нию) с обфуска­цией и опти­миза­цией, как бы про­тиво­речи­во это ни зву­чало. Фак­тичес­ки они пожер­тво­вали кросс‑плат­формен­ностью (ну и зачем она, спра­шива­ется, нуж­на в уже ском­пилиро­ван­ной прог­рамме, заточен­ной под опре­делен­ную архи­тек­туру?).

Уж не знаю, нас­коль­ко такой под­ход спо­собс­тву­ет опти­миза­ции, — иссле­дован­ное мной при­ложе­ние чер­тов­ски нетороп­ливо и про­жор­ливо к ресур­сам компь­юте­ра, а глав­ное, занима­ет нес­коль­ко сот мегабайт. Но реверс‑инже­нерам пред­ложен­ный раз­работ­чиками под­ход силь­но усложня­ет жизнь. Лич­но я не нашел в паб­лике внят­ного ману­ала по орга­низа­ции дан­ных в таких прог­раммах, и во мно­гих обзо­рах эта тех­нология счи­тает­ся луч­шей для защиты Java-при­ложе­ний от взло­ма и декодин­га. Называ­ется она Excelsior JET.

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

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

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

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

Стро­ка 1 чис­то рудимен­тарная и никакой полез­ной наг­рузки (во вся­ком слу­чае, в при­веден­ных выше при­мерах) не несет. Здесь в eax прис­ваивает­ся зна­чение, лежащее на сте­ке выше текуще­го положе­ния на C00h байт. Мож­но пред­положить, что это сво­еоб­разная защита от перепол­нения, — при вызове каж­дой про­цеду­ры на сте­ке гаран­тирован­но дол­жен быть запас из C00h байт.

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

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

По счастью, соз­датели ста­рень­кого леген­дарно­го отладчи­ка OllyDbg перед тем, как про­ект зак­рылся, успе­ли сде­лать тес­товую 64-бит­ную вер­сию сво­ей прог­раммы, очень сырую, с уре­зан­ными воз­можнос­тями, но не кон­флик­тующую с кап­ризной и жад­ной до ресур­сов соф­тиной. Итак, заг­ружа­ем иссле­дуемую прог­рамму в OllyDbg и оста­нав­лива­ем ее на начале любой из подоб­ных про­цедур. Струк­тура, ссыл­ку на которую упор­но кла­дут на стек, выг­лядит при­мер­но так.

Вид­но, что у каж­дой про­цеду­ры есть своя собс­твен­ная запись раз­мером 0x40 байт. Не знаю, как они пра­виль­но называ­ются, давай для удобс­тва называть их струк­тура-40 по их раз­меру. Наз­начение полей этой струк­туры малопо­нят­но, за исклю­чени­ем ука­зате­ля на про­цеду­ры (выделе­но синим) и по нулево­му сме­щению ука­зате­ля на дру­гую, более инте­рес­ную струк­туру, выделен­ную зеленым. У сосед­них записей ссыл­ка на эту новую струк­туру оди­нако­ва, и, если прис­мотреть­ся, в ней явно вид­но пол­ное имя клас­са. Струк­тура ини­циали­зиро­вана в исходном коде, но без име­ни клас­са и некото­рых полей.

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

Как ни стран­но, метод решения у этих задач один: ста­вим точ­ку оста­нова типа Memory на инте­рес­ный нам адрес и ждем в засаде, пока не пой­мает­ся изме­няющий его кусок кода.

Нач­нем с рас­шифров­ки имен клас­сов. Ста­вим Memory breakpoint на пер­вый байт стро­ки java/ по адре­су 72B7718 и запус­каем прог­рамму. Наша ловуш­ка сра­зу сра­баты­вает на прос­тень­кой про­цеду­ре рас­шифров­ки:

На вхо­де RCX-адрес зашиф­рован­ной стро­ки и RDX-адрес рас­шифро­ван­ной стро­ки (в нашем слу­чае исходный RCX). А еще R8-байт, с которым стро­ка ксо­рит­ся, в нашем слу­чае это F9h.

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