Автор темы
На BSidesSF 2026 автономный AI-агент решил все 52 задания и занял первое место. Не ассистировал команде - победил в одиночку. И это не приговор формату CTF. Это приговор ленивому подходу к проектированию тасков. Большинство заданий, которые автор считает «сложными», построены на паттернах из публичных writeup-ов - для модели, натренированной на миллионах таких разборов, это не задача, а поиск по индексу. Статья - полная карта процесса: от первого вопроса «чему научит мой таск» до момента, когда
docker-compose up поднимает инфраструктуру на 500 участников.Карта темы: навигатор по разработке CTF заданий
| # | Подтема | Подробнее |
|---|---|---|
| 1 | Структура флага, нарратив и типичные провалы авторов | Как создать CTF таск: структура флага, сторителлинг и ошибки авторов |
| 2 | Кривая сложности, динамический скоринг и борьба с unintended | Балансировка сложности CTF заданий |
| 3 | CTFd, kCTF, Docker-изоляция от 50 до 2000 участников | CTF инфраструктура развёртывание |
| 4 | Форматы соревнований, системы подсчёта очков и античит | Организация CTF соревнований |
| 5 | Gameserver, чекеры и SLA для Attack-Defense | Attack-Defense CTF организация |
| 6 | Reverse-таски: упаковщики, OEP, KeyGen | Реверс-инжиниринг для CTF |
| 7 | CTF как инструмент тренировки Red/Blue Team и оценки кандидатов | CTF соревнования по кибербезопасности |
| 8 | Первые шаги в поиске уязвимостей | С чего начать искать уязвимости новичку |
Образовательная цель задания - то, без чего всё остальное бессмысленно
Каждый второй автор начинает разработку CTF задания с вопроса «какую уязвимость воткнуть». Неправильный вопрос. Правильный: какой конкретный навык отработает участник, решив этот таск? Без ответа задание превращается в головоломку ради головоломки - участник потратит час, получит флаг и не вынесет ничего применимого.Три фильтра перед открытием редактора кода
Прежде чем писать первую строчку кода уязвимого сервиса, прогоните идею через три вопроса:- Какая реальная атака моделируется? SQL injection, buffer overflow, memory forensics - таск должен отражать сценарий, который встречается на реальном пентесте или при расследовании инцидента. Задание на Base64/ROT13 в десятый раз не моделирует ничего.
- Какой инструмент или методология отрабатывается? Если участник после решения не узнал ничего нового о Ghidra, pwntools, Wireshark или Burp Suite - задание пустое. Хорошие таски заставляют изучить конкретный инструмент в процессе решения.
- Для какой аудитории? Easy-таск для школьников на первом CTF и easy-таск для пентестеров с опытом - два принципиально разных задания. Школьнику «прочитай robots.txt» - нормально. Пентестеру easy - это одношаговая техническая задача с реальным вектором.
Контекст реального мира
Контекст определяет, будет ли задание полезным за пределами соревнования. Forensics-таск на артефактах Linux-десктопа - звучит нормально, пока не задашь вопрос: как часто IR-специалисты расследуют инциденты на рабочих станциях с Linux? «Скомпрометированный веб-сервер» или «дамп памяти Windows-машины с подозрительной активностью» - правдоподобнее и учит навыкам, которые пригодятся при реальном реагировании на инцидент.Связь между CTF-заданиями и реальными техниками атак описана в MITRE ATT&CK: web-таск с эксплуатацией публичного приложения (T1190) или forensics-задание на поиск учётных данных в файлах (T1552.001) - это не абстрактные задачи, а тренировка конкретных detection-сценариев.
Подробный разбор формулирования образовательных целей и антипаттернов: Как создать CTF таск: структура флага, сторителлинг и ошибки авторов
7 категорий CTF заданий: что строить и какие навыки закладывать
Разработка задач для CTF начинается с выбора категории. У каждой - своя специфика создания, свои грабли и свои требования к инфраструктуре.| Категория | Ключевой навык участника | Требует контейнера? | Типичная ошибка автора |
|---|---|---|---|
| Web | Эксплуатация веб-уязвимостей (OWASP Top 10) | Да | Забыл закрыть .git-директорию |
| Crypto | Криптоанализ, разбор ошибок в реализации | Нет (обычно) | Задание решается brute-force за секунды |
| Pwn | Binary exploitation, работа с памятью | Да | Не отключил ASLR или оставил лишние gadgets |
| Reverse | Реверс-инжиниринг бинарников | Нет (обычно) | Флаг лежит plaintext в строках бинарника |
| Forensics | Анализ дампов, артефактов, логов | Нет | Ответ подбирается перебором трёх файлов |
| Stegano | Извлечение скрытых данных | Нет | Решается одной командой binwalk -e |
| PPC/Misc | Скриптинг, автоматизация, нестандартное мышление | Иногда | Слишком узкое условие, единственный язык решения |
Распределение по категориям в рамках одного ивента: стремитесь к 2-6 заданий на категорию (рекомендации rCTF docs) и избегайте ситуации, когда одна категория заметно тоньше других. Если нет сильного автора по crypto - лучше три качественных таска, чем шесть «для количества». Проверено: шесть слабых crypto-тасков убивают репутацию ивента надёжнее, чем полное отсутствие категории.
Для начинающих авторов и тех, кто ищет первые вектора эксплуатации: С чего начать искать уязвимости новичку
Создание web заданий CTF: от одношаговой injection до цепочек эксплойтов
Web - самая популярная категория на большинстве CTF. И самая коварная по части unintended solutions. Автор тратит две недели на цепочку из SQL injection, bypass фильтрации и LFI, а участники за 40 минут находят.git-директорию и читают флаг из конфигурационного файла. Видел такое не раз - обидно до зубовного скрежета.Чеклист для web-таска
Проектирование сценария эксплуатации уязвимости для CTF:- Выберите один основной вектор атаки (OWASP A03:2021 - Injection, path traversal, SSTI, deserialization). Одношаговые таски для easy, цепочки из 2-3 шагов для medium/hard.
- Напишите уязвимый сервис на Flask, Express или Go. Избегайте фреймворков с встроенной защитой (Django ORM по умолчанию экранирует SQL) - либо явно отключайте защиту, либо используйте raw-запросы.
- Уберите все непреднамеренные точки входа:
.git,.env, debug-эндпоинты, стандартные учётные записи, directory listing. - Добавьте «шум» - дополнительные маршруты, которые не ведут к флагу, но создают реалистичное окружение.
Пример: минимальный web-таск на SSTI
Уязвимый Flask-сервис для категории easy - Server-Side Template Injection в Jinja2:
Python:
from flask import Flask, request, render_template_string
app = Flask(__name__)
@app.route('/greet')
def greet():
name = request.args.get('name', 'guest')
return render_template_string(f'Hello, {name}!')name подставляется напрямую в шаблон, и отправить {{config}} или {{7*7}} для подтверждения SSTI. Intended path - через [B]subclasses[/B] к чтению файла с флагом. Задание моделирует реальный вектор T1190 (Exploit Public-Facing Application).После написания - прогоните
dirsearch и nikto по собственному сервису. Проверьте HTTP-заголовки на утечку версий. Если сами нашли обход за 10 минут - участники найдут за 5.Написание crypto заданий CTF: грань между математикой и решаемостью
Crypto-таски - единственная категория, где задание может быть математически безупречным и при этом абсолютно несправедливым. Если участнику для решения нужно знать теорему, о которой он услышит впервые - это не задание, а экзамен по алгебре.Принципы проектирования crypto-тасков
Easy: классические шифры с известной слабостью. Цезарь с известным фрагментом plaintext, XOR с коротким ключом, RSA с маленькимe и общим модулем. Участник учится применять стандартные атаки.Medium: ошибки реализации стандартных протоколов. AES-CBC с предсказуемым IV, повторное использование nonce в потоковом шифре, padding oracle. Нужно понимать протокол, а не просто натравить инструмент.
Hard: авторская криптосистема с неочевидной уязвимостью. Но участник должен иметь возможность обнаружить слабость через анализ предоставленного кода - не через угадывание. Если для решения нужна телепатия - это не hard, это баг.
Частая ошибка: brute-force как unintended
Автор проектирует RSA-задание с кастомной генерацией простых чисел, рассчитывая на факторизацию через специфическую слабость. Но ключ получается настолько малым, чтоfactordb.com возвращает ответ за секунду. Правило: перед деплоем проверьте, что размер ключа не позволяет brute-force в пределах времени соревнования. Прогоните числа через factordb и yafu. На одном ивенте видел, как «hard» RSA-таск на 512 бит был решён первым - через 4 минуты после старта. Автор потом долго оправдывался.Генерация динамических флагов для crypto-заданий описана в гайде: Как создать CTF таск: структура флага, сторителлинг и ошибки авторов
Pwn задания CTF: разработка binary exploitation тасков
Pwn - самая требовательная категория к инфраструктуре и к квалификации автора. Бинарник должен быть уязвимым ровно так, как задумано, и защищённым от всего остального. Тонкая грань, на которой многие спотыкаются.Контролируемые митигации
Каждый pwn-таск - комбинация включённых и выключенных защит. Управляйте ими явно через флаги компиляции:
Bash:
# Easy: всё выключено, простой stack overflow
gcc -o easy_pwn -fno-stack-protector -z execstack -no-pie task.c
# Medium: NX включён, нужен ROP
gcc -o med_pwn -fno-stack-protector -z noexecstack -no-pie task.c
# Hard: PIE + canary, нужен leak
gcc -o hard_pwn -fstack-protector-all -z noexecstack -pie task.cchecksec (из pwntools). Убедитесь, что митигации соответствуют intended difficulty. Если хотите NX, но случайно собрали с -z execstack - участники просто запихнут шеллкод на стек, и ваш ROP-таск станет easy. Классическая ошибка, встречается чаще, чем хотелось бы.Тестирование pwn-тасков
Напишитеsolve.py с использованием pwntools до того, как считаете таск готовым. Solve-скрипт - не бонус, а часть разработки. Если вы не можете написать надёжный exploit - участники тоже не смогут, но по другим причинам, и в чате поддержки будет ад.Запустите exploit минимум 10 раз подряд. Если хотя бы одна попытка падает из-за race condition или смещения стека - исправляйте. На соревновании участник не будет разбираться, его ли это ошибка или ваша. Он просто напишет в Discord «таск сломан» - и будет прав.
Подробный разбор реверс-инжиниринга для CTF, включая анализ упаковщиков и поиск OEP: Реверс-инжиниринг для CTF: анализ упаковщиков, поиск OEP и написание KeyGen
Докеризация CTF заданий: изоляция без компромиссов
Каждое задание, которое принимает пользовательский ввод по сети, обязано жить в контейнере. Без исключений. Участники будут запускать reverse shell, форк-бомбы и пытаться читать/etc/shadow. Ваша задача - сделать так, чтобы всё это не затронуло соседние таски и хост.Docker compose для CTF инфраструктуры: базовые правила
Один контейнер - одно задание. Если заданию нужен веб-сервер и база данных, используйтеdocker-compose с отдельными сервисами, но изолируйте сетевой доступ через internal-сети.Минимальные базовые образы:
alpine или debian-slim вместо полноценного ubuntu. Меньше поверхность атаки, быстрее сборка, меньше неожиданных бинарников, которые участник может использовать для unintended. На одном ивенте участник нашёл python3 в образе, где его быть не должно, и через него вытянул флаг - автор использовал ubuntu:latest «для удобства».Non-root внутри контейнера. Сервис задания должен работать от непривилегированного пользователя. Даже если участник получит RCE - выход из контейнера будет значительно сложнее.
Security defaults для docker-compose
YAML:
services:
web-task:
build: ./web-task
read_only: true
tmpfs:
- /tmp:size=64M
deploy:
resources:
limits:
memory: 256M
pids: 64
networks:
- task-net
security_opt:
- no-new-privileges:true| Директива | Зачем |
|---|---|
read_only: true | Файловая система только для чтения - участник не запишет бэкдор на диск |
tmpfs: /tmp:size=64M | Ограниченный tmpfs для временных файлов |
pids: 64 | Защита от форк-бомб |
memory: 256M | Лимит памяти - защита от heap spray и утечек |
no-new-privileges | Запрет эскалации привилегий через SUID-бинарники |
Network isolation: для multi-container заданий используйте internal-сети, чтобы база данных не торчала наружу напрямую. Участник должен попасть к БД только через уязвимое приложение.
Детальный разбор инфраструктурных решений от 50 до 2000 участников: CTF инфраструктура развёртывание: CTFd, kCTF и Docker-изоляция
Инфраструктура для CTF: от платформы до CI/CD пайплайна
Выбор платформы: CTFd и альтернативы
CTFd - де-факто стандарт для jeopardy-формата. Открытый исходный код, плагинная архитектура, поддержка динамического скоринга. Разработан изначально для соревнования CSAW в NYU. Ограничение, о котором забывают: CTFd управляет логистикой (регистрация, scoreboard, сдача флагов), но не занимается провижинингом инфраструктуры заданий - это ваша головная боль.Для Attack-Defense формата CTFd не подходит. Нужны специализированные решения с gameserver-ом, чекерами и SLA-мониторингом. Подробный разбор: Attack-Defense CTF организация: от gameserver до автоматизации SLA
rCTF - альтернатива с встроенным Docker-инстансером, который создаёт изолированные контейнеры для каждой команды и уничтожает их по таймауту. Для заданий, требующих per-team инстансов (pwn, web с persistent state), это серьёзное преимущество перед CTFd.
CI/CD: автоматический деплой заданий из Git-репозитория
Исследователи из Университета Наварры (статья «CTF as a Service», arXiv:2603.22511) описывают архитектуру, где задания автоматически деплоятся из Git-репозитория через CI/CD пайплайн. Каждый push в веткуmain запускает сборку Docker-образов, прогон тестов (включая проверку, что solve-скрипт возвращает правильный флаг) и деплой в оркестратор.Минимальный pipeline для GitLab CI:
YAML:
test-challenge:
script:
- docker-compose -f challenge/docker-compose.yml up -d
- sleep 5
- python3 challenge/solve.py | grep -q "FLAG{"
- docker-compose -f challenge/docker-compose.yml downКонфигурация CTFd: на что обратить внимание
Формат флага - задайте единый префикс (например,codeby{...}) и настройте case-insensitive проверку, если ваши флаги не содержат значимого регистра. Один участник, потративший 20 минут на угадывание O vs 0 - это UX-провал, а не сложность.Dynamic scoring - очки за задание уменьшаются с количеством решений. Звучит справедливо, но на внутренних ивентах участники воспринимают потерю очков негативно. Для публичных CTF - работает. Для корпоративных - лучше статические очки. Проверено на нескольких корпоративных ивентах: динамический скоринг вызывает больше жалоб, чем мотивации.
Anti-bruteforce - CTFd поддерживает rate-limiting на сдачу флагов. Включайте всегда. 10 попыток в минуту - разумный порог.
Тестирование CTF заданий перед соревнованием: 5 этапов, которые спасают ивент
Тестирование - самая недооценённая фаза разработки задач для CTF. Большинство провалов на живых соревнованиях связаны не с плохой идеей, а с тем, что автор не пытался сломать собственное задание.Этап 1: Автор решает свой таск с нуля
После написания задания подождите 2-3 дня. Потом откройте чистую среду (новый контейнер, новая VM) и решите задание, не заглядывая в исходный код. Если застряли - задание либо слишком сложное, либо у него неочевидный intended path. Два дня паузы - минимум. За это время мозг забывает «очевидные» подсказки, которые очевидны только автору.Этап 2: Перекрёстное тестирование другим автором
Минимум два независимых тестера на каждое задание (рекомендация из документации rCTF). Тестер не должен знать intended solution. Его задача - решить таск и зафиксировать путь решения. Путь совпадает с intended - отлично. Не совпадает - у вас unintended solution, и лучше узнать об этом сейчас.Этап 3: Автоматизированная проверка solve-скрипта
Каждое задание должно иметьsolve.py, который на выходе даёт флаг. Прогоняйте его в CI при каждом изменении Dockerfile или кода сервиса. Один раз solve-скрипт ломается в CI - один раз вы ловите баг до деплоя.Этап 4: Adversarial testing
Запустите против web-таска сканер (nikto, dirsearch, sqlmap). Проверьте, что pwn-бинарник не содержит строковых утечек (strings binary | grep -i flag). Попробуйте стянуть .git, .env, docker-compose.yml через веб-сервер. На одном из ивентов автор оставил flag.txt в корне Docker-образа, доступным через directory traversal в nginx - при том, что intended path проходил через три шага эксплуатации. Участники сдали флаг через 8 минут после старта. Автор был в шоке.Этап 5: Нагрузочное тестирование
Если ожидается 200+ участников, запустите 50 одновременных solve-скриптов. Проверьте, что сервис не падает под нагрузкой и что лимитыpids/memory в Docker работают корректно. Fork-бомба от одного участника не должна убивать сервис для остальных.Детальный разбор методов поиска unintended solutions и конкретные антипаттерны: Балансировка сложности CTF заданий: от кривой difficulty до борьбы с unintended solutions
Балансировка сложности: кривая difficulty для разных аудиторий
Правильное распределение сложности - разница между ивентом, где участники уходят через час, и ивентом, о котором говорят полгода. Универсальной формулы нет, но есть проверенные отправные точки.Распределение сложности по типу аудитории
| Тип CTF | Easy | Medium | Hard | Extreme |
|---|---|---|---|---|
| Обучающий (студенты, первый CTF) | 35% | 35% | 25% | 5% |
| Конференция (опытная аудитория) | 10% | 25% | 40% | 25% |
| Корпоративный (смешанная аудитория) | 25% | 35% | 30% | 10% |
Easy-таски решают критическую задачу - они дают участнику первый флаг. Участник, который за два часа не сдал ни одного задания, уходит. Просто встаёт и уходит. Первый флаг создаёт ощущение прогресса и мотивирует копать дальше. Обязательно включайте 1-2 таска, которые решаются за 10-15 минут.
Extreme - не «сделаю сам, потому что могу». Написать задание уровня extreme, которое будет одновременно сложным, интересным и решаемым - тяжело даже для опытного автора. Если не уверены - лучше ещё один quality medium, чем сломанный extreme, который никто не решит и который не научит ничему.
Сторителлинг как инструмент баланса
Объединяющая тема соревнования (кинофраншиза, ретро-игры, корпоративный детектив) создаёт дополнительную мотивацию. Участник не просто «ищет SQL injection» - он проникает в систему антагониста. Тема также даёт естественный способ встраивать подсказки через элементы сюжета, а не через прямые указания.Пример: задание называется «Financial PATH», описание - история сотрудника, чей «карьерный путь» привёл к финансовым секретам. Слово PATH - подсказка на path traversal. Для новичка незаметно, для внимательного участника - вектор атаки. Такие штуки работают лучше, чем «hint: посмотрите на URL».
CTF как инструмент тренировки и оценки команд: CTF соревнования по кибербезопасности: тренировка Red/Blue Team и оценка кандидатов в ИБ
Деплой CTF заданий: чеклист автора перед стартом соревнования
За неделю до ивента каждое задание проходит финальную проверку. Чеклист ниже собран из опыта нескольких десятков соревнований и рекомендаций документации rCTF.Pre-event чеклист для каждого таска
- [ ] Задание решаемо с предоставленными материалами. Если есть файлы для скачивания - проверить, что это правильные версии (авторы часто обновляют код, забывая пересобрать архив)
- [ ]
solve.pyвыводит корректный флаг - [ ] Флаг соответствует ожидаемому формату (
PREFIX{...}) - [ ] Прогнан перекрёстный плейтест (минимум 2 тестера)
- [ ] Удалённые сервисы доступны и стабильны
- [ ] Docker-контейнеры собираются и запускаются без ошибок
- [ ] Авторский writeup написан и доступен команде поддержки
- [ ] Флаг не гуглится (прогоните через поисковик)
- [ ] Промежуточные данные (пароли, ключи в задании) не гуглятся
- [ ] Нет утечек в публичные репозитории, Pastebin, gist
- [ ]
dirsearch/niktoпо web-таску не выявляет непреднамеренных путей - [ ]
stringsпо бинарнику не выдаёт флаг в plaintext - [ ] Security defaults в Docker включены (read_only, pids limit, memory limit)
Таймлайн подготовки ивента
Начинайте минимум за 2-3 месяца. Один рабочий график:- 3 месяца до старта: выбор даты, общий план заданий, проверка CTFtime на конфликты с крупными CTF, контакт со спонсорами.
- 2 месяца до старта: начало написания заданий.
- 2 недели до старта: заморозка новых идей. Фокус на плейтест, ревизии, настройку платформы и инфраструктуры.
- 1 неделя до старта: финализация всех заданий, открытие регистрации, подготовка Discord для участников.
AI и будущее CTF: почему старые паттерны больше не работают
CTFAgent на базе GPT-4o и Gemini-2.5-Pro превосходит 88% человеческих команд в полностью автоматическом режиме на задачах PicoCTF. Специализированный crypto-агент KryptoPilot показывает 100% solve rate на бенчмарке InterCode-CTF. Мультиагентные системы вроде D-CIPHER координируют planner- и executor-агентов для покрытия всех категорий. Цифры неприятные, но игнорировать их - себе дороже.Почему большинство заданий падают перед AI
AI-модели обучены на датасетах, включающих writeup-ы, exploit-базы и документацию. Когда задание следует известному паттерну - стандартный buffer overflow, типовой SQL injection, задокументированная криптографическая слабость - модель не рассуждает, а находит совпадение в обучающих данных. Исследователи NYU (NYU CTF Bench) подтвердили: модели справляются с паттерн-задачами, но ломаются на multi-step reasoning в незнакомых контекстах. Команда CTFusion показала, что при использовании только live-задач, никогда не появлявшихся в обучающих данных, производительность агентов резко падает.По сути, AI решает CTF-задания так же, как плохой студент решает экзамен - по шпаргалке. Если задача есть в шпаргалке - ответ мгновенный. Если нет - ступор.
5 принципов проектирования AI-устойчивых заданий
- Оригинальные уязвимости. Кастомные приложения с авторскими логическими багами, нестандартные реализации протоколов, уникальные комбинации технологий - заставляют рассуждать, а не извлекать из памяти.
- Неоднозначность и необходимость суждений. Incident response-сценарии с одновременным триажем нескольких алертов, forensics с misleading evidence, оценка бизнес-воздействия - AI плохо справляется с контекстуальными суждениями.
- Динамическое окружение. Attack-Defense с ротацией флагов каждые 1-5 минут, где нужно поддерживать exploit-ы и патчить собственные сервисы одновременно.
- Взаимодействие с live-системами. Задания, требующие работы с реальной сетью или инфраструктурой, которую невозможно полностью симулировать в промпте.
- Командная координация. Форматы, требующие real-time взаимодействия людей с разными ролями (network defense, forensics, коммуникация) - автономным агентам координация между ролями пока недоступна.
Куда движется разработка задач для CTF
Три вектора определят следующие 1-2 года:Персонализация инфраструктуры. Модель «один сервис на всех» уходит. Архитектуры вроде CTF-as-a-Service (описанной исследователями из UPNA) с per-team инстансами через Docker Swarm или kCTF становятся стандартом. Это усложняет инфраструктуру, но устраняет целый класс проблем: утечку флагов между командами, race condition при эксплуатации shared-сервисов, DoS одного задания, убивающий доступ для всех.
Scoring beyond flags. Оценка только по сданным флагам оптимизирует именно то поведение, в котором AI уже сильнее людей. Скоринг, учитывающий документацию процесса, defensive actions и time-to-detect, меняет правила игры. CSAW Agentic Automated CTF уже требует от участников предоставлять полные траектории решений.
Writeup до деплоя - обязательно. Если writeup не написан до того, как задание попало на платформу - задание не готово. Writeup - не бонус, а инструмент верификации: он фиксирует intended solution, проверяет воспроизводимость и закрепляет образовательную цель.
Большинство авторов CTF-заданий тратят 80% времени на проектирование intended path и 0% - на попытку сломать собственный таск. Результат предсказуем: на каждом втором ивенте хотя бы один таск сдаётся через unintended за первые 40 минут. И те же авторы потом жалуются на «нечестных» участников, хотя проблема - в отсутствии adversarial testing.
Ещё одна закономерность, которую мало кто признаёт вслух: большинство «hard»-заданий на современных CTF - не hard для AI-агентов. Они hard для людей, которые не читали нужный writeup, и trivial для модели, которая «прочитала» все writeup-ы за последние 10 лет. Настоящая сложность - в оригинальности сценария, а не в количестве шагов. Таск из одного шага с авторской логической ошибкой в кастомном протоколе сложнее для автоматизации, чем пятишаговая цепочка из стандартных OWASP-уязвимостей.
Авторы, которые поймут это раньше других, будут определять формат соревнований на ближайшие годы. Остальные продолжат удивляться, почему их CTF «решается ботами». Попробуйте прямо сейчас: возьмите свой последний таск, скормите его GPT-4o и посмотрите, за сколько секунд он выдаст solve. Если ответ - меньше минуты - вы знаете, что делать.
Совсем скоро на HackerLab появятся лабы, которые не решаются копипастой из writeup-а и не решаются AI.
Последнее редактирование: