python - 原始浮点编码

Question

更新
原来的问题不再是解决此问题的合适问题，因此我将不做任何说明，以证明我尝试/学习的知识以及背景知识。显然，这不仅是“Base64变体”，而且涉及更多。

背景:
我使用python 3.x编程，主要用于与开源程序Blender一起使用。我是新手/业余级程序员，但我对大型概念非常了解
我已经阅读了与我的问题有关的这些文章。

Wikipedia on Base64

Base64 can get you pwned (pdf)

stackoverflow discussion

其他一些

问题:
我有一个二进制文件，其中包含3d网格数据(浮点列表和整数列表)，该数据对应于每个顶点(浮点)的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的标准格式

当我捕获这些字节并在python中使用标准base64decode时，我从

中获得了513792字节

如果可以相信vertex_count =“42816”，则每个顶点应该需要42816 * 12bytes来表示x，y，z。 42816 * 12 =513792。非常好。

现在，如果我尝试将解码后的字节解压缩为32bit浮点数，则会产生垃圾...所以有些不对劲。

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

这是两个示例文件。我从“顶点”和“构面”字段中提取了原始二进制文件(未解码的b64)，并从“查看器”中为公司提供的此类文件提供了边界框信息。
示例文件1

unmodified file

vertices binary:

facets binary:

Decrypted Data:这是一个.zip文件，其中包含解密的顶点字段和解密的面字段(分别为mesh2.vertices和mesh2.faces)。它还包含一个.STL网格文件，可以在许多应用程序中查看/打开该文件。

示例文件2

unmodified file

vertices binary:

facets binary:

边界框:最小[-4.6，-40.3，-7.3]最大[7.5，-23.1、2.6]

关于“顶点”字段的注释

header 指定vertex_count

header 指定base64_encoded_bytes，它是base64编码发生之前的字节数

header 指定一个“check_value”，其重要性尚未确定

字段中的数据仅包含标准base64字符

在标准base64解码后，输出数据具有...长度= vertex_count * 12 = base64_encoded_bytes。有时b64输出中有4个额外的字节？
-编码/解码字节的比率为4/3，这也是典型的base64

关于“构面”字段的注释

header 指定facet_count

头base64_encoded_bytes是base64编码发生之前的字节数

base64_encoded_bytes/facet_count的比率似乎相差很大
少量。从1.1到1.2。如果他们的比率为12，
被编码为对应于顶点索引的3x4byte整数。
因此，要么压缩此字段，要么将模型保存为
triangle strips或同时使用:-/

更多监听
我打开了公司提供的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.@

嗯...现在这很有趣。默认的加密 key 。注意，每个描述符之间有27个字节，它们始终以“with”结尾。这是24个字节，不包括“ÿÿ”。对我来说，这是一个192位 key ...但是谁知道这些字节中的所有24个是否都与该 key 相对应？有什么想法吗？

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个字节值都在同一范围内，因此我假设它们都是浮点值。