原始浮点编码

Question

更新 原始问题不再是这个问题的适当问题,所以我将单独留下来展示我尝试/学习的内容和背景.很明显,这不仅仅是一个"Base64变种",而且涉及的更多一些.

背景: 我在python 3.x中编程主要用于开源程序Blender.我是新手/业余级程序员,但我很了解大概念我已经阅读了与我的问题相关的这些文章.

• Base64上的维基百科
• Base64可以帮助你(pdf)
• stackoverflow讨论
• 其他一些人

问题: 我有一个二进制文件,其中包含对应于每个顶点(浮点数)的x,y,z坐标的3d网格数据(浮点列表和整数列表)以及构成网格面的顶点索引(整数).该文件以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个字节的数据
2. 这些字节只包含aa,AZ,0-9和+,/,这是base64的标准
3. 当我抓住那些字节,并在python中使用标准的base64decode时,我得到了513792个字节
4. 如果可以认为vertex_count ="42816",则表示每个顶点的x,y,z需要42816*12bytes.42816*12 = 513792.优秀.
5. 现在,如果我尝试将解码后的字节解压缩为32位浮点数,我会得到垃圾......所以有些东西是ammis.

我在想某处有一个额外的加密步骤.也许有翻译表,旋转密码或某种流密码？奇怪的是,字节数是正确的,但结果不应该限制可能性.有任何想法吗？以下是两个示例文件,文件扩展名更改为*.mesh.我不想公开这种文件格式,只想为Blender编写一个导入器,这样我就可以使用这些模型了.

这是两个示例文件.我从Vertices和Facets字段中提取了原始二进制文件(不是b64解码),并从公司提供的此类文件的"Viewer"中提供了边界框信息.
示例文件1

• 未修改的文件
• 顶点二进制:
• facets binary:
• 解密数据: 这是一个.zip,包含解密的顶点字段和解密的faces字段(分别为mesh2.vertices和mesh2.faces).它还包含一个.stl网格文件,可以在许多应用程序中查看/打开.

示例文件2

• 未修改的文件
• 顶点二进制:
• 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_bytes.偶尔b64输出中还有4个额外的字节？ - 编码/解码字节的比率是4/3,这也是典型的base64

关于Facets字段的注释

• 标头指定了facet_count

• 标头base64_encoded_bytes,它是发生base64编码时的字节数

• base64_encoded_bytes/facet_count的比例似乎变化很大.从1.1到大约1.2.如果它们被编码为对应于顶点索引的3x4byte整数,我们期望比率为12.因此要么对此字段进行补充,要么使用三角形条保存模型,或者两者都保存 : - /

更多窥探
我打开了viewer.exe(在十六进制编辑器中),由公司提供查看这些文件(也是我获得边界框信息的地方).以下是我发现有趣的一些片段,可以进一步搜索.

f_LicenseClient ......我@ ...... m_wApplicationID ..... @ ...... f_bSiteEncryptionActive ..... @ ...... f_bSaveXXXXXXInternalEncrypted ..... @ .... ..f_bLoadXXXXXXInternalEncrypted ...¼!@ ...... f_strSiteKey ....我†......

在LoadXXXXXXInternalEncrypted和SaveXXXXXXInternalEncrypted中,我用XX阻止了公司名称.看起来我们肯定有一些超出简单的base64表变体的加密.

SaveEncryptedModelToStream .................自... PUX ....型号... AC ....流....

对我来说,这看起来像是关于如何保存加密模型的函数定义.

DefaultEncryptionMethod¼@ ........ÿ.......€...€ÿÿ.DefaultEncryptionKey€ - †.... Y ...ÿ.......€... .ÿÿ.DefaultIncludeModelData - †....ÿ...ÿ.......€...€De.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

Answer 1

我不知道为什么你认为结果不是浮点数。您提供的“解密数据”中的顶点数据包含前 4 个字节“f2 01 31 41”。给定 LSB 字节顺序，对应于位模式“413101f2”，它是浮点值 11.062973 的 IEEE 754 表示形式。该文件中的所有 4 字节值都在同一范围内，因此我假设它们都是浮点值。