Обновление Исходный вопрос больше не подходит для этой проблемы, поэтому я оставлю это в покое, чтобы продемонстрировать, что я пытался / выучил, и для фона.Понятно, что это не просто «вариант Base64», а немного более сложный.
Справочная информация: Я программирую на python 3.x в основном для использования с программой с открытым исходным кодом Blender.Я программист начинающего / любительского уровня, но я достаточно хорошо понимаю большие концепции, я прочитал эти статьи, имеющие отношение к моему вопросу.
Проблема: У меня есть двоичный файл, который содержит данные трехмерной сетки (списки с плавающей точкой и списки целых чисел), соответствующие 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 байтданных между " Вершины " и " / Вершины "
- Эти байты состоят только из aa, AZ, 0-9 и +, / что является стандартным дляbase64
- Когда я получаю эти байты и использую стандартный код base64 в python, я получаю 513792 байта обратно
- Если можно считать, что vertex_count = "42816", то для этого должно быть 42816 * 12 байтовпредставляют x, y, z для каждой вершины.42816 * 12 = 513792. отлично.
- Теперь, если я попытаюсь распаковать мои декодированные байты как 32-битные числа с плавающей запятой, я получу мусор ... так что что-то не так.
I 'Я думаю, что где-то есть дополнительный криптографический шаг.Возможно, есть таблица перевода, шифр вращения или какой-то потоковый шифр?Странно, что количество байтов правильное, но результаты не такие, которые должны ограничивать возможности.Есть идеи?Вот два примера файлов с расширением файла, измененным на * .mesh.Я не хочу публично публиковать этот формат файлов, просто хочу написать импортер для Blender, чтобы я мог использовать эти модели.
Вот два примера файлов.Я извлек необработанный двоичный файл (не декодированный b64) из полей Vertices и Facets, а также предоставил информацию о ограничивающей рамке из «Viewer» для файла этого типа, предоставленного компанией.
Файл примера 1
Файл примера 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 ................. Self ... pUx .... Model ... ˆÃC .... Stream ....
Для меня это выглядит как определение функции сохранения зашифрованной модели.
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