DFIR в Minecraft: расследование и выявление читов (1.8–1.21.11)

1. Основы DFIR для Minecraft и модель угроз читов

Основы DFIR для Minecraft и модель угроз читов

Зачем в Minecraft нужен DFIR

DFIR (Digital Forensics and Incident Response) — это дисциплина, которая объединяет:

Incident Response: быстрое реагирование на инцидент (подозрение на читы), чтобы остановить ущерб и зафиксировать факты

Digital Forensics: аккуратный сбор и анализ цифровых следов так, чтобы выводы были проверяемыми и воспроизводимыми

В контексте Minecraft DFIR нужен, чтобы:

отличать реальные читы от лагов, багов версии, особенностей модов и ошибочных обвинений

понимать что именно было использовано (external/internal), когда и как

иметь доказательную базу, которую можно объяснить игроку, администратору, античит-команде

В этом курсе мы рассматриваем версии 1.8–1.21.11, потому что они покрывают разные эпохи клиента: старые сборки с другими паттернами модов/инжектов и современную экосистему лаунчеров, модлоадеров, оверлеев и телеметрии.

Базовые понятия и термины

Инцидент

Инцидент — это событие, которое нарушает правила сервера/турнира или политику честной игры: например, подозрение на KillAura, TriggerBot, Reach, BHop, AutoClicker, X-Ray и т.д.

Артефакт

Артефакт — это любой след, который помогает подтвердить или опровергнуть гипотезу. Для Minecraft это могут быть:

логи клиента и лаунчера

список процессов и модулей в памяти

файлы модов/ресурс-паков/конфигов

сетевые признаки (подключения, прокси, VPN-клиенты)

следы оверлеев и перехватчиков ввода

Гипотеза и проверяемость

DFIR начинается с гипотезы (“использовался чит X”) и заканчивается выводом, который:

опирается на наблюдаемые факты

воспроизводим: другой проверяющий по тем же артефактам может прийти к тем же выводам

отделяет доказательства от интерпретации

Что такое “чит” с точки зрения DFIR

В учебном смысле чит — это инструмент или модификация среды, которая дает игроку преимущество, нарушая правила.

Важно различать:

функцию (например, автокликер)

реализацию (external macro, драйверный кликер, мод, инжект)

канал воздействия (ввод, память процесса, рендер, сеть)

Одна и та же функция может быть реализована разными способами — и артефакты будут отличаться.

Классы читов: External и Internal

External (внешние)

External-читы работают вне процесса игры. Они не обязаны внедряться в javaw.exe (Java Edition) или в процесс Bedrock.

Типичные механики:

эмуляция ввода (автокликер, макросы)

чтение экрана и распознавание (реже, но встречается)

оверлеи поверх игры (иногда легитимные, иногда читерские)

использование сетевых инструментов (прокси, туннели, манипуляции маршрутом) как части схемы

Почему это важно: внешние читы часто оставляют меньше следов в модулях Minecraft, но оставляют следы в системе (процессы, хуки ввода, устройства, конфиги, автозапуск).

Internal (внутренние)

Internal-читы взаимодействуют внутри процесса игры (или его адресного пространства): моды, инжекты, загрузчики, агенты.

Типичные механики:

инжект DLL/so/dylib (в зависимости от ОС и типа клиента)

модификация JVM/Bytecode (Java Agent), JNI-интеграции

подмена классов, миксины, модлоадеры

чтение/изменение памяти для получения позиций, хитбоксов, таймингов

Почему это важно: внутренние читы чаще оставляют артефакты в памяти процесса, в списке модулей/классов, в файлах клиента и конфигурациях.

Модель угроз: кто, что атакует и где остаются следы

Модель угроз помогает не “искать все подряд”, а понимать:

кто противник (обычный игрок, “продвинутый” читер, продавец читов)

какая цель (PvP преимущество, обход античита, скрытность)

какие возможности (админ-доступ, драйверы, приватные сборки)

какие следы неизбежны (файлы, процессы, сеть, логи, тайминги)

Участники и активы

Активы, которые вы защищаете (или проверяете на компрометацию):

честность PvP/PvE (тайминги ударов, reach, movement)

результаты турниров/ивентов

репутация сервера и античит-системы

безопасность проверяющего процесса (чтобы проверка не стала “охотой на ведьм”)

Участники:

игрок (может быть честным или читером)

проверяющий (DFIR-роль)

античит (серверный, клиентский, гибридный)

ОС и окружение игрока (драйверы, оверлеи, лаунчеры)

!Диаграмма показывает, где работают external/internal и какие категории артефактов обычно проверяют.

Поверхности атаки (что чит “трогает”)

В Minecraft чаще всего встречаются такие поверхности:

Ввод

1. Автокликеры и макросы (реальные или драйверные) 2. Хуки низкого уровня для мыши/клавиатуры 3. Виртуальные устройства

Графика и оверлеи

1. DirectX/OpenGL оверлеи, захват экрана 2. Наложение ESP-подсказок

Процесс игры

1. Инжекты/агенты 2. Модификация классов/методов 3. Подмена библиотек или загрузчиков

Файловая система

1. Моды, конфиги, бинды 2. Подозрительные лаунчеры/обфусцированные загрузчики

Сеть

1. Туннели, прокси, “ускорители” 2. Сопутствующие соединения чит-клиента (обновления, авторизация)

DFIR-цикл проверки: от подозрения до отчета

Ниже — базовый цикл, который мы будем разворачивать в следующих статьях.

Выявление (Detect)

Сигналом могут быть:

античит-алерты

жалобы игроков

статистические аномалии

поведенческие паттерны (например, стабильный CPS/тайминг)

Задача этапа: сформулировать проверяемую гипотезу.

Сохранение (Preserve)

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

Что обычно важно:

фиксировать время (часовой пояс, локальное время)

не запускать лишние “чистилки”, которые уничтожат следы

документировать, что именно делали во время проверки

Сбор (Collect)

Сбор зависит от модели угроз: если подозрение на internal — приоритет памяти/модули/файлы клиента; если external — приоритет ввода/процессов/автозапуска.

Примеры источников (без привязки к конкретным утилитам — инструменты будут позже):

логи Minecraft/лаунчера

список процессов и их командные строки

автозагрузка, службы, драйверы (если разрешено правилами)

содержимое .minecraft (mods, versions, libraries, logs, resourcepacks)

Анализ (Analyze)

Анализ — это сопоставление:

что должно быть в норме для конкретной версии/сборки

что есть фактически

какая гипотеза лучше всего объясняет набор артефактов

Отчет (Report)

