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


491

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

Также возможно преобразовать приложение C # в собственный код, и Xenocode слишком дорог .

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

Безопасные сертификаты можно легко удалить из подписанных сборок в .NET.



@ Андреас: Это круто! Я собираюсь попробовать. Кто-нибудь использует это?
Джек,

1
@ Джек, это только для приложений магазина окон. У настольных приложений нет графика времени (насколько я могу судить).
Тайлер Лонг

Если вы хотите нативный без архаичного C ++, используйте Delphi. В любом случае, простота .Net пришла от Delphi.
Уильям Эгге

Ответы:


671

Ты не можешь

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

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

Вот несколько советов, которые помогут вам защитить ваше приложение:

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

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

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

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

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

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

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

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


67
+1, что почти +2. Я бы хотел, чтобы больше людей наконец-то поняли, что вы просто не можете защитить свое программное обеспечение от решительного злоумышленника
Бомба

102
Вы достигли нирваны защиты программного обеспечения: речь идет не о добавлении дополнительной защиты, а о том, чтобы сосредоточиться на продукте и сделать его настолько хорошим, что люди ХОТЯТ платить за него. А тем, кто его пиратствует, они никогда бы не заплатили, так что как будто их никогда не существовало.
Артур Чапарян

6
@ Артур Чапарян, согласен. Это заняло много времени, но я наконец увидел свет. Я пошел по пути более ограничительных мер защиты и борьбы с крекерами. Я узнал все, что мог о реверс-инжиниринге, пытаясь предотвратить свое собственное. Я наконец понял правильную идеологию
mmcdole

50
Черт, для меня было честью узнать, что кто-то думает, что мое программное обеспечение стоит пиратства ...
Эрик Форбс

10
Когда вы начинаете полагаться на продажи своего программного обеспечения в большей части своего дохода, это меняет дело. Такое чувство, что кто-то крадет у тебя. Я понимаю, что вы говорите, хотя. Я был шокирован, когда впервые обнаружил кряки для моего программного обеспечения на торрент-сайтах.
mmcdole

265

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

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

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

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

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

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

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

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

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

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

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

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

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

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


1
@Learning: со временем она выросла и прошла автоматическое преобразование в CW порог.
Джоэл Коухорн

1
+1 Лучше, чем ответ, который я дал на предыдущую версию этого вопроса. @ Джоэл Не знал, что был предел.
pipTheGeek

1
Я не полностью согласен со всем здесь, и это все равно легко +1 для чрезвычайно хорошо продуманной презентации и аргументации.
Беска

2
Хороший аргумент, но пропускает пункт о защите интеллектуальной собственности. Если в вашем приложении есть какой-то код, который выполняет что-то более сложное, запутывание может обеспечить разницу между простым копированием и вставкой кода и попыткой интерпретировать и реинжинировать код, чтобы он работал. Это особенно важно с обновлениями: если кто-то скопировал ваш запутанный код, когда вы выпускаете обновление, они должны делать это снова - и, по крайней мере, это причиняет им больше боли / затрат / времени. Если у вас нет какой-либо защиты, они просто копируют / вставляют снова, и это работает.
gregmac

4
Отличный пост - он действительно подробно описывает все причины, по которым не стоит беспокоиться о том, чтобы писать сложные средства защиты от копирования. Несмотря на то, что вопрос является дубликатом, стоит открыть его только для этого ответа. Может мод может слить это?
EMP

45

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


38

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


1
Кстати, я делаю проект, в котором я хочу также активировать продукт "в автономном режиме" (я сделал сервис WCF, чтобы сделать активацию онлайн). В этом случае, как вы будете манипулировать кодом? ты можешь дать мне несколько хитов?
Пиюш

1
Интересная идея, но какой способ действий вы бы порекомендовали кому-то, кто разрабатывает приложение, которое должно работать без подключения к данным, например игры WP7?
Чарли Скилбек

23

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

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

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

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

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

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


Использование надежной криптографии для защиты / проверки ваших лицензий совершенно бесполезно, если кто-то извлекает код, который прерывает работу приложения, если лицензия не проверяется. :)
Бомба

Согласились, но, как я уже говорил, защита не для тех групп пользователей, которые прибегнут к использованию кряков (предположение, которое я сделал, будет существовать).
Мистик

криптография с открытым ключом = асимметричная криптография. Я думаю, что вы имели в виду симметричный.
mmcdole

