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 Кб, 16 просмотров)

0

Сообщение от Custos то тут возникают вопросики о его "экспертности"

ясно, значит флудер - игнорируем

Сообщение от Custos Фактически этот CrackMe был рассчитан на то, чтобы подловить тех, кто привык использовать популярные инструменты типа x64dbg/etc , для которых полно разных anti-anti-debug плагинов для обмана anti-debug детектов, и т.д.

И, кстати, он почти меня подловил. Я же первым делом открыл x96dbg.
Хорошо, что быстро понял, что нужно поменять отладчик. WinDbg и отладчик Rizin справились.
В любом случае, крякми был полезным, узнал про этот хитрый трюк.

0

Сообщение от Royal_X И, кстати, он почти меня подловил. Я же первым делом открыл x96dbg. Хорошо, что быстро понял, что нужно поменять отладчик. WinDbg и отладчик Rizin справились. В любом случае, крякми был полезным, узнал про этот хитрый трюк.

Вот обновленный вариант, просто немного изменена проверка пароля, но тоже ничего сложного

Вложения

CrackMe_Find_Password_V2.7z (54.1 Кб, 10 просмотров)

0

Сообщение от Custos Учитывая, что он первый раз узнал о существовании WoW64 из этого сообщения, то тут возникают вопросики о его "экспертности"

я этот термин и так то знал, я вопрос по другому вопросу задал... так - то... Моя "экспертность" - моя экспертность это любитель не более того...

0

Сообщение от Custos просто немного изменена проверка пароля

неужели теперь добавлено хеширование? тупо бегать по строчкам в отладчике не интересно, а в IDA там нечего анализировать, всё скрыто

0

Сообщение от Royal_X неужели теперь добавлено хеширование?

Нет, просто процесс сравнения теперь не настолько очевиден

0

Custos, я особо пока не смотрел, но запустил в отладчике и немного глянул на код.
Во-первых, обрадовался, что отладчик работает (ты просто писал, что умеешь ограничивать работу остальных отладчиков тоже).
Во-вторых, мне кажется, что мне нужно обратить внимание на кусочек 0x0040156e - 0x00401576.
Я правильно размышляю или нет?
Но сейчас появились другие дела, поэтому не обещаю, что вернусь к крякми в ближайщие дни. Тем более, ты говоришь, что сравнение теперь не настолько очевидно, а значит мне понадобится время. Полагаю, что в этот раз так просто, чтобы пароль лежал в регистре, не будет.

0

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

Это же базовый CrackMe, никакой защиты от отладки не добавлял

Сообщение от Royal_X Во-вторых, мне кажется, что мне нужно обратить внимание на кусочек 0x0040156e - 0x00401576. Я правильно размышляю или нет?

Никаких подсказок

0

Сообщение от Custos Никаких подсказок

значит, горячо) иначе, ты бы ответил отрицательно.

0

Сообщение от Royal_X засунуть приложение в архив с паролем

Несолидно (мягко говоря). Если приложение не может обеспечить даже простую авторизацию - какой смысл его покупать?

Повторяю вопрос: как сделать простую защиту (типа от энтузиастов в этой теме). Писать пример необязательно, достаточно (толкового) объяснения/псевдокода. Больше деталей задачи в моем посте #93

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

Немного намекну. Найти готовый инструмент реально, напр VMProtect. Но так результат зависит не от Вас, мне лично это не нравится, хотя объективно хз. Неужели надо бросаться изучать всю хрякерскую кухню и.т.п.? И с учетом кроссплатформенности! Нет ни времени, ни, по большому счету, желания, карьера хакера меня не привлекает. Ну да, ну да, "а как ты хотел?" А я вот думаю что скромную защиту за день (с нуля) соорудить можно

0

Сообщение от Igor3D Несолидно (мягко говоря). Если приложение не может обеспечить даже простую авторизацию - какой смысл его покупать?

Объясни подробно, что нужно? Я не совсем понимаю. Ты писал, что само приложение уже готово.
Самый простой способ защитить такое приложение, это отправить его в 7z архив с паролем))

Собственно, если не нравится идея использования архива с паролем, то можно самому сделать то же самое: шифрование AES256 + PBKDF2 + какое-то сжатие, например, LZMA2. Но зачем это делать, если можно использовать архив с паролем с помощью 7zip, ведь там, по сути, тоже самое.

Сообщение от Royal_X AES256 + PBKDF2

вот такое я уже делал на WinAPI (с помощью Cryptography API: Next Generation)

Сообщение от Royal_X LZMA2

такое тоже делал с использованием библиотеки https://tukaani.org/xz/#_source_packages (там LZMA2, но формат xz, а не 7z)
преимущество этой библы в том, что распаковывает в памяти без создания файлов на диске. Например, unrar так не умеет (Рошал мне лично писал про это).