Хороший отчет в Minecraft-DFIR:

отделяет факты от выводов

перечисляет проверенные источники

указывает ограничения (что нельзя было проверить)

объясняет вывод понятным языком

Почему важно учитывать версию 1.8–1.21.11

Проверка “одним шаблоном” для всех версий приводит к ошибкам. Отличия могут быть в:

структуре папок и логов лаунчера

популярных модлоадерах и способах модификации

типичных чит-пакетах под конкретные PvP-версии (например, legacy PvP)

Практическое правило: сначала фиксируйте точную версию клиента и способ запуска (официальный лаунчер, сторонний лаунчер, модлоадер), и только потом выбирайте тактику сбора.

Границы, этика и законность

DFIR-проверка легко превращается в злоупотребление, если нет правил.

Обязательные принципы для курса:

добровольность и регламент: правила сервера/турнира должны описывать формат проверки

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

конфиденциальность: не распространять приватные данные игрока

воспроизводимость: любые выводы должны быть подтверждаемы артефактами

Полезные базовые документы по IR/форензике (для понимания терминологии и процесса):

NIST SP 800-61 Rev. 2 Computer Security Incident Handling Guide

NIST SP 800-86 Guide to Integrating Forensic Techniques into Incident Response

Что будет дальше в курсе

В следующих статьях мы будем углубляться в:

типовые артефакты external-читов (ввод, процессы, автозапуск)

типовые артефакты internal-читов (моды, агенты, инжекты, память)

построение чеклистов под разные версии клиента

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

2. Сбор и сохранение артефактов: клиент, система, сеть

Сбор и сохранение артефактов: клиент, система, сеть

Как эта тема продолжает DFIR-цикл

В предыдущей статье мы разобрали, что проверка на читы в Minecraft должна идти по DFIR-циклу: выявление → сохранение → сбор → анализ → отчет. Эта статья раскрывает два самых “ломких” этапа: сохранение и сбор артефактов.

Главная цель: получить проверяемые данные (их можно перепроверить) и воспроизводимые результаты (другой проверяющий, имея те же артефакты, придет к тем же выводам), не уничтожив следы.

Базовые принципы сохранения артефактов

Что такое “сохранение” в практическом смысле

Сохранение — это действия, которые удерживают артефакты в состоянии, максимально близком к тому, каким оно было во время инцидента.

Ключевые правила:

Минимум изменений: чем меньше вы запускаете “лишнего”, тем меньше вы затираете следы.

Последовательность: сначала фиксируйте самое “летучее”, потом — стабильное.

Прозрачность: все действия должны быть записаны, чтобы их можно было объяснить.

“Летучие” и “нелетучие” артефакты

Чтобы не собирать в неправильном порядке, делите артефакты на две группы:

Летучие: легко меняются или исчезают при закрытии игры/перезагрузке.

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

Нелетучие: обычно сохраняются на диске.

- Примеры: логи лаунчера, содержимое .minecraft, конфиги, файлы модов, папки версий.

Практическое правило: если есть риск, что игрок сейчас закроет игру или перезагрузит ПК, приоритет у летучих данных.

Цепочка хранения (chain of custody)

Цепочка хранения — это короткий журнал, который отвечает на вопросы:

Кто собирал артефакты.

Когда собирал (время и часовой пояс).

Где хранил.

Что делал с файлами дальше (копировал, архивировал, передавал).

Даже в “серверной” проверке Minecraft это важно: без цепочки хранения любые доказательства легко оспорить как “подмененные”.

Контроль целостности: хэш-суммы

Хэш-сумма — это строка, вычисленная из содержимого файла. Если файл изменился хотя бы на 1 байт, хэш-сумма обычно станет другой.

Зачем это нужно:

Чтобы доказать, что файл после изъятия не менялся.

Чтобы корректно сравнивать артефакты между проверками.

Для практики удобно фиксировать хэши средствами ОС (например, PowerShell Get-FileHash на Windows: Документация Get-FileHash).

Подготовка к сбору: границы, согласие, объем

Проверка на читы почти всегда затрагивает приватные данные. До старта определите рамки.

Минимально достаточный объем

Собирайте только то, что нужно для гипотезы.

Пример:

Подозрение на internal (инжект/мод): приоритет у файлов клиента, папок модов, логов, признаков вмешательства в процесс.

Подозрение на external (автокликер/макрос/оверлей): приоритет у процессов, автозапуска, следов ПО ввода и оверлеев, а также сетевых признаков.

Документирование контекста

Перед сбором зафиксируйте:

Версию Minecraft (например, 1.8.9 или 1.21.1).

Тип клиента и способ запуска: официальный лаунчер, сторонний лаунчер, модлоадер.

ОС игрока (Windows/macOS/Linux).

Время, часовой пояс и источник времени.

Три источника артефактов: клиент, система, сеть

!Диаграмма показывает, откуда собирать артефакты и как они сходятся в единое хранилище доказательств

Артефакты клиента Minecraft

Где обычно лежит клиентская часть

Для Java Edition основной “узел” — папка .minecraft.

Полезная справка по структуре: Minecraft Wiki: .minecraft.

Типичные пути:

| ОС | Типичный путь | Что важно | |---|---|---| | Windows | %AppData%\.minecraft | logs, mods, versions, resourcepacks, shaderpacks, config | | macOS | ~/Library/Application Support/minecraft | то же, плюс лаунчерные логи рядом | | Linux | ~/.minecraft | то же |

Если используется сторонний лаунчер, путь может отличаться. Поэтому фиксируйте фактический путь (из настроек лаунчера или из командной строки процесса javaw.exe).

Что собирать в первую очередь

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

Логи игры

1. logs/latest.log и архивы в logs/. 2. Цель: увидеть загрузку модов, ошибки, необычные параметры запуска, сообщения модлоадеров.

Состав клиента

1. Папки mods/, config/, libraries/, versions/. 2. Цель: определить, что реально подключалось.

Ресурс-паки и шейдеры

1. resourcepacks/, shaderpacks/. 2. Цель: исключить спорные случаи (например, “легитные” пакеты, которые дают преимущество, если правила это запрещают).

Файлы аккаунта и лаунчера (аккуратно)

1. Собирать только если регламент это разрешает. 2. Цель: подтвердить способ входа, источник сборки клиента, время запуска.

Важные нюансы по версиям 1.8–1.21.11

Разница не только в “папках”, а в экосистеме.

Для 1.8–1.12 чаще встречаются “legacy PvP” сборки с набором модов, где чит может маскироваться под обычный мод.

