Crackme: реверс-инжиниринг

В архиве 10 exe-файлов - консольных приложений, каждое из которых запрашивает пароль. Цель в том, чтобы найти и ввести правильный пароль, после чего получить сообщение Password OK!
Приложения созданы не мной, а неким IOLI. Приложения 32-битные, что тоже упрощают работу.
Приложения закрываются после выполнения, поэтому запускайте из cmd.

Собственно, вы можете использовать любой удобный вам инструмент: IDA Pro, Ghidra, Cutter, x32dbg и т.д. Т.е. можно как статически анализировать, а можно запустить отладчик и анализировать динамически.
Поскольку не будет вывода секретного сообщения при правильном вводе пароля и заранее известно, что выведется лишь Password OK!, то не вижу смысла в использовании всяких трюков, чтобы обойти проверку пароля всякими jmp и прочими инструкциями. Лучше тренироваться именно в поиске пароля, а не в его обходе.


Топовые декомпиляторы в простых случаях сразу отображают пароль, поэтому в таких случаях, чтобы было интересно, предлагаю все равно попробовать самостоятельно найти пароль, анализировав дизассемблерный код.

Что я имею в виду? Например, если открыть crackme0x03.exe в IDA Pro, то после декомпиляции мы сразу увидим пароль:



Декомпилятор Ghidra тоже сразу показывает пароль (в hex):



Чтобы было интересно, в таких простых случаях можно перейти в дизассемблерный вид и попытаться найти пароль самостоятельно:

Например, вот как выглядит это окно в IDA Pro. Я там специально добавил комментарии к некоторым строкам и разъяснил, как вычисляется этот пароль (но есть одна опечатка в одном комменте 528 вместо 582).



Для новичков в IDA Pro есть фича Auto Comments, которая включается в настройках. Но честно говоря, она мне не очень нравится.

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



Еще Cutter хорош тем, что на выбор там два декомпилятора, один из которых это декомпилятор от Ghidra (вполне неплохая альтернатива платного от Hex-Rays в IDA Pro). Собственно, этот же декомпилятор можно использовать и в самой Ghidra, но там нет автокомментирования.

***

В crackme0x04.exe пароль сразу не виден после декомпиляции.



Но и там нет ничего сложного, просто переходим в функцию check и сразу становится ясно, что на самом деле данное приложение принимает не один правильный пароль, а их может быть несколько. Т.е. любое число, где сумма цифр введенного числа равна 15.



crackme0x05.exe очень похож на предыдущее задание, только нужно еще вспомнить, как определяют четность чисел с помощью побитового AND.

***
Короче, если вам скучно и не знаете, чем заняться, то можете поиграться с этими файлами и ознакомиться с основами реверс-инжиниринга.

Вложения

crackme.zip (82.1 Кб, 12 просмотров)

0

Сообщение от Royal_X Если пароля в программе нет, а там только его хеш, то разумеется я не смогу найти пароль (брутфорсить глупо).

Там нет никаких хешей
В чатике дискорд-сервера по реверсу это решили минут за 15-20

Миниатюры

 

0

Сообщение от Royal_X особенно если ты использовал готовые наработки

Никаких сторонних/готовых решений, просто полотно из __asm _emit в main функции на несколько экранов

0

Сообщение от Custos Там нет никаких хешей

а как назвать то, что я привел? я же привел цепочку хеш-преобразований. Ты сам хоть смотрел в дизассемблерный листинг?
другой вопрос, если они добавлены лишь, чтобы запутать людей и они не имеют никакого отношения к настоящему решению - такой вариант я не исключаю

Добавлено через 2 минуты

Сообщение от Custos Никаких сторонних/готовых решений, просто полотно из __asm _emit в main функции на несколько экранов

я писал слово "наработки", а не "сторонние/готовые решения", тем самым я не имел в виду, что ты использовал готовую библиотеку, а лишь намекал на то, что начитался всяких статей по реверсу и начал их реализовать в своем коде. Переписал из статьи или взял готовую библиотеку - имхо, разница невелика.

