Защищать .NET код от обратного инжиниринга?

Вы не можете.

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

То, что вы хотите сделать, - это просто сделать его достаточно сложным для взлома, чтобы это не стоило проблем людей.

Некоторые предложения, которые я могу вам помочь защитить ваше приложение:

• Obfuscate ваш код. Dotfuscator имеет бесплатную версию и поставляется с Visual Studio.
• Используйте общедоступный/закрытый ключ или асимметричное шифрование для создания ваших лицензий на продукт. Это гарантирует, что вы сможете генерировать свои коды лицензий. Даже если ваше приложение взломан, вы можете быть уверены, что они не выпустят генератор ключей для вашего приложения, потому что невозможно изменить алгоритм генерации ключей.
• Используйте сторонний упаковщик, чтобы упаковать исполняемый файл .NET в зашифрованное приложение оболочки Win32. Themida является одним из лучших. Это препятствует тому, чтобы люди отражали ваше приложение в .NET Reflector и заставляли больно распаковывать реверсирование.
• Напишите свой собственный пользовательский пакетер. Если сторонние упаковщики стоят слишком дорого, подумайте о том, чтобы написать свой собственный. Иногда пользовательские упаковщики могут быть очень эффективными, потому что не существует хорошо опубликованных методов их распаковки. Учебник Как написать собственный упаковщик дает массу полезной информации о написании собственного пакета Win32.

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

Опытный инженер-разведчик может запустить IDA-Pro и нарезать ваше приложение, как масло, независимо от того, что вы делаете. Упакованное приложение может быть распаковано, и обфускация только предотвращает его прогулку в парке. Вся ваша сложная работа с вашим сложным лицензионным кодом может быть отменена с помощью одного байтового патча.

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

Тем не менее, существует множество компаний, которые никогда не рискуют получить иск и с удовольствием покупают лицензии на программное обеспечение и многие компьютерные пользователи, которые либо не хотят рисковать, либо ошибаются, либо недостаточно разбираются в технике, чтобы пиратствовать. Это ваши настоящие клиенты, и вы должны сосредоточить свои усилия на предоставлении им хорошего пользовательского опыта и игнорировать людей, взламывающих ваше программное обеспечение.

У меня раньше было мое пиратство, и я воспринял это как личное оскорбление. Здесь я был маленьким разработчиком, вливая свое сердце и душу в приложение, и эти люди галлу пираты от меня?! Они брали деньги прямо из моего кармана!

Я сразу же добавил в кучу драконовского кода DRM и попытался саботировать любого человека, использующего незаконную или взломанную копию. Я должен был, конечно, работать над тем, чтобы сделать мое приложение лучше, вместо того, чтобы пытаться остановить неизбежное. Не только это, но я причинял боль моим истинным клиентам все эти дополнительные меры защиты, которые я вводил.

После долгой битвы я понял, что сражаюсь с приливами, и все это время было напрасно. Я достал весь телефонный код, кроме лицензионных функций barebone и никогда не оглядывался назад.

Вы не можете полностью защитить любое приложение (управляемое или нет). Если такие системы, как Playstation и iPad, могут быть взломаны -— где поставщик даже контролирует аппаратное обеспечение; какая надежда у вашего приложения? К счастью, вы действительно этого не хотите. На мой взгляд, вам нужно защитить ваше приложение настолько, что кто-то не может случайно пиратствовать с вашим продуктом, и не более того.

Например, если вы используете лицензию для каждого компьютера, она не должна работать только при ее установке на новой второй машине. Вам нужно хорошее сообщение об ошибке, чтобы предотвратить дополнительные вызовы поддержки, но не трать лишнее время, чтобы сделать его слишком трудным для работы и не поражать пользователей по голове.

Другим примером является ограниченное время. Даже не беспокойтесь о простых вещах, например, если пользователи могут просто откатить системные часы. Кто-то, кто это знает, знает, что они нарушают вашу лицензию, и до тех пор, пока пользователь знает, когда они находятся в нарушении, вы сделали достаточно.

Вам нужно сделать это, потому что пользователи не заботятся о вашей лицензии. Лицензии составляют вещи, которые никто не заботится, пока им не понадобится. Никто их не читает, и им действительно не нужно. Поэтому лучший способ рассказать пользователю, где находятся границы, - это то, что поведение готового приложения для вашего приложения соответствует лицензии. В этом первом случае это означает либо неспособность установить или установить в режиме пробной версии второй раз. Для последнего это может означать проверку даты простого текста в файле конфигурации. В любом случае, убедитесь, что вы справляетесь с этим элегантным, полезным и уважительным образом.