Для 1.13+ и особенно 1.16+ чаще встречаются современные модлоадеры и более сложные схемы внедрения, поэтому возрастает роль:

1. точного списка загруженных модов; 2. параметров запуска JVM; 3. подтверждения соответствия библиотек ожидаемым.

Практическое правило: вывод “это чит” нельзя строить только на названии файла. Нужна корреляция: файл + лог загрузки + поведение.

Что считается “подозрительным” артефактом на стороне клиента

Подозрительный артефакт — это не “вещь, которая мне не нравится”, а несоответствие ожидаемому профилю.

Примеры типовых несоответствий:

Моды, которые:

1. не заявлены в регламенте; 2. скрывают следы (например, агрессивная очистка логов); 3. добавляют автоматизацию боевки или движение.

Необычные параметры запуска Java (например, нестандартные агенты).

Разные “версии” одной и той же сборки, которые не объясняются обновлениями.

Артефакты системы (ОС)

Системные артефакты особенно важны для external читов: автокликеры, макросы, оверлеи, хуки ввода, “помощники” для мыши.

Минимальный системный сбор (без сложных инструментов)

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

Список процессов и командные строки

1. Цель: увидеть, что запущено параллельно с Minecraft и как именно запущен javaw.exe.

Автозагрузка

1. Цель: найти резидентные компоненты, которые стартуют с системой.

Службы и драйверы (если это разрешено регламентом)

1. Цель: выявить низкоуровневые кликеры или перехватчики.

События ОС (логи)

1. Цель: косвенно подтвердить установки/запуски и время активности.

Ссылки на базовые системные журналы Windows:

Microsoft Learn: Windows Event Log

“Летучая” фиксация системы во время инцидента

Если проверка идет “по горячим следам”, порядок обычно такой:

Зафиксировать текущее время и часовой пояс.

Снять список процессов.

Снять активные сетевые подключения.

Только затем переходить к копированию файлов клиента.

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

Что искать в системе под разные гипотезы

Ниже — ориентиры, которые помогают не распыляться.

| Гипотеза | Что чаще дает след | Примеры системных следов | |---|---|---| | Автокликер/макрос | Ввод и резидентные процессы | фоновый процесс, автозапуск, ПО мыши с макросами | | Оверлей/ESP | Графический стек и процессы | оверлейный процесс, захват экрана, внедрение в графический рендерер | | Internal (инжект/агент) | Процесс игры и параметры запуска | необычные аргументы запуска JVM, сторонние библиотеки рядом с клиентом | | “Чистилка следов” | Файловые операции и поведение | резкое исчезновение логов, недавние очистки, несоответствие времени |

Важно: сам факт наличия “софт для мыши” не доказывает читы. Это повод сузить анализ: проверять профили, бинды, активность во время игры, соответствие правилам.

Артефакты сети

Сеть полезна в двух сценариях:

читу нужно соединение (лицензия, обновления, панель управления);

игрок использует туннели/прокси/VPN в обход правил или как часть “схемы”.

Что собирать из сети на уровне ОС

Активные подключения и слушающие порты

1. Цель: понять, какие процессы общаются снаружи во время игры. 2. Справка по netstat на Windows: Microsoft Learn: netstat.

DNS-кэш (если разрешено)

1. Цель: увидеть домены, к которым обращались (иногда там всплывают сервисы читов).

Конфигурация прокси и VPN

1. Цель: подтвердить факт использования и время активности, если правила это запрещают.

Ограничения сетевых артефактов

Сетевые признаки редко дают “железное” доказательство сами по себе.

Типовые причины:

Домены могут быть общими (CDN, облака).

Чит может работать офлайн.

Игрок может использовать VPN по легитимной причине.

Правильное использование сети в DFIR-проверке — это корреляция: сеть подтверждает или опровергает гипотезу вместе с клиентом и системой.

Практический порядок сбора: от меньшего вмешательства к большему

Ниже — универсальная схема, которую можно адаптировать под регламент.

Зафиксировать контекст

1. Кто проверяет, кого проверяют. 2. Время, часовой пояс. 3. Версия Minecraft и способ запуска.

Собрать летучие артефакты

1. Процессы и их параметры. 2. Активные сетевые подключения.

Собрать клиентские артефакты

1. Логи. 2. mods/, config/, versions/ и связанные папки.

Собрать системные артефакты

1. Автозагрузка. 2. Службы/драйверы (если разрешено). 3. События ОС (при необходимости).

Упаковать и зафиксировать целостность

1. Сделать копию в отдельную папку. 2. Посчитать хэш-суммы важных файлов. 3. Записать в журнал действий.

Как упаковывать артефакты, чтобы их было удобно анализировать

Рекомендуемая структура “папки дела”:

00_notes — текстовый журнал действий (кто/когда/что сделал).

10_client — .minecraft (или его часть по регламенту).

20_system — процессы, автозагрузка, логи ОС.

30_network — подключения, DNS, сведения о VPN/прокси.

90_hashes — файл со списком хэш-сумм.

Смысл структуры: чтобы при разборе не “перемешивать” источники, а также проще объяснять выводы в отчете.

Типовые ошибки проверяющих

Сразу просить игрока “почистить папку” или “удалить лишнее”. Это уничтожает доказательства.

Полагаться на один артефакт.

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

Не фиксировать время и часовой пояс.

1. Тогда таймлайн становится спорным.

Не записывать свои действия.

1. Любое действие проверяющего тоже меняет систему и должно быть отражено.

Правовые и этические рамки

Эта статья описывает общий DFIR-подход и не заменяет регламент сервера или турнира. Перед сбором должны быть ясны:

добровольность проверки и последствия отказа;

список разрешенных источников (что можно собирать, а что нельзя);

правила хранения и удаления данных.

Полезные основы по интеграции форензики в реагирование:

NIST SP 800-86 Guide to Integrating Forensic Techniques into Incident Response

NIST SP 800-61 Rev. 2 Computer Security Incident Handling Guide

Что дальше

В следующих материалах курса мы будем углублять анализ по двум направлениям:

артефакты external читов: ввод, макросы, оверлеи, автозапуск, системные следы;

артефакты internal читов: модлоадеры, агенты, инжекты, признаки вмешательства в процесс и в клиентскую сборку.

3. Анализ Internal читов: моды, инжекты, Java-артефакты

Анализ Internal читов: моды, инжекты, Java-артефакты

Как эта тема связана с предыдущими статьями

В первых двух материалах курса мы:

описали модель угроз читов (external и internal) и DFIR-цикл проверки

разобрали, как правильно сохранить и собрать артефакты с клиента, системы и сети

