Необработанное кодирование с плавающей запятой
Обновление Первоначальный вопрос больше не подходит для этой проблемы, поэтому я оставлю его в покое, чтобы продемонстрировать, что я пробовал/узнал, и для фона. Понятно, что это не просто «вариация Base64», а нечто большее.
Фон: Я программирую на python 3.x в основном для использования с программой Blender с открытым исходным кодом. Я программист уровня новичка/любителя, но я достаточно хорошо понимаю большие концепции. Я прочитал эти статьи, относящиеся к моему вопросу.
Задача: У меня есть двоичный файл, который содержит данные трехмерной сетки (списки поплавков и списки целых чисел ), соответствующие координатам x, y, z для каждой вершины (поплавки )и индексы вершин, которые составляют грани сетки (целые числа ). Файл организован в стиле xml...
**thensomedatabetween**
Вот пример из поля "Вершины"
685506bytes of b64 encoded data
- Между «Vertices » и «/Vertices »
- находится 685506 байт данных. Эти байты состоят только из -a, A -Z, 0 -9 и +,/, что является стандартным для base64
- . Когда я беру эти байты и использую стандартный base64decode в python, я получаю обратно 513792 байта
- Если вершине _count="42816" можно верить, должно быть 42816 *12 байт, необходимых для представления x,y,z для каждой вершины. 42816 *12 = 513792. отлично.
- Теперь, если я попытаюсь распаковать свои декодированные байты как 32-битные числа с плавающей запятой, я получу мусор... так что что-то не так.
Я думаю, что где-то есть дополнительный криптографический шаг.Возможно, есть таблица перевода, ротационный шифр или какой-то поточный шифр? Странно, что количество байтов правильное, а результаты нет, что должно ограничивать возможности. Любые идеи? Вот два примера файлов с измененным расширением на *.mesh. Я не хочу публиковать этот формат файла, просто хочу написать импортер для Blender, чтобы я мог использовать модели.
Вот два примера файлов. Я извлек необработанный двоичный файл (, не декодированный с помощью b64 ), из полей Вершины и Фасеты, а также предоставил информацию о ограничивающей рамке из «Просмотра» для этого типа файла, предоставленного компанией.
Пример файла 1
- немодифицированный файл
- бинарные вершины:
- бинарные грани:
- Расшифрованные данные:Это ZIP-файл, содержащий поле расшифрованных вершин и поле расшифрованных граней (mesh2.vertices и mesh2.faces соответственно ). Он также содержит файл сетки.stl, который можно просмотреть/открыть во многих приложениях.
Пример файла 2
- немодифицированный файл
- бинарные вершины:
- бинарные грани:
- Граничная рамка :Мин[ -4,6, -40,3, -7,3] Макс[7,5, -23,1, 2,6]
Примечания к полю вершин
- Заголовок указывает количество вершин _
- . Заголовок указывает base64 _закодированные _байты, которые представляют собой #байтов ДО кодирования base64
- В заголовке указано «проверочное _значение», значимость которого еще предстоит определить
- . Данные в поле содержат только стандартные символы base64
- . После стандартного декодирования base64 выходные данные имеют... длина = вершина _количество *12 = base64 _закодировано _байт.Иногда в выводе b64 есть 4 дополнительных байта? -соотношение закодированных/декодированных байтов составляет 4/3, что также типично для base64
Примечания к полю «Фасеты»
- В заголовке указан фасет _счетчик
Заголовок base64 _закодировал _байт, который представляет собой #байтов ДО кодирования base64
Соотношение base64 _закодированных _байт/количество фасетов _, по-видимому, сильно различается. кусочек. От 1,1 до примерно 1,2. Мы ожидаем коэффициент 12, если они были закодированы как целые числа размером 3x4 байта, соответствующие индексам вершин. Так что либо это поле сжато, либо модель сохраняется с треугольные полосы или и то, и другое :-/
Больше слежки
Я открыл файл 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
Фрагменты кода
Чтобы сэкономить место в этой ветке, я поместил этот скрипт в папку -для скачивания. Он читает поле, извлекает основную информацию из полей вершин и граней и выводит кучу информации. Вы можете де -закомментировать конец, чтобы сохранить блок данных в отдельный файл для облегчения анализа.
базовая _сетка _read.py
Это код, который я использовал, чтобы попробовать все «разумные» варианты стандартной библиотеки base64. попробовать _все _b64 _table.py