» x32dbg, ключ из txt файла.

Есть программа, купленная за деньги. В ней стоит защита на основе текстового файла, при установке генерируется код машины, отсылается разработчику и он присылает специальный файл с опциями и ключем. При замене мат. платы, HDD и т.д. код машины меняется и приходится отсылать заново, а это время, т.к. не всегда быстро разработчик реагирует на создание файла. Хочу сделать временную "заглушку", т.е. самому генерировать такие файлы на время пока разработчик не отвечает.

Пробовал x32dbg, Ollydbg, но там не могу понять, как формируется ответный ключ и можно ли вообще его получить? Подскажите, как работает этот механизм защиты?

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

Обычно разработчик формирует структуру данных лицензии из ему присланного мак адреса, серийного номера BIOS'а итд; а также из разрешённых опций, имени, названия фирмы, итд; шифрует RSA приватным шифром и высылает файл клиенту. Прога расшифровывает файл RSA публичным шифром, читает структуру данных лицензии, проверяет мак адрес, серийный номер BIOS'а, разрешает разрешённое, вешает имя, название фирмы в About'е. Как-то так, если коротко.

Тут все гораздо проще. Программа генерирует код: например EGDHSN, этот код посылается разработчику, он в своем генераторе прописывает имя клиента, кол-во подключений и т.д. и присылает файл с уже сформированными полями и ключем WBSM-JRFNF-EDSM. Если в файле изменить хоть одну букву, программа не принимает файл регистрации.

digital422
Если действительно происходит симметричное кодирование, ваша программулька генерирует код из параметров железа, разработчик у себя и них создаёт ключ.
Программулька на вашей стороне по тому же алгоритму из кода генерирует ключ и сравнивает с ключом в файле.
Вы правы, чтобы узнать алгоритм на вашей стороне
Цитата:

Тут без знания Ассемблера не обойтись.

Вы какого результата ожидаете?
Чтобы кто-то вдруг угадал способ перевести EGDHSN в WBSM-JRFNF-EDSM?

Моя попытка:
Берём маску WBSM-JRFNF-___M
на пустые позиции подставляем 1-й, 3-й и 5-й символ исходного кода.
На имеющемся наборе примеров мой способ даёт 100%-е совпадение

Цитата:

...присылает файл с уже сформированными полями и ключем WBSM-JRFNF-EDSM. Если в файле изменить хоть одну букву, программа не принимает файл регистрации.

Это вариант электронной подписи. В классическом случае все данные лицфайла кроме ключа хешируются MD5 или SHA или другим алгоритмом, хеш шифруется приватным RSA ключём, приводится в читаемый вид, добавляется в лицфайл и высылается клиенту.
Прога читает лицфайл, хеширует все данные кроме ключа, переводит подпись (ключ) из ASCII в бинарный вид, расшифровывает его публичным RSA шифром, сравнивает расшифрованный хеш с подсчитанным на первом этапе.
В данном случае или всё сильно упрощено или в качестве алгоритма подписи использован HFE, у которого подпись очень короткая по сравнению с RSA, DSA, ECC алгоритмами. Если там всё просто, анализируем код и пишем генератор лицензии, если там HFE, тоже анализируем код и патчим прогу.

KDPoid - пример я просто набил от руки . С маской подставления не проходят, в имеющемся ключе даже нет тех символов, что генерируется у клиента. Пока мои исследования заканчиваются на том что я вижу как происходит импорт из файла и превращается это все в 16-ричный код. Дальше не хватает знаний и опыта.
ne_viens - в ASCII выводится подозрительный набор случайных символов (31 шт.), расположены они возле того места, где происходит принятие решение о принятии и непринятии ключа.

Каким кодом в OllyDBG можно посмотреть результат расшифровки после этих случайный символов? Пробовал pop, но он выводит тоже самое, что в окне регистров.

Результат расшифровки можно посмотреть в левом нижнем окне данных. Ctrl-g и ввести адрес массива.

digital422 опыт приходит с практикой, теорию чтения асма можно подчерпнуть здесь: http://beginners.re/