Теперь переходим к этапу анализа для класса internal: когда преимущество достигается за счет вмешательства внутрь клиента Minecraft (чаще всего Java Edition) — через моды, модлоадеры, Java Agent, инжект через JNI и похожие техники.

Цель этой статьи: дать воспроизводимый подход, который позволяет:

отделять легитимную модификацию от чит-механик

объяснять выводы через конкретные артефакты (логи, параметры запуска, состав модов, содержимое JAR)

учитывать разницу версий 1.8–1.21.11

!Иллюстрация связывает механизмы internal читов с тем, где они оставляют следы

Что считается internal читом в практическом DFIR

Internal чит — это не обязательно “DLL-инжект” в классическом смысле. В Minecraft Java Edition типовые варианты такие:

чит как мод (Forge/Fabric/Quilt/NeoForge)

чит как модификация загрузки (tweaker, coremod, launchwrapper-подмена в старых версиях)

чит как Java Agent через -javaagent (подмена/инструментирование байткода)

чит через JNI/нативные библиотеки (например, мод грузит .dll/.so и получает низкоуровневые возможности)

Ключевой общий признак: чит получает доступ к внутренним данным клиента (позиции сущностей, тайминги, хитбоксы, пакеты, ввод) и/или изменяет внутреннюю логику клиента.

Базовый принцип анализа: сначала “что должно быть”, потом “что есть”

Internal-расследование ломается, если проверяющий не фиксирует “ожидаемый профиль”. Поэтому анализ удобнее вести в два слоя.

Ожидаемый профиль клиента

Ожидаемый профиль — это минимальный набор утверждений о норме для конкретной ситуации:

версия Minecraft и сборка (например, 1.8.9 Forge или 1.21.1 Fabric)

способ запуска (официальный лаунчер, Prism Launcher/Multimc-подобные, сторонний лаунчер)

разрешенные моды/клиенты по регламенту (например, OptiFine разрешен, minimap запрещен)

Фактический профиль по артефактам

Фактический профиль строится по доказательствам, а не по словам игрока:

что реально лежит в mods/, versions/, libraries/, config/

что реально загрузилось (по logs/latest.log и лаунчерным логам)

с какими аргументами запускалась JVM (командная строка javaw.exe)

Почти все сильные выводы по internal читам получаются из несоответствия между ожидаемым и фактическим профилем.

Где internal читы оставляют наиболее “говорящие” артефакты

Ниже — практичная карта источников (вы собирали их в предыдущей статье; здесь — как читать).