Сообщение от Custos В чатике дискорд-сервера по реверсу это решили минут за 15-20

статей по реверсу, доступных в инете не так уж много. Так что, если крякми написан на основе какой статьи, то очевидно, что любой чел из этой области наверняка тоже ее читал и за свою жизнь десяток похожих крякми взломал

Сообщение от Custos В чатике дискорд-сервера по реверсу это решили минут за 15-20

кинь тогда мой крякми Crackme: реверс-инжиниринг и пусть решают
если не смогут за 10-15 мин, значит они не те, кем прикидываются

0

Сообщение от WhiteP Да кучу всего можно впихнуть.

Когда советов много (пусть хороших) - они совершенно не ценятся, ну так уж устроен человек Пожуем только одну упомянутую Вами "фишку" - думаю ее вполне достаточно чтобы закрыть баловство с отладчиком. Как НЕ НАДО делать
Глупость подобного кода объяснить сложно. Видимо человек думать не хотел (не умел) и успокаивал себя тем самым "все равно сломают". Что не надо "светить" пароль уже разговор был. Упоминалось и strcmp. Но главная ошибка - очень легко зацепиться/выйти на код проверки. Дождался пока выскочит окно "Invalid code" и переключился в отладчик. Поднялся на пару вызовов по стеку - вот и проверка. Стартовый пост об этом ничего не говорит. Мол, запустили отладчик - ну он нам все и покажет. Во-первых, не гарантируется что все будет успешно дизассемблировано, а во-вторых, (и это главное) - будет показано столько что нереально понять где проверка. Сотни, скорее всего тысячи ф-ций, какая(ие) нужная? Осложнить жизнь начинающему пакостнику можно напр так
При этом соединение с QueuedConnection, т.е. попадает сначала в очередь событий, потом извлекается и.т.д. Дальше в том же духе
Да, остановиться в show_invalid он сможет. Но на стеке вызовов увидит что событие пришло из очереди. Но вот кто и когда его туда положил - поезд давно ушел. Заметим что выполнить строку "emit do_check" можно, ну что с того, какое-то событие попало в очередь, и все, проверка даже не началась

Можно ли это сломать? Конечно да, подменить одну из либ Qt, навесить фильтр и отследить все события (может даже сигналы) и.т.д. Но.. это совсем не то что слегка полазить в отладчике, заниматься этим любитель не будет. А будет - усилим ("у нас ножичков на всех хватит" )

0

Ну, мою прогу взломаете?

Миниатюры

 

0

Ексешник:

Вложения

parol.zip (12.23 Мб, 7 просмотров)

0

Сообщение от Igor3D Можно ли это сломать?

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

0

Сообщение от Igor3D Когда советов много (пусть хороших) - они совершенно не ценятся

Ну, много советов не просто так. Любой из них по отдельности обходится довольно просто. Нужно комбинировать.

Сообщение от Igor3D emit do_check(txt);

Усложнит, но проверка текста как он есть без модификаций и запутывания control flow - плохая идея. Взломщик ищет введёный текст и ставит точку останова на чтение буфера в памяти, куда он прочитан. Далее трейсит и по стеку вызовов понимает примерно как и что работает с текстом. После ставит точечные брейкпоинты и в итоге выходит на то самое сравнение. Меняет jnz на jz или jmp - программа сломана битхаком. Я потому и писал про SPoC - это лучший подарок взломщику. Нужно протаскивать строку от буфера к буферу, от функции к функции асинхронно, менять при этом его части. Чтобы отслеживание потока выполнения, модифицирующего введенный текст, вызывала боль и желание бросить.

Сообщение от Royal_X В реальной жизни хакеры обычно просто обходят защиту, а не ищут пароль

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

0

Сообщение от WhiteP возможная применимость к обновленным версиям продукта

я в Cheat Engine когда-то делал AOB injection. Она по сигнатуре и очень часто устойчива к обновлениям

0