Итак, это объясняет, что значит делать именно так. Но почему бы не пойти дальше? Почему бы не подключить каждую маленькую дыру, которую вы можете найти? Ответ состоит из двух частей. Во-первых, если кто-то преодолеет этический порог сознательного нарушения ваших условий лицензии -— даже простым способом; они также захотят сделать что-то более сложное или опасное, например, вытащить приложение из torrent site — и существует определенная опасность, связанная с запуском приложений, загруженных из ненадежных источников. Сделать его труднее всего лишь незначительное раздражение для этих пользователей и риски, которые вызывают проблемы с вашими платящими клиентами. Простота в использовании может помешать кому-то копаться в вашем приложении и высвободить более полную трещину. Во-вторых, у вас мало доступных глаз, чтобы искать недостатки; у хакеров много, и у них больше практическая находка. Вам нужно только пропустить один маленький недостаток, и ваше приложение будет иметь одинаковое распространение на сайтах пиратов, как будто вы ничего не сделали. Вы должны быть правы каждый раз; им нужно только однажды повезти. Таким образом, требуемые усилия очень высоки, и вероятность любой степени успеха очень низкая.

В конечном счете, если кто-то хочет пиратствовать ваше приложение (а не просто использовать его), и это их главная цель. Там вы ничего не можете сделать, чтобы остановить их. Это характер программного обеспечения; как только файлы, составляющие ваш продукт, находятся на компьютере пользователя, они смогут делать с ними по своему усмотрению. Это особенно актуально в управляемых средах, таких как Java или .NET, но это определенно относится и к собственному коду. Время на их стороне, и при достаточном количестве времени любая цифровая безопасность может быть нарушена.

Поскольку вы не можете запретить пользователям пиратство вашего продукта, ваш лучший способ действий состоит в том, чтобы вовлечь этого класса пользователя в то, как он использует их в ваших интересах. Часто можно заставить их работать на вас, а не против вас. Имея это в виду, независимо от вашего приложения, вероятно, стоит сохранить бесплатную версию, которая почти полностью функциональна и не истекает. Разница между ценой и ценой за 1 доллар США огромна, если только по той причине, что клиент не должен доверять вам свою кредитную карту. Бесплатная версия вашего продукта не только эффективно уничтожит пиратское распространение (зачем рисковать пиратской версией, когда вы можете быть легитимной по той же цене?), Она может значительно расширить вашу аудиторию.

В результате вам может потребоваться увеличить цену выпуска для оплаты, так что в итоге вместо 2000 пользователей по 20 долларов США у вас будет 100 000 бесплатных пользователей, из которых 500 готовы заплатить 99 долларов за "профессионального" издания. Это дает вам больше денег, чем если бы вы потратили кучу времени на блокировку своего продукта. Более того, вы можете привлекать этих свободных пользователей и использовать отношения несколькими важными способами.

Один из них - поддержка. Пессимист воспользовался этой возможностью, чтобы пожаловаться на увеличение стоимости поддержки 100 000 бесплатных пользователей, но вместо этого происходит нечто удивительное: ваш продукт становится в значительной степени самоподдерживающимся. Вы видите это все время с большими проектами с открытым исходным кодом, у которых нет денег на поддержку. Пользователи будут активизироваться и сделать это.

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

Другим является обратная связь. Наблюдая за своим форумом, вы узнаете важные идеи по улучшению, которые вы, возможно, никогда не рассматривали иначе. Это позволит вам в конечном итоге превратить ваших бесплатных пользователей в платных пользователей и создать более привлекательный продукт, который привлечет еще большую аудиторию.

Наконец, вам нужно рассмотреть маркетинг. Все эти бесплатные пользователи теперь болельщики, а не противники, и они будут действовать соответственно. Не только это, но когда придет время выпустить следующую версию, эти пользователи пройдут через ваш одобренный канал распространения, а не какой-то другой неизвестный механизм. Это означает, что для вашей следующей версии вы начинаете общаться с более широкой, заинтересованной и поддерживающей аудиторией.

Лучшие возможности для профессионального издания - это инструменты, направленные на упрощение корпоративного развертывания и управления. Взломщик не будет рассматривать их как достаточно убедительные причины, чтобы взломать его для собственного использования, но для бизнеса, желающего купить 300 лицензий и вытолкнуть его в масштабах всей компании, это необходимо. Конечно, профессиональное издание будет пиратским в любом случае, но опять же: не потейте, потому что вы, вероятно, не сможете продать продукт этим пиратам, независимо от того, что вы сделали, чтобы он не стоил вам никакого дохода.

