原始浮点编码 [英] Raw floating point encoding

问题描述

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

Update The original question is no longer the appropriate question for this problem, so I'm going to leave this alone to demonstrate what I tried/learned and for the background. It's clear that this is not just a "Base64 variation" and is a bit more involved.

背景：
我在python 3.x主要用于开源程序Blender。我是新手/业余级程序员，但我对基本概念了解得很好
我已经阅读了与问题相关的文章。

Background: I program in python 3.x mainly for use with the open source program Blender. I'm a novice/amateur level programmer but I understand the big concepts fairly well I've read these articles relevant to my question.

• Wikipedia on Base64


• Base64可以让您获得（pdf）


• stackoverflow讨论


• 一些其他人

• Wikipedia on Base64
• Base64 can get you pwned (pdf)
• stackoverflow discussion
• Some others

问题：
我有一个二进制文件，其中包含3d网格数据（浮点列表和整数列表），与每个顶点（浮点）的x，y，z坐标相对应，并构成了顶点的面的索引网格（整数）。该文件以xml'ish的感觉进行组织...

Problem: I have a binary file which contains 3d mesh data (lists of floats and lists of integers) corresponding to x,y,z coordinates for each vertex (floats) and the indices of the vertices which make up the faces of the mesh (integers). The file is organized in an xml'ish kind of feeling...

<SomeFieldLabel and header like info>**thensomedatabetween**</SomeFieldLabel>

这里是顶点字段中的示例

Here is the example from the "Vertices" field

<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. 现在，如果我尝试将解码后的字节解压缩为32bit浮点数，则会出现垃圾...所以有些东西了。

1. There are 685506 bytes of data between "Vertices" and "/Vertices"
2. Those bytes only consist of a-a, A-Z, 0-9, and +,/ which is standard for base64
3. When I grab those bytes, and use standard base64decode in python, I get 513792 bytes back out
4. If vertex_count="42816" can be believed, there should be 42816*12bytes needed to represent x,y,z for each vertex. 42816*12 = 513792. excellent.
5. Now, if I try and unpack my decoded bytes as 32bit floats, I get garbage...so something is ammis.

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

I'm thinking there is an extra cryptographic step somewhere. Perhaps there is a translation table, rotation cipher or some kind of stream cipher? It's strange that the number of bytes is correct but that the results are not which should limit the possibilities. Any ideas? Here are two example files with the file extension changed to *.mesh. I don't want to publicly out this file format, just want to write an importer for Blender so I can use the models.

这里有两个示例文件。我已经从顶点和构面字段中提取了原始二进制文件（未解码的b64），并从查看器中提供了该公司提供的此类文件的边界框信息。

示例文件1

Here are two example files. I have extracted the raw binary (not b64 decoded) from the Vertices and Facets fields as well as provided the bounding box information from a "Viewer" for this type of file provided by the company.
Example File 1

• 未修改的文件


• 顶点二进制文件：


• 方面二进制文件：


• 解密的数据：这是一个.zip文件，其中包含解密的顶点字段和解密的面部字段（mesh2.vertices和mesh2 .faces）。它还包含一个.stl网格文件，可以在许多应用程序中查看/打开该文件。

• unmodified file
• vertices binary:
• facets binary:
• Decrypted Data: This is a .zip containing the decrypted vertices field and the decrypted faces field (mesh2.vertices and mesh2.faces respectively). It also contains a .stl mesh file which can be viewed/opened in many applications.

示例文件2

• 未修改的文件


• 顶点二进制文件：


• facets二进制文件：


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

• unmodified file
• vertices binary:
• facets binary:
• Bounding Box: Min[-4.6, -40.3, -7.3] Max[7.5, -23.1, 2.6]

关于顶点字段的注释

• 标头指定顶点计数


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


• 标头指定一个 check_value，其重要性尚未确定确定


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


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

• The header specifies the vertex_count
• The header specifies base64_encoded_bytes which is the # of bytes BEFORE base64 encoding takes place
• The header specifies a "check_value" whose significance is yet to be determined
• The data in the field only contains the standard base64 characters
• After standard base64 decoding the output data has... length = vertex_count*12 = base64_encoded_bytes. Occasionally there are 4 extra bytes in the b64 output? -the ratio of encoded/decoded bytes is 4/3 which is also typical base64

