Защитить код.NET от реверс-инжиниринга?
Запутывание является одним из способов, но оно не может защитить от нарушения защиты приложений от пиратства. Как мне убедиться, что приложение не подделано, и как я могу убедиться, что механизм регистрации не может быть восстановлен?
Также возможно преобразовать приложение C# в собственный код, и Xenocode слишком дорог.
C# предоставляет множество функций и является идеальным языком для моего кода, поэтому о повторном написании всей базы кода на C++ не может быть и речи.
Безопасные сертификаты можно легко удалить из подписанных сборок в.NET.
38 ответов
Ты не можешь
Есть шаги, которые вы можете предпринять, чтобы сделать это немного сложнее, но в конечном итоге любой исполняемый файл на локальной машине можно взломать. В конце концов, этот код должен быть преобразован в машинный код, и каждое работоспособное приложение уязвимо.
То, что вы хотите сделать, это просто сделать его достаточно трудным для взлома, чтобы оно не стоило проблем людям.
Вот несколько советов, которые помогут вам защитить ваше приложение:
- Запутать ваш код. Dotfuscator имеет бесплатную версию и поставляется с Visual Studio.
- Используйте открытый / закрытый ключ или асимметричное шифрование для генерации лицензий на ваш продукт. Это гарантирует, что только вы можете генерировать свои лицензионные коды. Даже если ваше приложение взломано, вы можете быть уверены, что оно не выпустит генератор ключей для вашего приложения, потому что невозможно изменить алгоритм генерации ключа.
- Используйте сторонний упаковщик для упаковки исполняемого файла.NET в зашифрованное приложение-оболочку Win32. Фемида одна из лучших. Это мешает людям отражать ваше приложение в .NET Reflector и делает его неудобным для распаковки.
- Напишите свой собственный упаковщик. Если сторонние упаковщики слишком дороги, подумайте над написанием своего. Иногда нестандартные упаковщики могут быть очень эффективными, потому что нет хорошо опубликованных методов, как их распаковать. Учебник Как написать собственный упаковщик дает массу полезной информации о написании собственного упаковщика Win32.
В конечном счете, если люди захотят взломать ваше приложение, они это сделают. Посмотрите на все коммерческое программное обеспечение, которое имеет огромное количество ресурсов для защиты своих приложений, и все же они взломаны еще до того, как приложения будут опубликованы.
Опытный реверс-инженер может запустить IDA-Pro и прорезать ваше приложение, как масло, независимо от того, что вы делаете. Упакованное приложение можно распаковать, а запутывание мешает ему прогуляться по парку. Вся ваша тяжелая работа с вашим сложным лицензионным кодом может быть отменена с помощью одного байта патча.
Вам просто нужно принять тот факт, что есть очень реальный шанс, что люди собираются пиратствовать на вашем программном обеспечении. Есть некоторые люди, которые никогда не собираются платить за ваше заявление, несмотря ни на что, и это люди, о которых вам не нужно беспокоиться.
Тем не менее, есть много компаний, которые никогда не рискнули бы судебным процессом и с удовольствием купили бы лицензии на программное обеспечение, и многие пользователи компьютеров, которые либо не хотят рисковать, либо ошибаются, либо недостаточно разбираются в технологиях, чтобы заниматься пиратством. Это ваши настоящие клиенты, и вы должны сосредоточить свои усилия на предоставлении им хорошего пользовательского опыта и не обращать внимания на тех, кто взламывает ваше программное обеспечение.
У меня раньше было пиратское заявление, и я воспринял это как личное оскорбление. Здесь я был маленьким разработчиком, вкладывающим мое сердце и душу в приложение, и эти люди имели право на пиратство от меня?! Они брали деньги прямо из моего кармана!
Я немедленно добавил кучу драконовского кода DRM и попытался саботировать любого человека, используя незаконную или взломанную копию. Конечно, я должен был работать над улучшением своего приложения, а не пытаться остановить неизбежное. Не только это, но я причинял боль своим истинным клиентам, которые будут использовать все эти дополнительные средства защиты, которые я использовал.
После долгой битвы я понял, что борюсь с потоками, и все это время было потрачено впустую. Я вытащил весь код телефона-дома, за исключением функций лицензии barebones, и никогда не оглядывался назад.
Вы не можете полностью защитить любое приложение (управляемое или нет). Если такие системы, как Playstation и iPad, могут быть взломаны - где поставщик даже контролирует оборудование - на что надеется ваше приложение? К счастью, вы действительно не хотите. На мой взгляд, вам нужно защитить свое приложение настолько, чтобы кто-то не мог случайно украсть ваш продукт, и не более того.
Например, если вы используете лицензию для каждой машины, она не должна работать только при установке ее на новую вторую машину. Вам понадобится хорошее сообщение об ошибке, чтобы предотвратить дополнительные звонки в службу поддержки, но не тратьте дополнительное время на то, чтобы сделать его слишком сложным для обхода, и не ударяйте пользователей по этому поводу.
Другой пример - ограниченное по времени испытание. Даже не беспокойтесь о простых вещах, например, о том, могут ли пользователи просто откатить системные часы. Кто-то, кто делает это, знает, что он нарушает вашу лицензию, и пока пользователь знает, когда он нарушает, вы сделали достаточно.
Вы должны сделать это много, потому что пользователи не заботятся о вашей лицензии. Лицензии - это выдуманные вещи, о которых никто не заботится, пока им это не нужно. Никто не читает их, и они действительно не должны этого делать. Поэтому лучший способ сообщить пользователю, где находятся границы, - это если готовое поведение для вашего приложения соответствует лицензии. В этом первом случае это означает либо неудачную установку, либо повторную установку в режиме пробной версии. В последнем случае это может означать проверку простой текстовой даты в файле конфигурации. В любом случае, убедитесь, что вы справляетесь с этим элегантно, полезно и с уважением.
Так что это объясняет, что это значит, просто так много. Но почему бы не пойти дальше? Почему бы не закрыть каждую маленькую дырочку, которую вы можете найти? Ответ состоит из двух частей. Во-первых, если кто-то преодолеет этический порог сознательного нарушения условий вашей лицензии - даже простым способом - он также захочет сделать что-то более сложное или опасное, например, вытащить ваше приложение с торрент- сайта - и это определенная сумма опасности, связанной с запуском приложений, загруженных из ненадежных источников. Сложность усложняет работу этих пользователей и создает проблемы с вашими платящими клиентами. Проще говоря, это может помешать кому-то копаться в вашем приложении и выпустить более полный взлом. Во-вторых, у вас мало глаз, чтобы искать недостатки; у хакеров их много, и у них больше практики по их поиску. Вам нужно пропустить только один маленький недостаток, и ваше приложение будет иметь такой же дистрибутив на пиратских сайтах, как если бы вы ничего не делали. Вы должны быть правы каждый раз; им только повезет один раз. Таким образом, требуемые усилия очень высоки, а вероятность любого показателя успеха очень низка.
В конечном счете, если кто-то хочет пиратствовать в вашем приложении (а не просто использовать его), и это является его главной целью, он это сделает. Вы ничего не можете сделать, чтобы остановить их. Это природа программного обеспечения; как только файлы, составляющие ваш продукт, будут на компьютере пользователя, они смогут делать с ними все, что пожелают. Это особенно актуально в управляемых средах, таких как Java или .NET, но определенно относится и к нативному коду. Время на их стороне, и при наличии достаточного количества времени любая цифровая защита может быть взломана.
Поскольку вы не можете остановить пользователей от пиратства вашего продукта, лучше всего привлекать этот класс пользователей таким образом, чтобы он использовал их в ваших интересах. Часто можно заставить их работать на вас, а не против вас. Имея это в виду, независимо от того, какое у вас приложение, вероятно, стоит сохранить бесплатную версию, которая почти полностью функциональна и не имеет срока действия. Разница между ценой даже в 1 доллар США и бесплатной огромна, если только по той причине, что клиент не должен доверять вам свою кредитную карту. Бесплатная версия вашего продукта не только эффективно убьет пиратскую дистрибуцию (зачем рисковать пиратской версией, если вы можете быть легитимной по той же цене?), Но и может значительно расширить вашу аудиторию.
В результате вам может потребоваться увеличить цену за платную версию, так что в итоге вместо 2000 пользователей по 20 долларов у вас будет 100 000 бесплатных пользователей, из которых 500 готовы заплатить 99 долларов за "профессиональную" версию., Это зарабатывает вам больше денег, чем если бы вы потратили кучу времени, запирая свой продукт. Более того, вы можете привлечь этих бесплатных пользователей и использовать отношения несколькими важными способами.
Одним из них является поддержка. Пессимист воспользовался бы этой возможностью, чтобы пожаловаться на возросшую стоимость поддержки 100 000 бесплатных пользователей, но вместо этого происходит нечто удивительное: ваш продукт становится в значительной степени самостоятельным. Вы видите это все время с большими проектами с открытым исходным кодом, у которых нет денег на расходы на поддержку. Пользователи подойдут и сделают это возможным.
Как правило, бесплатные пользователи имеют заниженные ожидания по поддержке, и на то есть веские причины. Все, что вам нужно сделать, - пометить бесплатную версию как подходящую для поддержки сообщества и создать для этой цели модерируемый пользователем онлайн-форум. Ваша база знаний службы поддержки генерируется самостоятельно, и опытные пользователи будут помогать тем, кто нуждается в дополнительной поддержке от вашего имени. Что еще более важно, это позволит вам быстрее выявлять и исправлять ошибки, в конечном итоге улучшая качество вашего продукта и снижая общие расходы на поддержку. Раньше это было невозможно, потому что ваша пользовательская база была недостаточно велика, но когда вы относитесь к бесплатным пользователям как к клиентам, это может работать очень хорошо.
Еще один отзыв. Наблюдая за своим форумом, вы узнаете важные идеи по улучшению, которые вы, возможно, никогда не рассматривали иначе. Это может позволить вам в конечном итоге превратить больше ваших бесплатных пользователей в платных и создать более привлекательный продукт, который привлечет еще большую аудиторию.
Наконец, вам нужно рассмотреть маркетинг. Все эти бесплатные пользователи теперь являются поклонниками, а не противниками, и они будут действовать соответственно. Кроме того, когда придет время выпустить вашу следующую версию, все эти пользователи пройдут через ваш одобренный канал распространения, а не какой-то другой неизвестный механизм. Это означает, что для вашей следующей версии вы начнете общаться с более широкой, очень заинтересованной и поддерживающей аудиторией.
Лучшие функции, которые можно зарезервировать для профессиональной версии, - это инструменты, упрощающие корпоративное развертывание и управление. Взломщик не будет рассматривать их как достаточно вескую причину, чтобы взломать его для собственного использования, но для бизнеса, желающего купить 300 лицензий и распространить его по всей компании, это просто необходимо. Конечно, профессиональное издание все равно будет пиратским, но опять же: не переживайте, потому что вы, вероятно, не сможете продать продукт тем пиратам, что бы вы ни делали, так что это не будет стоить вам никакого дохода.
Хотя психологически может быть трудно отдать свой продукт так много, надеюсь, вы поймете, как это действительно лучший путь. Мало того, это единственный путь в долгосрочной перспективе. Я знаю, что кто-то там думает, что он не хочет делать это таким образом. В конце концов, они просто отлично продавали свой заблокированный продукт за 20 долларов в течение многих лет. Но это очень плохо, потому что, если вы не сделаете это таким образом, в конечном итоге это сделает кто-то другой. И их продукт будет таким же хорошим, как ваш, или достаточно близким, чтобы они могли с этим смириться. Внезапно ваши цены выглядят возмутительно, продажи резко падают, и вы ничего не можете сделать. Вы можете выбрать дополнительный средний уровень, если это необходимо, но вряд ли это вам поможет.
По моему опыту, усложнение взлома вашего приложения или библиотеки наносит ущерб вашим честным клиентам, в то время как лишь немного задерживает нечестных. Сконцентрируйтесь на создании отличного продукта с низким коэффициентом трения, вместо того, чтобы прикладывать немало усилий, чтобы отложить неизбежное.
Секрет, которым вы делитесь со многими людьми, не является секретом. Если у вас есть секретный материал в вашем коде, запутывание его не является защитой; это должно быть только один раз. Если у вас есть секрет, которым вы не хотите делиться со своими клиентами, не делитесь им со своими клиентами. Напишите свой код в виде веб-службы и храните свой суперсекретный код на своем собственном сервере, где только вы можете его увидеть.
Вообще говоря, есть три группы людей.
Те, кто не будет покупать ваше программное обеспечение и прибегать к взломам, или если они не найдут его, вообще не будут использовать ваше программное обеспечение. Не ждите, чтобы заработать деньги из этой группы. Они полагаются либо на свои собственные навыки, либо на взломщиков (которые, как правило, расставляют приоритеты по времени, в зависимости от того, насколько вы полезны и насколько велика ваша аудитория. Чем полезнее, тем скорее будет доступен кряк).
Группа законных пользователей, которые будут покупать (оплачивать) ваше программное обеспечение независимо от того, какой механизм защиты вы используете. Не усложняйте жизнь своим законным пользователям, используя сложный механизм защиты, поскольку они в любом случае будут платить за него. Сложный механизм защиты может легко испортить пользовательский опыт, и вы не хотите, чтобы это случилось с этой группой. Лично я бы проголосовал против любого аппаратного решения, которое увеличивает стоимость вашего программного обеспечения.
Меньшинство, которое не будет прибегать к "неэтичному" взлому и будет платить за ваше программное обеспечение, потому что его функции защищены механизмом лицензирования. Вы, вероятно, не хотите, чтобы эта группа очень легко обходила вашу защиту. Однако все ваши усилия по защите программного обеспечения окупятся, в зависимости от того, насколько велика эта группа людей. Это полностью зависит от типа программного обеспечения, которое вы создаете.
Учитывая то, что вы сказали, если вы думаете, что существует достаточно большое меньшинство, которое может быть подтолкнуто к покупке вашего программного обеспечения, продолжайте внедрять некоторую форму защиты. Подумайте о том, сколько денег вы можете заработать на этом меньшинстве в сравнении со временем, потраченным на работу по защите, или суммой, которую вы тратите на сторонний API/ инструмент защиты.
Если вы хотите реализовать собственное решение, использование криптографии с открытым ключом - хороший способ (в отличие от симметричных алгоритмов) предотвратить легкие взломы. Например, вы можете подписать свою цифровую подпись (серийный номер или файл лицензии). Единственный способ обойти это тогда - декомпилировать, изменять и перекомпилировать код (что можно усложнить, используя методы, подобные тем, которые предложены в ответе Симукала).
Вы не можете помешать людям взломать ваше программное обеспечение.
Тем не менее, вы можете заставить их создавать трещины, которые меньше повредят вашим продажам. Генераторы ключей, которые могут выдать действительный регистрационный код для вашего программного обеспечения, намного хуже, чем простые исправления, которые удаляют стимулы регистрации из вашего программного обеспечения. Это потому, что кряк будет работать только для одной версии программного обеспечения и перестанет работать со следующим выпущенным вами обновлением программного обеспечения. Генератор ключей будет продолжать работать до тех пор, пока вы не измените алгоритм регистрации ключа, и вам не стоит часто этим заниматься, потому что это оттолкнет ваших честных клиентов.
Итак, если вы ищете способ борьбы с нелегальными генераторами ключей для вашего программного обеспечения и не хотите использовать ассиметричное шифрование из-за длинных кодов регистрации, которые вы генерируете, вы можете взглянуть на Partial Key Verification.
Частичная проверка ключа гарантирует, что каждый нелегальный генератор ключей работает только для одной конкретной версии вашего программного обеспечения. По сути, вы должны убедиться, что каждый выпуск вашего программного обеспечения связан только с кодом для проверки НЕКОТОРЫХ цифр регистрационного кода. Какие цифры являются случайными, поэтому взломщикам придется перепроектировать множество различных версий вашего программного обеспечения и объединить все это в один генератор ключей, чтобы выпустить генератор ключей, который работает для всех версий вашего программного обеспечения.
Если вы выпускаете новые версии программного обеспечения на регулярной основе, это приводит к тому, что многочисленные генераторы ключей распространяются на все виды архивов пиратства программного обеспечения, которые больше не работают. Потенциальные пираты программного обеспечения обычно ищут кряк или кейген для последней версии, поэтому они, вероятно, попробуют некоторые из них и в конце концов сдадутся.
Я использовал Partial Key Verification в моих новых (C++) новых условно-бесплатных играх, и это было очень эффективно. Раньше у нас было много проблем с генераторами ключей, с которыми мы не могли бороться. После этого было много кряков и несколько генераторов ключей, которые работали только для этой конкретной версии игры, но не было генератора ключей, который работал бы со всеми версиями. Мы регулярно выпускаем очень незначительные обновления игры и делаем все ранее существующие кряки бесполезными.
Кажется, есть .NET Framework с открытым исходным кодом для частичной проверки ключа, хотя я не пробовал.
Используйте онлайн-обновление, чтобы заблокировать эти нелицензионные копии.
Проверьте серийный номер из разных модулей вашего приложения и не используйте один вызов функции для выполнения проверки (чтобы взломщики не могли легко обойти проверку).
Не только проверять серийный номер при запуске, выполнять проверку при сохранении данных, делать это каждую пятницу вечером, делать это, когда пользователь простаивает...
Проверьте контрольную сумму файла приложения, сохраните контрольную сумму в разных местах.
Не заходите слишком далеко на такие уловки, убедитесь, что ваше приложение никогда не дает сбой / сбой при проверке регистрационного кода.
Создать полезное приложение для пользователей гораздо важнее, чем сделать
небьющийся бинарный файл для взломщиков.
Вы можете..
Службы Microsoft SLP Программный потенциал InishTech позволяет защитить код без ущерба для функциональности ваших приложений.
ОБНОВЛЕНИЕ: (Раскрытие информации: я работаю на Eazfuscator.NET). Отличительной особенностью программного обеспеченияMicrosoft SLP Services является возможность виртуализации кода, так что вы определенно можете. Прошло несколько лет с тех пор, как вопрос был задан изначально; сегодня доступно больше продуктов, которые также работают на аналогичной основе, например:
Если вы хотите, чтобы люди могли выполнять ваш код (а если нет, то почему вы написали его в первую очередь?), То их ЦП должен иметь возможность выполнять ваш код. Чтобы иметь возможность выполнять код, процессор должен уметь его понимать.
Поскольку процессоры тупые, а люди нет, это означает, что люди могут понимать и код.
Есть только один способ убедиться, что ваши пользователи не получают ваш код: не передавайте им свой код.
Это может быть достигнуто двумя способами: Программное обеспечение как услуга (SaaS), то есть вы запускаете свое программное обеспечение на своем сервере и разрешаете своим пользователям только удаленный доступ к нему. Это модель, которую использует переполнение стека, например. Я уверен, что Stack Overflow не запутывает их код, но вы не можете его декомпилировать.
Другой способ - модель устройства: вместо того, чтобы предоставлять своим пользователям свой код, вы предоставляете им компьютер, содержащий код. Это модель, которую используют игровые приставки, большинство мобильных телефонов и TiVo. Обратите внимание, что это работает, только если вы "владеете" всем путем выполнения: вам нужно создать свой собственный ЦП, свой компьютер, написать свою собственную операционную систему и свою собственную реализацию CLI. Тогда и только тогда вы сможете защитить свой код. (Но учтите, что даже небольшая ошибка сделает все ваши средства защиты бесполезными. Microsoft, Apple, Sony, музыкальная индустрия и киноиндустрия могут это подтвердить.)
Или вы можете просто ничего не делать, а это означает, что ваш код будет автоматически защищен законом об авторском праве.
.NET Reflector может открывать только "управляемый код", что в основном означает "код.NET". Таким образом, вы не можете использовать его для дизассемблирования файлов COM DLL, нативного C++, классического кода Visual Basic 6.0 и т. Д. Структура скомпилированного кода.NET делает его очень удобным, переносимым, обнаруживаемым, проверяемым и т. Д. В.NET Reflector используются преимущества это позволяет вам вглядываться в скомпилированные сборки, но декомпиляторы и дизассемблеры ни в коем случае не являются специфическими для.NET и существуют до тех пор, пока существуют компиляторы.
Вы можете использовать обфускаторы, чтобы сделать код более трудным для чтения, но вы не можете точно предотвратить его декомпиляцию, не сделав его нечитаемым для.NET. Существует несколько продуктов (обычно дорогих), которые утверждают, что "связывают" ваше приложение с управляемым кодом с приложением с собственным кодом, но даже если они действительно работают, определенный человек всегда найдет способ.
Однако, когда дело доходит до запутывания, вы получаете то, за что платите. Поэтому, если ваш код настолько запатентован, что вы должны приложить немало усилий, чтобы защитить его, вы должны быть готовы вкладывать деньги в хороший обфускатор.
Однако за 15 лет своего написания кода я понял, что чрезмерная защита исходного кода - пустая трата времени и мало пользы. Попытка прочитать оригинальный исходный код без поддержки документации, комментариев и т. Д. Может быть очень трудной для понимания. Добавьте к этому бессмысленные имена переменных, которые придумывают декомпиляторы, и код спагетти, который создают современные обфускаторы - вам, вероятно, не нужно слишком беспокоиться о людях, крадущих вашу интеллектуальную собственность.
Помимо защиты покупок вы (или ваши разработчики) можете научиться защищать от копирования.
Это идеи:
Сначала попробуйте написать программу, которая записывает себя в консоль. Это известная проблема. Основная цель этой задачи - попрактиковаться в написании кода, ссылающегося на себя.
Во-вторых, вам нужно разработать технологию, которая будет переписывать некоторый код так, чтобы он зависел от CIL других методов.
Вы можете написать виртуальную машину (пока в .NET). И поместите туда немного кода. В конечном счете, виртуальная машина запускает другую виртуальную машину, которая выполняет код. Это для части редко называемых функций, чтобы не слишком сильно замедлять производительность.
Перепишите некоторую логику в C++/CLI и смешайте управляемый код с неуправляемым. Это укрепит разборку. В этом случае не забудьте также предоставить двоичные файлы x64.
Существует подробное сравнение нескольких инструментов обфускации.Net.
Скриншот взят с https://www.obfuscators.io/
Это действительно того стоит? Каждый защитный механизм может быть сломан с достаточной решимостью. Учитывайте свой рынок, цену товара, количество покупателей и т. Д.
Если вы хотите что-то более надежное, то идите по пути аппаратных ключей, но это довольно хлопотно (для пользователя) и дороже. Программные решения, вероятно, будут пустой тратой времени и ресурсов, и единственное, что они вам дадут, - это ложное чувство "безопасности".
Еще несколько идей (ни одна не идеальна, поскольку нет идеальной).
- AntiDuplicate
- Смени язык, используй приятные трюки, которые использовали авторы Skype
- Лицензионный сервер
И не тратьте на это слишком много времени, потому что взломщики имеют большой опыт работы с типичными методами и на несколько шагов впереди вас. Если вы не хотите использовать много ресурсов, возможно, поменяйте язык программирования (сделайте это в Skype).
К сожалению, от этого не убежишь. Лучше всего написать код на C и P/Invoke.
Есть небольшая загвоздка-22, кто-то может просто декомпилировать ваше приложение в CIL и уничтожить любой код проверки / активации (например, вызов вашей библиотеки C). Помните, что приложения, написанные на C, также подвергаются обратному проектированию со стороны более настойчивых хакеров (просто посмотрите, как быстро игры взламываются в наши дни). Ничто не защитит ваше приложение.
В конце концов, он работает так же, как ваш дом, защищает его достаточно хорошо, чтобы на него не затрачивалось слишком много усилий (здесь помог бы спагетти-код), и чтобы нападавший просто перешел к ближайшему соседу (соревнование:)). Посмотрите на Windows Vista, должно быть 10 различных способов взломать ее.
Существуют пакеты, которые будут зашифровывать ваш EXE-файл и расшифровывать его, когда пользователю разрешено его использовать, но, опять же, это использует универсальное решение, которое, без сомнения, было взломано.
Механизмы активации и регистрации нацелены на "среднего Джо": людей, у которых недостаточно технических знаний, чтобы обойти это (или в этом отношении знают, что они могут обойти это). Не беспокойтесь о крекерах, у них слишком много времени.
Да. Это правда. Код.NET чрезвычайно легко перепроектировать, если код не запутан.
Запутывание добавит слой раздражения людям, пытающимся перепроектировать ваше программное обеспечение. В зависимости от того, какую версию вы получите, вы получите разные уровни защиты.
Visual Studio включает в себя версию Dotfuscator. Так как это пакетная версия, вы точно не получите самое сильное запутывание. Если вы посмотрите на их списки функций, вы увидите, что именно вам не хватает (и что именно сделает приложение, чтобы сделать ваш код более безопасным).
Есть несколько других бесплатных или открытых исходных кодов.NET (но я не могу комментировать качество или различные методы, которые они используют):
В конце концов, нет ничего идеального. Если кто-то действительно хочет увидеть, как работает ваше программное обеспечение, он увидит.
Ну, вы не можете ПОЛНОСТЬЮ защитить ваш продукт от взлома, но вы можете максимизировать / повысить уровни безопасности и сделать его слишком сложным для взлома новичками и промежуточными взломщиками.
Но имейте в виду, что нет ничего взломанного, только программное обеспечение на стороне сервера хорошо защищено и не может быть взломано. В любом случае, чтобы повысить уровень безопасности в вашем приложении, вы можете сделать несколько простых шагов, чтобы не взломать "не все" взломщики ваших приложений. Эти шаги приведут в замешательство этих взломщиков и, возможно, приведут в отчаяние:
- Запутывайте ваш исходный код, очевидно, это сделает ваш исходный код беспорядочным и нечитаемым.
- Запустите несколько процедур случайной проверки внутри вашего приложения, например, каждые два часа, 24 часа, один день, неделю и т. Д. Или, возможно, после каждого действия пользователя.
- Сохраните контрольную сумму MD5 вашего выпущенного приложения на своем сервере и реализуйте процедуру, которая может проверять текущую контрольную сумму файла MD5 с реальной на стороне сервера и запускать ее случайным образом. Если контрольная сумма MD5 была изменена, это означает, что эта копия была пиратской. Теперь вы можете просто заблокировать его или выпустить обновление, чтобы заблокировать его и т. Д.
- Попробуйте создать подпрограмму, которая может проверить, действительно ли некоторые ваши коды (функции, классы или определенные подпрограммы) были изменены или изменены или даже удалены. Я называю это (проверка целостности кода).
- Используйте бесплатные неизвестные упаковщики для упаковки вашего приложения. Или, если у вас есть деньги, выберите коммерческие решения, такие как Thamida или .NET Reactor. Эти приложения регулярно обновляются, и как только взломщик распаковывает ваше приложение, вы можете просто получить новое обновление от этих компаний, и как только вы получите новое обновление, вы просто упаковываете свою программу и выпускаете новое обновление.
- Регулярно выпускайте обновления и заставляйте своих клиентов загружать последние обновления.
- Наконец, сделайте ваше приложение очень дешевым. Не делай это слишком дорогим. Поверьте, вы получите больше довольных клиентов, а взломщики просто оставят ваше приложение, потому что не стоит тратить время на взлом очень дешевого приложения.
Это всего лишь простые способы предотвратить взлом вашего приложения новичками и промежуточными взломщиками. Если у вас есть больше идей для защиты вашего приложения, просто не стесняйтесь их реализовывать. Это просто усложнит жизнь взломщикам, и они будут разочарованы, и в конечном итоге они покинут ваше приложение, потому что это просто не стоит их времени.
Наконец, вы также должны подумать о том, чтобы тратить время на написание хороших и качественных приложений. Не тратьте свое время на кодирование сложных уровней безопасности. Если хороший взломщик хочет взломать ваше приложение, он / она будет делать, что бы вы ни делали...
А теперь иди и реализуй игрушки для крекеров...
Если Microsoft сможет найти решение, у нас не будет пиратских версий Windows, поэтому нет ничего особо безопасного. Вот несколько похожих вопросов из Stack Overflow, и вы можете реализовать свой собственный способ их защиты. Если вы выпускаете разные версии, вы можете использовать разные методы для разных версий, так что к тому времени, когда первая будет взломана, вторая может вступить во владение.
Есть Salamander, который является собственным компилятором.NET и компоновщиком от Remotesoft, который может развертывать приложения без.NET Framework. Я не знаю, насколько хорошо это соответствует его требованиям.
Обновить
Джаред отметил, что de4dot утверждает, что может его декомпилировать.
.NET Reactor обеспечивает полную защиту вашей чувствительной интеллектуальной собственности путем преобразования ваших сборок.NET в неуправляемые процессы, которые не могут быть поняты как CIL, и которые ни один из существующих инструментов не может декомпилировать. Хакеры не имеют доступа к любой понятной форме вашего источника.
Мощные и гибкие функции лицензирования.NET Reactor позволяют обеспечить соблюдение условий лицензии и защитить поток доходов с помощью аппаратных и программных блокировок. Менеджер лицензий может создать пробные или постоянные лицензии за считанные секунды. Полностью документированный набор средств разработки программного обеспечения (SDK), в комплекте с примерами, позволяет вызывать систему лицензирования непосредственно из вашего кода, позволяя создавать собственные расширения для системы лицензирования.
Вот одна из идей: у вас может быть сервер, размещенный вашей компанией, к которому должны подключаться все экземпляры вашего программного обеспечения. Недостаточно просто подключить их и проверить регистрационный ключ - они просто уберут чек. В дополнение к проверке ключа необходимо также, чтобы сервер выполнял некоторые важные задачи, которые клиент не может выполнить сам, поэтому его невозможно удалить. Это, конечно, вероятно, будет означать много тяжелой обработки со стороны вашего сервера, но это будет затруднять кражу вашего программного обеспечения, и если у вас есть хорошая схема ключей (проверка владения и т. Д.), Ключи также будет трудно украсть. Это, вероятно, более инвазивно, чем вы хотите, так как это потребует подключения ваших пользователей к Интернету для использования вашего программного обеспечения.
Все, что работает на клиенте, может быть декомпилировано и взломано. Обфусификация только усложняет. Я не знаю ваше заявление, но 99% времени я просто не думаю, что оно того стоит.
Честно говоря, иногда нам нужно запутывать код (например, регистрировать классы лицензий и так далее). В этом случае ваш проект не является бесплатным. ИМО, ты должен заплатить за хороший обфукатор.
Dotfuscator скрывает ваш код, а .NET Reflector выдает ошибку при попытке его декомпиляции.
Я также сделал некоторые соображения относительно взлома безопасности в своем дизайне и хочу добавить их, так как некоторые из них, кажется, не упоминаются:
У меня есть интерфейс сценариев в моем приложении. Чтобы гарантировать, что сценарии могут вызывать только те методы, которые предназначены для вызова (python)-скриптами, у меня есть атрибут scriptvisibilityattribute и System.Dynamic.DynamicMetaObjectProvider, который распознает эти атрибуты.
Лицензии используют открытый / закрытый ключ.
ViewModels необходимо разблокировать, предоставив пароль для функции разблокировки.
CoreRoutines могут быть реализованы на ключе. (Есть ключи, которые поддерживают это)
Большое решение, как обертки не было запланировано.
Конечно, это приложение для работы со скриптами /viewModel не делает невозможным разблокирование и вызов невидимых в скрипте функций из кода, но это делает его немного более сложным - как и все, что связано с анти-хакерскими усилиями.
Если он написан на.NET и скомпилирован в CIL, это может быть отражено. Если безопасность является проблемой, и следует избегать запутывания, то я рекомендую написать ваше приложение с использованием неуправляемого языка, который по своей природе труднее реконструировать.
Имейте в виду, что более 99% ваших пользователей не будут заинтересованы в изучении вашего исполняемого файла, чтобы увидеть, как он работает.
Учитывая, что очень немногие люди даже потрудятся попробовать и что с большинством обфускаторов можно обойтись, стоит ли это вашего времени и усилий?
Вы бы лучше потратили время на улучшение своего продукта, чтобы больше людей захотело им пользоваться.
Как убедиться, что приложение не подделано, и как убедиться, что механизм регистрации не может быть реверс-инжиниринг.
Оба имеют один и тот же очень простой ответ: не передавайте объектный код ненадежным сторонам, таким как (очевидно) вашим клиентам. Возможно ли разместить приложение на ваших машинах, зависит только от того, что оно делает.
Если это не веб-приложение, возможно, вы можете разрешить вход в SSH с пересылкой X на сервер приложений (или, как мне кажется, для подключения к удаленному рабочему столу для Windows).
Если вы дадите объектный код людям типа "всезнайка", и они думают, что ваша программа может быть забавной, она будет взломана. Обойти это невозможно.
Если вы мне не верите, обратите внимание на громкое приложение, которое не было взломано и пиратским.
Если вы используете аппаратные ключи, это сделает производство более дорогим, и ваши пользователи будут ненавидеть вас за это. Это настоящая сука, ползущая по полу, подключающая и отключающая ваши 27 разных USB-штучек, потому что производители программного обеспечения не доверяют вам (я полагаю).
Существуют пакеты, которые будут шифровать ваш EXE-файл и расшифровывать его, когда пользователю разрешено его использовать.
Конечно, можно обойти тест "can-I-use-it", чтобы он всегда возвращал значение true.
Гадкий трюк может состоять в том, чтобы использовать байтовые значения кодов операций, которые выполняют тест где-то еще в программе, грязным способом, который приведет к аварийному завершению программы, если только это значение не является правильным. Это делает вас связанным с конкретной архитектурой, хотя:-(
Когда дело доходит до.NET, если вы выпускаете приложение Windows Forms (или любое приложение, в котором у клиента есть файл Portable Executable), оно может быть взломано.
Если вы хотите придерживаться.NET и минимизировать вероятность получения исходного кода, то вы можете рассмотреть возможность его развертывания в качестве приложения ASP.NET на веб-сервере вместо создания приложения Windows Forms.
Просто добавьте предупреждение: если вы собираетесь использовать обфускацию, проверьте, что все еще работает! Запутывание может изменить такие вещи, как имена классов и методов. Поэтому, если вы используете рефлексию для вызова определенных методов и / или классов (как в плагин-архитектуре), ваше приложение может потерпеть неудачу после запутывания. Также трассировки стека могут быть бесполезны для отслеживания ошибок.