Защита .net приложения от посторонних глаз

[tushkanM]

против дизассемблера такое не сработает, но праздношатающихся отведёт

Вот на этом шатком предположении и строится вся защита…
Как упражнение это все очень весело, а в продакшене даже HASP ломают

[hmspns]

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

• Сам запустил приложение, введя пароль
• Позволил кому-то подключиться с отладчиком к твоей машине

А это, согласитесь, достаточно специфичная ситуация.

[Gol]

Насчёт выполнения кода удалённо — вот такая штука могёт помочь resanity.com/ru/docs Само собой, работает только при наличии подключения к инету. Непосредственно .Net не получится, надо нативную dll делать а в неё критичный код помещать. С обычными приложениями конеш попроще.

[hmspns]

Спасибо за наводку, посмотрю

[DevMan]

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

[mayorovp]

Нам понадобится импортировать пару неуправляемых методов и скрыть само окно
Скрываем консоль

Пожалуйста, не делайте так. Лучше создайте обычное оконное приложение, а не консольное — тогда и консоль скрывать не надо будет. Ваш вариант хорош только в том случае, когда приложение запускается ярлыком из проводника. А если я запущу его из FARа? Или из пакетного файла?

[hmspns]

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

[mayorovp]

Тогда делайте FreeConsole вместо ее сокрытия — это хотя бы не искалечит тот же FAR. А еще лучше — запускайтесь в оконном режиме и делайте AllocConsole, потом FreeConsole — тогда FAR еще и не будет ждать завершения приложения.

[hmspns]

Окей, буду иметь в виду :)

[gandjustas]

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

Как раз обфускация более надежна.

[hmspns]

Он проанализирует сборку-загрузчик, в которой действительно нет никакой ценности. Сборки самой программы шифруются AES, в качестве ключа используется пароль, указанный при шифровании. Без знания ключа это просто набор «белого шума», которые дизассемблер не возьмёт.

[gandjustas]

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

[hmspns]

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

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

[gandjustas]

И? От чего вы защищаете? От несанкционированного доступа? Или от «утекания» интеллектуальной собственности?
В обоих случаях обфускатор+https://www.nuget.org/packages/Portable.Licensing/ (опционально) как-то понадежнее будет, да и кода поменьше.

[DeOhrenelli]

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

Странный какой-то юзкейс.
использовать утилиты может только автор или доверенное лицо.
То есть код может утечь только если автор или доверенное лицо его пропотеряет или намеренно кому-то отдаст.

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

Кстати к вопросу о использовании ША-256 в качестве ключа:
сдается мне что подобрать слабый пароль имея зашифрованную сборку будет достаточно легко.
(А если пароль будет сильный, то он скорее всего будет лежать в текстовом файле рядом со собркой).
АЕС, как известно, блочный шифр, работает блоками по размеру ключа.
У сборки должен быть свой, четко определенный формат, особенно у начала.
Таким образом для того, чтобы определить валидность ключа во время подборки нужно попытаться расшифровать первые 256 байт,
и посмотреть валидны ли они, то есть расшифровывать всю сборку, что сильно увеличит потери времени на подбор, не нужно.

Все 256 бит подбирать не обязательно, проще подбирать пароль — до определенной его длинны там просто меньше возможностей чем 2^256.

[GLeBaTi]

Как успехи? Получилось сделать защиту?