1
Справедливости ради следует отметить, что третий пункт является предвзятым, поскольку он предполагает, что часть людей всегда составляет меньшинство. Я уверен, что в определенных рамках это явное большинство. У меня есть онлайны игры с многопользовательской особенностью в виде , потому что а) большинство пользователей дети с очень низким этическими стандартами ; б) стоимость может быть существенной для тех пользователей , если это ежемесячная плата , которая тащит в течение нескольких месяцев и т.д.
J РИВ

19

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

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

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

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

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

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

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


1
как идея, вы также можете использовать разные пароли для ассиметричного шифрования в разных выпусках.
Приянк Болия

Интересная идея, но в чем конкретно проблема с длинным регистрационным кодом? В наши дни никто все равно не будет вводить это вручную - все копируют и вставляют его, поэтому не имеет значения, будет ли это 10 или 100 символов.
EMP

4
@ Евгений: Это верно только в том случае, если ваши пользователи являются опытными пользователями. Мы создавали условно-бесплатные / казуальные игры в течение многих лет, и я могу вам сказать, что большинство наших пользователей не могут копировать и вставлять. В окне регистрации даже есть руководство по копированию и вставке, а некоторые даже не читают его.
Адриан Григоре

Вот Это Да! Ладно, у тебя явно больше опыта, чем у меня, так что я не могу спорить, я могу только сказать, что я удивлен. Но я бы сказал, что если они не знают, как копировать и вставлять, то вы должны сделать код длиной в 200 символов, чтобы они выучили очень полезные навыки работы с компьютером. :)
EMP

1
@Evgeny: Даже с короткими регистрационными кодами мы все еще получали много писем от людей, которые неправильно набрали свои коды и поэтому думали, что код не может быть действительным, потому что они никогда не допустят ошибку, подобную этой, несколько раз за строка. Я предпочитаю оставить преподавание ИТ другим компаниям ... :-)
Адриан Григор

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

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

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

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

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

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


14

Вы можете..

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

UPDATE: (Раскрытие информации: Я работаю на Eazfuscator.NET) Что делает Microsoft SLP Services Software Потенциальный отличается способность виртуализировать код, так что вы определенно можете . Прошло несколько лет с тех пор, как вопрос был задан изначально; сегодня доступно больше продуктов, которые также работают на аналогичной основе, например:


2
ценообразование мой друг, покупка лицензионного программного обеспечения от Microsoft слишком дорого для обычного ISV
Priyank Bolia

Я пробовал, он работает очень хорошо, но он шифрует код только внутри метода, а не всей сборки или проекта, поэтому взломщик может легко изменить поток программы с помощью IL-инъекции
Мохсен Афшин,

@ogggre Если вы добавляете ссылки поставщиков, вам действительно нужно раскрывать свои связи в посте. Также текущая версия SLPS (над которой я работаю: D) поддерживает дженерики. Естественно, что у всех решений есть свои плюсы и минусы, которые только eval может правильно контекстуализировать для людей
Рубен Бартелинк

@MohsenAfshin Я не понимаю, что вы говорите, суть в том, что вам нужно защищать любые методы, в которых добавление / удаление / изменение IL будет представлять собой нарушение лицензии. Поскольку виртуализация вещей не может быть бесплатной, просто не имеет смысла «магически защищать все», как вы предлагаете. Возвращаясь к ключевому моменту: цель защиты SP состоит в том, чтобы предотвратить изменения IL в методах, которые вы выбираете, исходя из того, что они чувствительны (плюс, как правило, некоторые другие в качестве шума, чтобы избежать посадки, вам нужно взломать этот бит здесь -> знак )
Рубен Бартелинк

1
@RubenBartelink Я согласен с вами. К сожалению, эта тема слишком большая с несколькими страницами контента. Сначала я хотел добавить новый ответ, но StackOverflow предположил, что лучше расширить существующий. Так я и сделал. Надеюсь, мой маленький кусочек информации полезен. Спасибо за обновление общей поддержки в SLPS и ваши исправления.
ogggre

10

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

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

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

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


9

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

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

Еще несколько идей (ни одна не идеальна, поскольку нет идеальной).

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

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


Не забывайте, что вполне возможно атаковать программную часть аппаратной блокировки.
Магнус Хофф

Да, это правда, единственный реальный вариант - это частичное внедрение приложения в аппаратное обеспечение (например, какое-то странное сочетание программного VHDL-приложения). Это также может быть взломано, хотя ...
Anonymous

Как насчет ключей, которые реализуют стратегию открытых / закрытых ключей. Только закрытый ключ ключа может расшифровать приложение и запустить его.
mmcdole

Вот что обычно делает аппаратный ключ. Но вы можете либо атаковать ключ - клонировать его, либо программное обеспечение, отвечающее за общение с ключом (обойти, отключить и т. Д.).
Аноним

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

