Виртуальный лабиринт. Разбираем защиту Eazfuscator.NET и ломаем обфускацию

Ес­ли пос­ле статьи «Кон­фуз, сэр! Добыва­ем код из ConfuserEx без готовых деоб­фуска­торов» тебе не надо­ели .NET-обфуска­торы, сегод­ня мы перей­дем к обсужде­нию еще более злов­редно­го пред­ста­вите­ля это­го семей­ства — Eazfuscator.NET. Злов­редность его зак­люча­ется в том, что, помимо уже встре­чав­шегося нам ранее джентль­мен­ско­го набора фич вро­де обфуска­ции control flow, шиф­рования кон­стант, строк и имен иден­тифика­торов, в нем при­сутс­тву­ет впол­не себе натураль­ная вир­туаль­ная машина. Наподо­бие тех, которые мы встре­чали во взрос­лых защитах Enigma, Obsidium, Themida или даже в VMProtect.

До это­го мы раз­бирали спо­соб сок­рытия IL-кода путем шиф­рования отдель­ных клас­сов или методов с рас­шифров­кой непос­редс­твен­но перед JIT-ком­пиляци­ей, что делало его уяз­вимым для ревер­са на этом эта­пе. В рас­смат­рива­емом же слу­чае набор IL-инс­трук­ций пре­обра­зует­ся в шиф­рован­ную пос­ледова­тель­ность псев­докоманд шитого кода, пошаго­во исполня­емую встро­енным интер­пре­тато­ром. Разуме­ется, это чер­тов­ски замед­ляет работу при­ложе­ния, одна­ко на что не пой­дешь ради при­ват­ности кода? Ну что же, давай пос­мотрим, что мож­но пред­при­нять в столь запущен­ном слу­чае.

Итак, у нас есть некое при­ложе­ние. Тре­бует­ся отсле­дить в нем вызов опре­делен­ного диало­гово­го окна и по воз­можнос­ти научить­ся управлять им. К сожале­нию, Eazfuscator пока еще не детек­тиру­ется стан­дар­тны­ми средс­тва­ми, Detect It Easy видит в нем обыч­ное обфусци­рован­ное .NET-при­ложе­ние PE32:

De4dot детек­тиру­ет некий неиз­вес­тный Unknown Obfuscator, поэто­му наличие Eazfuscator нам при­дет­ся опре­делять эмпи­ричес­ки, по внеш­нему виду кода. Заг­рузим иссле­дуемое при­ложе­ние в отладчик dnSpy.

Бро­сает­ся в гла­за упо­мяну­тый выше базовый набор обфуска­тора — нечита­емые име­на, неук­люжая обфуска­ция control flow с добав­лени­ем бес­смыс­ленных условных опе­рато­ров и поч­ти пол­ное отсутс­твие видимых стро­ковых кон­стант. De4dot слег­ка при­чесы­вает код, уби­рая лиш­ние условные опе­рато­ры и меняя слож­ночита­емые длин­ные име­на на нумеро­ван­ные клас­сы и методы, одна­ко весь­ма дорогой ценой — прог­рамма при этом теря­ет работос­пособ­ность.

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

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

Бла­года­ря нашему опы­ту работы с дру­гими обфуска­тора­ми нас начина­ют тер­зать смут­ные сом­нения, что вызовы метода #=zjsc8ywR05iBjsM$TSzzy5Bfjq_c3.#=zI35NzNE=() и есть обра­щение к тек­сто­вым кон­стан­там. При­чем прос­тые манипу­ляции с отладчи­ком это под­твержда­ют (еще одна хорошая новость — Eazfuscator в отладке прог­раммы нам пока что совер­шенно не пре­пятс­тву­ет). И сно­ва при­ятная неожи­дан­ность: нам не при­дет­ся самим декоди­ровать стро­ковые кон­стан­ты, пос­коль­ку умные люди и тут пос­тарались до нас — инс­тру­мент EazFixer в сочета­нии с de4dot прек­расно рас­шифро­выва­ет стро­ки и ресур­сы до чита­емо­го вида. К сожале­нию, ценой той же самой потери работос­пособ­ности деоб­фусци­рован­ного модуля, поэто­му дан­ный метод годит­ся толь­ко для ана­лиза кода.

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

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