В психологическом отношении это может быть трудно отдать вашему продукту, надеюсь, вы поймете, как это действительно лучший способ. Не только это, это единственный способ пойти в долгосрочной перспективе. Я знаю, что кто-то там думает, что они не хотят этого делать. В конце концов, у них просто прекрасная продажа их запертого продукта стоимостью 20 долларов в течение многих лет. Но это слишком плохо, потому что, если вы этого не сделаете, в конце концов кто-то еще будет. И их продукт будет таким же хорошим, как ваш, или достаточно близко, и они могут убежать от этого. Тогда внезапно ваши цены выглядят возмутительно, продажи резко падают, и вы больше ничего не можете сделать. Вы можете выбрать дополнительный средний уровень, если хотите, но вряд ли вам помогут.

По моему опыту, затруднять взломать ваше приложение или библиотеку, причиняет боль вашим честным клиентам, лишь слегка откладывая нечестные. Сосредоточьтесь на создании отличного продукта с низким коэффициентом трения вместо того, чтобы приложить немало усилий для отсрочки неизбежного.

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

Вообще говоря, есть три группы людей.

• Те, кто не купит ваше программное обеспечение и не прибегнет к трещинам, или, если они их не найдут, вообще не используют ваше программное обеспечение. Не ждите от вас каких-либо денег от этой группы. Они полагаются либо на собственные навыки, либо на взломщики (которые склонны уделять приоритетное внимание своему времени в зависимости от вашего полезного и насколько велика ваша аудитория. Чем полезнее, тем скорее будет трещина).

• Группа законных пользователей, которые будут покупать (оплачивать) ваше программное обеспечение, независимо от того, какой механизм защиты вы используете. Не делайте жизнь трудной для ваших законных пользователей, используя сложный механизм защиты, поскольку они будут платить за нее в любом случае. Сложный механизм защиты может легко испортить работу пользователя, и вы не хотите, чтобы это происходило с этой группой. Лично я проголосовал против любого аппаратного решения, которое добавляет к стоимости вашего программного обеспечения.

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

Учитывая то, что вы сказали, если вы считаете, что существует достаточно большое количество меньшинств, которые могут быть вовлечены в покупку вашего программного обеспечения, продолжайте и реализуйте некоторую форму защиты. Подумайте о том, сколько денег вы можете получить от этого меньшинства по сравнению с тем временем, которое вы потратили на защиту, или на сумму, которую вы тратите на сторонний API/инструмент защиты.

Если вы хотите реализовать собственное решение, использование криптографии с открытым ключом - это хороший способ (в отличие от симметричных алгоритмов), чтобы предотвратить легкие хаки. Например, вы можете подписать цифровую лицензию (серийный номер или файл лицензии). Единственным способом обойти это было бы декомпилировать, изменить и перекомпилировать код (который вы могли бы усложнять с помощью техник, которые были предложены в ответе Simucal).

Вы не можете помешать людям взломать ваше программное обеспечение.

Однако вы можете заставить их создавать трещины, которые могут повредить ваши продажи. Keygenerators, которые могут выдавать действительный регистрационный код для вашего программного обеспечения, намного хуже, чем простые исправления, которые устраняют стимулы регистрации от вашего программного обеспечения. Это связано с тем, что трещина будет работать только для одной версии программного обеспечения и перестанет работать со следующим выпуском программного обеспечения, которое вы выпустили. Keygenerator будет продолжать работать до тех пор, пока вы не измените алгоритм регистрационного ключа и что вы не хотите делать часто, потому что это отложит ваших честных клиентов.

Итак, если вы ищете метод борьбы с нелегальными ключевыми генераторами для своего программного обеспечения, и вы не хотите использовать ассиметричное шифрование из-за длинных регистрационных кодов, которые это генерирует, вы можете взглянуть на проверку частичного ключа.

Проверка частичного ключа гарантирует, что каждый незаконный keygenerator работает только для одной конкретной версии вашего программного обеспечения. В основном, что вы делаете, убедитесь, что каждая версия вашего программного обеспечения связана только с кодом для проверки НЕКОТОРЫХ цифр регистрационного кода. Какие цифры являются случайными, поэтому взломщики должны были бы перепрограммировать много разных версий вашего программного обеспечения и объединить все это в один keygenerator, чтобы освободить keygenerator, который работает для всех версий вашего программного обеспечения.

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

Я использовал проверку частичного ключа в моих (С++) более новых бесплатных играх, и это было очень эффективно. Раньше у нас было много проблем с ключевыми генераторами, с которыми мы не могли бороться. После этого было много трещин и несколько ключевых генераторов, которые работали только для этой конкретной версии игры, но не использовали генератор ключей, который работал бы со всеми версиями. Мы регулярно выпускаем очень незначительные обновления игры и делаем все ранее существовавшие трещины бесполезными.

Кажется, что с открытым исходным кодом .NET framework для проверки частичного ключа, хотя я этого не пробовал.

• Используйте онлайн-обновление, чтобы заблокировать эти нелицензированные копии.

• Проверьте серийный номер из разных модулей вашего приложения и не используйте один вызов функции для выполнения проверки (чтобы крекеры не могли легко обходить проверку).

