С помощью Codex разработчики восстановили формат зашифрованной базы CronosPro
Команда, которая занимается нормализацией разнородных данных в дата-lake, получила дамп базы CronosPro, три бинарных файла, CroBank.dat, CroIndex.dat и CroStru.dat, которые существующие инструменты не могли разобрать и считали повреждёнными. CronosPro (Cronos), проприетарная десктопная система управления информацией, исторически применявшаяся организациями в России и других постсоветских странах для построения реестров, поисковых архивов и внутренних информационных систем.
За основу взяли открытый парсер Cronodump (репозиторий alephdata/cronodump с двумя командами: crodump для инспекции внутренней структуры файлов и croconvert для экспорта в CSV, PostgreSQL или HTML), а для анализа структуры проблемного дампа и доработки кодовой базы Cronodump привлекли ИИ-агента Codex. Штатный парсер не смог прочитать файл схемы CroStru.dat, из-за чего крупный CroBank.dat, где хранятся сами записи, превращался в нечитаемый поток байтов без привязки к столбцам.
Осмотр заголовков файлов показал: версия формата, Cronos 01.11 (соответствует Cronos v4), и из трёх файлов только схема CroStru была закодирована защитной таблицей замены, так называемой KOD-таблицей (KOD S-box) на 256 значений, в которой расшифровка байта зависит ещё и от его позиции внутри записи, и от номера самой записи: plaintext[i] = KOD[ciphertext[i]] − i − номер_записи (по модулю 256). Файлы CroBank и CroIndex были только сжаты, KOD-защиты на них не было. Из-за этого встроенные в Cronodump эвристики восстановления таблицы не сработали: strucrack, который ищет KOD-таблицу по частоте нулевых байт в схеме, не набрал достаточно данных из-за малого объёма CroStru, а dbcrack, который использует предсказуемые заголовки сжатых записей CroBank/CroIndex, вообще не был применим, эти файлы не были KOD-кодированы. Попутно в самом Cronodump нашли и поправили мелкий баг: код восстановления таблицы падал из-за отсутствующего поля cargs.compact.
Тогда команда построила собственную статистическую модель. По эталонной тестовой базе, входящей в репозиторий Cronodump, и по нешифрованному компоненту того же дампа оценили типичное распределение байт в валидной схеме Cronos: много нулей, короткие целочисленные значения, ASCII-имена полей, текст в кодировке Windows-1251, повторяющиеся шаблоны описания полей. Для каждого зашифрованного байта схемы, зная его позицию и номер записи, и для каждого возможного варианта расшифровки посчитали, насколько правдоподобным получился бы такой байт; так возникла таблица оценок 256×256. Поскольку KOD-таблица обязана быть перестановкой (каждому байту шифротекста соответствует ровно один байт открытого текста, без повторов), выбрать лучший вариант независимо для каждой строки нельзя, несколько строк могли бы претендовать на одно и то же значение. Это классическая задача о назначениях, и её решили венгерским алгоритмом из SciPy (scipy.optimize.linear_sum_assignment), подав оценки со знаком минус, чтобы встроенная в функцию минимизация стоимости работала как максимизация правдоподобия. Результатом стала полная 256-байтовая перестановка KOD-таблицы, кандидат на верный ключ.
Далее авторы поясняют, что одной «читаемости» результата недостаточно как доказательства правильности: неверная подстановка тоже может случайно дать похожие на буквы и цифры фрагменты, и CSV с как будто нормальными значениями под неверными заголовками хуже явной ошибки, потому что выглядит достоверно, оставаясь семантически испорченным. Поэтому дальше должна идти структурная проверка результата, но именно в этом месте доступный текст статьи обрывается на середине фразы, и чем закончилась проверка, из него не видно.
Ключевые факты
- CronosPro (Cronos), проприетарная десктопная СУБД, распространённая в России и постсоветских странах для реестров и архивов; дамп из трёх файлов (.dat) существующие инструменты считали повреждённым
- Команда доработала открытый парсер Cronodump, для анализа структуры дампа и правки кодовой базы привлекли ИИ-агента Codex
- Не читалась только схема CroStru.dat, она была защищена 256-байтовой KOD-таблицей подстановки, где расшифровка зависит от позиции байта и номера записи; CroBank и CroIndex были лишь сжаты, без KOD-защиты
- Встроенные в Cronodump эвристики восстановления таблицы (strucrack, dbcrack) не справились из-за малого объёма данных схемы и того, что CroBank/CroIndex не были KOD-кодированы
- KOD-таблицу восстановили как задачу о назначениях: построили таблицу правдоподобия по статистике байт эталонных схем и решили её венгерским алгоритмом из SciPy (linear_sum_assignment), получив полную 256-байтовую перестановку
Почему это важно
Случай показывает рабочую связку для взлома простых, но недокументированных форматов защиты: не перебор пароля, а статистика по эталонным данным плюс точная комбинаторная оптимизация. Задача восстановления таблицы подстановки формально сведена к задаче о назначениях и решена венгерским алгоритмом вместо жадного посимвольного подбора, это надёжнее, потому что учитывает ограничение «таблица обязана быть перестановкой» сразу для всех 256 значений, а не по одному байту. ИИ-агент здесь выступает не автором решения, а инструментом анализа: Codex помог разобраться в структуре дампа и доработать существующую кодовую базу, а собственно статистическую модель и решение задачи о назначениях команда строила сама.
Кому это важно
Дата-инженерам и архивистам, которые сталкиваются с легаси-форматами вроде CronosPro, базами на нём десятилетиями пользовались госструктуры и организации на постсоветском пространстве для реестров и документных архивов, и рабочих читалок для повреждённых дампов немного. Специалистам по реверс-инжинирингу простых substitution-шифров и криптоанализу с открытым текстом. Разработчикам, использующим ИИ-агентов (Codex и аналоги) для разбора и доработки чужого низкоуровневого кода парсеров.
Как это применить
Метод переносим на похожие задачи восстановления таблиц подстановки: сначала разделить, что в файле сжато, а что защищено шифром, это разные слои, и смешивать их не стоит; затем по образцовым/эталонным файлам того же формата оценить типичное распределение байт открытого текста; для каждого зашифрованного байта посчитать таблицу правдоподобия по всем возможным вариантам расшифровки с учётом позиции и, если нужно, номера записи; решить получившуюся задачу не жадным выбором максимума по строке, а как задачу о назначениях, например scipy.optimize.linear_sum_assignment. Инструментарий из статьи открытый: парсер Cronodump (alephdata/cronodump) и SciPy.
Можно ли доверять
Технический процесс расписан детально и с конкретными числами (версия формата 01.11, размер таблицы 256 байт, формула декодирования, ссылка на PR #22 в апстриме), это похоже на достоверный инженерный отчёт. Но доступный текст статьи обрывается на середине фразы прямо в разделе про финальную структурную проверку результата, чем закончилась валидация и подтвердилась ли расшифровка как верная, в тексте не сказано. Ни автор, ни организация, ни дата публикации в тексте не указаны.
Риски и подводные камни
Главный риск, о котором прямо предупреждают сами авторы: неверная подстановка тоже может случайно дать похожие на буквы и цифры фрагменты, и на вид корректный CSV под неверными заголовками столбцов опаснее явной ошибки, потому что выглядит достоверным, оставаясь по сути неверным, отсюда и нужна отдельная структурная проверка, а не просто визуальная читаемость результата. Кроме того, найденный в апстриме незавершённый патч (PR #22) решает только проблему неоднозначных KOD-записей и не учитывает ряд других особенностей именно этой версии формата, встроенный в запись Cronos v4 заголовок, сдвигающий декодирование, скрытые технические поля и типы текстовых полей, так что готовый чужой патч в лоб для такой задачи не подходит.