Ну, и немного мыслей на эту тему, как разработчика CTF со стажем.
Для начала, распишу немного подробнее формат:
0. Взламывать игру? В смысле?
В прямом. Мы даем игрокам исходный код игры на Go с уровнем, на котором есть 4 предмета, и их нужно собрать.
Понятно, что если задача будет просто собрать предметы, то игроки могут очень быстро поломать игру локально и просто переместить игрока к предмету или поменять код, чтобы сделать себе wall-hack.
Поэтому у нас есть сервер, который проверяет, что игроки не написали чит. В нашем варианте всё работает достаточно просто:
* Раз в тик состояние игры меняется, в том числе, если игрок нажал на клавишу
* На клиенте мы считаем контрольную сумму состояния движка (буквально где стоит игрок, сколько у него хп, где находится босс и т.д.)
* Input игрока и хэш состояния игры отправляется на сервер
* Сервер применяет инпут игрока, сверяет контрольную сумму и, если она не совпадает, заявляет, что игрок считерил.
Такое решение позволяет нам запрещать какие-то мощные читы (тот же wall-hack), но при этом разрешать другие читы (slow-mode, free camera).
1. Такой формат не самый лучший для проведения идеальных (максимально честных) соревнований.
Но формат достаточно интересно смотреть даже, если вы ничего в этом не понимаете.
Для этого правда нужна очень хорошая трансляция, если интересно, посмотрите финал Google CTF прошлого года.
https://www.youtube.com/watch?v=HFeD4kYcW7A
2. Такой формат гораздо интереснее писать разработчикам.
Последние много лет я делаю задачи на CTF, и идей уже меньше, мотивация делать задачи зачастую отсутствует.
А тут что-то новое, так еще и разработка игр. Я никогда не занимался разработкой игр, а тут тебе нужно делать всё практически с нуля, чтобы сделать баги в игровом движке.
Получается два в одном: ты закрываешь юношеский гештальт по разработке игр + делаешь интересные задачи для участников.
3. Раунды короткие.
Всего 4 предмета и 2.5 часа. Соревнования достаточно динамичные и игроки точно не успевают заскучать.
На прошедшем финале только последний уровень игроки смогли полностью решить (собрать все предметы), но и на это потребовалось почти всё время.
4. Некоторые баги придумываются сами-собой.
Мой баг для первого уровня появился когда я делал реализацию Coyote-фреймов. Я забыл ресетнуть новое состояние при ресете игры, и получалось, что ты мог сделать прыжок в воздухе сразу после рестарта игры (и только после рестарта).
Дальше другой разработчик для красоты сделал тайлы, с которыми игрок не коллизится (для красоты). Сразу решили добавить это в первый уровень, сделав "фэйковую стену"
Но есть и минусы:
1. Сложно придумать много багов на механики игры и не повторять себя.
Чтобы сделать все баги в игре на механики, нужно добавить много механик, а это не так уж и просто. В итоге мы добавили несколько обычных CTF-задачек в игру. Но для решения некоторых задачек всё равно нужно было понимать как работает движок игры (например, как можно ввести unicode в диалоговое окно).
2. В соревновании сильно решает умение быстро и много читать код на языке движка.
В нашем случае нужно было читать много кода на Go, который я считаю очень читаемым языком. Но всё равно, получается небольшое преимущество, если у вас в команде есть senior go developers.
Итог:
Формат придуманный Гуглом, кажется глотком свежего воздуха в мире CTF, где существует 2.5 формата (KoH считаем за 0.5).
Я очень рад, что наша команда может повторить этот формат для наших соревнований, дать участникам кубка пощупать новый формат хакерских игр и получить удовольствие от участия в финале.
Для начала, распишу немного подробнее формат:
0. Взламывать игру? В смысле?
В прямом. Мы даем игрокам исходный код игры на Go с уровнем, на котором есть 4 предмета, и их нужно собрать.
Понятно, что если задача будет просто собрать предметы, то игроки могут очень быстро поломать игру локально и просто переместить игрока к предмету или поменять код, чтобы сделать себе wall-hack.
Поэтому у нас есть сервер, который проверяет, что игроки не написали чит. В нашем варианте всё работает достаточно просто:
* Раз в тик состояние игры меняется, в том числе, если игрок нажал на клавишу
* На клиенте мы считаем контрольную сумму состояния движка (буквально где стоит игрок, сколько у него хп, где находится босс и т.д.)
* Input игрока и хэш состояния игры отправляется на сервер
* Сервер применяет инпут игрока, сверяет контрольную сумму и, если она не совпадает, заявляет, что игрок считерил.
Такое решение позволяет нам запрещать какие-то мощные читы (тот же wall-hack), но при этом разрешать другие читы (slow-mode, free camera).
1. Такой формат не самый лучший для проведения идеальных (максимально честных) соревнований.
Но формат достаточно интересно смотреть даже, если вы ничего в этом не понимаете.
Для этого правда нужна очень хорошая трансляция, если интересно, посмотрите финал Google CTF прошлого года.
https://www.youtube.com/watch?v=HFeD4kYcW7A
2. Такой формат гораздо интереснее писать разработчикам.
Последние много лет я делаю задачи на CTF, и идей уже меньше, мотивация делать задачи зачастую отсутствует.
А тут что-то новое, так еще и разработка игр. Я никогда не занимался разработкой игр, а тут тебе нужно делать всё практически с нуля, чтобы сделать баги в игровом движке.
Получается два в одном: ты закрываешь юношеский гештальт по разработке игр + делаешь интересные задачи для участников.
3. Раунды короткие.
Всего 4 предмета и 2.5 часа. Соревнования достаточно динамичные и игроки точно не успевают заскучать.
На прошедшем финале только последний уровень игроки смогли полностью решить (собрать все предметы), но и на это потребовалось почти всё время.
4. Некоторые баги придумываются сами-собой.
Мой баг для первого уровня появился когда я делал реализацию Coyote-фреймов. Я забыл ресетнуть новое состояние при ресете игры, и получалось, что ты мог сделать прыжок в воздухе сразу после рестарта игры (и только после рестарта).
Дальше другой разработчик для красоты сделал тайлы, с которыми игрок не коллизится (для красоты). Сразу решили добавить это в первый уровень, сделав "фэйковую стену"
Но есть и минусы:
1. Сложно придумать много багов на механики игры и не повторять себя.
Чтобы сделать все баги в игре на механики, нужно добавить много механик, а это не так уж и просто. В итоге мы добавили несколько обычных CTF-задачек в игру. Но для решения некоторых задачек всё равно нужно было понимать как работает движок игры (например, как можно ввести unicode в диалоговое окно).
2. В соревновании сильно решает умение быстро и много читать код на языке движка.
В нашем случае нужно было читать много кода на Go, который я считаю очень читаемым языком. Но всё равно, получается небольшое преимущество, если у вас в команде есть senior go developers.
Итог:
Формат придуманный Гуглом, кажется глотком свежего воздуха в мире CTF, где существует 2.5 формата (KoH считаем за 0.5).
Я очень рад, что наша команда может повторить этот формат для наших соревнований, дать участникам кубка пощупать новый формат хакерских игр и получить удовольствие от участия в финале.