-
Notifications
You must be signed in to change notification settings - Fork 1
Интерфейс «проверяющая система чекеры»
Строка, подходящая под регулярное выражение: /^[0-9A-Z]{31}=$/. Генерируется проверяющей системой. Является псевдослучайной. Можно считать, что все флаги (сгенерированные за игру) уникальны.
По идентификатору из сервиса можно получить флаг.
Генерируется либо проверяющей системой, либо чекером, либо сервисом. Может быть одной или несколькими строками.
Проверяющая система генерирует идентификаторы, подходящие под регулярное выражение /^[0-9a-z]{4}-[0-9a-z]{4}-[0-9a-z]{4}$/
Уязвимое приложение, запущенное на игровом сервере команды. Хранит флаги.
Функциональность, не связанная с флагами.
Модуль проверяющей системы, относящийся к одному из сервисов. Задачи чекера: проверять общую функциональность сервиса, устанавливать флаги в сервис, проверять наличие флагов в сервисе.
Чекер представляет собой исполняемый файл (ELF, perl-скрипт, bash-скрипт, java класс, ...)
Входные данные получает через аргументы командной строки. Выходные данные возвращает через: код завершения, STDOUT, STDERR.
Чекер запускается проверяющей системой с аргументами: <режим> [<hostname> [<id> <flag> <vuln>]]
-
<режим>- определяет какую операцию должен выполнить чекер -
<hostname>- имя хоста (сервера) команды (имеет вид: teamN.ructf) -
<id>- идентификатор флага -
<flag>- флаг -
<vuln>- номер уязвимости в сервисе, натуральное число.
Режимы:
-
info- информация о сервисе -
check- проверка общей функциональности -
put- установка флага в сервис -
get- получение флага из сервиса
Результат операции чекер сообщает кодом завершения процесса:
- 101 - ОК (операция завершилась успешно)
- 102 - CORRUPT сервис работает, но запрашиваемого флага нет (только в режиме «get»)
- 103 - MUMBLE сервис работает неправильно (напр., отвечает не по протоколу)
- 104 - DOWN сервис не работает (напр., нет connect-а на порт)
- 110 - CHECKER ERROR внутренняя ошибка чекера (напр., неправильные аргументы командной строки)
Остальные коды возврата недопустимы и считаются ошибкой чекера.
Всё, что выводится чекером на STDOUT и STDERR, а также коды возврата, записывается в лог-файлы проверяющей системы.
Чекер может использовать поток STDERR для вывода собственных диагностических сообщений.
STDOUT может использоваться для:
- вывода пояснений командам о причине неработоспособности сервиса (если код завершения не равен 101)
- вывода нового идентификатора флага (в режиме "put", если код завершения равен 101)
Причина неработоспособности (напр., "Connection refused", "Unexpected answer from service", ...) будет отображаться всем командам на странице скорборда с текущими статусами сервисов.
Использование STDOUT и STDERR является необязательным.
-
INFO: вывод информации о сервисе.
./checker info
Чекер должен вернуть 101 ("OK") и вывести на STDOUT информацию в виде key: value\n[key2: value2\n...]
Поддерживаемые ключи:
- vulns
Значением должна быть строка, состоящая из N чисел разделенных двоеточием. N — количество уязвимостей в сервисе. Числа означают с какой частотой в сервис будет устанавливаться флаг для данной уязвимости. Например, строка "1:3:2" означает, что в сервисе есть три уязвимости и они будут устанавливаться в таком порядке 1, 2, 2, 2, 3, 3, ...
-
CHECK: проверка общей функциональности.
./checker check <hostname>
Чекер должен проверить общую функциональность сервиса.
Если чекеру не нужна такая проверка, он возвращает 101 ("OK").
-
PUT: установка флага.
./checker put <hostname> <id> <flag> <vuln>
Чекер должен установить флаг <flag> для уязвимости <vuln> на хост <hostname>.
В случае успешной установки (код возврата 101 - ОК) чекер может вывести на STDOUT новый идентификатор флага. В этом случае проверяющая система занесет в базу флагов новый идентификатор, а не . Новый идентификатор может состоять из нескольких строк. Его длина не должна превышать 1024 байта.
Если на STDOUT ничего не выведено, считается,
что флаг установлен под идентификатором <id>, изначально предложенным проверяющей системой.
Проверять, установился ли флаг (т.е. пытаться его получить из сервиса), чекер в этой процедуре не должен. Это сделает проверяющая система сразу после вызова "put".
-
GET: получение флага.
./checker get <hostname> <id> <flag> <vuln>
Чекер должен проверить: можно ли по идентификатору <id> получить флаг <flag> для уязвимости <vuln> с хоста <hostname>.
Строка <id> может содержать пробелы и переводы строк. Вся строка целиком будет лежать в argv[3].
Чекеры нужно именовать так: <имя_сервиса>.checker[.расширение] (имя_сервиса - в lower case без пробелов)
Чекеры должны располагаться в Git в каталоге: ructf-2017/checkers/<имя_сервиса> и иметь исполняемый бит.
Если процесс чекера не завершится в течение таймаута, он будет завершен принудительно. Такое поведение допустимо. Вставлять в чекер свою проверку таймаута не обязательно. По умолчанию таймаут составлет 10 секунд, он может быть изменен, например сообразно скорости игровой сети.