• Не только проверить серийный номер на запуск, выполните проверку, пока экономя данные, делайте это каждую пятницу вечером, сделайте это, когда пользователь простаивает ...

• Проверка проверки файла приложения сумму, сохраните сумму проверки безопасности в в разных местах.

• Не заходите слишком далеко на этот вид трюки, убедитесь, что ваше приложение никогда не сбой/попадание в неисправность проверяя регистрационный код.

• Создайте полезное приложение для пользователей. гораздо важнее, чем сделать нерушимый бинарный файл для взломщиков.

Вы можете..

Службы Microsoft SLP Потенциал программного обеспечения InishTech позволяет защитить код без ущерба для функциональности ваших приложений.

ОБНОВЛЕНИЕ: (Раскрытие информации: я работаю над Eazfuscator.NET) Что делает Microsoft SLP Services Потенциал ПО по-разному - это способность виртуализировать код, поэтому вы определенно можете. Прошло несколько лет с тех пор, как вопрос был изначально задан; сегодня есть больше доступных продуктов, которые также работают на аналогичной основе, например:

• Agile.NET
• Eazfuscator.NET

.NET Reflector может открывать только "управляемый код", который в основном означает ".NET-код". Таким образом, вы не можете использовать его для дизассемблирования COM файлов DLL, собственного С++, классического Visual Basic 6.0 и т.д. Структура скомпилированного .NET код делает его очень удобным, переносимым, доступным для обнаружения, проверяемым и т.д..NET Reflector использует это для того, чтобы вы могли сверяться с компилируемыми сборками, но декомпиляторы и дизассемблеры никоим образом не являются специфичными для .NET, и они были до тех пор, пока компиляторы были вокруг.

Вы можете использовать obfuscators, чтобы сделать код более трудным для чтения, но вы не можете точно предотвратить его декомпиляцию, не делая его также нечитаемым для .NET. Есть несколько продуктов там (обычно дорого), которые утверждают, что "связывают" ваше управляемое приложение кода с приложением собственного кода, но даже если они действительно работают, определенный человек всегда найдет способ.

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

Однако в течение примерно 15 лет опыта написания кода я понял, что чрезмерная защита вашего исходного кода является пустой тратой времени и имеет небольшую выгоду. Просто попытка прочитать исходный код без поддержки документации, комментариев и т.д. Может быть очень трудно понять. Добавьте к этому бессмысленные переменные, имена которых появляются в декомпиляторах, и код спагетти, который создаются современными обфускаторами - вам, вероятно, не нужно слишком беспокоиться о том, что люди крадут вашу интеллектуальную собственность.

Если вы хотите, чтобы люди могли запускать ваш код (а если нет, то зачем вы его пишете в первую очередь?), то их процессор должен иметь возможность выполнять ваш код. Чтобы иметь возможность выполнять код, ЦП должен уметь это понимать.

Поскольку ЦП немыслимы, а люди - нет, это означает, что люди также могут понимать код.

Есть только один способ убедиться, что ваши пользователи не получают ваш код: не указывайте им свой код.

Это может быть достигнуто двумя способами: Программное обеспечение как услуга (SaaS), то есть вы запускаете свое программное обеспечение на своем сервере и только пусть ваши пользователи получают доступ к нему удаленно. Это модель, которую использует Stack Overflow. Я уверен, что Qaru не обфускает их код, но вы не можете декомпилировать его.

Другим способом является модель устройства: вместо предоставления вашим пользователям кода вы даете им компьютер, содержащий код. Это модель, в которой используются игровые консоли, большинство мобильных телефонов и TiVo. Обратите внимание, что это работает только в том случае, если вы "владеете" целым пути выполнения: вам нужно создать собственный процессор, свой собственный компьютер, написать свою собственную операционную систему и свой собственный CLI. Тогда и только тогда вы сможете защитить свой код. (Но обратите внимание, что даже самая маленькая ошибка сделает все ваши защиты бесполезными. Microsoft, Apple, Sony, музыкальная индустрия и киноиндустрия могут подтвердить это.)

Или вы можете просто ничего не делать, а это значит, что ваш код будет автоматически защищен законом об авторских правах.

Помимо защиты от покупок, вы (или ваши разработчики) можете научиться защищать копии.

Это идеи:

Сначала попробуйте написать программу, которая записывает себя на консоль. Это известная проблема. Первичной целью этой задачи является практика написания самореферентного кода.

Во-вторых, вам нужно разработать технологию, которая будет переписывать некоторый код таким образом зависит от других методов CIL.

Вы можете написать виртуальную машину (еще в .NET). И поставьте там код. В конечном счете, виртуальная машина запускает другую виртуальную машину, которая запускает код. Это для части редко называемых функций, чтобы не слишком замедлять работу.

