Я искал лучшее шифрование для лицензионного ключа для приложения, и кто-то сказал, что кто-то может легко декомпилировать приложение, а затем просто пропустить тест для лицензионного ключа.
как кто-то будет делать это практически? Таким образом, у них есть мой .dll, они должны каким-то образом декомпилировать его, затем прокомментировать вызов функции, чтобы проверить лицензию, а затем перекомпилировать ее? Декомпилятор должен быть действительно хорош, чтобы код все еще компилировался!
Попробуйте открыть приложение с помощью Reflector. Вы, вероятно, будете удивлены: -)
И как только взломщик разместил нужное место в вашем коде, они могут использовать комбинацию ildasm/ilasm, чтобы удалить проверку из вашего приложения - даже если код Reflector не будет скомпилирован.
Если исходный код обычно скомпилирован, очень легко декомпилировать сборки .NET.
Вы можете использовать .NET Reflector, первоначально разработанный Lutz Roeder, теперь поддерживаемый Redgate Software. Внизу этого ответа есть снимок экрана, который дает вам впечатление, что делает Reflector.
Вы можете просматривать пространства имен и классы и просматривать исходный код и методы на вашем любимом языке .NET. Denis Bauer FileDisassembler позволит вам (или злым хакерам в вашем случае) преобразовать его в решение VS и внесите изменения в программу.
Существуют некоторые контрмеры, такие как использование > obfuscator кода, чтобы сделать ваш код практически нечитаемым.
В StackOverflow есть еще несколько интересных вопросов по этой теме:
Снимок экрана с рефлектора:
alt text http://www.red-gate.com/products/reflector/images/screenshot_full_screen.gif
Джош Смит недавно выпустил Crack.NET, который можно использовать для присоединения к выполняемому .NET-процессу, а затем открыть его в Reflector - поэтому, даже если сборки на диске каким-то образом зашифрованы (чтобы люди, использующие Reflector, не могли их получить), они все равно смогут для использования версий в памяти
.NET очень легко декомпилировать. Obfuscation будет немного сложнее понять, что происходит, но кто-то, кто декомпилирует ваш код, все еще может понять это, если они настойчивы.
Вот несколько советов по защите вашего .NET-кода, который я нашел в Интернете:
http://blogs.msdn.com/ericgu/archive/2004/02/24/79236.aspx
Просто отметьте, что ни один из обсуждаемых методов не эффективен на 100%, а просто вопрос о том, сколько обручей вы сделаете, чтобы взломщик проскочил.
.NET-компиляция в целом довольно проста: чтобы почувствовать это самостоятельно, просто возьмите копию .NET Reflector и дайте это попытка.
В большинстве случаев не нужно будет перекомпилировать код, чтобы удалить простую проверку лицензии: просто исправить MSIL выполнит трюк.
Защита себя от этого сценария приводит к быстрому уменьшению отдачи: будет always быть достаточно умным, чтобы обойти все дополнительные проверки, которые вы добавляете в свой код. Например, вы можете добавить цифровую подпись к своему коду и отказаться от запуска подписи не соответствует (указывая на то, что код был изменен, например, чтобы удалить проверку лицензии).
Затем игра становится удалять проверку подписи (в дополнение к проверке лицензионного ключа). Таким образом, вы добавляете еще одну проверку, которую затем можно обойти, и так далее, до бесконечности.
Там вся индустрия obfuscatation кода и защита от копирования инструменты, которые помогут вам защитить свое программное обеспечение от таких проблем. Вам решать, будут ли дополнительные усилия на вашей стороне и досадой, которую вы причините своим законным клиентам, стоит покупать в этих решениях...
Если это то, против чего вы пытаетесь защитить, вы можете прочитать о том, как атаковать его.
Использование программного обеспечения Грегом Холландом и Гэри Макгроу - отличное введение.
Лучше не переходить за борт по технологии лицензионного ключа. Независимо от того, что вы делаете, вы можете взломать определенный пользователь, и вы рискуете добавить проблемы, которые останавливают законных пользователей, использующих ваше приложение. Я даже видел код, который был защищен Hasp Dongles, который был взломан. Шифрование вашего лицензионного ключа и обфускация вашего кода должна быть достаточной для того, чтобы помешать оппортунистическим атакам, мало что можно сделать дальше.
Эрик Санк написал хорошую статью, охватывающую этот момент, см. раздел "4. Не радуйтесь честным людям" "Принципы прозрачности"
Даже без Reflector люди делают это целую вечность. В основном вы смотрите приложение с отладчиком - что-то вроде WinDBG, и узнайте, когда происходит проверка лицензии. Вы смотрите возвращаемое значение, а затем вы просто исправляете приложение, чтобы перейти непосредственно ко всей проверке.
Я бы рекомендовал все, что люди разместили выше. Вам просто нужно понять, что это игра в кошки и мышки, и если ваш возврат инвестиций будет стоить того. Если у вас есть пользователи, которые не пытаются играть в систему, то что-то простое может сделать. Если у вас есть что-то, где взломается растрескивание, вам придется искать разные стратегии и идти оттуда.
Вам не нужно перекомпилировать приложение для его исправления - там есть много бинарных программных патчей. И это не остановит ваших самых решительных крекеров, если будет достаточно денег, чтобы их можно было сделать.
"Слишком"
Любой тип "стандартного" /обычного механизма проверки лицензии является целью автоматического средства удаления. И в нескольких коммерческих приложениях .NET, о которых я размышлял, эти "слишком тривиальные" проверки выглядят обычными.
Лучше всего защищать, внося часть программы в зависимость от веб-службы. Это не должно быть слишком частым интерфейсом, чтобы избежать замедления выполнения, но он не должен быть очень коротким, так как эти фрагменты могут быть сразу загружены и кэшированы локально в "взломанной версии", если приложение не зависит от них, которые часто меняются.
Если вы хотите избежать сетевого подключения (некоторые из них используют или пользователи могут обнаружить, что проблема/сомнительна в зависимости от приложения, если только это то, что вы описываете и не обеспечиваете значение), затем разделение некоторых программ на родную dll или две и имеющие проверять лицензии во всех частях приложения и, что менее очевидно, на родной DLL, скорее всего, будет достаточно, чтобы сдержать большинство.