соединить всё вместе можно в wxWidgets (Qt весит много), чтобы формошлепить на wxFormBuilder и справится за час.

Идея такая: при запуске приложения появляется окно, которое требует ввести пароль. Если пароль корректный, то расшифровывается и распаковывается настоящее приложение, которое потом запускается.

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

я и не собирался, поскольку

Сообщение от Royal_X сейчас появились другие дела

0

Сообщение от Royal_X Идея такая: при запуске приложения появляется окно, которое требует ввести пароль. Если пароль корректный, то расшифровывается и распаковывается настоящее приложение, которое потом запускается.

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

0

Сообщение от Custos В такой постановке это не работает.

потому что я не понял само условие

Сообщение от Royal_X Объясни подробно, что нужно? Я не совсем понимаю.

Я думал, что речь идет об одном покупателе. Т.е. человек заплатил - получил пароль. Зачем дампить, если приложение расшифровывается и распаковывается на диске покупателя.

Полагаю, что я вообще не понял, что нужно.

0

Сообщение от Royal_X Я думал, что речь идет об одном покупателе.

Вангую, что речь идет об обычном лицензировании софта, чтобы пользоваться им мог только тот, кто купил.

Сообщение от Royal_X Зачем дампить, если приложение расшифровывается и распаковывается на диске покупателя

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

0

Custos, т.е. речь идет о том, что приложение в открытом доступе, но оно триальное. Тот, кто покупает, получает пароль для активации? Так типа?

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

Сообщение от Custos Можно сделать так, чтобы распаковывать и запускать приложение не извлекая его на диск.

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

0

Сообщение от Custos В такой постановке..

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

Просьба держаться в рамках темы, альтернативами не увлекаться

0

Igor3D, если не хочется вникать во всё это и софт написан, архитектуру менять и выстраивать инфраструктуру для выноса важной функциональности в онлайн нет желания/возможности/целесообразности etc., то ваш выбор - навесные системы защиты, которые максимально усложнят взлом (themida или VM какой). Если программа уникальна и востребована, то её так или иначе взломают.

Для защиты же от начинающих есть золотые правила:
1. Не хранить строки про авторизацию в открытом виде. Шифруйте.
2. Разнесите проверку и получение данных авторизации во времени. Лучше, чтобы проверка была недетерминированной (то тут проверим, то там). Кусками.
3. Никаких сообщений об удачной или неудачной авторизации. Можно поменять коэффициенты числовые какие при отсутствии авторизации, чтобы программа генерировала правдоподобный бред. Можно использовать введенный ключ для расшифровки данных. Если ключ ерунда, то и на выходе ерунда (но тут надо подбирать алгоритм правильно, ибо это тоже потенциальный вектор атаки).

Если есть такая возможность, то собирайте программу под каждого клиента с уникальной цифровой подписью, с уникальным ключом шифрования, который будет расшифровывать и зашифровывать куски функциональности прям в памяти, можно для каждой сборки разные куски. Может даже аппаратный Sentinel/HASP ключ, если целесообразно. Это по крайней мере поможет утечку обнаружить и применить меры (например, онлайн проверки периодические).

0

Сообщение от Royal_X sporta1982, хочешь сказать, что в user mode (ring 3) нет cs?

вообще-то, в дизассемблерном листинге прямо видно, что используется регистр CS. Т.е. тут нет места всяким рассуждениям, а это факт.

0

Сообщение от WhiteP её так или иначе взломают.

Это верно концептуально, типа всегда возможен такой меч что пробьет и данный щит. Поэтому не стоит ставить задачу создать непробиваемый. Но практически это используется как отмазка чтобы никакой защиты не создавать. Тот же эффект с "преждевременной оптимизацией", верная мысль доводится до абсурда/противоположности

Сообщение от WhiteP Для защиты же от начинающих есть золотые правила: 1. Не хранить строки про авторизацию в открытом виде. Шифруйте. 2. Разнесите проверку и получение данных авторизации во времени. Лучше, чтобы проверка была недетерминированной (то тут проверим, то там). Кусками. 3. Никаких сообщений об удачной или неудачной авторизации. Можно поменять коэффициенты числовые какие при отсутствии авторизации, чтобы программа генерировала правдоподобный бред. Можно использовать введенный ключ для расшифровки данных. Если ключ ерунда, то и на выходе ерунда (но тут надо подбирать алгоритм правильно, ибо это тоже потенциальный вектор атаки).

Ну вот, есть же нормальные люди которые дают нормальные ответы. Подробности

- вверху была ссылка на GitHub по поводу шифрования. Интересно, а не станет ли само шифрование "объектом атаки" (не найдут ли кусок этого кода)

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

