Помню, как в июне 2021-го в сеть «слили» ранний билд Windows 11. Тогда знатно полыхнуло у всех: Microsoft впервые в истории запретила ставить систему на компы без TPM 2.0 и Secure Boot. Казалось бы — всё, приехали, корпорация решила, на чем нам работать.
Но в нашей среде «нельзя» — это просто вызов. Энтузиасты за считанные часы нашли виновных: модули appraiser.dll и winsetup.dll. И тут многие спросили: как вообще люди понимают, что происходит внутри закрытой винды, если у них нет ни строчки исходного кода?
Взлом под названием «Реверс»
Процесс, когда вы разбираете уже готовую программу, чтобы понять её логику, называется реверс-инжинирингом. Это как если бы вам дали готовый торт и попросили восстановить рецепт, не заглядывая в кулинарную книгу.
Сложность в том, что после компиляции все наши красивые названия функций и комментарии выбрасываются на помойку. Процессор понимает только нули и единицы. Чтобы не сойти с ума, глядя в этот цифровой «код Матрицы», мы используем декомпиляторы вроде IDA Pro или Ghidra.
Эти программы превращают машинный бред в псевдокод на Си — он технически приближен к оригиналу, но вместо понятных имен функций там часто безликие числа типа sub_69737.
Подарок от жадной корпорации
Самое ироничное, что Microsoft сама упрощает нам жизнь. Они выкладывают в открытый доступ PDB-файлы — отладочные символы. Это делают прагматично: чтобы сторонние разработчики сами понимали, почему их софт падает, и не заваливали поддержку жалобами.
Импортируешь такие символы в ту же IDA, и — о чудо! — безликая sub_69737 превращается в условную CheckNumber. Но даже с именами функций читать сотни тысяч строк кода «в лоб» — гиблое дело. Нужна зацепка.
Как найти иголку в стоге сена
Когда нужно быстро найти «виноватую» функцию, на помощь приходит динамический анализ — изучение программы прямо во время её работы. С установщиком Windows 11 ребята сработали изящно: они использовали Windows Performance Analyzer.
Сценарий простой: запускаешь запись работы системы, доводишь установщик до ошибки «Запуск Windows 11 невозможен» и тормозишь трейс. Изучая события за секунду до ошибки, нашли прямое обращение к ключу реестра LabConfig.
Оказалось, за проверку железа отвечает функция VerifyRAMRequirements из модуля Winsetup.dll. Внутри псевдокода всё было банально: условие проверки требовало, чтобы определенное число в реестре просто было больше нуля. Так и родились те самые «костыли» для обхода ограничений.
Немного о боли и указателях
Конечно, не всё так гладко. Часто приходится воевать с указателями — это когда переменная хранит не число, а адрес в памяти, где это число лежит. В коде это выглядит как страшные конструкции со звездочками типа *(_DWORD *)(v4 + 0x40).
А еще есть ASLR — защита, которая при каждом запуске системы раскидывает адреса программ по рандомным местам в памяти. Чтобы данные из отладчика совпали с тем, что мы видим в статическом анализе, приходится делать «Rebase» — пересчитывать адреса под реальный запуск.
Вывод
Реверс — это не только про взлом или обход ограничений. Это про глубокое понимание того, как всё устроено под капотом. Необязательно переписывать ядро системы, чтобы заставить его работать по твоим правилам. Достаточно немного любопытства и пары правильных инструментов.
А вы когда-нибудь пытались разобраться в том, как работает программа, которая «просто не хочет» делать то, что вам нужно? Или предпочитаете искать готовые ответы на форумах?