Инсталляторы бывают разные: и попроще, и посложнее. Иногда среди них попадаются уж совсем навороченные — их исследование превращается в настоящее приключение. Сегодня мы рассмотрим именно такой случай: разберемся, как устроен изнутри инсталлятор WiX.
В своих статьях я неоднократно затрагивал инсталляторы и среды для их разработки. Эта тема обширна и неисчерпаема, поскольку для удобства и простоты над базовыми системами инсталляции были созданы надстройки, над которыми разработчики соорудили другие надстройки, и так далее. В итоге сам инсталлятор по сложности и красоте интерфейса (к сожалению, и размеру) иногда не уступает инсталлируемому пакету, а разборка и реверс его вызывает профессиональный интерес и доставляет настоящее удовольствие. Пример исследования одного из подобных инсталляторов мы и рассмотрим в сегодняшней статье.
Статья написана в исследовательских целях, имеет ознакомительный характер и предназначена для специалистов по безопасности. Автор и редакция не несут ответственности за любой вред, причиненный с применением изложенной информации. Использование или распространение ПО без лицензии производителя может преследоваться по закону.
Итак, у нас имеется инсталлятор для некоего технического пакета, оформленный в виде весьма увесистого (размером в несколько гигабайтов) самодостаточного EXE-файла. Интерфейс у инсталлятора продвинутый и стильный, он не похож на визуальное представление ни одного из встречавшихся нам до этого стандартных инсталляционных пакетов. Оно наполнено различными элементами управления, которые шустро переключают странички по мере заполнения, приближая начало установки программы. Но вот беда — в определенный момент инсталлятор начинает требовать лицензию, без которой упорно не желает переходить на следующий экран.
Мы уже встречались с подобным поведением программ установки в предыдущих статьях. Однако в этот раз выяснилось, что программа содержит все неприятные фичи, присущие инсталляторам:
Попытавшись приаттачиться к запущенному процессу при помощи 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.
Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», позволит скачивать выпуски в PDF, отключит рекламу на сайте и увеличит личную накопительную скидку! Подробнее
9990 рублей 4000 р.
[TD]
920 р.
[/TD]
Я уже участник «Xakep.ru»
В своих статьях я неоднократно затрагивал инсталляторы и среды для их разработки. Эта тема обширна и неисчерпаема, поскольку для удобства и простоты над базовыми системами инсталляции были созданы надстройки, над которыми разработчики соорудили другие надстройки, и так далее. В итоге сам инсталлятор по сложности и красоте интерфейса (к сожалению, и размеру) иногда не уступает инсталлируемому пакету, а разборка и реверс его вызывает профессиональный интерес и доставляет настоящее удовольствие. Пример исследования одного из подобных инсталляторов мы и рассмотрим в сегодняшней статье.
warning
Статья написана в исследовательских целях, имеет ознакомительный характер и предназначена для специалистов по безопасности. Автор и редакция не несут ответственности за любой вред, причиненный с применением изложенной информации. Использование или распространение ПО без лицензии производителя может преследоваться по закону.
Итак, у нас имеется инсталлятор для некоего технического пакета, оформленный в виде весьма увесистого (размером в несколько гигабайтов) самодостаточного EXE-файла. Интерфейс у инсталлятора продвинутый и стильный, он не похож на визуальное представление ни одного из встречавшихся нам до этого стандартных инсталляционных пакетов. Оно наполнено различными элементами управления, которые шустро переключают странички по мере заполнения, приближая начало установки программы. Но вот беда — в определенный момент инсталлятор начинает требовать лицензию, без которой упорно не желает переходить на следующий экран.
Мы уже встречались с подобным поведением программ установки в предыдущих статьях. Однако в этот раз выяснилось, что программа содержит все неприятные фичи, присущие инсталляторам:
- Из весьма увесистого EXE-файла исполняемым является только крохотный и совершенно неинформативный загрузчик.
- Владелец процесса тоже относительно небольшой EXE-файл, запущенный из системной папки временных файлов.
- Перед нами не хорошо изученные 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.
Присоединяйся к сообществу «Xakep.ru»!
Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», позволит скачивать выпуски в PDF, отключит рекламу на сайте и увеличит личную накопительную скидку! Подробнее
| -60% |
1 год
9990 рублей 4000 р.
[TD]
1 месяц
920 р.
[/TD]
Я уже участник «Xakep.ru»
