Розробка AI-системи детекції чітерства Anti-Cheat

Уявіть: ви запускаєте рейтинговий матч у вашому шутері й за хвилину розумієте — ворог не промахується. Аімбот. Традиційні сигнатурні антічіти шукають відомі хеші DLL, але чітери оновлюють код за хвилини. Наш підхід — поведінковий аналіз. Ми дивимося не на код, а на дії: як гравець рухає мишу, як реагує на противників. Навіть новий, невідомий чіт видає себе аномаліями. Ми розробляємо AI-антічіти, які аналізують поведінку в реальному часі зі швидкістю до 128 вимірювань за секунду. За статистикою, до 30% матчів у популярних шутерах містять чітерів, і сигнатурні методи пропускають 90% нових читів. Згідно з аналітикою Newzoo, втрати від чітерів сягають 20% виручки ігрових проєктів. Наша система — ефективне рішення для online game cheat detection та AI cheating prevention.

Наші інженери мають досвід 8+ років у розробці анті-чітів для AAA-ігор. Ми працюємо під ключ: від аудиту поточного захисту до впровадження та підтримки. Отримайте безкоштовну консультацію — проаналізуємо логи та запропонуємо рішення.

Типологія чітерства та методи детекції

Чіти поділяються на кілька категорій, кожна потребує свого підходу до детекції. Розглянемо основні:

cheat_categories = {
    'aimbot': {
        'signatures': ['instant_target_acquisition', 'superhuman_accuracy',
                       'head_only_shots', 'tracking_through_walls'],
        'detection': 'mouse_movement_statistics + aim_curve_analysis'
    },
    'wallhack': {
        'signatures': ['preemptive_aiming_before_visible',
                       'shooting_at_enemy_position_before_reveal',
                       'unusual_rotation_to_enemies_behind_cover'],
        'detection': 'player_vs_enemy_visibility_analysis'
    },
    'speedhack': {
        'signatures': ['position_delta_exceeds_physics',
                       'animation_speed_mismatch'],
        'detection': 'server_side_movement_validation'
    },
    'triggerbot': {
        'signatures': ['fire_delay_too_consistent', '0ms_reaction_on_crosshair'],
        'detection': 'reaction_time_distribution_analysis'
    },
    'radar_hack': {
        'signatures': ['positioning_correlates_with_enemy_map_positions'],
        'detection': 'behavioral_correlation_analysis'
    }
}

Як працює детекція аімбота?

Аналізуємо траєкторію прицілу. Людина рухає мишу з варіаціями швидкості та ривками. Аімбот дає рівномірний рух, різкі стрибки до цілі та неприродно низьку дисперсію. Розраховуємо aimbot_score на основі кількох метрик:

• Кількість снапів (різких стрибків >99-го перцентиля швидкості) — у чітера їх у 10 разів більше.
• Точність після снапа — покращення позиціонування на 80-95%.
• Куртозис швидкості — у чітера >10, у людини 3-5.
• Коефіцієнт варіації швидкості — у чітера <0.1, у людини 0.3-0.6.

import numpy as np
from scipy import stats
import pandas as pd

