Comments 26
А зачем это нужно было вам лично?
Предположу, что за деньги?
Так он же пишет, что раньше этим не занимался.
Мне кажется в этом нет противоречия. Понятно где искать исполнителя на "сделать сайт визитку", а при постановке задачи "взломать какую то старую проприетарную фигню, не доломав окончательно, в которой уже ковырялись, про которую никто не знает как она работает и насколько это вообще законно" поиск специалиста становится интересней. Таких людей не то чтобы много, и как правило они не сидят на фриланс площадках.
Я правильно понял, что в аппаратном ключе не было вообще ничего криптографического?
Мда. Столько усилий, чтобы разобраться с ключом, хотя хватило найти два места, где вызывается обработка ответа из верификации лицензии, и там пропатчить обработку ответа. Я в похожей ситуации тупо нашел соответствующую функцию проверки и заменил её код на эквивалент return VALID_LICENSE, и всё завелось без танцев с бубном. Правда, там была Java, которую декомпилировать проще.
евреи говорят - "Чтоб я бы таким умным сегодня как моя Сара завтра".
Формально, когда дело доходит до аппаратных ключей, меры противодействия отладке обычно приняты в достаточном объёме. Тут конечно FTDIка в качестве ключа намекает, но и выглядит соблазнительно :-) так что я лично автора вполне понимаю...
Нда. Обленились люди. Если хоть раз видел отладчик в жизни, понимаешь, что можно просто поставить бряки. Не только на код, но и на доступ к памяти по определьным адресам. И не нужно полагаться на стандартные обфуксакторы и пр. Первым делом делается явная проверка, для частных людей. Она работает, но легко выпиливатся. Ее цель формальная. Далее хотя бы делается развязка кода общения с ключом и кода запрашивающего. Минимальная крипта. В случае маленьких обменов и тривиальной хватит. Т.е. факт запроса есть, а кто запросил и что сделал с результатом не ловится. Ну и по результатам немного что-то делаем, без явного последствия. Это уже болезненно. А если сверху статистику от ключа с неизвестным распределением и обычный обфускатор, то, скорее всего, ваше ПО не насколько нужно. Все перечисленное "свое" пишется за день. Пробовал. Работает отлично
Интригующая история) Надеюсь это стоило затраченного времени. Кстати, сколько его ушло?
И ещё вопрос - дату localtime не пробовали поменять в системе на ранее той, что зашита в ключе? Понимаю, что это может не подойти как рабочий вариант, но всё же, интересно.
Было бы удивительно, конечно, что "оборудование стало простаивать" из-за expired даты, и вместо того, чтобы просто откатить её на рабочую, на месте решили поломакать ключ.
При озвученных условиях, что в инет не лезем и ключ читался, можно было банально обойтись батником, даже с восстановлением текущей даты, что-то типа:
Hidden text
rem BAT/CMD. Запускать от имени учётки с правами на "изменения даты и времени":
set curdate=%date:~-10%
date 01-01-2020
program.exe
date %curdate%
Автору респект, было интересно и познавательно. С DLL-injection было дело, DLL-proxying не довелось.
Заходим в отладчике в вызов проксирующего FT_OpenEx и видим лишний код, работающий с ebp и esp
В Visual Studio можно писать функции без стандартных прологов. Для этого есть ключевое слово naked. Оно не работает в x64, но вам же надо только x86. Вы могли написать как-то так:
__declspec(naked) void PROXY_FT_CLOSE() {
__asm {
jmp Original_FT_Close
}
}
Понравился пост. Про аппаратные ключи на такой элементной базе не слышал ещё.
А с FlexLM я тоже сталкивался. Ставят эту штуку только на очень крутой и дорогой софт (дешевле тысячи долларов за дистрибутив я не видел), а сама защита практически никак не защищена от реверса. Но в том софте, что довелось использовать мне (это был компилятор SDS для архитектуры MC68000), аппаратных ключей не использовалось, было достаточно заменить на пропатченную одну-единственную DLL-ку (lmgr325c.dll), которую мне заботливо доложили вместе с установочными файлами. Вроде в ней была вся магия. Был даже кейген для FlexLM, в точности повторявший алгоритм из FlexLM SDK (который некогда можно было свободно скачать).
...и после всех изысканий продлить ещё на полгода...
Респект. Старое доброе jnz => jmp
Dependency Walker не нужен, есть HIEW который показывает импорты и экспорты, а заодно имеет встроенный дизассемблер.
Логирование USB можно было даже не расматривать по причине того, что с FTDI работают только через родные библиотеки. По крайней мере спецификации на его USB-интерфейс мной найдено не было
Отличная статья, спасибо. Лет 25 назад был опыт подобного хакинга (точнее, не hack, а crack) - и точно также "три четверти - неудачные пути". Только тогда гуглом не пользовались.
В таких случаях мне всегда не хватало упорства. Ведь не факт, что получится довести дело до конца, проще забить и заняться работой по профилю. Особенно когда платят за результат
А если бы погуглили до конца, то и патчинг бы не пригодился. Flexlm старых версий отвязывается (кейгенится) не то что бы сложно.
Мой уровень знаний несколько ограничен и местами я едва схватывал суть происходящего, но признаюсь, что с великим удовольствием читал о процессе настоящего хакинга. Хочется также отметить, что на самом деле, если понимаешь о чем речь - это все выглядит не менее эффектно (в некотором смысле), чем в кино.
Взлом аппаратного ключа методом veni, vidi, vici