stihl не предоставил(а) никакой дополнительной информации.
Иногда в мои руки попадают весьма экзотические продукты, для исследования которых отсутствуют проверенные инструменты, а информации о них в интернете — кот наплакал. Давай разберем именно такой случай и расковыряем приложение, созданное в среде WinDev.
Сегодня мы поговорим о французской компании Для просмотра ссылки Войдиили Зарегистрируйся и ее продукте Для просмотра ссылки Войди или Зарегистрируйся — среде для разработки СУБД, а также веб- и мобильных приложений. Несмотря на то что создатели изначально замахивались на кросс‑платформенность, продукт получился действительно очень экзотический: он поддерживает всего три национальных языка и за пределами Франции практически неизвестен. Зато, если загуглить по его названию, из выборки картинок можно собрать набор длинноногих девиц для эротического журнала средней степени целомудренности.
Является ли это причиной, почему мировая закулиса усиленно задвигает на задний план продукцию компании и ее фирменный язык программирования Для просмотра ссылки Войдиили Зарегистрируйся (или на французский манер — WLangage), — решать тебе, а мы перейдем от лирики к практической задаче.
Итак, у нас есть некое торговое приложение на очень экзотическом языке, при запуске предлагающее ввести серийный номер в ответ на аппаратный ID.
Для просмотра ссылки Войдиили Зарегистрируйся
Слегка нервирует тот факт, что формат кода неясен, а при вводе неправильного значения ничего не происходит от слова совсем. Судя по размеру запускаемого модуля (около 300 Кбайт), это просто лаунчер, не содержащий в себе ничего интересного. Detect It Easy нам тоже не помощник — с такой экзотикой это приложение незнакомо.
Определить принадлежность пациента к нашей поликлинике мы можем лишь по косвенным признакам: в комплект входит библиотека WD553HF.dll, которая гуглится как Для просмотра ссылки Войдиили Зарегистрируйся, а также весьма увесистый файл с расширением .WDL, который, по информации Для просмотра ссылки Войди или Зарегистрируйся, представляет собой основную библиотеку проекта и содержит формы, исполняемый шитый код и прочие используемые ресурсы. И наконец, при беглом просмотре исполняемого файла в Hex-редакторе в юникодном режиме мы видим множественные упоминания WinDev и его служебных библиотек.
Для просмотра ссылки Войдиили Зарегистрируйся
Обретенное знание нас мало радует: файл библиотеки .WDL при ближайшем рассмотрении оказывается запакован или зашифрован, причем этот Джо настолько неуловим, что нагуглить в паблике декомпилятор для актуальной версии невозможно. Видимо, когда‑то давно исходный код WLanguage хранился прямо внутри exe-файла в явном виде (о чем свидетельствует наличие весьма Для просмотра ссылки Войдиили Зарегистрируйся, но сейчас эти счастливые времена прошли, и нам снова приходится делать все самостоятельно.
По‑хорошему надо бы разобрать формат WDL и написать собственный декомпилятор, но (учитывая чуть менее чем никакую практическую полезность этого экзотического продукта) снова пойдем путем наименьшего сопротивления — попробуем найти код проверки серийного номера и написать его генератор.
Для этого загрузим нашу исследуемую программу в отладчик x32dbg и для начала попробуем проследить судьбу текста, введенного нами в поле серийного номера. К сожалению, контролы у окна приложения сплошь кастомные, поэтому брейк‑пойнты на функции GetWindowText, GetDlgItemText и им подобные здесь совершенно не в тему.
Попробуем совсем тупой способ: введем какой‑нибудь запоминающийся серийник типа 0123456789876543210 и поищем его в памяти.
Конечно, он находится в юникодном виде, причем сразу в нескольких десятках мест. Не ленимся поставить точки останова на каждое из них и сразу обламываемся — обращение к этим строкам идет постоянно, причем они непрерывно передаются из переменной в переменную, старые значения затираются, новые плодятся, поэтому отслеживать все ветки совершенно бесполезно. Тем более мы еще даже не нажали кнопку регистрации. Идея изначально была дурацкой, однако в ходе ее проверки мы делаем полезное наблюдение: программа вовсю использует функцию msvcrt.dll.wsclen. Не мудрствуя лукаво ставим на нее условную точку останова, чтобы отследить все строки, проходящие через этот «строкомер».
Для просмотра ссылки Войдиили Зарегистрируйся
Нажимаем кнопку регистрации и смотрим в журнал отладчика.
Для просмотра ссылки Войдиили Зарегистрируйся
Легко догадаться, что раз программа проверяет длину всех строк подряд, то в логируемый список вместе с содержимым контролов попадают и их заголовки, и даже их внутренние идентификаторы. Сложив два плюс два, мы легко догадаемся, что идентификатор контрола, в который мы пытаемся вбить серийник, называется EDT_Seriali и в окне присутствует некий невидимый нам контрол EDT_Edit3, содержимое которого программа дергает при нажатии кнопки регистрации.
Хранящаяся в нем строка 5652029 подозрительно напоминает серийный номер, которым и оказывается при проверке, — введя это значение в поле EDT_Seriali, мы обнаруживаем, что именно оно и ожидалось! Это было чересчур просто и даже в некотором роде неспортивно, поэтому попробуем все‑таки докопаться, каким образом нам удался этот фокус. Ведь в самом деле, не будем же мы на каждом компьютере (а серийник, напоминаю, зависит от аппаратного ID) заходить в отладчик и искать правильный номер? Для начала попробуем найти самое первое упоминание строки 5652029 с момента запуска приложения. Для этого слегка модифицируем точку останова.
Для просмотра ссылки Войдиили Зарегистрируйся
Перезапускаем программу, затем поэтапно поднимаемся вверх по стеку вызовов, внимательно следя за кодом, из которого вызывается каждая функция. Буквально через несколько шагов мы возвращаемся в код, который не принадлежит ни одному из загруженных модулей, более того, он даже поиском по всем файлам приложения не находится.
Для просмотра ссылки Войдиили Зарегистрируйся
Похоже на код, полученный в результате JIT-компиляции, а это именно то, что мы ищем. Обрати внимание на значение регистра ecx — в нем хранится указатель на переменную, значение которой — 563E3D, то есть 5652029 в десятичном виде. Это и есть правильный серийник. Нам осталось придумать, как зафиксировать точку останова в этом неуловимом JIT-коде, и отследить расчет нужной нам переменной.
Первое, что приходит в голову, — выделить в этом коде некую жесткую сигнатуру, последовательность байтов, которая не будет меняться в зависимости от адреса скомпилированного фрагмента, то есть не содержит в себе адресов переменных и вызовов функций. Например, подходит такая последовательность, начиная с адреса 1A20B44 на предыдущем скриншоте:
Теперь ставим точку останова на вызов откомпилированного JIT-кода.
Для просмотра ссылки Войдиили Зарегистрируйся
После этого перезапускаем программу. При каждом останове на этом вызове мы проверяем поиском по выбранной выше маске в памяти процесса, не скомпилировался ли нужный фрагмент кода. Наши старания очень скоро увенчаются успехом: буквально четвертый вызов ведет нас на искомый фрагмент кода. Дальше все оказывается очень просто: команда imul по адресу 1A20B14 перемножает числа 0x6230 и 0xDE, а результат последовательно суммируется с числами 0x117BF и 0xDE, в итоге и получается искомое число 0x563E3D (5652029). Откуда берутся числа 0x6230 и 0x117BF, даже и доискиваться не надо — это шестнадцатеричные представления числовых частей системного ID 25136-LAN-71615. Надо сказать, авторы программы довольно халтурно подошли к формированию серийного номера, явно понадеявшись на закрытость кода и отсутствие декомпиляторов в паблике, но нам в целях обучения такой простой пример идеален.
Итак, мы нашли простое решение простой задачи, однако тебе наверняка могут попасться задачи и посложнее. Какие направления их решения можно сразу наметить? Для начала — автопатчинг JIT-скомпилированного кода. Нам ведь известна (и мы имеем представление, как ее найти) точка входа скомпилированной функции (см. последний скриншот), можно ее запатчить на предмет контроля подгружаемого кода и автоматизировать этот процесс.
Еще один вариант — найти JIT-компилятор и озадачить автопатчингом именно его. С другой стороны, если ты найдешь JIT-компилятор и разберешь принцип его работы, то что (кроме наличия свободного времени, усидчивости и достойной мотивации) мешает тебе написать нормальный декомпилятор с этой французской вундервафли и облегчить задачу следующим поколениям хакеров?
Сегодня мы поговорим о французской компании Для просмотра ссылки Войди
Является ли это причиной, почему мировая закулиса усиленно задвигает на задний план продукцию компании и ее фирменный язык программирования Для просмотра ссылки Войди
Итак, у нас есть некое торговое приложение на очень экзотическом языке, при запуске предлагающее ввести серийный номер в ответ на аппаратный ID.
Для просмотра ссылки Войди
Слегка нервирует тот факт, что формат кода неясен, а при вводе неправильного значения ничего не происходит от слова совсем. Судя по размеру запускаемого модуля (около 300 Кбайт), это просто лаунчер, не содержащий в себе ничего интересного. Detect It Easy нам тоже не помощник — с такой экзотикой это приложение незнакомо.
Определить принадлежность пациента к нашей поликлинике мы можем лишь по косвенным признакам: в комплект входит библиотека WD553HF.dll, которая гуглится как Для просмотра ссылки Войди
Для просмотра ссылки Войди
Обретенное знание нас мало радует: файл библиотеки .WDL при ближайшем рассмотрении оказывается запакован или зашифрован, причем этот Джо настолько неуловим, что нагуглить в паблике декомпилятор для актуальной версии невозможно. Видимо, когда‑то давно исходный код WLanguage хранился прямо внутри exe-файла в явном виде (о чем свидетельствует наличие весьма Для просмотра ссылки Войди
По‑хорошему надо бы разобрать формат WDL и написать собственный декомпилятор, но (учитывая чуть менее чем никакую практическую полезность этого экзотического продукта) снова пойдем путем наименьшего сопротивления — попробуем найти код проверки серийного номера и написать его генератор.
Для этого загрузим нашу исследуемую программу в отладчик x32dbg и для начала попробуем проследить судьбу текста, введенного нами в поле серийного номера. К сожалению, контролы у окна приложения сплошь кастомные, поэтому брейк‑пойнты на функции GetWindowText, GetDlgItemText и им подобные здесь совершенно не в тему.
Попробуем совсем тупой способ: введем какой‑нибудь запоминающийся серийник типа 0123456789876543210 и поищем его в памяти.
Конечно, он находится в юникодном виде, причем сразу в нескольких десятках мест. Не ленимся поставить точки останова на каждое из них и сразу обламываемся — обращение к этим строкам идет постоянно, причем они непрерывно передаются из переменной в переменную, старые значения затираются, новые плодятся, поэтому отслеживать все ветки совершенно бесполезно. Тем более мы еще даже не нажали кнопку регистрации. Идея изначально была дурацкой, однако в ходе ее проверки мы делаем полезное наблюдение: программа вовсю использует функцию msvcrt.dll.wsclen. Не мудрствуя лукаво ставим на нее условную точку останова, чтобы отследить все строки, проходящие через этот «строкомер».
Для просмотра ссылки Войди
Нажимаем кнопку регистрации и смотрим в журнал отладчика.
Для просмотра ссылки Войди
Легко догадаться, что раз программа проверяет длину всех строк подряд, то в логируемый список вместе с содержимым контролов попадают и их заголовки, и даже их внутренние идентификаторы. Сложив два плюс два, мы легко догадаемся, что идентификатор контрола, в который мы пытаемся вбить серийник, называется EDT_Seriali и в окне присутствует некий невидимый нам контрол EDT_Edit3, содержимое которого программа дергает при нажатии кнопки регистрации.
Хранящаяся в нем строка 5652029 подозрительно напоминает серийный номер, которым и оказывается при проверке, — введя это значение в поле EDT_Seriali, мы обнаруживаем, что именно оно и ожидалось! Это было чересчур просто и даже в некотором роде неспортивно, поэтому попробуем все‑таки докопаться, каким образом нам удался этот фокус. Ведь в самом деле, не будем же мы на каждом компьютере (а серийник, напоминаю, зависит от аппаратного ID) заходить в отладчик и искать правильный номер? Для начала попробуем найти самое первое упоминание строки 5652029 с момента запуска приложения. Для этого слегка модифицируем точку останова.
Для просмотра ссылки Войди
Перезапускаем программу, затем поэтапно поднимаемся вверх по стеку вызовов, внимательно следя за кодом, из которого вызывается каждая функция. Буквально через несколько шагов мы возвращаемся в код, который не принадлежит ни одному из загруженных модулей, более того, он даже поиском по всем файлам приложения не находится.
Для просмотра ссылки Войди
Похоже на код, полученный в результате JIT-компиляции, а это именно то, что мы ищем. Обрати внимание на значение регистра ecx — в нем хранится указатель на переменную, значение которой — 563E3D, то есть 5652029 в десятичном виде. Это и есть правильный серийник. Нам осталось придумать, как зафиксировать точку останова в этом неуловимом JIT-коде, и отследить расчет нужной нам переменной.
Первое, что приходит в голову, — выделить в этом коде некую жесткую сигнатуру, последовательность байтов, которая не будет меняться в зависимости от адреса скомпилированного фрагмента, то есть не содержит в себе адресов переменных и вызовов функций. Например, подходит такая последовательность, начиная с адреса 1A20B44 на предыдущем скриншоте:
89 47 1C 8B 7D 14 8B 47 18 8B 5F 1C 03 C3 0F 80Теперь ставим точку останова на вызов откомпилированного JIT-кода.
Для просмотра ссылки Войди
После этого перезапускаем программу. При каждом останове на этом вызове мы проверяем поиском по выбранной выше маске в памяти процесса, не скомпилировался ли нужный фрагмент кода. Наши старания очень скоро увенчаются успехом: буквально четвертый вызов ведет нас на искомый фрагмент кода. Дальше все оказывается очень просто: команда imul по адресу 1A20B14 перемножает числа 0x6230 и 0xDE, а результат последовательно суммируется с числами 0x117BF и 0xDE, в итоге и получается искомое число 0x563E3D (5652029). Откуда берутся числа 0x6230 и 0x117BF, даже и доискиваться не надо — это шестнадцатеричные представления числовых частей системного ID 25136-LAN-71615. Надо сказать, авторы программы довольно халтурно подошли к формированию серийного номера, явно понадеявшись на закрытость кода и отсутствие декомпиляторов в паблике, но нам в целях обучения такой простой пример идеален.
Итак, мы нашли простое решение простой задачи, однако тебе наверняка могут попасться задачи и посложнее. Какие направления их решения можно сразу наметить? Для начала — автопатчинг JIT-скомпилированного кода. Нам ведь известна (и мы имеем представление, как ее найти) точка входа скомпилированной функции (см. последний скриншот), можно ее запатчить на предмет контроля подгружаемого кода и автоматизировать этот процесс.
Еще один вариант — найти JIT-компилятор и озадачить автопатчингом именно его. С другой стороны, если ты найдешь JIT-компилятор и разберешь принцип его работы, то что (кроме наличия свободного времени, усидчивости и достойной мотивации) мешает тебе написать нормальный декомпилятор с этой французской вундервафли и облегчить задачу следующим поколениям хакеров?