Обновить Исходный вопрос больше не является подходящим вопросом для этой проблемы, поэтому я собираюсь оставить его в покое, чтобы продемонстрировать, что я пытался / выучил, и для справки. Понятно, что это не просто «вариант Base64», а более сложный процесс.

Фон: Я программирую на python 3.x в основном для использования с программой с открытым исходным кодом Blender. Я программист начинающего / любительского уровня, но я достаточно хорошо понимаю большие концепции, я прочитал эти статьи, имеющие отношение к моему вопросу.

Википедия на Base64Base64 может помочь вам (pdf)обсуждение стекаНекоторые другие

Проблема: У меня есть бинарный файл, который содержит данные трехмерной сетки (списки с плавающей точкой и списки целых чисел), соответствующие координатам 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) из полей Vertices и Facets, а также предоставил информацию об ограничивающей рамке из «Viewer» для этого типа файла, предоставленного компанией.
Файл примера 1

неизмененный файлдвоичные вершины:бинарные грани:Расшифрованные данные: Это ZIP-файл, содержащий поле дешифрованных вершин и поле дешифрованных граней (mesh2.vertices и mesh2.faces соответственно). Он также содержит файл сетки .stl, который можно просматривать / открывать во многих приложениях.

Файл примера 2

неизмененный файлдвоичные вершины:бинарные грани:Ограничительная рамка: Мин. [-4,6, -40,3, -7,3] Макс. [7,5, -23,1, 2,6]

Примечания о поле «Вершины»

Заголовок определяет vertex_countВ заголовке указывается base64_encoded_bytes, который представляет собой количество байтов ДО того, как произойдет кодирование base64.Заголовок определяет "check_value", значение которого еще предстоит определитьДанные в поле содержат только стандартные символы base64После стандартного декодирования base64 выходные данные имеют ... length = vertex_count * 12 = base64_encoded_bytes. Иногда в выводе b64 есть 4 лишних байта? отношение кодированных / декодированных байтов равно 4/3, что также является типичным base64

Примечания о поле Facets

В заголовке указывается facet_count

Заголовок base64_encoded_bytes, который является числом байтов ДО кодирования base64, имеет место

Соотношение base64_encoded_bytes / facet_count, похоже, немного варьируется. От 1,1 до 1,2. Мы ожидаем, что отношение 12, если они были закодированы как 3x4-байтовые целые числа, соответствующие индексам вершин. Так что либо это поле сжато, либо модель сохранена сполоски треугольника, или оба :-/

Больше Snooping
Я открыл файл viewer.exe (в шестнадцатеричном редакторе), который предоставляется компанией для просмотра этих файлов (также там, где я получил информацию о ограничительной рамке). Вот некоторые фрагменты, которые мне показались интересными и могли бы способствовать поиску.

f_LicenseClient ... я. @ ...... m_wApplicationID ..... @ ...... f_bSiteEncryptionActive ..... @ ...... f_bSaveXXXXXXInternalEncrypted ..... @ .... ..f_bLoadXXXXXXInternalEncrypted ... ¼ @ ...... f_strSiteKey .... í † ......

В LoadXXXXXXInternalEncrypted и SaveXXXXXXInternalEncrypted я заблокировал название компании с помощью XX. Похоже, у нас определенно есть какое-то шифрование, кроме простого варианта таблицы base64.

SaveEncryptedModelToStream ................. самообслуживания ... Pux .... модель ... Ac .... поток ....

Для меня это выглядит как определение функции о том, как сохранить зашифрованную модель.

DefaultEncryptionMethod¼ @ ........ ÿ ....... € ... € ÿÿ.DefaultEncryptionKey € - † .... ... ÿ ÿ ....... € ... .ÿÿ.DefaultIncludeModelData -. † .... ... ÿ ÿ ....... € ... € ÿÿ.DefaultVersion @

Аааа ... теперь это интересно. Ключ шифрования по умолчанию. Обратите внимание, что между каждым из этих дескрипторов есть 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

Фрагменты кода
Чтобы сэкономить место в этой теме, я поместил этот скрипт в окно для загрузки. Он читает поле, извлекает основную информацию из полей вершин и фасетов и распечатывает кучу вещей. Вы можете закомментировать конец, чтобы сохранить блок данных в отдельный файл для более удобного анализа.
basic_mesh_read.py

Это код, который я использовал, чтобы попробовать все «разумные» варианты стандартной библиотеки base64.try_all_b64_tables.py