Обновление Первоначальный вопрос больше не является подходящим вопросом для этой проблемы, поэтому я собираюсь оставить это в одиночку, чтобы продемонстрировать, что я пробовал/изучал и на заднем плане. Понятно, что это не просто "вариация Base64", а несколько более активное участие.
Фон: Я программирую в python 3.x в основном для использования с программой с открытым исходным кодом Blender. Я программист новичков/любителей, но я хорошо понимаю большие концепции Я прочитал эти статьи, относящиеся к моему вопросу.
Проблема: У меня есть двоичный файл, который содержит данные 3d-меша (списки поплавков и списки целых чисел), соответствующие координатам x, y, z для каждой вершины (поплавки) и индексы вершин, составляющие грани меша (целые числа), Файл организован в виде xml'ish чувства...
<SomeFieldLabel and header like info>**thensomedatabetween**</SomeFieldLabel>
Вот пример из поля "Вершины"
<Vertices vertex_count="42816" base64_encoded_bytes="513792" check_value="4133547451">685506bytes of b64 encoded data
</Vertices>
- Есть 685506 байт данных между " Вершины" и "/Вершины"
- Эти байты состоят только из a-a, A-Z, 0-9 и +,/, которые являются стандартными для base64
- Когда я беру эти байты и использую стандартный base64decode в python, я получаю обратно 513792 байта.
- Если vertex_count = "42816" можно считать, должно быть 42816 * 12 байтов, необходимых для представления x, y, z для каждой вершины. 42816 * 12 = 513792. отлично.
- Теперь, если я попытаюсь распаковать мои декодированные байты как 32-битные поплавки, я получаю мусор... так что что-то не так.
Я думаю, что где-то есть дополнительный криптографический шаг. Возможно, есть таблица перевода, шифр вращения или какой-то потоковый шифр? Странно, что количество байтов правильное, но результаты не ограничивают возможности. Есть идеи? Вот два примера файлов с расширением файла, измененным на *.mesh. Я не хочу публично публиковать этот формат файла, просто хочу написать импортер для Blender, чтобы я мог использовать модели.
Вот два примера файлов. Я извлек необработанный двоичный файл (не декодированный b64) из полей "Вершины и грани", а также предоставил информацию о ограничительном поле из "Viewer" для этого типа файла, предоставленного компанией.
Файл примера 1
- немодифицированный файл
- вершины двоичные:
- facets binary:
- Расшифрованные данные: Это .zip, содержащий поле расшифрованных вершин и поле расшифрованных граней (mesh2.vertices и mesh2.faces соответственно). Он также содержит файл .stl mesh, который можно просмотреть/открыть во многих приложениях.
Файл примера 2
- немодифицированный файл
- вершины двоичные:
- facets binary:
- Ограничительная коробка: Мин [-4.6, -40.3, -7.3] Макс [7.5, -23.1, 2.6]
Заметки о поле Вершины
- Заголовок указывает вершину_count
- Заголовок указывает base64_encoded_bytes, который является # байтами ПЕРЕД базовой кодировкой base64.
- Заголовок указывает "check_value", значение которого еще не определено
- Данные в этом поле содержат только стандартные символы base64
- После стандартного декодирования base64 выходные данные имеют... length = vertex_count * 12 = base64_encoded_bytes. Иногда в b64 выводятся 4 дополнительных байта? - отношение кодированных/декодированных байтов составляет 4/3, что также является типичным base64
Заметки о поле Границы
- Заголовок указывает facet_count
-
Заголовка base64_encoded_bytes, которая является # байтами, перед кодировкой base64 имеет место
-
Соотношение base64_encoded_bytes/facet_count, по-видимому, немного. От 1,1 до 1,2. Мы ожидаем, что соотношение 12, если они были закодированы как целые числа 3 × 4 байта, соответствующие индексам вершин. Таким образом, либо это поле будет сжато, либо модель будет сохранена с треугольные полосы или оба: -/
Подробнее Snooping
Я открыл файл viewer.exe(в шестнадцатеричном редакторе), который предоставляется компанией для просмотра этих файлов (также где я получил информацию о ограничительной коробке). Вот некоторые фрагменты, которые я нашел интересными и могли продолжить поиск.
f_LicenseClient... я. @...... m_wApplicationID..... @...... f_bSiteEncryptionActive..... @...... f_bSaveXXXXXXInternalEncrypted..... @...... f_bLoadXXXXXXInternalEncrypted... ¼ @...... f_strSiteKey.... í †......
В LoadXXXXXXInternalEncrypted и SaveXXXXXXInternalEncrypted Я заблокировал название компании с помощью XX. Похоже, что у нас определенно есть шифрование за пределами простой таблицы base64.
SaveEncryptedModelToStream................. Self... pUx.... Model... ÃC.... Stream....
Это для меня похоже на определение функции о том, как сохранить зашифрованную модель.
DefaultEncryptionMethod¼ @........ ÿ....... €... € ÿÿ.DefaultEncryptionKey € - †....... ÿ ÿ....... €.... ÿÿ.DefaultIncludeModelData -. †....... ÿ ÿ....... €... € ÿÿ.DefaultVersion @
Ahhh... теперь это интересно. Клавиша шифрования по умолчанию. Обратите внимание, что между каждым из этих дескрипторов имеется 27 байт, и они всегда заканчиваются на "ÿÿ". Здесь 24 байта, исключая "ÿÿ". Для меня это 192-битный ключ... но кто знает, соответствуют ли все 24 байта этим ключевым? Любые мысли?
80 96 86 00 18 00 00 FF 18 00 00 FF 01 00 00 00 00 00 00 80 01 00 00 00
Фрагменты кода
Чтобы сэкономить место в этом потоке, я помещаю этот script в свой drop-box для загрузки. Он читает через поле, извлекает основную информацию из полей вершин и граней и выдает кучу материала. Вы можете отменить комментарий, чтобы сохранить блок данных в отдельный файл для упрощения анализа.
basic_mesh_read.py
Это код, который я использовал, чтобы попробовать все "разумные" варианты стандартной библиотеки base64. try_all_b64_tables.py