| Категория | Где смотреть | Что это доказывает | Типовые “красные флаги” | |---|---|---|---| | Логи игры | .minecraft/logs/latest.log и архивы в logs/ | факт загрузки модлоадера/модов/миксинов/ошибок | неизвестные моды, упоминания mixin/coremod/tweakClass не по профилю, попытки скрытия | | Состав модов | .minecraft/mods/ | что может быть загружено | обфусцированные имена, “helper/loader/update”, несоответствие регламенту | | Конфиги | .minecraft/config/ | как моды были настроены | бинды на функции (aim, aura), “режимы обхода”, профили под античит | | Версии и библиотеки | .minecraft/versions/, .minecraft/libraries/ | состав среды запуска | лишние/нетипичные библиотеки, подмены файлов, странные даты/структура | | Параметры JVM | командная строка процесса javaw.exe | факт использования агентов/особых опций | -javaagent, нестандартный classpath, подозрительные -D... флаги | | Нативные компоненты | рядом с модом/внутри JAR, временные папки | что выполнялся нативный код | .dll/.so/*.dylib, загрузка через JNI, странные имена |

Разница версий 1.8–1.21.11, которая реально влияет на расследование

Старые PvP-версии (1.8–1.12): launchwrapper, tweaker и “coremod-стиль”

Для legacy-версий типичны:

запуск через Launchwrapper и параметры вроде --tweakClass

наличие “ядровых” модификаций (в терминах экосистемы того времени) и более грубые способы вмешательства

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

Полезный признак: если вы видите в логах/аргументах запуска механизмы, характерные для моддинга, но игрок заявляет “ваниль/без модов”, это уже сильное несоответствие.

Современные версии (1.16+ и особенно 1.19–1.21): mixin-подход, Fabric/Quilt/NeoForge

В новых версиях легитимный моддинг широко использует:

Mixin как технику внедрения изменений

более сложные цепочки загрузки и больше библиотек

Это усложняет анализ: сам по себе факт наличия mixin — не “чит”. Важнее:

какие именно моды грузят миксины

что они меняют

есть ли признаки античит-ориентированных функций

Справочные материалы по экосистеме (для понимания терминов и типового устройства):

Документация Minecraft Forge

Fabric Wiki

SpongePowered Mixin (репозиторий)

Пошаговый метод анализа internal артефактов

Ниже — схема, которая хорошо работает как чеклист и при этом остается воспроизводимой.

Триаж: подтвердить тип клиента и модлоадер

Сначала ответьте на вопросы:

Java Edition или Bedrock (в этой статье фокус на Java)

есть ли модлоадер и какой (Forge/Fabric/Quilt/NeoForge)

это “чистая” версия или сборка

Практически это делается через:

строки в latest.log (обычно там явно видно, что стартовал Forge/Fabric и какие моды нашлись)

наличие характерных папок и файлов в .minecraft

Если модлоадер есть, следующий шаг — точно перечислить, что он загрузил.

Составить модлист и сопоставить его с логами

Ошибочный, но частый подход — смотреть только на папку mods/. Правильнее строить тройную связку:

mods/ как “что лежит на диске”

latest.log как “что реально загрузилось”

config/ как “как это было настроено”

Что фиксировать в модлисте:

имя файла

версию (если видно из метаданных/лога)

источник/модлоадер (Forge/Fabric)

наличие зависимостей (в новых версиях часто мод не стартует без библиотек)

Типовая DFIR-логика:

если файл есть, но в логе нет загрузки — это не доказательство использования, но повод проверить, почему он не грузился

если в логе мод есть, а на диске его “нет” — вероятны удаления/подмены после инцидента или нестандартный путь модов

Анализ конфигов: где прячутся “режимы обхода”

Конфиги сами по себе редко “доказывают” чит, но часто объясняют поведение.

Что искать в конфиге подозрительного мода:

бинды на включение функций

профили “legit/ghost”

параметры, связанные с PvP: автоклик, рич, поворот камеры, таргетинг

упоминания античитов и “обходов”

Важно: не делайте вывод по одному слову. Подтверждайте конфигом то, что вы уже видите в модлисте и логах.

Проверка параметров запуска JVM: Java Agent и “нестандартная” среда

Командная строка javaw.exe — один из самых сильных артефактов, потому что показывает, что именно разрешили JVM при старте.

Что такое Java Agent простыми словами

Java Agent — это механизм, который позволяет подключить код, меняющий или наблюдающий классы Java при загрузке. Подключается аргументом -javaagent:путь_к_файлу.jar.

С точки зрения DFIR:

наличие -javaagent — это факт (артефакт уровня запуска)

“зачем он” — это интерпретация, которую нужно подтвердить анализом содержимого JAR и корреляцией с логами

Официальная справка по механизму инструментирования:

Java Instrumentation API (java.lang.instrument)

Справка по параметрам запуска java

Какие аргументы запуска чаще всего требуют внимания

Ниже — примеры категорий аргументов, которые стоит выделять в отчете (не как “чит”, а как “требует объяснения и проверки”):

-javaagent:... (подключение агента)

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

нетипичный -classpath или нестандартные пути библиотек

Сильный вывод получается, когда:

в аргументах есть агент

на диске найден JAR агента

в логах видны эффекты его работы (или, наоборот, аномально “пустые” логи при активном моддинге)

Статический анализ подозрительного JAR (мод/лоадер/агент)

В рамках Minecraft-проверок часто достаточно легкого статического анализа, не превращая проверку в полноценный reverse engineering.

Что полезно извлечь из JAR:

META-INF/MANIFEST.MF (что заявлено как Main-Class, Premain-Class для агентов)

структуру пакетов (слишком общие имена, обфускация, “loader/update/auth” как маркеры риска)

наличие нативных файлов внутри JAR или рядом с ним

Практическое правило формулировки:

факт: “в JAR присутствует Premain-Class, значит он может работать как Java Agent”

факт: “внутри JAR найден *.dll”

вывод: “компонент может внедряться в загрузку классов/использовать нативный код”

Признаки внедрения через Mixin: не “наличие”, а “кто и что меняет”

Mixin — легитимная техника моддинга, поэтому анализ строится так:

определяем мод(ы), которые используют mixin

проверяем, соответствуют ли эти моды разрешенному списку

смотрим в логах, какие миксины применялись и были ли ошибки/предупреждения

Если мод запрещен регламентом, то задача DFIR — корректно доказать, что:

мод присутствовал

мод реально загрузился

его конфигурация/поведение соответствует нарушению

JNI и нативные компоненты: почему это важно для читов

Некоторые internal решения уходят в нативный код, потому что так проще:

скрывать логику

взаимодействовать с системой (ввод, хуки, защита/обфускация)

Что фиксировать как артефакты:

факт наличия .dll/.so/*.dylib

связь с модом (лежит рядом, упоминается в конфиге или логах)

время появления файла (по метаданным файловой системы, если это разрешено регламентом)

При этом помните: нативные библиотеки бывают и у легитимных модов (например, оптимизация/звук). Важна корреляция с другими признаками.

Корреляция: как превращать “находки” в доказательную картину

Хороший internal-анализ почти всегда выглядит как связка из нескольких источников.

Примеры сильных корреляций:

мод лежит в mods/ + мод указан как загруженный в latest.log + конфиг содержит PvP-автоматизацию

в командной строке есть -javaagent + агент-JAR найден на диске + в манифесте агента есть Premain-Class

в моде найден нативный компонент + в логах есть строки о загрузке нативной библиотеки + процесс параллельно имеет нетипичные связи (если это собиралось по регламенту)

Примеры слабых одиночных индикаторов (их нельзя превращать в бан “в одиночку”):

“подозрительное название файла” без подтверждения загрузки

“есть Fabric/Forge” (модлоадер не равен читу)

“внутри много обфусцированного кода” (встречается и у легитимных проектов)

Как оформлять вывод по internal читам в отчете

Структура, которая помогает отделять факты от интерпретации:

контекст проверки (версия, регламент, способ запуска)

перечисление проверенных источников (логи, mods, config, параметры запуска)

факты с цитированием артефактов (имя файла, путь, фрагмент лога)

вывод с уровнем уверенности и ограничениями (что не удалось проверить)

Формулировки, которые повышают качество отчета:

“обнаружено и подтверждено загрузкой” вместо “точно использовал”

“не удалось подтвердить загрузку” вместо “не чит”

“признак требует объяснения” для спорных и неоднозначных находок

Этика и безопасность при анализе модов и агентов

Internal-анализ может легко затронуть приватные данные (аккаунты, токены, личные файлы), поэтому:

анализируйте только то, что входит в регламент

храните артефакты в структуре “папки дела” и фиксируйте хэши для целостности (как в предыдущей статье)

не передавайте JAR/конфиги третьим лицам без оснований и согласия

Что дальше по курсу

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

4. Анализ External читов: процессы, драйверы, макросы и устройства

Анализ External читов: процессы, драйверы, макросы и устройства

Как эта тема продолжает курс

В предыдущих статьях мы:

определили DFIR-цикл и модель угроз читов (external и internal)

разобрали сохранение и сбор артефактов (клиент, система, сеть)

изучили анализ internal читов (моды, инжекты, Java-артефакты)

Теперь переходим к анализу external читов: когда преимущество достигается вне процесса Minecraft, через системные компоненты, эмуляцию ввода, оверлеи, драйверы, резидентные сервисы и устройства.

Ключевая идея: при external-читах папка .minecraft может выглядеть чисто, а доказательства будут лежать в ОС: процессах, автозапуске, драйверах, событиях и следах виртуальных устройств.

!Схема показывает, на каких уровнях работают external-читы и где обычно остаются артефакты

Что такое external чит в практическом DFIR

External чит — это инструмент, который дает преимущество, не требуя модификации Java-клиента как мода или агента. Он может:

эмулировать или подменять ввод (автоклик, макросы, recoil-контроль)

накладывать визуальные подсказки (оверлеи) или захватывать экран

использовать низкоуровневые методы через драйверы или виртуальные устройства

работать как отдельный процесс, сервис или резидентный компонент

Важно различать:

функцию (например, автоклик)

канал реализации (пользовательский процесс, драйвер, виртуальная HID-клавиатура)

артефакты (что именно это оставляет в системе)

Модель угроз для external: от простого к сложному

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

Уровень 1: обычные пользовательские кликеры и макросы

Обычно это отдельные приложения, которые:

запускаются как обычный процесс

имеют настройки/профили/конфиги

часто попадают в автозапуск

Уровень 2: оверлеи и перехватчики ввода

Обычно это:

оверлейные процессы (включая легитимные, поэтому нужен контекст)

хуки ввода на уровне пользовательского режима

захват экрана или внедрение в графический стек (на Windows чаще через API-графики)

Уровень 3: драйверы, виртуальные устройства, “низкий уровень”

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

Типовые признаки:

установленные драйверы и сервисы, связанные с виртуальными HID

появление дополнительных устройств ввода

резидентные компоненты, которые стартуют до входа пользователя

Базовый принцип: external почти всегда доказывается корреляцией

Один артефакт редко достаточен.

Сильная связка обычно выглядит так:

Факт активности: процесс/сервис/драйвер реально работал во время игры.

Факт назначения: у компонента есть конфиги, профили, логика макросов или явная специализация.

Факт привязки ко времени: таймлайн совпадает с матчем/инцидентом.

Слабые одиночные индикаторы (ими нельзя заканчивать расследование):

“подозрительное название процесса”

“есть софт для мыши”

“есть VPN”

Источники external-артефактов

Эти источники вы собирали на этапе Collect; здесь — как их анализировать.

| Категория | Где смотреть | Что может подтвердить | Типовые красные флаги | |---|---|---|---| | Процессы | список процессов, командные строки | что работало параллельно с Minecraft | неизвестные резидентные утилиты ввода, странные пути запуска, запускаемые рядом с матчем | | Автозапуск | автозагрузка, планировщик задач | устойчивость и “скрытность” | автозапуск без внятного производителя, запуск из временных каталогов | | Службы | список сервисов | наличие резидентного компонента | сервис с неочевидной ролью, привязанный к вводу/устройствам | | Драйверы | список драйверов | низкоуровневые методы | драйвер без доверенного происхождения, драйвер виртуального устройства | | Устройства ввода | список HID и устройств | виртуальные/дополнительные устройства | появление виртуальной клавиатуры/мыши, несоответствие заявленной периферии | | Журналы ОС | события установки/запуска | таймлайн инсталляций и запусков | установка перед матчем, очистка следов | | Сеть | подключения и DNS (если собирали) | связь с панелями/лицензией/обновлениями | соединения процесса-кликера с внешними ресурсами |

Анализ процессов: что искать в списке процессов и командных строках

На Windows ключевая ценность — не только “имя процесса”, а:

путь к файлу

родительский процесс (кто запустил)

командная строка (аргументы)

время запуска (если доступно по собранным данным)

Рекомендация DFIR-формулировки: “процесс X был запущен из пути Y с аргументами Z” — это факт. “это чит” — это вывод, который нужно подтвердить дальше.

Типовые паттерны риска в процессах

Запуск из временных или пользовательских каталогов без признаков нормальной установки.

Частая смена имени файла при одинаковом размере/поведении (косвенно, если видно по множественным артефактам).

Связка “процесс + конфиг/профиль макросов” в соседней папке.

Наличие второй части: “loader/updater/auth” рядом с основным EXE.

Полезные справочные источники (Windows)

Для понимания, какие данные можно извлекать системно:

PowerShell Get-Process

PowerShell Get-CimInstance

Если регламент разрешает Sysinternals как стандартный инструмент диагностики:

Sysinternals Process Explorer

Автозапуск и устойчивость: где прячутся резидентные external-компоненты

External-читы часто стремятся переживать перезагрузку, поэтому автозапуск — один из самых результативных источников.

Что анализировать:

Точки автозагрузки пользователя (приложения, которые стартуют при входе).

Точки автозагрузки системы (сервисы, задачи, драйверы).

Логику запуска (по расписанию, при событии, при входе).

Красные флаги:

запуск из путей, которые не похожи на нормальную установку

отсутствие внятного издателя у исполняемого файла

задачи/запуски, замаскированные под системные

Справка по инструментам (Windows):

Sysinternals Autoruns

Windows Task Scheduler

Службы и драйверы: как аккуратно трактовать низкоуровневые следы

Почему драйверы важны именно для external

Драйверный уровень может использоваться, чтобы:

эмулировать ввод более “натурально” для античитов

перехватывать события устройств

создавать виртуальные устройства ввода

Но в DFIR-проверках Minecraft есть ограничение: многие легитимные компоненты (драйверы мыши, тачпада, ПО производителей) тоже работают на низком уровне.

Поэтому правильная логика такая:

Зафиксировать факт наличия драйвера/сервиса.

Привязать его к поставщику и назначению (по метаданным, пути, контексту установки).

Сопоставить с другими артефактами (процесс, конфиги, таймлайн).

Где искать сведения (Windows)

Официальные источники по драйверам и диспетчеру устройств:

Microsoft Learn: Device Manager

driverquery (Windows commands)

Практические “красные флаги” по драйверам и сервисам

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

Драйвер/сервис появился незадолго до турнира или жалобы.

Устройство ввода в системе стало “двойным”: физическая мышь плюс виртуальная.

Компонент явно связан с эмуляцией HID или перехватом ввода и не объясняется легитимным ПО.

Макросы и ПО периферии: как не перепутать легитимное и запрещенное

ПО производителей мышей/клавиатур может:

создавать профили и макросы

переключать DPI и бинды

имитировать последовательности нажатий

Это создает типичную спорную ситуацию: инструмент легитимен, но настройка может нарушать регламент.

Рекомендуемый DFIR-подход:

Зафиксировать наличие ПО (процессы, автозапуск, сервисы).

Найти и зафиксировать артефакты конфигурации (профили, файлы настроек), если регламент это допускает.

Отделить возможность от использования:

- возможность: “ПО поддерживает макросы” - использование: “существует активный профиль/скрипт, привязанный к кнопке, и он был включен в момент игры”

Устройства ввода и виртуальные HID: что означает “лишняя клавиатура”

External-инструменты иногда создают виртуальные устройства, чтобы генерировать ввод.

Что важно для анализа:

сколько устройств ввода видит ОС

когда они появились (по событиям установки, если доступно)

связаны ли они с подозрительным процессом/сервисом

Ограничение: само по себе наличие виртуального устройства не всегда нарушение, потому что виртуальные устройства встречаются у:

софта для удаленного доступа

некоторых программ доступности

драйверов производителя

Поэтому обязательна корреляция с таймлайном и процессами.

Сетевые признаки external: как использовать их без “натягивания”

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

Примеры полезных корреляций:

Процесс макрос/кликер активен во время матча и имеет внешние соединения (обновления, лицензия, панель управления).

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

Ограничения:

домены могут быть общими (CDN)

чит может работать офлайн

VPN может быть легитимным

Пошаговый метод анализа external-читов (воспроизводимый чеклист)

Ниже — методика, которая хорошо переносится между версиями Minecraft 1.8–1.21.11, потому что external живет на уровне ОС.

Собрать “ожидаемый профиль” системы и периферии

Какая ОС и версия.

Какая периферия заявлена (мышь/клавиатура), есть ли софт производителя.

Какие программы разрешены регламентом (например, запись экрана, оверлеи).

Построить “фактический профиль” по артефактам

Процессы во время инцидента и рядом по времени.

Автозапуск и планировщик.

Сервисы и драйверы (если их сбор разрешен).

Список устройств ввода (если разрешен).

Выделить кандидатов и собрать по ним “мини-досье”

Для каждого кандидата фиксируйте:

Имя и путь.

Признаки устойчивости (автозапуск/сервис/задача).

Связанные файлы конфигурации.

Связанные сетевые признаки (если есть).

Привязку ко времени матча.

Сформировать вывод через корреляцию

Сильный вывод обычно требует минимум двух независимых источников, например:

Процесс активен во время игры.

Есть автозапуск или профиль макросов.

Или:

Обнаружен сервис/драйвер, связанный с эмуляцией ввода.

Появилось виртуальное устройство ввода.

Как писать отчет по external, чтобы его было сложно оспорить

Структура отчета полезна та же, что и для internal, но акценты другие.

Рекомендуемая структура:

Контекст проверки (версия Minecraft, режим, регламент).

Проверенные источники (процессы, автозапуск, службы/драйверы, устройства, сеть).

Факты (с путями, именами, временем, выдержками из артефактов).

Интерпретация (почему это связано с гипотезой), с указанием ограничений.

Примеры корректных формулировок:

Факт: “во время матча работал процесс X из пути Y; присутствует автозагрузка Z”.

Вывод: “комбинация артефактов соответствует инструменту автоматизации ввода; прямых доказательств конкретной функции (например, CPS) из артефактов не извлечено”.

Типовые ошибки при расследовании external

Делать вывод по одному названию процесса без пути, времени и контекста.

Объявлять любой софт мыши “читом”, не проверив правила и конфигурацию.

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

Не фиксировать действия проверяющего (это ломает воспроизводимость).

Что дальше по курсу

После internal и external у вас есть две половины картины.

Следующий шаг в полном DFIR-подходе для Minecraft — научиться собирать единую линию событий и делать устойчивые выводы:

таймлайны (согласование времени, источников и последовательности)

объединение клиентских, системных и сетевых артефактов в одну доказательную модель

стандартизация чеклистов под разные регламенты и уровни доступа

5. Корреляция, атрибуция, отчет и цепочка хранения доказательств

Корреляция, атрибуция, отчет и цепочка хранения доказательств

Зачем нужна эта тема после internal и external анализа

В предыдущих статьях курса мы разобрали:

как устроен DFIR-цикл проверки в Minecraft и почему важно разделять external и internal читы

как собирать и сохранять артефакты с клиента, системы и сети

как анализировать internal (моды, агенты, Java-артефакты) и external (процессы, драйверы, макросы, устройства)

Эта статья закрывает практический разрыв между находками и решением.

Даже если вы нашли подозрительный мод, процесс или драйвер, вам все равно нужно уметь:

связать разные источники в единую картину (корреляция)

корректно ответить на вопрос кто и что сделал в допустимых рамках (атрибуция)

оформить результат так, чтобы его было сложно оспорить (отчет)

доказать, что артефакты не подменялись и не менялись после изъятия (цепочка хранения доказательств)

Это критично для версий 1.8–1.21.11, потому что внешняя оболочка клиента, модлоадеры и способы запуска менялись, а споры вокруг проверок остаются одинаковыми: что именно вы проверили, что именно нашли, насколько надежны выводы.

!Диаграмма показывает, как артефакты превращаются в выводы, и почему chain of custody поддерживает доверие к расследованию

Корреляция: как связать артефакты в доказательную картину

Что такое корреляция в Minecraft-DFIR

Корреляция это привязка разных наблюдений к одному событию или гипотезе.

Практически это ответы на вопросы:

какие артефакты относятся к одному и тому же периоду матча

какие артефакты относятся к одному и тому же инструменту

какие артефакты подтверждают друг друга независимо

Важное правило: один артефакт редко доказывает чит. Сильная позиция появляется, когда несколько источников дают согласованную картину.

Три опоры корреляции

#### Время Время связывает матч и действия на ПК.

Типовая проблема: источники времени разные.

логи Minecraft пишутся одним форматом

Windows Event Log фиксирует события по своему времени

лаунчерные логи могут иметь отдельные отметки

время на ПК может быть неверным

Практичный подход:

Фиксируйте часовой пояс и текущее время в начале проверки.

Для каждого источника отмечайте, как именно там записано время.

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

#### Сущность Сущность это объект, вокруг которого строится мини-досье.

В Minecraft-DFIR сущностями обычно являются:

мод или JAR (internal)

процесс, служба, драйвер (external)

профиль макросов или конфиг

конкретная сборка клиента и способ запуска

#### Механика Механика это способ получения преимущества.

автоматизация ввода

изменение логики клиента

визуальные подсказки и оверлеи

сетевые обходы правил

Корреляция должна показывать не только что найдено, но и как это связано с заявленной механикой.

Практическая матрица корреляции

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

| Артефакт | Источник | Что это подтверждает | Привязка ко времени | Связь с гипотезой | Ограничения | |---|---|---|---|---|---| | latest.log | клиент | загрузка модлоадера и модов | отметки времени в логе | показывает, что мод реально грузился | лог мог быть частично очищен | | командная строка javaw.exe | система | фактические параметры запуска JVM | время снятия процесса | показывает -javaagent или нестандартный classpath | снимок только на момент проверки | | запись автозапуска | система | устойчивость инструмента | время создания записи, если доступно | поддерживает гипотезу external | автозапуск не равен использованию | | активные подключения | сеть | активность инструмента и его связь с сетью | время снятия netstat | может подтвердить лицензирование или панель | чит может работать офлайн |

Смысл таблицы: отделить факт от интерпретации и сразу записать ограничения.

Примеры сильных корреляций

#### Internal: мод или агент Сильная связка обычно выглядит так:

Файл подозрительного мода или агента присутствует на диске.

В latest.log есть подтверждение, что он загрузился.

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

#### External: макросы или эмуляция ввода Сильная связка обычно выглядит так:

Процесс автоматизации работал во время матча или в непосредственной близости по времени.

Есть след конфигурации или профиля с макросами.

Есть признак устойчивости (автозапуск, задача планировщика, сервис) или признак привязки к устройству.

Частые ошибки корреляции

Коррелировать только по названию файла или процесса, игнорируя путь и контекст.

Делать вывод из наличия инструмента без привязки ко времени матча.

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

Атрибуция: что именно вы можете утверждать

Два уровня атрибуции

В Minecraft-DFIR важно разделять:

атрибуцию инструмента: что за инструмент или класс инструментов использовался

атрибуцию действия игроку: что игрок сознательно применял инструмент во время матча

Первое обычно доказать проще. Второе часто упирается в регламент и доступность артефактов.

Атрибуция инструмента: осторожные формулировки

Корректные выводы строятся как:

обнаружено: файл, процесс, сервис или драйвер существует

подтверждено использование: есть признаки запуска или загрузки в нужное время

соответствует механике: признаки конфигурации или поведения соответствуют запрещенной функции

Некорректные формулировки:

точно использовал чит X только потому, что найден файл

это 100% чит только по названию процесса

Атрибуция игроку: что может помочь

В рамках честной проверки (и без выхода за регламент) обычно помогают такие категории:

Привязка ко времени матча.

Признаки активности инструмента.

Признаки управления инструментом.

Примеры признаков управления:

активный профиль макросов, привязанный к конкретной кнопке

горячие клавиши, указанные в конфиге

запуск инструмента непосредственно перед игрой и закрытие после

Ограничение: даже эти признаки часто дают высокую вероятность, но не юридически абсолютную доказанность намерения. Поэтому в отчете важны уровни уверенности и перечисление ограничений.

Уровни уверенности в выводе

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

| Уровень уверенности | Что означает | Минимальная база | |---|---|---| | Низкая | есть индикатор, но мало подтверждений | один источник без привязки ко времени | | Средняя | есть корреляция из двух источников, но остаются альтернативные объяснения | два источника, ограниченная привязка | | Высокая | независимые источники согласованы и привязаны ко времени матча | минимум два независимых источника плюс таймлайн |

Важно: это не математика, а дисциплина формулировок. В отчете вы обязаны указать, почему выбран уровень и какие альтернативы остаются.

Цепочка хранения доказательств: как сделать артефакты доверенными

Что такое цепочка хранения

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

Цель: чтобы другой проверяющий мог ответить:

откуда взялись файлы

кто имел к ним доступ

менялись ли они после изъятия

Общий стандартный контекст инцидент-реагирования и форензики описан в документах NIST:

NIST SP 800-61 Rev. 2 Computer Security Incident Handling Guide

NIST SP 800-86 Guide to Integrating Forensic Techniques into Incident Response

Минимальный состав chain of custody для Minecraft-проверки

Даже в “серверной” практике можно вести минимальную форму.

Идентификатор дела.

Кто проверяет и кого проверяют.

Время начала и окончания сбора, часовой пояс.

Перечень артефактов и откуда они получены.

Где хранятся исходники и где рабочие копии.

Кто и когда получал доступ.

Хэши важных файлов.

Хэши: зачем и как их трактовать

Хэш нужен для проверки целостности.

Правильная логика:

Вы снимаете артефакт.

Сразу фиксируете хэш.

Дальше работаете с копией.

При споре пересчитываете хэш и сравниваете.

Практическая оговорка: хэш подтверждает неизменность файла, но не подтверждает “что файл честный” или “что это точно чит”. Он подтверждает, что ваш экземпляр не менялся.

Упаковка артефактов: разделяйте исходники и анализ

Рекомендуемая схема хранения (продолжает структуру из статьи про сбор):

evidence_original — то, что вы получили, не редактировать

evidence_working — копия для анализа

notes — журнал действий

hashes — хэши и контрольные списки

Критично: если вы распаковали архив, извлекли JAR или открывали файл, это должно происходить в evidence_working, а evidence_original должен оставаться неизменным.

Журнал действий проверяющего

Журнал нужен, потому что действия проверяющего тоже меняют систему.

Фиксируйте:

Какие команды запускались.

Какие окна открывались и какие файлы копировались.

Что было сделано со временем и часовым поясом.

Какие ограничения были (например, “запрещен сбор драйверов по регламенту”).

Отчет: как писать так, чтобы вас могли перепроверить

Главный принцип отчета

Отчет должен позволять другому человеку:

понять контекст

повторить анализ по тем же артефактам

увидеть, где заканчиваются факты и начинаются выводы

Мини-шаблон отчета (как текстовая заготовка)

Что особенно важно для споров по версиям 1.8–1.21.11

Типовые конфликтные точки, которые стоит закрывать прямо в отчете:

какой именно способ запуска использовался (официальный лаунчер или сторонний)

какой модлоадер и какие версии модов

что именно загрузилось (по логам), а что просто лежало в папке

какие системные артефакты относятся ко времени матча

Практический сценарий: как выглядит доказательная цепочка

Ниже пример, как связать в одну историю без “натягивания”.

Сценарий: подозрение на internal через агент или нестандартную загрузку.

В списке процессов зафиксирована командная строка javaw.exe с -javaagent:....

Указанный JAR агента найден на диске и добавлен в evidence_original.

В META-INF/MANIFEST.MF агента есть признак, что это агент (например, наличие поля для premain).

В latest.log присутствуют косвенные признаки модификации среды запуска или необычные загрузочные сообщения.

В отчете формулируется вывод: обнаружены и коррелированы артефакты, соответствующие подключению Java Agent; назначение требует интерпретации, но факт подключения подтвержден параметрами запуска и наличием файла; уровень уверенности зависит от наличия логов и контекста регламента.

Сценарий: подозрение на external автоматизацию ввода.

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

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

В автозапуске есть запись, которая объясняет резидентность.

В отчете фиксируются факты и ограничения: наличие инструмента и профиля подтверждено, но точные значения CPS по артефактам ОС могут быть недоступны без специализированных телеметрий, поэтому вывод формулируется по механике автоматизации и таймлайну.

Типовые ошибки, которые ломают доверие к проверке

Работать прямо в папке с исходными артефактами, меняя метаданные и содержимое.

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

Писать вывод как обвинение без перечисления источников и ограничений.

Смешивать факты и интерпретации в одном предложении.

Что дальше в курсе

После этой статьи у вас есть полный “сквозной” каркас проверки:

сбор и сохранение

анализ internal и external

корреляция и атрибуция

отчет и chain of custody

Следующий практический шаг для закрепления курса обычно делается через стандартизацию:

единые чеклисты под разные регламенты и уровни доступа

унификация форматов “папки дела”, хэшей и шаблонов отчетов

построение таймлайнов, которые выдерживают спорные случаи