Как стать автором
Обновить

Комментарии 28

Это статья уже более реальнее )
1. Нужно будет так изменять каждый защищаемый метод?
2. Как все это дело автоматизировать? Может написать свой обфускатор (применяя изложенные методы в заметке) и есть ли такие уже готовые?
Все уже давно написано.
1) Если в методе убрать параметр «string methodName» и проверку «if (method.Name == methodName)», то он обработает все методы целевой сборки.

2) Конечно, уже есть готовые утилиты, применяющие этот и многие другие методы, но я не знаю хорошего бесплатного обфускатора (но что касается именно указанного в заметке метода — его применяют некоторые бесплатные обфускаторы). Также, как я уже описал в заметке, не стоит слишком полагаться на этот метод, так как разработчик, который знает, как его обойти, обойдет его без проблем. Автоматизировать это можно например так — указать в PostBuild событии Visual Studio для целевого проекта путь к консольному приложению с параметром в виде пути к вашей сборке, используя соответствующие макросы VS (до этого конечно нужно обернуть описанный выше метод в консольное приложение). Тогда после каждого успешного построения все методы вашей сборки будут автоматически обрабатываться. Другой способ — подключиться к MSBuild.
я не знаю хорошего бесплатного обфускатора

Можете попробовать Babel .NET, мы им пользуемся для обфускации, довольны.
Перевод в C#, VB,… можно также отрубить, вызывая Exception в Reflector путем введения в стек лишних значений и перемешивания кода.
Очень интересная тема. Спасибо.

Читателям добавлю: Разработчики, применяйте обфускацию, хотя бы в коммерческих проектах. Этим самым обезопасите себя во многих направлениях.
От чего обезопасим «защитив» код? И какой обфускатор посоветуете (методы обфускации). Можно даже купить, если стоимость не будет равна годовому заработку :)
К сожалению самому пока не доводилось писать приложения, которые распростараняются, а только работающие внутри компании. Как следствие, не занимался в плотную обфускацией. Посоветовать к сожалению не могу.

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

От лицензирования подобный софт отучается на раз два. Нет ни какой гарантии, что этими исходниками не воспользуются со стороны. Кроме того этим облегчается поиск уязвимостей (в большей степени актуально для серверных решений).
Такова природа NET приложений на данный момент.
Ну к серверным решениям вы сначала доступ получите, а потом рефлектором смотрите :)
Я имею виду случай, если продукт продается с сайта и доступен для свободного скачивания
насколько я понимаю, инструкций не 65538, а несколько меньше.
ведь раз инструкция либо однобайтная, либо двухбайтная, значит один бит уходит на указание того, сколько байт в инструкции.
значит остается 128 однобайтных и 32768 двухбйтных инструкций.
всего 32896.
ну это так, придираясь по мелочи. )
Все верно, но сути не меняет :)
Про стек еще напишите.
Не понял, что именно вам интересно про стек. Некоторая информация об этом есть в моей первой статье.
Я имел ввиду манипуляции со стеком, которые так же приводят к «обвалу» рефлектора.
А можно сделать обратно, когда с помощью Mono.Cecil удалить весь некорректный код, который не обрабатывается в .NET Reflector, да и вообще никогда не выполняется?
Конечно можно, поэтому я и говорю, что не стоит ни в какой мере надеяться на указанную в топике защиту (правда при этом сборка потеряет свое строгое имя, однако это не является проблемой). Простые методы обфускации (запутывание потока вызовов, переименование методов, вставка некорректных инструкций и т.д.) не могут в полной мере защитить NET сборку от дизассемблирования профессионалом. Более надежные методы обфускации, например запуск кода под виртуальной машиной с уникальной (виртуальной) архитектурой процессора (и соответственно ассемблера) могут помочь, но они дороги и далеко не всегда могут быть применены.
спасибо за статью,
может быть стоит ее открыть из под замка?
Сторонники OperSource сообщества будут в ярости от увиденного =)
У статьи 39 плюсов, она в конце ленты на 3 странице. Думаю, что боятся уже ничего не стоит
Подумал, что вы правы и раз статья на 3ей странице уже, то проблем быть не должно :) Открыл.
Даже комментарии минусуют :) Что им не нравится?
Open* конечно же, за правописание двойку мне
Когда я открыл ее, сразу начали минусовать :) Я так думаю это потому, что она засоряла главную страницу тем, кому NET впринципе не интересен, но возможно я чего-то не понимаю.
Спасибо за статью.
Хорошо бы было написать как именно обходится такая обфускация.
Есть неплохой проект "Simple Assembly Explorer" там можно в два клика мышкой пофиксить или метод или всю сборку на предмет таких трюков, чтобы рефлектор мог показать потом.
Еще вариант — поправить некоторые вещи в CLR-заголовке или PE-заголовке, тогда рефлектор может не обнаружить что это дотнетовская сборка вообще, а работать все еще будет. Чем поправить — например CFF Explorer полезная тулза.
Будет ли такой вариант работать на WPF приложениях?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации