SilentBless
🔧 Что можно улучшить в stalcraft-jvm-optimization
В коде и README есть несколько мест, где реализацию можно сделать не только быстрее, но и безопаснее.
—
1. Архитектура и поведение
A. IFEO-хук (главный риск)
Сейчас проект прописывает Debugger в HKLM (IFEO), из-за чего wrapper.exe перехватывает запуск:
- stalcraft.exe
- stalcraftw.exe
Это удобно, но архитектурно спорно.
⚠️ Проблема:
- требует админ-права
- создаёт системный launch-hook
- wrapper.exe становится точкой полного доверия
- при подмене бинарника можно выполнить любой код
💡 Лучше:
- использовать обычный launcher (exe/батник/ярлык)
- запускать игру через него
- IFEO оставить как опциональный режим
Это:
- снижает риск
- убирает зависимость от реестра
- уменьшает вероятность ложных срабатываний античитов и AV
—
B. Large Pages
В README заявлена поддержка large pages, но в коде используется только проверка через GetLargePageMinimum.
⚠️ Проблема:
- это проверка поддержки API, а не наличия привилегии
- флаг -XX:+UseLargePages может включаться впустую
💡 Лучше:
- проверять SeLockMemoryPrivilege
- включать large pages только если доступ реально есть
—
C. Агрессивный “буст” процесса
Используются:
- SetProcessPriorityBoost
- NtSetInformationProcess (memory / I/O priority)
⚠️ Проблема:
- может ухудшать отзывчивость системы
- возможны конфликты с античитами
- не всегда даёт реальный прирост
💡 Рекомендация:
—
D. Аргументы командной строки
Сборка command line реализована не идеально.
⚠️ Проблема:
- возможны ошибки с кавычками
- некорректный парсинг спецсимволов
💡 Лучше:
- использовать корректный Windows-safe quoting
—
E. Передача окружения
Сейчас передаётся полный os.Environ().
⚠️ Проблема:
- передаются лишние переменные
- возможны чувствительные данные
💡 Лучше:
- использовать whitelist:
- PATH
- SystemRoot
- JAVA_*
- только необходимые переменные
—
F. Работа с IFEO
При установке Debugger просто перезаписывается.
⚠️ Проблема:
- можно потерять старое значение
💡 Лучше:
- сохранять предыдущее значение
- восстанавливать его при uninstall
—
2. Есть ли здесь малварь?
По исходникам:
✔ нет сетевых запросов
✔ нет webhook / URL
✔ нет кода стиллера
📌 Вывод:
В коде нет признаков вредоносного ПО.
Но:
⚠️ IFEO делает wrapper.exe точкой выполнения кода до запуска игры.
—
3. Можно ли полностью исключить вредонос?
Нет.
Если скомпрометирован:
- релиз
- CI
- ключ подписи
- или система пользователя
→ защита не абсолютна.
Но можно сильно снизить риск.
—
4. Как защититься
Лучший вариант
- брать конкретный commit / tag
- собирать бинарник самостоятельно
- не использовать готовый wrapper.exe
—
Альтернатива
- проверять SHA-256
- использовать reproducible build
- сравнивать бинарники
—
Что должен сделать разработчик
- фиксировать версию Go
- использовать детерминированную сборку
- публиковать SHA-256
- подписывать релизы
- использовать защищённый CI
- добавить provenance / attestation
—
5. Практическая схема использования
Если ты пользователь
Оптимальный вариант:
- Не доверять Releases
- Брать конкретный commit
- Собирать самому
- Использовать свой бинарник
- По возможности не использовать IFEO
—
Если ты разработчик / делаешь форк
Рекомендуется:
- сделать IFEO опциональным
- добавить reproducible build
- публиковать hash’и
- подписывать теги
- использовать защищённый CI
—
6. Итог
✔ Проект сам по себе не является стиллером
✔ Код достаточно прозрачный
⚠️ Основной риск:
wrapper.exe становится критической точкой выполнения кода.
📌 Рекомендация:
- использовать launcher
- или собирать проект самостоятельно
—
Коротко:
Это не малварь, но архитектура требует осторости