9

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

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

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

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

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

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


8

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

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

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

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

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


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

8

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

Это идеи:

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

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

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

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


не можете объяснить подробно.
Приянк Болия

7

Да. Это правда. Код .NET чрезвычайно легко перепроектировать, если код не запутан.

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

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

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

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


11
Это не просто «если они действительно хотят увидеть, как работает ваше программное обеспечение, они это сделают». Если они заботятся, они могут догадаться, не глядя. У 99,9% + программного обеспечения нет алгоритмов волшебной пыли. Сложная часть программирования не является какой-то особой секретной техникой. Это просто заставляет все части выстраиваться и работать.
Кен

9
@ Кен - Тссс! Вы не можете позволить остальному миру знать, что большую часть времени мы не используем алгоритмы магической пыли.
Джастин Нисснер

9
Джастин: Любовь считается магическим алгоритмом? Любовь - это то, что делает мои программы особенными. Я не думаю, что вы можете разобрать Любовь.
Кен

Babel.NET больше не является бесплатным. Вы можете найти список наиболее распространенных обфускаторов (бесплатных и коммерческих) здесь .
InputOutput

6

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

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

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

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

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

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


5

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


Ответ довольно прост: жаль, что большинство ответов говорят о запутывании. Обфускация хороша для того, чтобы остановить первую (похожую на рефлектор) попытку поиска в вашем коде, вот и все. Это не плохо. И, конечно, ничто не мешает настоящим хакерам, понимающим ассемблерный код, кроме написания приложения SAAS (даже тогда они могут попытаться взломать ваш сервер). Но есть еще кое-что, есть такие инструменты, как Salamander, .NET Reactor и др., Которые предоставляют (возможно) почти такую ​​же форму безопасности, которая не компилируется, как Win32 .exe, скомпилированный C ++. Какой из этих инструментов лучше, я пока не могу судить.
Филм

5

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


5

.NET Reactor

Обновить

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

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

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


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

1
У меня были некоторые проблемы с их продуктом ранее, а затем я задал вопрос о значках высокого разрешения в groups.google.se/group/net-reactor-users, и я получил ответ и исправление, но теперь кажется, что их трудно получить за. К плохому - это отличный продукт, и я все еще использую его
loraderon

2
Если «никакой существующий инструмент не может декомпилироваться», почему он указан в качестве поддерживаемого обфускатора / упаковщика на странице возможностей de4dot
Джаред Тирск

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

de4dot - очень мощный инструмент. Я попробовал это против нескольких обфускаторов, и это делает большую работу. Однако он не смог обработать защищенные файлы .NET Reactor (v6.0). Может быть, de4dot не в курсе.
InputOutput

4

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


5
Что, если сервер не работает или пользователи не имеют доступа к Интернету всегда, ваш метод просто разочарует клиентов тем, что они часто посещают интернет-серверы, просто чтобы использовать приложение.
Приянк Болия

Я полностью согласен. Вот почему я сказал «это, вероятно, более агрессивно, чем вы хотите ...» в моей последней строке. Я просто предлагал ОП лучшее решение, которое, на мой взгляд, было технически выполнимым, а не лучший подход к удовлетворению клиентов :)
rmeador

В первом квартале 2010 года (через несколько месяцев после написания этого ответа) компания по разработке игр Ubisoft попробовала это сделать, и, очевидно, нагрузка на серверные компоненты была настолько большой, что игры были неиграбельны. Общее впечатление от ПО: «хлопот в установке, нельзя использовать в автономном режиме, агрессивно и ненадежно ». Таким образом, если вы решите, что обработка на стороне сервера - это путь, убедитесь, что вы действительно можете масштабироваться по требованию.
Писквор покинул здание

3

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


3

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



2

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

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

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


2

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


2

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


2

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

У обоих одинаковый очень простой ответ: не передавайте объектный код ненадежным сторонам, таким как (очевидно) вашим клиентам. Возможно ли разместить приложение на ваших машинах, зависит только от того, что оно делает.

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

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

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

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

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

Конечно, можно обойти тест «can-I-use-it», чтобы он всегда возвращал значение true.

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


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

Ой. Я имел в виду трюки C; скажем, взять адрес функции проверки, сложить 10 первых байтов в этом массиве символов (приведите указатель на функцию); выберите любую функцию f и сохраните [адрес f минус предыдущую сумму] в fptr. Всегда называйте f как * (fptr + эта сумма). Предварительно вычислите «эту сумму»
Йонас Кёлкер

2

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


2

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

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


2

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

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


Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.