def analyze_mouse_movement(aim_trajectory: np.ndarray,
                            target_positions: np.ndarray,
                            sampling_rate: int = 128) -> dict:
    """
    aim_trajectory: (N, 2) масив позицій прицілу за часом
    target_positions: (N, 2) позиції найближчої цілі
    """
    velocities = np.diff(aim_trajectory, axis=0) * sampling_rate
    speeds = np.linalg.norm(velocities, axis=1)

    speed_cv = np.std(speeds) / (np.mean(speeds) + 1e-9)
    jerk = np.diff(velocities, axis=0)
    jerk_magnitude = np.linalg.norm(jerk, axis=1)

    snap_indices = np.where(speeds > np.percentile(speeds, 99))[0]
    snap_events = len(snap_indices)

    if len(target_positions) > 0:
        errors_before_snap = []
        errors_after_snap = []
        for snap_idx in snap_indices:
            if snap_idx > 0 and snap_idx < len(aim_trajectory) - 1:
                before = np.linalg.norm(aim_trajectory[snap_idx-1] - target_positions[snap_idx-1])
                after = np.linalg.norm(aim_trajectory[snap_idx] - target_positions[snap_idx])
                errors_before_snap.append(before)
                errors_after_snap.append(after)

        avg_error_before = np.mean(errors_before_snap) if errors_before_snap else 0
        avg_error_after = np.mean(errors_after_snap) if errors_after_snap else 0
        snap_improvement = (avg_error_before - avg_error_after) / (avg_error_before + 1e-9)
    else:
        snap_improvement = 0

    aim_kurtosis = stats.kurtosis(speeds)

    aimbot_score = (
        0.3 * min(1, snap_events / 50) +
        0.3 * min(1, snap_improvement) +
        0.2 * min(1, max(0, aim_kurtosis - 5) / 20) +
        0.2 * max(0, 1 - speed_cv)
    )

    return {
        'aimbot_score': round(aimbot_score, 3),
        'snap_events': snap_events,
        'aim_kurtosis': round(aim_kurtosis, 2),
        'speed_cv': round(speed_cv, 3),
        'snap_accuracy_improvement': round(snap_improvement, 3)
    }

Чому поведінковий аналіз ефективніший за сигнатурний?

Сигнатури шукають конкретні рядки, хеші DLL або патерни пам'яті. Чітери змінюють код — і сигнатура застаріває за години. Поведінковий аналіз дивиться на те, як гравець діє: швидкість реакції, траєкторія прицілу, рух по карті. Навіть якщо чіт повністю переписаний, його поведінка залишиться аномальною. Наприклад, triggerbot стріляє із затримкою 0-5 мс, а людина — 150-400 мс. Для відрізнення машини від людини застосовуємо тест Шапіро-Уілка та порогові значення. Детальніше про aimbot.

def analyze_reaction_times(kill_events: pd.DataFrame) -> dict:
    """
    Реакція людини: 150-400 мс з нормальним розподілом.
    Triggerbot: 0-5 мс, занадто постійне (низький CV).
    """
    reaction_times = kill_events['reaction_time_ms'].values

    mean_rt = np.mean(reaction_times)
    std_rt = np.std(reaction_times)
    cv_rt = std_rt / (mean_rt + 1e-9)
    min_rt = np.min(reaction_times)

    _, normality_p = stats.shapiro(reaction_times[:50])

    triggerbot_flags = []

    if min_rt < 20:
        triggerbot_flags.append('ultra_fast_reaction')
    if cv_rt < 0.05:
        triggerbot_flags.append('suspicious_consistency')
    if mean_rt < 80:
        triggerbot_flags.append('below_human_threshold')

    triggerbot_score = len(triggerbot_flags) / 3

    return {
        'mean_reaction_ms': round(mean_rt, 1),
        'std_reaction_ms': round(std_rt, 1),
        'cv': round(cv_rt, 3),
        'min_reaction_ms': round(min_rt, 1),
        'triggerbot_score': triggerbot_score,
        'flags': triggerbot_flags
    }

Поведінковий аналіз wallhack

Wallhack виявляємо через кореляцію напрямку погляду з позиціями ворогів. Честний гравець повертається до ворога після того, як той стає видимим. Чітер — до, орієнтуючись на дані з пам'яті. Аналізуємо часовий зазор та кутове відхилення. Якщо гравець дивиться в бік прихованого ворога більш ніж за 500 мс до виявлення, це сильна ознака. Додаткова інформація: Wallhack.

