#cryptography #reverse-engineering #decompiling #analyzer
#криптография #обратный инжиниринг #декомпиляция #анализатор
Вопрос:
Я использую приложение Keygen (.exe). В его графическом интерфейсе есть два поля ввода:
p1— минимум 1 цифра, максимум 10 цифр — ^[0-9]{1,10} $p2— максимум 12 символов — прописные буквы / цифры / символы подчеркивания — ^[A-Z0-9_]{0,12} $
Нажатие generate кнопки создает ключ x .
x — ровно 20 цифр — ^[0-9]{20} $
Для каждой пары (p1,p2) существует только одна x (другими словами: f(p1,p2) = x является функцией)
Меня интересует его алгоритм шифрования.
Есть ли какой-либо способ обратного проектирования алгоритма?
Я подумал о двух способах:
- декомпиляция. Я использовал snowman, но результат слишком загрязнен. Декомпилированный код, вероятно, содержит не относящиеся к делу части, такие как графический интерфейс.
- анализ ввода и вывода. Интересно, есть ли какая-либо возможность определить используемый алгоритм шифрования путем анализа набора
f(p1,p2) = xрезультатов.
Комментарии:
1. Можете ли вы предоставить больше информации о приложении? Выполняют ли одни и те же входные
p1данные иp2генерируют одни и те же ключи? Можно ли установить размер ключа или каков размер ключа? Как выглядит ключ, имеет ли он определенный формат / кодировку? Если нет документации для приложения, вероятно, есть только те варианты, которые вы упомянули. Для второго варианта: вы можете сравнить результаты с обычными алгоритмами, используемыми для получения ключей (но здесь есть много возможностей, и этот подход также потерпит неудачу, если разработчики должны были придумать что-то свое).2. @Topaco, я отредактировал вопрос, предоставив запрошенную вами информацию
3. Что касается обратного проектирования , для этого есть специальный сайт reverseengineering.stackexchange.com .
4. Вы не можете просто определить алгоритм, но вы можете легко проверить одну или несколько гипотез о том, как он работает, реализовав некоторые алгоритмы-кандидаты и протестировав их с заданным набором входных данных и сравнив выходные данные, пока не найдете соответствующий алгоритм.
5. Законно ли публиковать тот же вопрос в reverseengineering.stackexchange.com / ?
Ответ №1:
Как вы упомянули, использование snowman или некоторых других инструментов декомпиляции, вероятно, является правильным решением.
Я сомневаюсь, что вы сможете определить алгоритм, просто посмотрев на комбинации ввода-вывода, поскольку можно написать любой произвольный алгоритм, который может вести себя любым способом.
Возможно, вы могли бы просто спросить автора, какой алгоритм они используют?
Ответ №2:
Если это не что-то действительно простое, я бы исключил ваш вариант 2 — попытаться выяснить это, просмотрев пары ввода и вывода.
Для декомпиляции / обратного проектирования статического двоичного файла вы должны сначала определить, является ли это приложением .NET или чем-то другим. Если он написан на .NET, вы можете попробовать это для декомпиляции:
https://www.jetbrains.com/decompiler/
Это действительно просто в использовании, если только двоичный файл не был запутан.
Если приложение не является приложением .NET, вы можете попробовать Ghidra и / или Cutter, в которые встроены довольно впечатляющие декомпиляторы:
Если статического анализа кода недостаточно, вы можете добавить к нему отладчик. Ghidra и x64dbg очень хорошо работают вместе и могут быть синхронизированы с помощью плагина, установленного в обоих.
Если вы новичок в этом, я могу порекомендовать вам изучить basic assembler для платформы x86, чтобы у вас было общее представление о том, как работает процессор. Еще один способ начать — это задания в стиле «crackme» на соревнованиях CTF. Часто есть отличные отзывы о решении, поэтому у вас есть как вопрос, так и ответ.
Удачи!
Ответ №3:
Введите p1 и p2. Просканируйте процесс на наличие этой строки байтов. Затем установите на него аппаратную точку останова для доступа к памяти. Сгенерируйте ключ, он достигнет этой аппаратной точки останова. Затем у вас есть адрес, который обращается к нему, и начните реверсирование оттуда в Ghidra (не забудьте использовать BASE OFFSET), поскольку выходные данные ghidra не будут иметь ту же базу, что и у запущенного приложения. Соответствующий код ДОЛЖЕН получить доступ к входным данным. Итак, вы знаете, где находится алгоритм. Поскольку он либо напрямую обращается к нему, либо где-то в этой цепочке вызовов выполняется относительно быстро. Никто не может знать, не видя исполняемый файл.