Кодирование с плавающей запятой

Question

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

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

• Wikipedia on Base64
• Base64 can get you pwned (pdf)
• stackoverflow discussion
• Некоторые другие

Проблема: У меня есть двоичный файл, который содержит 3D-данные сетки (списки поплавков и списки целых чисел) соответствующие координатам x, y, z для каждой вершины (float) и индексы вершин которые составляют грани сетки (целые числа). Файл организован в 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> 

1. Есть 685506 байт данных между "Вершины "и" /Vertices "
2. Эти байты только состоят из аа, AZ, 0-9 и + /, который является стандартом для base64
3. Когда я беру эти байты и использую стандартный base64decode в python, я получаю обратно 513792 байта
4. Если можно считать, что vertex_count = "42816" должно быть 42816 * 12 байтов, чтобы представлять x, y, z для каждого вершина. 42816 * 12 = 513792. отлично.
5. Теперь, если я попытаюсь распаковать мои декодированные байты как 32-битные поплавки, я получаю мусор ... так что что-то не так.

Я думаю, что где-то есть дополнительный криптографический шаг. Возможно, есть таблица перевода, шифр вращения или какой-то потоковый шифр? Странно, что количество байтов правильное, но результаты не ограничивают возможности. Есть идеи? Вот два примера файлов с расширением файла, измененным на * .mesh. Я не хочу публично публиковать этот формат файла, просто хочу написать импортера для Blender, чтобы я мог использовать модели.

Вот два примера файлов. Я извлек необработанный двоичный файл (не декодированный b64) из полей «Вершины и грани», а также предоставил информацию о ограничительном блоке из «Viewer» для этого типа файла, предоставленного компанией.
Файл примера 1

• unmodified file
• vertices binary:
• facets binary:
• Decrypted Data: Это .zip, содержащий расшифрованный поле вершины и поле расшифрованный граней (mesh2.vertices и mesh2.faces соответственно). Он также содержит файл .stl mesh, который можно просмотреть/открыть во многих приложениях.

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

• unmodified file
• vertices binary:
• facets binary:
• габаритный прямоугольник: Мин [-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_b ytes. Иногда в b64 выводятся 4 дополнительных байта? -The отношение кодированных/декодированных байт 4/3, который также типично base64

Заметки о поле Грани

• Заголовок указывает facet_count

• The base64_encoded_bytes заголовка, который является # байтов ПЕРЕД базовой кодировкой base64

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

Больше 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. @

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

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

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

Answer 1

Я не уверен, почему вы считаете, что результаты не являются числами с плавающей запятой. Данные вершин в «дешифрованных данных», которые вы указали, содержат первые 4 байта «f2 01 31 41». Учитывая порядок байтов LSB, который соответствует битовой схеме «413101f2», которая представляет собой представление IEEE 754 значения поплавка 11.062973. Все 4 байтовых значения в этом файле находятся в том же диапазоне, поэтому я предполагаю, что все они являются значениями с плавающей запятой.