def detect_wallhack_behavior(player_data: pd.DataFrame,
                               game_events: pd.DataFrame) -> dict:
    """
    Честний гравець повертається до ворога ПІСЛЯ того, як бачить його.
    Wallhack: поворот до прихованого ворога раніше, ніж він стає видимим.
    """
    suspicious_events = []

    for _, event in game_events[game_events['event_type'] == 'enemy_spot'].iterrows():
        enemy_visible_time = event['visible_timestamp']
        player_tracking = player_data[
            (player_data['timestamp'] >= enemy_visible_time - 2) &
            (player_data['timestamp'] <= enemy_visible_time)
        ]

        if len(player_tracking) > 0:
            direction_before = player_tracking.iloc[0]['view_direction']
            enemy_direction = event['enemy_direction']
            angle_error = abs(direction_before - enemy_direction)
            angle_error = min(angle_error, 360 - angle_error)

            if angle_error < 15:
                time_before_visible = enemy_visible_time - player_tracking.iloc[0]['timestamp']
                if time_before_visible > 0.5:
                    suspicious_events.append({
                        'event_id': event['event_id'],
                        'time_before_visible': time_before_visible,
                        'angle_error': angle_error
                    })

    wallhack_score = len(suspicious_events) / max(len(game_events), 1)
    return {
        'wallhack_score': round(wallhack_score, 3),
        'suspicious_events': suspicious_events,
        'wallhack_detected': wallhack_score > 0.3
    }

Кейс: економія бюджету на підтримку та зростання виручки

Один із наших клієнтів, гра з 2 млн активних гравців, втрачав 30% виручки через чітерів. Ми впровадили систему за 3 місяці. Після запуску кількість скарг на чітерів знизилася на 70%, а активні гравці стали витрачати на 15% більше часу в матчах. Витрати на ручну модерацію скоротилися вдвічі — це дало економію бюджету на підтримку $8,000 на місяць. Додаткова виручка від покращення retention склала $15,000 щомісяця. Кількість хибних спрацьовувань не перевищила 3%.

Сесійна ML-модель

Агрегуємо ознаки за весь матч: headshot ratio, accuracy, aimbot_score, triggerbot_score, рух по карті. Навчаємо XGBoost з вагами класів для рідкісних чітерів (співвідношення 1:20). Фінальна модель досягає AUC 0.99 на історичних даних.

from xgboost import XGBClassifier

def build_session_cheat_classifier(match_features_db: pd.DataFrame) -> XGBClassifier:
    """
    Ознаки за весь матч: headshot ratio, accuracy, position accuracy,
    kill assist patterns, movement entropy.
    """
    session_features = [
        'headshot_ratio', 'accuracy_pct', 'kd_ratio',
        'aimbot_score_avg', 'triggerbot_score_avg', 'wallhack_score_avg',
        'movement_entropy',
        'position_change_rate',
        'death_position_entropy',
        'spray_control_score'
    ]

    model = XGBClassifier(
        n_estimators=300,
        scale_pos_weight=20,
        eval_metric='aucpr'
    )
    model.fit(
        match_features_db[session_features],
        match_features_db['confirmed_cheater']
    )
    return model

Процес роботи

1. Аудит захисту — аналізуємо логи, визначаємо вразливості. Безкоштовно.
2. Проектування — обираємо архітектуру датчиків та модель детекції.
3. Реалізація — пишемо клієнтську телеметрію, серверну аналітику, ML-пайплайн.
4. Тестування — перевіряємо на історичних даних та в бойових матчах.
5. Деплой — розгортаємо на серверах, налаштовуємо моніторинг.

Що входить у роботу

• Архітектурна документація та опис датчиків.
• Вихідний код клієнтської та серверної частин.
• Навчена ML-модель зі звітом за метриками.
• Інтеграція з вашою системою логування.
• Навчання команди та документація для оператора.
• Технічна підтримка на 3 місяці з продовженням за SLA.
• Періодичне донавчання моделі на свіжих даних.

Терміни впровадження

Повноцінне рішення з поведінковим аналізом усіх видів читів та захистом від змагальних атак — від 3 до 4 місяців. Вартість розраховується індивідуально після аудиту вашої гри. Отримайте консультацію та попередню оцінку безкоштовно.

Захист від змагальних атак