Сообщение от WhiteP Разнесите проверку и получение данных авторизации во времени. Лучше, чтобы проверка была недетерминированной (то тут проверим, то там). Кусками.

Как лучше это оформить? Собсно на это я (упорно) намекаю пост за постом, ведь это множит на ноль игры с отладчиком

0

Сообщение от Igor3D Но практически это используется как отмазка чтобы никакой защиты не создавать.

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

Сообщение от Igor3D а не станет ли само шифрование "объектом атаки" (не найдут ли кусок этого кода)

Любой необычный код, паттерн которого отличается от остального легитимного - это объект повышенного интереса RE-аналитика. Сам по себе кусок зашифрованного кода довольно просто считывается энтропийным анализом. Точки останова на чтение такого куска - и смотрим что и как с ним работает. Если использовать стандартные известные алгоритмы, то аналитик увидит криптоконстанты в данных и это для него тоже крючок (можно даже специально напихать побольше криптоконстант в данные, но использовать их с другой целью).

Сообщение от Igor3D Использовать ключ для расшифровки - так и было, получил/огреб немало проблем когда структуры данных изменились.

Есть такая проблема в теории защиты ПО - Single Point of Check. Каким бы хитрым не был алгоритм, всё руинится тем фактом, что в конце проверяется if(valid) success(). Так что логика проверки валидности должна быть максимально встроена в логику программы. Шифрование ключом тут самый простой вариант для реализации, кмк.

Сообщение от Igor3D Как лучше это оформить? Собсно на это я (упорно) намекаю пост за постом, ведь это множит на ноль игры с отладчиком

1. Никогда не проверять ключ напрямую. Никаких strcmp(key,). После ввода данных лучше сто раз прогнать ключ по буферам. Стековым, на куче, туда обратно. Можно даже кусками. Можно часть ключа использовать для расшифровки каких-то данных после преобразования, которые даже не юзаются, например. Или юзаются не там.

2. Размазать проверки частями. Не прерывать, если обнаружено, что часть не совпадает! Это просто должно на выходе дать невалидный ключ для работы с данными. Например, куски шифруются чем-то, потом между собой, потом какое-нибудь статическое значение к ним добавляется, опять шифруется, потом часть отбрасывается и снова сливается позже. Цель - сбить с толку исследователя, чтобы он устал отслеживать свои точки останова. Можно расшифровывать кусками куски данных, которые будут использоваться ПОЗЖЕ. Тогда приложение упадет где-нибудь потом. От того, что расшифрован мусор.

3. Проверки сами распихать по разным потокам. Часть потоков что-то делает с частями ключа, другие потоки другое. Потом сливаются в разные буферы.

4. Распихивать проверки в обычные шаги работы программы - например, на Qt вызывать проверки в Qt::QueuedConnection, через кастомные QEvent с обработкой на неочевидном объекте, вместо таймера проверок юзать какую-нибудь анимацию QPropertyAnimation и проверять части ключа по событию finished. Используй проверки в обработчиках исключений, которые сам генерируешь (деление на ноль, например).

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

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

На самом деле защита программы это составление головоломки для реверсера. Чем лучше ты понимаешь как действует взломщик, тем лучшую защиту ты сможешь создать. Простой, но дорогой путь - навесная защита.

0

Сообщение от Custos Вот обновленный вариант, просто немного изменена проверка пароля, но тоже ничего сложного Вложения CrackMe_Find_Password_V2.7z (54.1 Кб, 8 просмотров)

Пишешь, что нет ничего сложного, тогда объясни мне свой легкий метод нахождения пароля.
Конечно, крякми тебе легко было создавать, особенно если ты использовал готовые наработки. Но создавать крякми одно дело, а находить потом пароль - другое.

***
В этот раз пароль уже не хранится в открытом виде, а применяются несколько хэш-преобразований, а потом сравнивается результат с константами через sete + and al, bl
Я потратил много времени на разбор этой цепочки хеш-преобразований:

Шаг 1 (0x4013f1–0x401419): входное число X → H1

Затем сравнение с 0 через sete - проверка, что H1 == 0.

Шаг 2 (0x40143e–0x40146f): X → H2

Сравнение с 0x334D31E5.

Шаг 3 (0x401474–0x4014AF): X → H3

Сравнение с 0x334D2ECE.

Шаг 4 (0x4014BE–0x4014EF): X → H4

Сравнение с 0x334D2ECE.

Шаг 5 (0x4014F5–0x401529): X → H5

Сравнение через test al, 0xD2 + imul.

Шаг 6 (0x401537–0x40156F): финальный

Сравнение с 0x4DFEEC13.

ВАЖНО

Конечно, это всё хорошо, но поскольку выше приведены однонаправленные хеш-операции, то просто алгебраически вывести X не получится.


Короче, рассказывай, как находить здесь пароль?.

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

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

0