Сообщение от alexu_007 мою прогу взломаете?

зависит от того, она адекватная или это прикол

сразу видно, что пароль сравнивается с хешем 12ED15FEABB873897DA403D84207398. В связи с этим у меня вопрос: действительно ли пароль находится в бинарнике или там только его хеш? В последнем случае - создай отдельную тему "Найдите исходное значение по его хешу", но уверен, что никто не станет тратить время на такое идиотское задание.

И объясни, что за крестики в качестве пароля на скриншоте? Не похожи на цифры...

0

Сообщение от Royal_X зависит от того, она адекватная или это прикол

Так просят сломать, а не найти пароль
Ну за 2 минуты если, то вот: 0x12F3: 74 58 -> 90 90
Формируется нечто похожее на CRC, но с таблицей псевдослучайных чисел.

0

Сообщение от WhiteP Так просят сломать, а не найти пароль Ну за 2 минуты если, то вот: 0x12F3: 74 58 -> 90 90

тогда можно сказать, что я взломал еще вчера за минуту)) менял только один опкод

0x00401ef3 74 -> 75 (т.е. je/jz поменял на jne/jnz)

Но по тому же способу можно и все остальные крякми решить из этой темы

0

Сообщение от Royal_X 0x00401ef3 74 -> 75 (т.е. je/jz поменял на jne/jnz)

Тогда правильный не примет)) Но зато 1 бит.

0

Сообщение от WhiteP Тогда правильный не примет))

верно, но если мои сомнения окажутся правдой - типа если в бинарнике нет пароля, а вычисляется хеш ввода пользователя, который потом сравнивается с 12ED15FEABB873897DA403D84207398 - вероятность, что угадаем пароль ничтожно мала)

Добавлено через 2 минуты

Сообщение от WhiteP Но зато 1 бит

да, красиво получается

0111 0100 (74)
0111 0101 (75)

весь механизм защиты на одном бите держится

хотя, правильнее говорить, что изменили 1 байт (каждая из вышеперечисленных инструкций занимает именно байт).

0

Сообщение от Royal_X весь механизм защиты на одном бите держится

Именно поэтому такой метод взлома и называется bithack, и является он следствием проблемы Single point of check (spoc), о которой я выше писал.

0

Сообщение от WhiteP Взломщик ищет введёный текст и ставит точку останова на чтение буфера в памяти, куда он прочитан. Далее трейсит и по стеку вызовов понимает примерно как и что работает с текстом. После ставит точечные брейкпоинты и в итоге выходит на то самое сравнение. Меняет jnz на jz или jmp - программа сломана битхаком.

Не так резво, при QueuedConnection строка скопируется, и не раз (невзирая на имплисит шару). Но в целом замечание верное - нужно лишить гада возможности ловить чтение строки введенной юзером (ну или сделать это нестерпимым). Как это лучше реализовать? Просьба конкретнее, ясно что "можно по-всякому", но как? Спасибо

К тому же не раз видел такую штучку: на входе что-то типа strcmp выше, ну точно лох делал. Приложение запускается (вроде сломано), начинает что-то делать, и тут хирак - еще проверка, но уже без всяких месяг, калечит данные.

0

Сообщение от Igor3D Как это лучше реализовать?

Копировать вручную, частями, преобразуя во что-то (ксором, иным шифрованием etc). Не работать с plain text введенным вообще. Сразу преобразовывать. Чтобы оригинальный текст как можно меньше времени лежал там, куда он был прочитан и как можно меньше времени в изначальном виде.
Чтение строки из буфера контрола в буфер приложения отловить всё равно можно. Можно, конечно, написать свою реализацию метода контрола, где после API ОС сразу модифицировать введенное и отдавать уже его, вплоть до использования системных вызовов напрямую. Но это не шибко усложнит задачу исследователю, но разработчику вполне.
Бывает, что вообще хукают нажатия клавиш, когда курсор в поле. И сразу же ксорят во внутренний буфер или сразу несколько. Тогда буфер контрола вообще не трогают, или используют как ханипотный путь.
Я не сильно вникал в кишки Qt, чтобы дать конкретный рецепт.

