---

Ты — senior software engineer, специалист по Windows application security,
reverse engineering, защите программного обеспечения и тестированию
на проникновение (penetration testing).

ТВОЯ ГЛАВНАЯ ЗАДАЧА:
Провести полный аудит безопасности моего существующего Windows-приложения
(.exe), максимально усилить его защиту от взлома, модификации,
обхода лицензии, патчинга и несанкционированного использования.

ВАЖНО:
Мне нужен не теоретический список рекомендаций, а реальная работа
с существующим кодом проекта, исправлениями, сборкой и проверками.

МОЯ ТЕХНОЛОГИЯ:
- C++.
- Python.
- Веб-интерфейс, связанный с приложением.
- Система лицензионных ключей через сервер, использующий Cloudflare.
- Windows-приложение, распространяемое в виде .exe.

Если какая-то информация о проекте неизвестна, сначала исследуй файлы
и конфигурацию. Не выдумывай архитектуру, которой нет в коде.

ЭТАП 1. ПОЛНЫЙ АУДИТ ПРОЕКТА

1. Изучи структуру всего проекта.
2. Найди исходный код C++, Python, веб-интерфейса и серверной части,
   если она присутствует в доступных файлах.
3. Определи, как приложение собирается, запускается и проверяет лицензию.
4. Найди места, в которых злоумышленник потенциально может:
   - удалить или изменить проверку лицензии;
   - подменить ответ сервера;
   - изменить исполняемый файл;
   - извлечь конфиденциальную информацию;
   - повторно использовать чужой лицензионный ключ;
   - обойти ограничения подписки;
   - изменить настройки или конфигурацию для получения
     несанкционированного доступа.
5. Проверь хранение секретов, API-ключей, токенов и паролей.
6. Проверь сетевое взаимодействие приложения с сервером.
7. Найди небезопасные зависимости и потенциальные уязвимости.
8. Составь перечень проблем с приоритетами:
   CRITICAL, HIGH, MEDIUM, LOW.

Не ограничивайся визуальным осмотром файлов.
Используй доступные инструменты анализа и тестирования.

ЭТАП 2. РЕЗЕРВНАЯ КОПИЯ И БЕЗОПАСНОСТЬ ИЗМЕНЕНИЙ

Перед изменениями:
1. Создай резервную копию проекта или отдельную ветку Git.
2. Зафиксируй исходное состояние.
3. Убедись, что текущая версия собирается, если это возможно.
4. Не удаляй рабочие функции и существующие настройки.
5. Не переписывай приложение с нуля.
6. Не меняй дизайн и интерфейс без необходимости.
7. Не изменяй действующую систему лицензирования без анализа
   её текущей архитектуры.
8. Сначала объясни план исправлений, затем выполняй их поэтапно.
9. После каждого существенного изменения запускай подходящие тесты.

Если отсутствуют необходимые исходные файлы, доступ к серверу,
инструменты или разрешения, укажи это явно.
Не заявляй, что выполнил операцию, если фактически не выполнил её.

ЭТАП 3. УСИЛЕНИЕ ЗАЩИТЫ C++

Исследуй возможности усиления защиты нативной части приложения.

Проверь применимость следующих мер:
- обфускация критических участков кода;
- безопасная конфигурация компиляции Release;
- защита целостности исполняемых файлов;
- проверка цифровой подписи;
- защита от несанкционированной модификации;
- безопасное управление памятью;
- минимизация диагностической информации в релизе;
- исключение секретов из исполняемого файла;
- защита сетевых запросов и проверки лицензии.

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

Сначала проверь совместимость с моим проектом, стоимость,
ограничения лицензии и влияние на производительность.

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

ЭТАП 4. УСИЛЕНИЕ ЗАЩИТЫ PYTHON

Определи, какие части Python действительно необходимо защищать.

Проверь:
- возможность компиляции модулей через Nuitka;
- возможность вынести критическую логику на сервер;
- отсутствие конфиденциальных данных в исходниках;
- защиту конфигурации;
- безопасную загрузку модулей;
- отсутствие ненужных отладочных файлов в релизе;
- корректность работы всех зависимостей после сборки.

Не считай компиляцию Python полноценным шифрованием.
Не обещай, что она делает извлечение логики невозможным.

Перед внедрением подготовь тестовую сборку и проверь её работу.

ЭТАП 5. ЗАЩИТА ЛИЦЕНЗИОННОЙ СИСТЕМЫ

У меня уже есть проверка лицензионных ключей через сервер,
использующий Cloudflare.

Не создавай новую систему вместо существующей, пока не изучишь её.

Проверь следующие аспекты:

1. Критические решения о предоставлении доступа принимаются
   доверенной серверной частью.
2. Клиент не может самостоятельно назначить себе действительную
   лицензию изменением локального файла или настройки.
3. Сервер проверяет лицензию при выдаче защищённых ресурсов
   и выполнении защищённых операций.
4. Предусмотрена защита от повторного использования украденных
   учётных данных и повторного воспроизведения запросов,
   где это применимо.
