Нет ли абсолютно никакой защиты для Windows приложений на do tnet?

Question

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

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

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

Мой вопрос: нет ли способа защитить сборку приложения от обратного проектирования, если я решу не использовать какой-либо из дорогих вариантов доступны

Answer 1

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

Answer 2

Простой факт декомпиляции таков: «Пока компьютер может выполнять его, он также может декомпилировать его».

Выполнение - это процесс, который преобразует двоичный код в действия.

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

Если один заблокирован, другой также блокируется.

Запутывание может усложнить чтение декомпилированного кода . Но это все, что он может сделать.

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

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

• , если сравнивать входные данные с чем-то в бэкэнде - как вы делаете с паролями - защита паролем может работать. Современная безопасность PW означает, что даже Adminsitrator не может определить пароль, но вы все равно можете сравнить с ним пользовательский ввод.
• Вы можете переместить строки в отдельное приложение. Вместо того, чтобы предоставлять приложениям строку подключения к серверу SQL, вы предоставляете ей доступ к веб-сервису, которым вы управляете. Только WebService действительно знает, как связаться с базой данных.

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