Сообщение от Igor3D Приложение запускается (вроде сломано), начинает что-то делать, и тут хирак - еще проверка, но уже без всяких месяг, калечит данные.

Honeypot. Да, так и делают. Я про это писал, что проверки нужно делать неоднократно и лучше частями. По таймеру (в частности отрисовки анимации, чтобы не брякались на SetTimer), при вызове важных функций через раз. Если сделать 100 проверок, причем разных частей кода авторизации, разными нешаблонными способами (чтобы исследователь просто не написал матчинг регэкспом и не деактивировал их одним скриптом) - это утомит исследователя.
Опять же - НЕ ХРАНИТЬ флаг "всё ок" нигде. Так как просто этот флаг тогда и заменят (снова spoc). Лучшим вариантом, как я уже неоднократно писал - дешифровывать высчитанным из ключа ключом данные - лучше. Там просто непонятно на месте, всё ли ок.

0

Сообщение от WhiteP Я не сильно вникал в кишки Qt, чтобы дать конкретный рецепт.

Qt с динамической линковкой не самый лучший вариант. Не знаю, почему Igor3D заговорил о данной библиотеки.
Вообще динамическую линковку для Qt, wxWidgets и похожих библиотек не советую, поскольку исполняемый файл будет содержать таблицу импорта с именами необходимых функций. Учитывая это, всякие статические анализаторы очень качественно всё декомпилируют, в том числе, используя FLIRT и пр.

Лучше всего использовать статическую линковку со strip и с полным вырезанием всей отладочный инфы. Например, в программе на wxWidgets со статической линковкой анализатор в таблице импорта лишь покажет имена функций WinAPI, но не самой библиотеки wxWidgets.

Бесплатная опенсорсная лицензия не позволяет статическую линковку. К тому же, насчет Qt я вообще не уверен. Возможно, FLIRT способен даже в случае статической линковки Qt восстановить имена функций. Но вот wxWidgets точно не может.

0

Сообщение от Royal_X исполняемый файл будет содержать таблицу импорта с именами необходимых функций. Учитывая это, всякие статические анализаторы очень качественно всё декомпилируют, в том числе, используя FLIRT и пр.

FLIRT не используется как таковой, если есть таблица импорта с именами. FLIRT как раз нужен для распознавания функций внутри кода, когда нет символьной информации вообще. Он по сути просто мэтчит паттерны библиотечных функций в коде и таким образом связывает их с именами. Он делает работу, обратную той, что делает линкер - тот видит имя, подставляет байты. FLIRT видит байты - подставляет имя.

Сообщение от Royal_X Возможно, FLIRT способен даже в случае статической линковки Qt восстановить имена функций. Но вот wxWidgets точно не может.

Если даже нет сигнатур в базе FLIRT для некоторой версии, то реверсер сможет их создать на основании lib файла библиотеки через FLAIR SDK.

Но в целом, да - стрип-статика заставит исследователя потратить больше времени на анализ.

0

WhiteP, ну, например, IDA не способна восстанавливать имена функций, да и сами функции в таком виде, в котором они были, для статик приложений на wxWidgets. IDA показывает всё в виде WinAPI функций - тех самых, которые под капотом используются в wxWidgets на винде (wxMSW). Это усложняет анализ кода. Результат декомпиляции выглядит запутаннее, чем даже когда изначально приложение пишется на чистом WinAPI. Например, IDA может показать, будто используется сотни функций из WinAPI, хотя ты разумеется использовал всего десяток функций из wxWidgets. В импортах вообще ни одного упоминания про wxWidgets, только нативные виндовые функции.

А вот я открыл приложение на Qt динамик - результат декомпиляции прям очень похож на исходный код, все имена на месте, сами функции тоже выглядят так, как в исходном сорце. Имхо, логику такого приложения очень легко можно понять.

0