Перепишите некоторую логику в С++/CLI и смешайте управляемый код с неуправляемым. Это упростит разборку. В этом случае не забудьте также предоставить x64.

Это действительно стоит? Каждый механизм защиты может быть разбит с достаточным определением. Рассмотрите свой рынок, цену продукта, количество клиентов и т.д.

Если вы хотите что-то более надежное, то идите по пути аппаратных клавиш, но это довольно хлопотно (для пользователя) и дороже. Программные решения, вероятно, были бы пустой тратой времени и ресурсов, и единственное, что они вам дадут, - ложное чувство "безопасности".

Немногие идеи (ни один не совершенен, поскольку нет идеального).

• AntiDuplicate
• Измените язык, используйте приятные трюки, которые использовали авторы Skype
• Сервер лицензий

И не тратьте слишком много времени на это, потому что крекеры имеют большой опыт работы с типичными приемами и на несколько шагов впереди вас. Если вы не хотите использовать много ресурсов, возможно, измените язык программирования (сделайте это способом Skype).

К сожалению, вы не собираетесь убежать от этого. Лучше всего написать код на C и P/Invoke it.

Есть небольшой catch-22, кто-то может просто декомпилировать ваше приложение в CIL и убить любой код проверки/активации (например, вызов вашей библиотеки C). Помните, что приложения, написанные на C, также реконструируются более стойкими хакерами (просто посмотрите, как быстро игры треснуты в эти дни). Ничто не защитит ваше приложение.

В конце концов, он очень похож на ваш дом, защищает его достаточно хорошо, так что это слишком много усилий (здесь может помочь код спагетти) и чтобы нападавший просто перешел на соседнюю соседку (конкурс:)). Посмотрите на Windows Vista. Должно быть 10 различных способов взломать ее.

Там есть пакеты, которые будут шифровать ваш EXE файл и расшифровать его, когда пользователю будет разрешено его использовать, но еще раз, что использует универсальное решение, которое, без сомнения, было взломанным.

Механизмы активации и регистрации нацелены на "среднего Джо": люди, у которых недостаточно технических навыков, чтобы обойти его (или, если известно, они могут обойти его). Не беспокойтесь о крекеры, у них слишком много времени на руках.

Да. Это правда..NET-код чрезвычайно прост в обратном проектировании, если код не запутался.

Obfuscation добавит слой раздражения людям, пытающимся перепроектировать ваше программное обеспечение. В зависимости от того, какую версию вы получите, вы получите различные уровни защиты.

Visual Studio включает версию Dotfuscator. Так как это комплектная версия, вы определенно не получаете самую сильную обфускацию. Если вы посмотрите на их списки функций, вы увидите, что именно вам не хватает (и точно, что приложение сделает, чтобы сделать ваш код более безопасным).

Есть несколько других бесплатных или открытых объектов .NET obfuscators (но я не могу прокомментировать качество или различные методы, которые они используют):

• Obfuscar
• Babel.NET

В конце концов, ничего не идеально. Если кто-то действительно хочет посмотреть, как работает ваше программное обеспечение, они будут.

Ну, вы не можете ПОЛНОСТЬЮ защитить ваш продукт от взлома, но вы можете максимизировать/улучшать уровни безопасности и сделать его немного сложнее, чтобы его потревожили новички и промежуточные крекеры.

Но имейте в виду, что ничего не пропадает, только программное обеспечение на стороне сервера хорошо защищено и не может быть взломан. Во всяком случае, чтобы повысить уровень безопасности в вашем приложении, вы можете сделать несколько простых шагов, чтобы предотвратить взлома некоторых взломанных "не всех" от взлома ваших приложений. Эти шаги заставят этих крекеров сходить с ума и, возможно, отчаяться:

• Обфускайте исходный код, очевидно, это заставит ваш исходный код выглядеть беспорядочным и нечитаемым.
• Запускайте несколько случайных процедур проверки внутри вашего приложения, как каждые два часа, 24 часа, один день, неделю и т.д. или, возможно, после каждого действия, которое пользователь выполняет.
• Сохраните опубликованную заявку MD5 на вашем сервере и выполните процедуру, которая может проверять текущую контрольную сумму MD5 с реальной на стороне сервера и сделать его случайным образом запущенным. Если контрольная сумма MD5 была изменена, это означает, что эта копия была пиратской. Теперь вы можете просто заблокировать его или опубликовать обновление, чтобы заблокировать его и т.д.
• Попробуйте сделать процедуру, которая может проверить, действительно ли некоторые из ваших кодов (функции, классы или конкретные процедуры) были изменены или изменены или удалены. Я называю это (проверка целостности кода).
• Используйте бесплатные неизвестные упаковщики для упаковки вашего приложения. Или, если у вас есть деньги, займитесь коммерческими решениями, такими как Thamida или .NET Reactor. Эти приложения регулярно обновляются, и как только взломщик распаковывает ваше приложение, вы можете просто получить новое обновление от этих компаний, и как только вы получите новое обновление, вы просто упакуете свою программу и опубликуете новое обновление.
• Регулярно публикуйте обновления и принудительно загружайте последнее обновление.
• Наконец, сделайте свое приложение очень дешевым. Не делайте это слишком дорого. Поверьте мне, вы получите больше счастливых клиентов, и крекеры просто оставят ваше выражение, потому что не стоит тратить время на очень дешевое приложение.

