GLM-5 против Claude и Codex: кейс по обратной инженерии USB-протокола и автоматическому исправлению кода

Зачем реверсить USB, если можно попросить ИИ?

Передо мной лежала китайская USB-донгл с проприетарным протоколом. Документации ноль. Wireshark показывает месиво из SETUP, IN, OUT пакетов. Раньше я потратил бы неделю на анализ. Сейчас у меня есть три модели: GLM-5 (последний релиз от Zhipu AI на февраль 2026), Claude Sonnet 4.8 и GPT-5.2 Codex. Давайте посмотрим, кто реально спасет мой дедлайн.

1Подготовка: что нужно, кроме смелости

Забудьте про голые промпты вроде "расшифруй USB". Реверс-инжиниринг — это многослойная задача. Вам понадобится:

• Сырые данные. Я использовал tshark для захвата трафика, потому что он дает чистый вывод для вставки в промпт.
• Контекст. Любая информация об устройстве: VID/PID, предположения о протоколе (HID, CDC, vendor-specific).
• Модели с длинным контекстом. Наш дамп — 5000 пакетов. GLM-5 и Claude Sonnet 4.8 легко глотают 200K токенов. GPT-5.2 Codex тоже, но он дороже.

# Команда для захвата. Важно: сохраняем в текстовом формате для AI.
tshark -i usbmon0 -Y "usb" -T fields -e frame.number -e usb.src -e usb.dst -e usb.setup.bRequest -e usb.setup.wValue -e usb.setup.wIndex -e usb.setup.wLength -e usb.data > usb_dump.txt

2Раунд 1: Анализ сырого дампа. Кто не испугался?

Я скормил дамп трем моделям с одинаковым промптом:

Ты — эксперт по USB-протоколам. Вот дамп трафика USB-устройства (VID: 1234, PID: 5678).
Устройство — кастомный HID-контроллер. Пакеты ниже.
Проанализируй структуру запросов (bRequest, wValue, wIndex). Определи, какие запросы отвечают за:
1. Инициализацию устройства.
2. Чтение данных с сенсора.
3. Запись конфигурации.
Выдели паттерны. Если видишь аномалии (например, повторяющиеся ошибки NAK), укажи на них.

Данные:
[вставка первых 200 строк дампа]

GLM-5 показал deeper understanding. Он не просто парсил — он искал outliers. Это критично для реверса.

3Раунд 2: Декодирование протокола. Где логика?

Теперь нужно понять смысл полей. Я дал каждой модели второй промпт с фокусом на data payload.

Claude Sonnet корректно декодировал целые числа. Codex предложил несколько вариантов энкодинга. GLM-5 пошел дальше: он заметил, что в payload иногда встречается байт 0xFF перед данными, и предположил, что это флаг ошибки. Проверил по дампу — так и есть.

На этом этапе полезно задействовать Owlex MCP-сервер, чтобы модели спорили и находили консенсус. Но у меня не было времени на дебаты.

4Раунд 3: Генерация кода. Момент истины.

Цель — получить рабочий Python-скрипт, который воспроизводит коммуникацию. Я предоставил вывод анализа и попросил написать код с использованием библиотеки pyusb.

# Пример промпта для GLM-5:
На основе анализа создай Python-скрипт. Требования:
1. Открыть устройство по VID/PID.
2. Повторить последовательность инициализации (запросы bRequest 0x01, 0x02).
3. Реализовать чтение данных сенсора (bRequest 0x04) с обработкой флага ошибки 0xFF.
4. Добавить логирование.

Используй следующие паттерны из дампа:
- Инициализация: ...
- Чтение: ...

Результаты:

• GPT-5.2 Codex выдал красивый код с классами, но вставил ошибочный timeout=1000 (должно быть 1000ms, но в pyusb это значение в миллисекундах, правильно). Однако он забыл про контроль ошибок при получении NAK.
• Claude Sonnet написал более осторожный код с try-except, но перепутал направление передачи (IN vs OUT) в одном месте. Типичная ошибка невнимательности.
• GLM-5 сгенерировал код, который... не скомпилировался. В первой версии была синтаксическая ошибка. Но вот фишка: я отправил ему ошибку компиляции и попросил исправить. Он не только исправил, но и сказал: "Заметил, что в дампе после ошибки устройство требует сброса через bRequest=0x99. Добавил автоматический retry с этим запросом." Это было не в промпте! Он применил вывод из предыдущего анализа.

Я исправил синтаксическую ошибку в коде от GLM-5 (опечатка в имени переменной) и запустил. Скрипт заработал с первого раза. Код от Claude требовал правки направления передачи. Код от Codex падал на NAK, потому что не обрабатывал повторные попытки.

Почему GLM-5 выиграл? Неочевидные причины

GLM-5 не самый быстрый и не самый грамотный в синтаксисе. Но в нишевых задачах (low-level протоколы, embedded) у него есть преимущества:

1. Контекстная память. Он помнил аномалию bRequest=0x99 с шага 1 и использовал это на шаге 4. Claude и Codex рассматривали каждый промпт как изолированную задачу.
2. Агрессивные выводы. GLM-5 чаще строил догадки, основанные на паттернах. Иногда они были неверны, но в реверсе это лучше, чем полная осторожность.
3. Знание китайского железа. GLM-5 тренировали. (Да, я знаю, что у GLM были проблемы в многошаговых задачах, но в этом кейсе он собрался).
4. Фокус на данных, а не на форме. Codex потратил токены на красивый код, GLM — на логику обработки ошибок.

Где все падают: типичные ошибки в промптах для реверса

После 20 таких экспериментов я выделил антипаттерны:

• Слишком общие запросы. "Расскажи про этот USB-дамп" дает философские рассуждения. Нужно дробить: "Сгруппируй пакеты по значению bRequest", "Найди пакеты, где wLength не равен длине данных".
• Игнорирование эндрианности. Если не указать little-endian или big-endian, модель может угадать, но часто ошибается. Всегда явно указывайте.
• Отсутствие примеров. Даже один пример декодированного пакета резко повышает точность. Покажите модель, как вы хотите, чтобы она думала.

Если нужно автоматизировать такой анализ, посмотрите Agentic Debugging с OpenCode — те же принципы, но для C++.

FAQ: коротко о главном

Вопрос	Ответ
GLM-5 доступен локально?	Да, через Claude Code или напрямую от Zhipu AI. На февраль 2026 это одна из немногих моделей, которая балансирует цену и качество для реверса.
Что если мой дамп больше 1 млн пакетов?	Разбейте на chunks по фазам протокола. Анализируйте каждую фазу отдельно, затем попросите модель синтезировать вывод. Или используйте LLM Council для параллельной обработки.
Как убедиться, что код безопасен?	Всегда запускайте в sandbox. GLM-5 иногда генерирует вызовы функций, которых нет в библиотеке. Проверяйте каждую строку. Claude Project может помочь с автоматическим тестированием.
Есть ли будущее у автономного реверса?	Да, но нужны специализированные агенты. Kimi Code показал, что мультимодальность помогает, но для USB нужно больше работы. Ожидайте взлета в 2027.

Мой вердикт? GLM-5 выиграл не потому, что он умнее. Он выиграл потому, что лучше сохраняет контекст между запросами и рискует строить гипотезы. В реверсе это critical thinking. Claude Sonnet безопаснее, Codex быстрее пишет код, но для взлома черного ящика нужна настойчивость.

Следующий эксперимент: заставлю их реверсить BLE-протокол с помощью стека Claude 4.5 + Cursor. Если выживу.