Чітери додають випадковий шум до рухів миші — імітують людину. Контрзаходи: глибокі поведінкові ознаки (мікровібрації, патерни перемикання зброї), графовий аналіз взаємодій з іншими гравцями — чітери ігнорують випадкових. Community reporting: висока кількість скарг посилює розслідування. Ми гарантуємо адаптивність — модель донавчається на нових даних. Ми забезпечуємо AI cheating prevention через адаптивні моделі. ML-антічіт еволюціонує разом із загрозами.

Зв'яжіться з нами для аудиту вашого проєкту — проаналізуємо логи та запропонуємо рішення.

Виявлення аномалій: автоенкодери, Isolation Forest, PyOD

Ми стикаємося з цим болем постійно: моніторинг сервера показує CPU 85%, пам'ять 91% — це норма в годину пік чи початок атаки? Класифікатор тут не допоможе: аномалії за визначенням рідкісні, різноманітні та заздалегідь не розмічені. Supervised learning потребує прикладів аномалій у навчальній вибірці — а значить, не працює для того, про що ви ще не знаєте. Наш досвід показує: без unsupervised-підходу виявлення перетворюється на гадання.

Чому виявлення аномалій потребує unsupervised підходу?

Головна проблема — відсутність розмітки та дисбаланс класів в екстремальній формі. Фрод-транзакції становлять 0.01–0.1% від загального об'єму. Виробничий дефект — 0.5–3%. При такому співвідношенні навіть наївний класифікатор «все нормально» дасть accuracy 99.9% і precision/recall для аномального класу, близькі до нуля. Supervised-моделі тут безсилі.

Друга проблема — «нормальність» завжди контекстна. Чи нормально, що користувач логіниться о 3 годині ночі? Залежить від його історії та часової зони. Чи нормальна вібрація підшипника 2.3 мм/с? Залежить від режиму роботи верстата та його віку. Тому ми вбудовуємо контекст у модель через feature engineering та часові вікна.

Третя — оцінка якості. Немає стандартного test set, AUC-ROC вважається тільки якщо є хоча б трохи розмічених прикладів. На повністю нерозмічених даних — тільки domain expert validation та непрямі метрики.

Як відрізнити аномалію від шуму в реальному часі?

Відповідь — адаптивні пороги та моніторинг статистик моделі. У розділі кейсу покажемо, як це працює.

Методи та інструменти

Isolation Forest — стандартний baseline для табличних даних. Ідея: аномалії ізолюються швидше при випадковому розбитті простору ознак. Працює добре при contamination 0.01–0.1, стійкий до масштабу ознак, не потребує нормалізації. Реалізація в sklearn.ensemble.IsolationForest.

Типова помилка: ставити contamination='auto' без розуміння даних. Auto-режим передбачає поріг -0.5, що не завжди відповідає реальній частці аномалій. Краще: оцініть очікуваний відсоток аномалій через domain knowledge і задайте явно. Ми гарантуємо підбір contamination під ваш кейс.

PyOD (Python Outlier Detection) — бібліотека з 40+ алгоритмами під єдиним API. Включає: OCSVM, LOF, COPOD, ECOD, DeepSVDD, AutoEncoder. Зручно для швидкого порівняння методів на одних даних.

Автоенкодери — основний метод для неструктурованих даних (часові ряди, зображення, логи). Ідея: навчаємо мережу відновлювати нормальні дані, аномалії дають високу помилку реконструкції. Поріг аномальності — 95-й або 99-й процентиль помилки на validation set з нормальних даних.

Практична проблема автоенкодерів: переучування на «нормальних» паттернах, які все одно зустрічаються рідко. Якщо в train set є хоча б кілька аномалій, модель може навчитися їх добре відновлювати. Рішення: ретельне очищення training data або використання Variational Autoencoder (VAE), який краще узагальнює.

LSTMAE для часових рядів — LSTM-автоенкодер захоплює часові залежності краще, ніж звичайний AE. Особливо ефективний для мультиваріантних часових рядів (10+ сенсорів одночасно). Реалізація через PyTorch, навчання з MSELoss на ковзних вікнах.

Детально: виявлення аномалій у промислових часових рядах

