WiX-фикс. Исследуем инсталлятор Windows Installer XML Toolset

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

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

Мы уже встре­чались с подоб­ным поведе­нием прог­рамм уста­нов­ки в пре­дыду­щих стать­ях. Одна­ко в этот раз выяс­нилось, что прог­рамма содер­жит все неп­рият­ные фичи, при­сущие инстал­ляторам:

1. Из весь­ма уве­сис­того EXE-фай­ла исполня­емым явля­ется толь­ко кро­хот­ный и совер­шенно неин­форма­тив­ный заг­рузчик.
2. Вла­делец про­цес­са тоже отно­ситель­но неболь­шой EXE-файл, запущен­ный из сис­темной пап­ки вре­мен­ных фай­лов.
3. Пе­ред нами не хорошо изу­чен­ные msiexec или InstallShield, а что‑то иное.

По­пытав­шись при­атта­чить­ся к запущен­ному про­цес­су при помощи x64dbg, мы видим, что код явно ском­пилиро­ван в про­цес­се исполне­ния. Этот код до боли напоми­нает .NET, что кос­венно под­твержда­ется наличи­ем в памяти про­цес­са заг­ружен­ных дот­нетов­ских биб­лиотек (clr.dll, clrjit.dll, mscoree.dll и так далее). Одна­ко ни сам инстал­лятор, ни исполня­емый файл из вре­мен­ной пап­ки .NET-при­ложе­ниями не явля­ются.

Дот­нетов­ский отладчик dnSpy хоть и рас­позна­ет про­цесс как род­ной и даже успешно кон­нектит­ся к нему, но никако­го дот­нетов­ско­го кода при этом не показы­вает и трас­сировать при­ложе­ние не дает. В прин­ципе, дот­нетов­ские про­екты с зак­рытым кодом мы уже учи­лись пот­рошить в стать­ях «Не­ядер­ный реак­тор. Взла­мыва­ем про­тек­тор .NET Reactor» и «Ан­гард! Ревер­сим при­ложе­ние, защищен­ное DNGuard», одна­ко побере­жем пока что тяжелую артилле­рию. Поп­робу­ем для начала разоб­рать­ся, с чем имен­но мы стол­кну­лись на этот раз. Необ­ходимую зацеп­ку нам дает Detect It Easy.

Оче­вид­но, и сам инстал­лятор, и вре­мен­ный файл рас­позна­ются DIE как WiX Toolset installer с овер­леем Microsoft Cabinet File (CAB). Про CAB, в прин­ципе, мож­но было бы догадать­ся по сиг­натуре 4D534346 (MSCF) у овер­леев, но это нам еще при­годит­ся чуть поз­же.

А пока поп­робу­ем вспом­нить, что такое WiX и чем имен­но это зна­ние может помочь в даль­нейшем ана­лизе при­ложе­ния. Это сло­во из трех букв рас­шифро­выва­ется как Windows Installer XML Toolset и пред­став­ляет собой (как сле­дует из наз­вания) набор инс­тру­мен­тов для соз­дания инстал­ляци­онных пакетов на осно­ве XML-опи­сания. Если тебе инте­рес­но узнать попод­робнее про этот пакет, ты можешь озна­комить­ся с его осо­бен­ностя­ми, нап­ример, в статье на «Хаб­рахаб­ре».

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

Cуть в том, что основное дос­тоинс­тво тех­нологии WiX в ее рас­ширя­емос­ти — нес­мотря на наличие сво­их собс­твен­ных интерфей­сных шаб­лонов, в ней име­ется воз­можность под­клю­чить кас­томный интерфейс поль­зовате­ля, написан­ный на .NET (Custom Bootstrapper Application). Что мы и наб­люда­ем в нашем при­ложе­нии. Как самому соз­давать подоб­ные интерфей­сы, мож­но узнать в статье Writing Your Own .Net-based Installer with WiX.