Это простые методы предотвращения взлома новичков и промежуточных крекеров от взлома вашего приложения. Если у вас больше идей для защиты вашего приложения, не стесняйтесь их реализовать. Это просто заставит крекеров жить тяжело, и они расстроятся, и в конечном итоге они оставят ваше выражение, потому что это просто не стоит их времени.

Наконец, вам также нужно подумать о том, чтобы тратить время на кодирование хороших и качественных приложений. Не тратьте время на кодирование сложных уровней безопасности. Если хороший взломщик хочет взломать ваше приложение, он/она будет делать независимо от того, что вы делаете...

Теперь идите и реализуйте игрушки для крекеров...

Если Microsoft может придумать решение, у нас не будет пиратских версий Windows, поэтому ничего не будет безопасно. Вот несколько подобных вопросов из Stack Overflow, и вы можете реализовать свой собственный способ их защиты. Если вы выпускаете разные версии, вы можете использовать различные методы для разных версий, поэтому к тому времени, когда первый треснут, второй может взять верх.

• Управление функциями на основе лицензии для приложения на С++

• Защитите DLL файл с помощью файла лицензии

• Программное обеспечение для лицензирования/защиты?

Там Salamander, который является родным компилятором .NET и компоновщиком от Remotesoft, который может развернуть приложения без платформы .NET. Я не знаю, насколько хорошо он оправдывает свои претензии.

.NET Reactor

Обновление

Джаред отметил, что de4dot утверждает, что может декомпилировать его.

.NET Reactor обеспечивает полную защиту вашей интеллектуальной интеллектуальной собственности путем преобразования ваших сборников .NET в неуправляемые процессы, которые нельзя понять как CIL, и которые ни один из существующих инструментов не может декомпилировать. Хакеры не имеют доступа к какой-либо понятной форме вашего источника.

Мощные и гибкие функции лицензирования .NET Reactor позволяют выполнять условия лицензии и защищать свой поток доходов с помощью аппаратных и программных блокировок. Менеджер лицензий может создавать пробные или постоянные лицензии в считанные секунды. Полностью документированный комплект разработки программного обеспечения (SDK), в комплекте с примерами, позволяет вам вызывать систему лицензирования непосредственно из вашего кода, что позволяет создавать пользовательские расширения для системы лицензирования.

Вот одна идея: у вас может быть сервер, организованный вашей компанией, с которым нужно подключать все экземпляры вашего программного обеспечения. Простое подключение и проверка регистрационного ключа недостаточны - они просто удаляют чек. В дополнение к проверке ключа вам также необходимо, чтобы сервер выполнял некоторые важные задачи, которые клиент не может выполнить сам, поэтому его невозможно удалить. Конечно, это, вероятно, означало бы большую интенсивную обработку со стороны вашего сервера, но это затрудняло бы кражу вашего программного обеспечения и предполагало бы, что у вас есть хорошая ключевая схема (проверить право собственности и т.д.), Ключи также будут трудно украсть. Это, вероятно, более инвазивное, чем вы хотите, поскольку для использования вашего программного обеспечения ваши пользователи будут подключены к Интернету.

Все, что работает на клиенте, может быть декомпилировано и взломан. Обфуфилизация просто усложняет ситуацию. Я не знаю вашего приложения, но в 99% случаев я просто не думаю, что это стоит усилий.

Обфускайте код! Существует пример в Obfuscating С# Code.

Просто добавьте предупреждение: если вы собираетесь использовать обфускацию, убедитесь, что все еще работает! Обфускация может изменить такие вещи, как имена классов и методов. Поэтому, если вы используете рефлексию для вызова определенных методов и/или классов (например, в плагиновой архитектуре), ваше приложение может выйти из строя после обфускации. Кроме того, stacktraces могут оказаться бесполезными для отслеживания ошибок.

Имейте в виду, что 99% + ваших пользователей не будут заинтересованы в изучении вашего исполняемого файла, чтобы узнать, как он работает.

Учитывая, что так мало людей даже собираются потрудиться, и что большинство обфускаторов можно обойти, стоит ли вам тратить время и силы?

Вам лучше инвестировать время в улучшение вашего продукта, чтобы больше людей хотели его использовать.