构面字段

• 标头指定一个facet_count



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

• The header specifies a facet_count

• The header base64_encoded_bytes which is the # of bytes BEFORE base64 encoding takes place

base64_encoded_bytes / facet_count的比率似乎相差
位。从1.1到1.2。如果将它们
编码为对应于顶点索引的3x4byte整数，我们期望比率为12。
因此，可以填写此字段，也可以使用
保存模型。三角带或两者皆有：-/

The ratio of base64_encoded_bytes/facet_count seems to vary quite a bit. From 1.1 to about 1.2. We would expect a ratio of 12 if they were encoded as 3x4byte integers corresponding to the vertex indices. So either this field is compresesed or the model is saved with triangle strips, or both :-/

More Snooping

我打开了公司提供的viewer.exe（在十六进制编辑器中）以查看这些文件（也在其中获得了边界框信息）。以下是一些我发现很有趣的片段，可以进一步进行搜索。

More Snooping
I opened up the viewer.exe (in a hex editor) which is provided by the company to view these files (also where I got the bounding box info). Here are some snippets which I found interesting and could further the search.

f_LicenseClient ...Ì。@ ...... m_wApplicationID ..... @ ...... f_bSiteEncryptionActive ..... @@ f_bSaveXXXXXXInternalEncrypted ..... @@ f_bLoadXXXXXXInternalEncrypted ...¼！@ ..... .f_strSiteKey ....í†......

f_LicenseClient...Ì.@......m_wApplicationID.....@......f_bSiteEncryptionActive.....@......f_bSaveXXXXXXInternalEncrypted.....@......f_bLoadXXXXXXInternalEncrypted...¼!@......f_strSiteKey....í†......

在LoadXXXXXXInternalEncrypted和SaveXXXXXXInternalEncrypted中，我用XX。看起来我们肯定已经对简单的base64表变量进行了加密。

In LoadXXXXXXInternalEncrypted and SaveXXXXXXInternalEncrypted I've blocked out the company name with XX. It looks like we definitely have some encryption beyond a simple base64 table variation.

SaveEncryptedModelToStream ......... ..... Self ... pUx .... Model ... ˆÃC .... Stream ....

SaveEncryptedModelToStream.................Self...pUx....Model...ˆÃC....Stream....

对我来说，这看起来像一个有关如何保存加密模型的函数定义。

This to me looks like a function definition on how to save an encrypted model.

DefaultEncryptionMethod¼！@ ... Default .......€...€ÿÿ.DefaultEncryptionKey€-†....ÿ...ÿ....€....ÿÿ.DefaultIncludeModelData-†....ÿ ...ÿ.......€...€ÿÿ.DefaultVersion。@

DefaultEncryptionMethod¼!@........ÿ.......€...€ÿÿ.DefaultEncryptionKey€–†....ÿ...ÿ.......€....ÿÿ.DefaultIncludeModelData –†....ÿ...ÿ.......€...€ÿÿ.DefaultVersion.@

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

Ahhh...now that is interesting. A default encryption key. Notice there are 27 bytes between each of those descriptors and they always end with "ÿÿ." Here is 24 bytes excluding "ÿÿ." To me, this is a 192 bit key...but who knows if all 24 of those bytes correspond to the key? Any thoughts?

80 96 86 00 18 00 00 FF 18 00 00 FF 01 00 00 00 00 00 00 80 01 00 00 00

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

This is the code I used to try all "reasonable" variations on the standard base64 library. try_all_b64_tables.py

推荐答案

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

I am not sure why you think the results are not floating point numbers. The vertices data in the "decrypted data" you gave, contains as first 4 bytes "f2 01 31 41". Given an LSB byte order, that corresponds to the bit pattern "413101f2", which is the IEEE 754 representation of the float value 11.062973. All the 4 byte values in that file are in that same range, so I assume they all are float values.

这篇关于原始浮点编码的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！