Comments 17
против дизассемблера такое не сработает, но праздношатающихся отведёт
Вот на этом шатком предположении и строится вся защита…
Как упражнение это все очень весело, а в продакшене даже HASP ломают
Это да. Насколько я понимаю, всё что попало на клиентский компьютер можно сломать.
Поэтому если нужна надёжность, производи ключевые операции на удалённом сервере (если смысл программы это позволяет, конечно).
Я здесь акцент делал на защиту собственных продуктов, которые используешь для себя, и код которых не хочешь где-то светить. Он становится уязвимым, если ты:
А это, согласитесь, достаточно специфичная ситуация.
Поэтому если нужна надёжность, производи ключевые операции на удалённом сервере (если смысл программы это позволяет, конечно).
Я здесь акцент делал на защиту собственных продуктов, которые используешь для себя, и код которых не хочешь где-то светить. Он становится уязвимым, если ты:
- Сам запустил приложение, введя пароль
- Позволил кому-то подключиться с отладчиком к твоей машине
А это, согласитесь, достаточно специфичная ситуация.
Насчёт выполнения кода удалённо — вот такая штука могёт помочь resanity.com/ru/docs Само собой, работает только при наличии подключения к инету. Непосредственно .Net не получится, надо нативную dll делать а в неё критичный код помещать. С обычными приложениями конеш попроще.
На что только люди не пойдут, лишь бы не писать хороший и полезный код.
Нам понадобится импортировать пару неуправляемых методов и скрыть само окноПожалуйста, не делайте так. Лучше создайте обычное оконное приложение, а не консольное — тогда и консоль скрывать не надо будет. Ваш вариант хорош только в том случае, когда приложение запускается ярлыком из проводника. А если я запущу его из FARа? Или из пакетного файла?
Скрываем консоль
А какой смысл сделанного? Человек в ILSpy откроет основной модуль, найдет код расшифровки и быстренько расшифрует ваши сборки.
Да и по большому счету в алгоритмах самих по себе ценности не много, а если надо пользоваться программой без ограничений, то ваш способ не то что не остановит, а даже не задержит атакующего.
Как раз обфускация более надежна.
Да и по большому счету в алгоритмах самих по себе ценности не много, а если надо пользоваться программой без ограничений, то ваш способ не то что не остановит, а даже не задержит атакующего.
Как раз обфускация более надежна.
Он проанализирует сборку-загрузчик, в которой действительно нет никакой ценности. Сборки самой программы шифруются AES, в качестве ключа используется пароль, указанный при шифровании. Без знания ключа это просто набор «белого шума», которые дизассемблер не возьмёт.
Этот пароль кто-то знает, кроме автора программы. Поэтому достаточно однократного попадания пароля в ненадежные руки, чтобы программу можно было на всегда от пароля отвязать. Вот и спрашиваю — от чего защищает.
Очевидно слабое места подобной защиты – необходимость знать пароль каждому, кто будет пользоваться приложением.
Также важно понимать, код сборок можно достать дизассемблером в процессе использования приложения.
Но если есть необходимость скрыть то, что делает утилита, которой вы сами пользуетесь, от посторонних глаз, такой подход себя оправдывает.
Основная проблема не в том, чтобы стырить код, а в том чтобы стырить читаемый и поддерживаемый код.
Таким образом обфускация лучше. А еще лучше совмещать оба метода.
Странный какой-то юзкейс.
использовать утилиты может только автор или доверенное лицо.
То есть код может утечь только если автор или доверенное лицо его пропотеряет или намеренно кому-то отдаст.
А отдать код вместе с паролем ненамного сложнее чем просто отдать код — это на случай злонамеренного доверенного лица.
Таким образом все эти ухищрения работают исключительно на случай потери контроля над ненамеренным распространением кода.
Кстати к вопросу о использовании ША-256 в качестве ключа:
сдается мне что подобрать слабый пароль имея зашифрованную сборку будет достаточно легко.
(А если пароль будет сильный, то он скорее всего будет лежать в текстовом файле рядом со собркой).
АЕС, как известно, блочный шифр, работает блоками по размеру ключа.
У сборки должен быть свой, четко определенный формат, особенно у начала.
Таким образом для того, чтобы определить валидность ключа во время подборки нужно попытаться расшифровать первые 256 байт,
и посмотреть валидны ли они, то есть расшифровывать всю сборку, что сильно увеличит потери времени на подбор, не нужно.
Все 256 бит подбирать не обязательно, проще подбирать пароль — до определенной его длинны там просто меньше возможностей чем 2^256.
Таким образом обфускация лучше. А еще лучше совмещать оба метода.
Странный какой-то юзкейс.
использовать утилиты может только автор или доверенное лицо.
То есть код может утечь только если автор или доверенное лицо его пропотеряет или намеренно кому-то отдаст.
А отдать код вместе с паролем ненамного сложнее чем просто отдать код — это на случай злонамеренного доверенного лица.
Таким образом все эти ухищрения работают исключительно на случай потери контроля над ненамеренным распространением кода.
Кстати к вопросу о использовании ША-256 в качестве ключа:
сдается мне что подобрать слабый пароль имея зашифрованную сборку будет достаточно легко.
(А если пароль будет сильный, то он скорее всего будет лежать в текстовом файле рядом со собркой).
АЕС, как известно, блочный шифр, работает блоками по размеру ключа.
У сборки должен быть свой, четко определенный формат, особенно у начала.
Таким образом для того, чтобы определить валидность ключа во время подборки нужно попытаться расшифровать первые 256 байт,
и посмотреть валидны ли они, то есть расшифровывать всю сборку, что сильно увеличит потери времени на подбор, не нужно.
Все 256 бит подбирать не обязательно, проще подбирать пароль — до определенной его длинны там просто меньше возможностей чем 2^256.
Отличная статья, автор. Как раз пытаюсь сделать, что-то похожее. В моем случае, нужно чтобы на ВПС работал софт и чтобы хостеры или брутеры, которых сейчас развелось много, не смогли запустить софт, не зная пароля, даже, если завладеют им.
Планирую также использовать AES-256 и держать основной код в зашифрованной, запакованной библиотеки, загружать только в память без распаковки на диск.
Умники, которые тут пишут о расшифровке AES-256 без пароля — пусть попробуют, я бы на это посмотрел.
Кто-то советует использовать лицензирование типа Portable.Licensing, .NET Reactor и иже с ними — цена этим советам нулевая, т.к. все это барахло снимается de4dot за минуту,
Обфусцированный, но восстановленный код до названий типа Class1, Class2 может оказаться вполне понятным, чтобы понять логику/идею работы Вашего софта и сделать аналог, либо заставить Ваш софт работать в другом месте.
Способ из статьи, конечно, не панацея, и при желании можно сдапмить расшифрованную сборку из памяти запущенного процесса.
Планирую также использовать AES-256 и держать основной код в зашифрованной, запакованной библиотеки, загружать только в память без распаковки на диск.
Умники, которые тут пишут о расшифровке AES-256 без пароля — пусть попробуют, я бы на это посмотрел.
Кто-то советует использовать лицензирование типа Portable.Licensing, .NET Reactor и иже с ними — цена этим советам нулевая, т.к. все это барахло снимается de4dot за минуту,
Обфусцированный, но восстановленный код до названий типа Class1, Class2 может оказаться вполне понятным, чтобы понять логику/идею работы Вашего софта и сделать аналог, либо заставить Ваш софт работать в другом месте.
Способ из статьи, конечно, не панацея, и при желании можно сдапмить расшифрованную сборку из памяти запущенного процесса.
Sign up to leave a comment.
Защита .net приложения от посторонних глаз