Я могу порекомендовать использовать Obfuscator.

Честно говоря, иногда нам нужно запутывать код (например, регистрировать классы лицензий и т.д.). В этом случае ваш проект не является бесплатным. ИМО, вы должны заплатить за хороший обфукатор.

Dotfuscator скрывает ваш код и .NET Reflector показывает ошибку при попытке декомпилировать ее.

Когда дело доходит до .NET, если вы выпускаете приложение Windows Forms (или любое приложение, в котором клиент имеет Portable Executable файл), он может быть взломан.

Если вы хотите придерживаться .NET и хотите свести к минимуму вероятность получить исходный код, то вы можете рассмотреть возможность его развертывания как ASP.NET через веб-сервер вместо того, чтобы делать это приложение Windows Forms.

Невозможно полностью защитить приложение, извините.

Просто сделайте хорошее приложение и закодируйте простую систему защиты. Неважно, какая защита вы выберете, она будет отменена... Поэтому не тратьте слишком много времени/денег.

Как убедиться, что приложение не подделано, и как убедиться, что механизм регистрации не может быть реконструирован.

Оба имеют тот же самый простой ответ: не передавайте объектный код ненадежным сторонам, например (видимо) вашим клиентам. Является ли это возможным для размещения приложения на ваших машинах, зависит только от того, что он делает.

Если это не веб-приложение, возможно, вы можете разрешить SSH с X переадресацией на сервер приложений (или Подключение к удаленному рабочему столу, я думаю, для Windows).

Если вы укажете объектный код для людей с жестким типом, и они считают, что ваша программа может быть забавной для взлома, она будет взломана. Никоим образом не вокруг.

Если вы мне не верите, укажите громкое приложение, которое не было взломанным и пиратским.

Если вы идете с аппаратными клавишами, это сделает производство дороже, и ваши пользователи будут ненавидеть вас за это. Это настоящая сука, которая ползает по полу, подключая и отключая 27 разных USB-устройств, потому что разработчики программного обеспечения не доверяют вам (я полагаю).

Там есть пакеты, которые будут шифровать ваш EXE и расшифровать его, когда пользователю разрешено использовать его

Конечно, путь вокруг него - это взломать тест "can-I-use-it", чтобы он всегда возвращал true.

Отвратительным трюком может быть использование байтовых значений кодов операций, которые выполняют тест где-то еще в программе грязным способом, что приведет к сбою программы с высокой вероятностью, если значение не будет правильным. Это заставляет вас привязаться к определенной архитектуре: - (

Если он написан на .NET и скомпилирован в CIL, он может быть отражен. Если безопасность является предметом озабоченности, и следует избегать обфускации, я рекомендую писать ваше приложение, используя не управляемый язык, который по своей природе сложнее реконструировать.

Лучший ответ - это первый от маленького разработчика, который говорит о своем собственном опыте, все описанные выше методы против реверсирования - это 101 учебник для любого серьезного инженера-ревертера.

Некоторые коммерческие DRM-решения довольно приличные, но каждый трек AAA-игра с пользовательскими DRM-решениями все время в течение нескольких часов (или дней) трещит. Только введение совершенно нового решения DRM - иногда - задержки неизбежны, возможно, через пару недель.

Получение максимальной отдачи от DRM требует много времени и денег и может легко повредить производительность, надежность, совместимость/переносимость и отношения с клиентами в целом. Либо придерживайтесь достойного коммерческого DRM, не пытаясь быть слишком умным и не тратьте свои (меньше) убытки или просто забывайте об этом полностью...

Один пример решения DRM, который выкопал его собственную (коммерческую) могилу: http://en.wikipedia.org/wiki/StarForce

Да, .NET двоичные файлы (EXE и DLL) можно легко декомпилировать до почти исходного кода. Проверьте инструмент .NET Reflector. Просто попробуйте использовать любой бинарный файл .NET. Лучшим вариантом является обфускация файлов, они все еще могут быть декомпилированы .NET Reflector, но они создают нечитаемый беспорядок. Я не думаю, что хорошие обфускаторы были бы свободными или дешевыми. Это Dotfuscator Community Edition, который поставляется с Visual Studio.

По нижеуказанному вопросу в блоге Microsoft:

https://blogs.msdn.microsoft.com/amb/2011/05/27/how-to-prevent-ildasm-from-disassembling-my-net-code/

Как я могу предотвратить разборку сборки ILDASM?

.NET имеет атрибут SuppressIldasmAttribute который предотвращает дизассемблирование кода. Например, рассмотрим следующий код:

using System;
using System.Text;
using System.Runtime.CompilerServices;
[assembly: SuppressIldasmAttribute()]

namespace HelloWorld
{
    class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine("Hello world...");
        }
    }
}

