С 27 по 29 августа 2021 года в онлайн-формате проходило соревнование YauzaCTF. Соревнование проводилось в формате Task-Based, принять участие могла любая команда, желающая попробовать свои силы. Участникам предстояло в течение 48 часов решить задания следующих категорий: web, reverse, PWN, forensics, crypto, OSINT, joy, hardware, pentest и emulation.

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

Предупреждение! Далее следует лонгрид про нули и единицы (в прямом смысле).

Привет! Меня зовут Александр Петровский, я инженер в DINS. Я работаю в команде, которая участвует в разработке сервисов облачной телефонии и видеоконференций. Каждый из них состоит из большого количества микросервисов.

Когда мы мигрировали один из наших микросервисов с CentOS 7 с ядром 4.19 на Oracle Linux 7 с ядром 5.4, мы заметили рост утилизации процессора на наших stress/performance-тестах. В статье я расскажу, как мы исследовали причины роста утилизации процессора сначала в user-space, а потом и в kernel-space и о том, к какому результату это нас привело.

Приветствую,

Сначала о проблеме/задаче:
Начав писать очередной плагин-отладчик для ретро-платформы под IDA Pro (по секрету: это будет SNES), я столкнулся со следующим набором, который требовалось подружить:

1. Ядро эмулятора написано на C++ и компилируется в DLL
2. GUI эмулятора написано на C# и использует DLL-ку ядра для управления эмуляцией
3. IDA Pro, которая использует плагины либо на питоне, либо на C++ в виде DLL (а отладчики только на C++)

Некоторое время назад у нас появился объект, где в техническом задании стояло требование: «Протокол Ethercat». В процессе поиска информации я полез на хабр и с удивлением обнаружил, что там разбора этого протокола нет. Да и вообще информация о нем довольно фрагментирована (забегая вперед — я просто не там искал). Проект мы сделали, а эта статья — для «более молодого меня», попытка сэкономить время кому-нибудь еще, кто собирается использовать или просто интересуется этим протоколом.

Единственный нюанс — я опишу довольно низкий уровень работы протокола (Data Layer в терминологии EtherCAT). Потому что именно он нам понадобился и им мы ограничились. Неописанными (пока?) останутся Application Layer протоколы типа CanOPEN-over-EtherCAT (CoE).

Общаются между собой две машины. Шлют друг другу цифровые данные, натурально нули и единицы. Только канал между ними не очень: биты регулярно то искажаются, то пропадают вовсе. Допустим, наш канал из 20 бит в среднем один бит ломает, другой теряет. А теперь пишем алгоритм, наиболее оптимально эти данные передающий.

Остальные части