Ответ Ghost687 в «Конец реверс-инжинирингу: релиз Markov Shield AI — софт, который "намертво" привязывает код к железу»
Это не допилили малость "защитнички".
Просто разрабы неправильно поняли суть проблемы и решили на отвяжись поставленную задачу.
Если кто не понял исходный пост, то это такая своеобразная защита методом вынесения какой-то функции из читабельного или уязвимого к анализу софта в черный ящик, который трудно реверсинженерить.
Правильный способ сделать такую защиту трудновзамываемой есть, и тут вспоминается один из проектов моей далёкой бурной разработческой молодости.
Меня как-то озадачили необходимостью защиты некоторого инженерного софта (написанного, кстати, мною же) от нелицензионного использования. Важно было, чтобы у лицензиата не было физической возможности обеспечить нашим софтом больше рабочих мест, чем те, за которые было уплочено.
После разговора с потенциальными клиентами мы сразу решили, что онлайн защиты нам не подходят. Ну, типа, если у клиента ляжет интернет по какой-то причине, он не сможет обслужить своих клиентов, кои обычно богатые деньгами. но небогатые временем серьёзные люди. Все наши клиенты не хотели, чтобы софт зависел от интернета.
В связи со всем вышеперечисленным выбор наш пал на аппаратные ключи, которые в клиентский комп вставляются в USB-порт и без которых наша защищаемая CAD-система превращается в тыкву.
Вот такие вот ключики мы использовали
Внутри у него своего рода маленький компьютер, примерно такой же находится в чипах банковских карт и RFID-карт доступа. Фактически там микроконтроллер, на котором запущена маленькая ява-машина, выполняющая код, который в устройство запищет разработчик.
Достать записанный в ключ код - задача настолько сложная, что трудно окупить таким образом стоимость взлома этого донгла безлимитными лицензиями на что угодно.
Правильный способ использования защиты ПО на основе таких ключей заключался в том, чтобы вынести на этот ключ кусочки секретных алгоритмов, которые обычно размещены прямо в бинарниках защищаемой программы.
Это очень не просто - выбрать такие чистые (в функциональном смысле). компактные (в донгле не так много места), не критичные к скорости (ява-машина в ключике не впечатляла скоростью, а всё ещё и через USB2.0 работало... если не 1.1, не помню уже), нетривиальные функции, которые нельзя было бы повторить так просто в эмуляторе ключа.
Да, можно было так же наговнякать как в исходном посте, вернуть true и проверять потом, но такие ключи - просто деньги на ветер.
По-моему, я выносил в ключи функции поиска и фильтрации граней на многограннике для определения поверхностей, подлежащих обработке. Алгоритм самописный, не тривиальный, достаточно быстро работал на ядре этой финтифлюжки, не требовавший объёмных аргументов и т.д.
Навернр в эмуляторе ключа можно было что-то изобрести похожее, но тогда (конец двухтысячных) не было ИИшек, которые делают сейчас такой реверс-инженеринг достаточно дешевым, а наш софт был не таким распространённым и известным, чтобы на его взлом тратить дохрена денег и мозгов грамотных специалистов.
И да, надо понимать, что любая просто быстро и наивно реализованная защита легко и дёшево обходится. Главное, чтобы это было экономически выгодно, а за взломом дело не встанет.
Вот и тут, не так просто найти даже в большом инженерном приложении кусочка, который можно настолько чисто изолировать, чтобы он мог работать на отдельном процессоре. А ещё надо, чтобы разработка и исправление ошибок в рамках поддержки защищенного ПО не превратились в кошмар, чтобы неаккуратность или ошибка разработчиков не поломали законно купленные лицензии.
И вот тут я расскажу ещё про один лайфхак. Защита должна быть многослойная и вероятностная.
Если ваш защитный механизм мгновенно замечает факт нелицензионного использования, и тут же блокирует работу защищаемого софта, то это плохой защитный механизм.
Хороший механизм будет некоторое время накапливать признаки нелицензионного использования, порог блокировки будет рандомизирован таким образом, чтобы нельзя было "нащупать" коридор допустимого при обходе защиты.
В нашем случае если приложение не видело аппаратный ключ, оно рисовало поверх рабочей области простой сплеш-скрин с просьбой его подключить. Технически это никакая не защита. потому что требуется элементарное вмешательство на уровне API Windows, чтобы убрать помеху и работать дальше. Но после этого софт переходит в режим войны.
Он тихо и рандомно ломает данные проектов, над которыми работают пользователи взломанного приложения. Проигнорированное предупреждение гласило, что при вмешательстве в работу ПО (а обход защиты именно этим и является) может привести к необратимой порче или потере данных.
Время от времени алгоритмы, вынесенные на аппаратный ключ падают с ошибкой и указанным выше предупреждением, а если ключ детектирует необычный баланс статистики вызовов защищенных функций, и их тайминги, то это признак взлома путём проксирования одного ключа на несколько рабочих станций. Все такие признаки накапливаются, а после рандомизированного порога приводят к рандомизированной отложенной порче выходных данных защищенных (вынесенных на донгл) функций.
Эти рандомизации критериев и отложенные реакции позволяют усложнить и замедлить цикл подбора параметров защищенных функций при взломе.
Сейчас такая защита тоже н еимеет никакого смысла, потому что ничего, в общем-то, не стоит переписать практически любой такой софт с нуля по образу и подобию готового прототипа с помощью нейронки. А раньше эта защита была неимоверно передовой и непробиваемой.
В геймдеве, кстати, её не использовали обычно скорее всего из-за медленной работы и трудности вынесения чувствительных и достаточно нетривиальных алгоритмов на аппаратный ключ.
Ну вот такой вот кусочек совершенно ненужного теперь опыта. Поделился с подписчиками.
Если непонятно что-то объяснил - спрашивайте. Мне казалось я умею объяснять сложные вещи простыми словами, особенно если сам понимаю эти сложные вещи. Но и на старуху, как говорится...
Типовой дисклеймер, которыми я снабжаю все свои посты.
Этот текст написан биогенным естественным интеллектом, работающим на аппаратном обеспечении моего собственного головного мозга. Никаких методов написания или улучшения текста генеративными моделями не применялось.
В наше время такое встречается не часто и я такое ценю, потому и добавляю такой дисклеймер.