Как видите, есть только два отличия:

1. Мы добавили замедление пространства имен System.Runtime.CompilerServices.

2. Мы добавили атрибут [assembly: SuppressIldasmAttribute()].

После сборки приложения в Visual Studio, когда мы пытаемся открыть полученный EXE файл в ILDASM, теперь мы получаем следующее сообщение:

Я также сделал некоторые соображения относительно взлома безопасности в моем дизайне и хочу добавить их, поскольку некоторые из них, похоже, не упоминаются:

У меня есть скриптовый интерфейс в моем приложении. Чтобы гарантировать, что скрипты могут вызывать только методы, которые предназначены для вызова (python) -cripts, у меня есть атрибут scriptvisibility и System.Dynamic.DynamicMetaObjectProvider, который распознает эти атрибуты.

Лицензии используют открытый/закрытый ключ.

ViewModels необходимо разблокировать, предоставляя пароль функции разблокировки.

CoreRoutines могут быть реализованы на ключе. (Есть ключи, вокруг которых есть поддержка)

Большое решение, такое как обертки, не планировалось.

Конечно, этот сценарий /viewModel apporach не делает невозможным разблокировать и вызывать script -непрозрачные функции из кода, но это делает его немного сложнее делать это - как со всем, что связано с усилиями по борьбе с взломом.

310+ голосов за ответ, который начинается с "Вы не можете" на сайте программирования?

Я думаю, вы можете, но в чем цель здесь? В конечном итоге это сводится к необходимости защиты IP (патентов) и оптимизации переменной, как чистая прибыль в течение срока. Защита IP-адреса является лишь частью общей стратегии.

Изучите, какие пользователи и конкуренты могут иметь ваше приложение. Это помогает решить оптимальный подход к продажам/маркетингу и необходимый уровень защиты.

например. Один из сценариев может быть вертикальным/нишевым продуктом, который должен быть установлен локально на клиенте без доступа к Интернету с небольшим количеством потенциальных клиентов, и эти клиенты могут взломать, так как цена может быть очень высокой для какого-то чрезвычайно проприетарного нишевого приложения. Вместо того, чтобы иметь доступ к вашему приложению, в этом случае вы, скорее всего, захотите найти этих потенциальных клиентов и перенести приложение, установку и поддержку и т.д. Вы бы хотели, чтобы приложение было достаточно для каждого клиента, если он просочился от клиента, вы бы это знали и могли подать иск на компенсацию.

Другой сценарий заключается в том, что ваш рынок очень дешевый/бедный человек. Получение третьей стороны для оплаты приложения (например, реклама/спонсор/правительство).

Если после всех бизнес-исследований вы определили, что вам действительно нужно тратить время/деньги на защиту вещей от сухарей и распределять "драгоценности короны" с клиентом, то создание собственных многоуровневых пользовательских защит с буквальной тонны проверки контрольной суммы и кода защиты, который в идеале обновляется из нескольких источников (например, сторонние плагины для вашего приложения также обновляют защиту), весьма эффективен. Таможенные упаковщики, избегая "keygennability", также важны. И весь этот защитный код не должен оставаться неизменным навсегда. Если используется стороннее решение защиты, возможно, лучше всего найти тот, который не очень хорошо известен и снова изменится, если он станет известен - чем больше клиентов используют решение защиты, тем более вероятно, что он привлечет внимание. Некоторые коммерческие решения для донглов длились долгое время без трещин, затем все приложения, использующие их, получили трещины одновременно, потому что решение защиты было одинаковым для каждого приложения. Это относится как к известным ключам, так и к играм, использующим защиту от одних и тех же компаний. Если в любой автономной игровой игре использовалась защита высокого уровня от разных компаний или полностью пользовательских, горстка игровых взломщиков была бы перегружена.

У производителей электронной музыки, похоже, есть репутация для того, чтобы быть бедным, но достаточно умным, чтобы найти трещины, основанные на количестве и новизне защиты в приложениях для рынка. Наиболее привлекательные/новые приложения, ориентированные на этот рынок, обычно поставляются с ключами или специальными защитами программного обеспечения, которые, по-видимому, защищают приложения в течение достаточного времени, которые некоторые из пиратов решают сэкономить и заплатить за них. Однако я бы сказал, что из тысяч приложений на этом рынке очень немногие действительно уникальные, которые также убедительны с точки зрения музыканта/продюсера. Я бы сказал, что, если вы не являетесь таким же музыкантом, как разработчик, вы, вероятно, не имеете ни малейшего представления о том, что было бы достаточно, чтобы тратить значительные усилия на защиту (и вы тоже хотели бы запатентовать эту идею), хотя многие действительно хорошие идеи уже запатентованы и обычно реализованы в музыкальном оборудовании и никогда не превращаются в легко распространяемую программную форму).