Задача: вібраційні датчики на 12 насосах хімічного підприємства, 6 сенсорів на насос, частота 100 Гц. Потрібно попередити про наближену поломку за 4–24 години.

Архітектура рішення:

Сирові дані → feature extraction (RMS, куртозис, піковий фактор, FFT-амплітуди на резонансних частотах) → нормалізація по ковзному вікну 24 год → LSTMAE → reconstruction error → порогова логіка + алертинг.

Розмір вікна LSTM: 60 секунд (6000 точок на 100 Гц). Занадто мале вікно — не захоплює повільні паттерни. Занадто велике — втрачає чутливість до швидких змін.

Поріг аномальності: не фіксований, а адаптивний. threshold = mean(errors_last_7d) + 3 * std(errors_last_7d). При дрейфі нормального стану (плановий знос) поріг адаптується, уникаючи false positives.

Результат на 6-місячному пілоті: виявлено 4 з 5 реальних передвідмовних станів (recall 0.8), 2 хибні тривоги за 6 місяців (precision 0.67). До впровадження: 3 незаплановані зупинки зі значними збитками. Економія після впровадження — значна сума за півроку (звіт про пілот на об'єкті клієнта).

Фрод-детекція: специфіка фінансових даних

Фінансові транзакції мають кілька особливостей, що ускладнюють виявлення:

• Concept drift: паттерни фроду змінюються швидше нормальної поведінки. Модель, навчена півроку тому, застаріває.
• Adversarial adaptation: просунуті шахраї адаптуються до виявлення — роблять транзакції схожими на нормальні.
• Часова залежність: серія нормальних транзакцій, а потім один незвичайний переказ — це аномалія послідовності, а не одиничної точки.

Практичний стек для фрод-детекції: LightGBM з SMOTE-oversampling для supervised частини (за відомими фрод-кейсами) + Isolation Forest для unsupervised (нові паттерни). Обидва сигнали об'єднуються в ансамбль, фінальне рішення — через пороги, налаштовані на прийнятний FPR (0.1–1% від транзакцій на ручну перевірку).

Як оцінити якість без розмітки?

Коли ground truth немає, для оцінки використовуємо:

• Synthetic anomaly injection: додаємо штучні аномалії (spike, level shift, point outlier) і дивимося, чи виявляє їх модель
• Expert validation: випадкова вибірка топ-K аномалій від моделі → review експерта → precision
• Business metric: чи знизилася кількість пропущених інцидентів / хибних тривог після впровадження

Процес роботи

1. Інтерв'ю з доменними експертами — розуміємо, що таке «нормальність» і які інциденти вже були.
2. EDA та підготовка даних — очищення, створення ознак, часові вікна.
3. Baseline (Isolation Forest) — швидка валідація на відомих інцидентах.
4. Вибір та кастомізація моделі — Autoencoder / LSTM-AE / ансамбль.
5. Навчання, валідація з синтетичними аномаліями.
6. Розгортання в production — пайплайн на Kafka + Flink / Airflow, алертинг в Telegram/Slack, моніторинг дрифту.
7. Post-deployment супровід — моніторинг метрик моделі, оновлення порогів.

Що входить у роботу

• Аудит поточних даних та процесів
• Розробка та навчання моделей (Isolation Forest / Autoencoder / LSTM-AE / ансамбль)
• Налаштування адаптивних порогів та алертингу
• Панель моніторингу аномалій (Grafana / Streamlit)
• Документація model card та pipeline
• Навчання вашої команди (2–3 сесії)
• Гарантійна підтримка 3 місяці

Терміни: baseline-система з одним методом — 2–4 тижні. Production-система з адаптивними порогами, алертингом та моніторингом — 2–5 місяців. Вартість розраховується індивідуально під ваш кейс.

Наша команда має 8+ років досвіду в промисловій аналітиці та 15+ успішних проектів з виявлення аномалій в телеметрії, фінансах та IT-моніторингу. Отримайте консультацію — розкажемо, як вирішити вашу задачу.