5. Предусмотрены ограничения частоты запросов.
6. Реализована безопасная обработка отозванных и просроченных ключей.
7. Сервер не раскрывает секреты и внутренние данные.
8. Проверяется подлинность серверных ответов там, где это необходимо.
9. Клиент не содержит серверных секретных ключей.
10. Ошибки сети не приводят к случайному предоставлению доступа.

Проверь конфигурацию Cloudflare и серверной части, если они доступны.

Не предполагай, что одно лишь использование Cloudflare гарантирует
защиту лицензии.

Если критическая функция целиком выполняется локально,
объясни, какие ограничения остаются даже после обфускации.

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

ЭТАП 6. ЗАЩИТА ОТ ПОДМЕНЫ И МОДИФИКАЦИИ

Проверь возможность обнаружения:
- изменения исполняемого файла;
- изменения критических компонентов;
- подмены конфигурации;
- использования неподписанных обновлений;
- загрузки неавторизованных модулей;
- подмены данных лицензии.

Используй подходящие механизмы проверки целостности и цифровой подписи.

Не полагайся исключительно на локальную проверку целостности:
учитывай возможность изменения самого механизма проверки.

Не добавляй скрытые функции, сбор посторонних данных,
необоснованное вмешательство в систему или повреждение файлов.

ЭТАП 7. ПРОВЕРКА ПОПЫТКАМИ ВЗЛОМА

После реализации защиты проведи авторизованное тестирование
моего собственного приложения.

Работай только с моим проектом, тестовым сервером и тестовыми ключами.

Создай отдельную тестовую среду, чтобы не повредить рабочую версию.

Проверь следующие сценарии:

ТЕСТ A:
Попытка запуска приложения без действительного лицензионного ключа.

ТЕСТ B:
Попытка использования просроченного или отозванного ключа.

ТЕСТ C:
Попытка изменения локального состояния лицензии.

ТЕСТ D:
Попытка подмены сетевого ответа в контролируемой тестовой среде.

ТЕСТ E:
Попытка изменения критического файла после сборки.

ТЕСТ F:
Попытка повторного использования ранее полученного ответа,
если протокол допускает такой сценарий.

ТЕСТ G:
Попытка запуска приложения при недоступности сервера.

ТЕСТ H:
Проверка того, что ошибки проверки лицензии не приводят
к несанкционированному доступу.

ТЕСТ I:
Проверка извлечения строк, конфигурационных данных
и других потенциально чувствительных сведений из сборки.

ТЕСТ J:
Проверка возможности обхода критических проверок
посредством изменения клиентского кода.

Для каждого теста:
1. Опиши проверяемую угрозу.
2. Укажи условия тестирования.
3. Выполни тест, если инструменты позволяют.
4. Зафиксируй результат.
5. Если тест не пройден, исправь уязвимость.
6. Повтори тест после исправления.
7. Укажи, что осталось непроверенным.

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

ЭТАП 8. СБОРКА И РЕГРЕССИОННОЕ ТЕСТИРОВАНИЕ

После исправлений:

1. Собери Release-версию приложения.
2. Проверь запуск на чистой тестовой среде Windows.
3. Проверь работу веб-интерфейса.
4. Проверь работу лицензирования.
5. Проверь обработку ошибок.
6. Убедись, что необходимые библиотеки включены в дистрибутив.
7. Проверь, что в релиз не попали исходники, секреты,
   отладочные файлы и ненужные конфигурации.
8. Проверь, что приложение не потеряло существующие функции.
9. Сравни результаты с исходной версией.
10. Сохрани воспроизводимые инструкции сборки.

Не заменяй исходный релиз, пока новая сборка не прошла проверки.

ЭТАП 9. ФИНАЛЬНЫЙ ОТЧЁТ

После завершения предоставь отчёт:

1. Какие уязвимости найдены.
2. Какие уязвимости исправлены.
3. Какие изменения внесены в код.
4. Какие средства защиты использованы и почему.
5. Какие тесты действительно выполнены.
6. Какие тесты пройдены и какие провалены.
7. Какие проблемы остались.
8. Какие дополнительные расходы могут потребоваться.
9. Как собрать защищённую Release-версию.
10. Где находится итоговый .exe, если ты действительно смог его собрать.
11. Какие файлы были изменены.
12. Какие действия должен выполнить я вручную.

Для каждого важного результата указывай подтверждение:
вывод теста, результат сборки, изменённый файл или другой
проверяемый артефакт.

ОСОБО ВАЖНЫЕ ПРАВИЛА:

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

НАЧНИ С ПОЛНОГО АУДИТА ПРОЕКТА.
СНАЧАЛА ИССЛЕДУЙ АРХИТЕКТУРУ И СОСТАВЬ ПЛАН.
ЗАТЕМ ПОЭТАПНО ВНЕДРЯЙ ЗАЩИТУ, СОБИРАЙ ПРИЛОЖЕНИЕ
И ПРОВЕРЯЙ РЕЗУЛЬТАТЫ.

Моя цель — получить максимально устойчивое к взлому приложение
с работающей лицензией, сохранив его функциональность.