numeros - float en python

Codificación de punto flotante sin procesar

Question

Actualización La pregunta original ya no es la pregunta adecuada para este problema, por lo que voy a dejar esto solo para demostrar lo que he probado / aprendido y para el fondo. Está claro que esto no es solo una "variación de Base64" y está un poco más involucrado.

Antecedentes: programo en Python 3.x principalmente para usar con el programa de código abierto Blender. Soy un programador de nivel principiante / aficionado pero entiendo los grandes conceptos bastante bien. He leído estos artículos relevantes a mi pregunta.

• Wikipedia en Base64
• Base64 puede hacerte pwned (pdf)
• discusión de stackoverflow
• Algunos otros

Problema: tengo un archivo binario que contiene datos de malla 3d (listas de flotadores y listas de enteros) correspondientes a las coordenadas x, y, z para cada vértice (flotadores) y los índices de los vértices que forman las caras de la malla ( enteros). El archivo está organizado en un tipo de sentimiento xml''ish ...

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

Aquí está el ejemplo del campo "Vértices"

<Vertices vertex_count="42816" base64_encoded_bytes="513792" check_value="4133547451">685506bytes of b64 encoded data
</Vertices>

1. Hay 685506 bytes de datos entre " Vertices " y " / Vertices "
2. Esos bytes solo constan de aa, AZ, 0-9 y +, que es estándar para base64
3. Cuando tomo esos bytes y uso el código base64 estándar en python, obtengo 513792 bytes de vuelta
4. Si vertex_count = "42816" se puede creer, debe haber 42816 * 12bytes necesarios para representar x, y, z para cada vértice. 42816 * 12 = 513792. excelente.
5. Ahora, si intento desempaquetar mis bytes decodificados como flotantes de 32 bits, obtengo basura ... así que algo es ammis.

Estoy pensando que hay un paso criptográfico extra en alguna parte. ¿Quizás hay una tabla de traducción, un cifrado de rotación o algún tipo de cifrado de flujo? Es extraño que la cantidad de bytes sea correcta pero que los resultados no limiten las posibilidades. ¿Algunas ideas? Aquí hay dos archivos de ejemplo con la extensión de archivo cambiada a * .mesh. No quiero publicar públicamente este formato de archivo, solo quiero escribir un importador para Blender para poder usar los modelos.

Aquí hay dos archivos de ejemplo. He extraído el binario sin formato (no b64 decodificado) de los campos de Vértices y Facetas, así como la información del cuadro delimitador de un "Visor" para este tipo de archivo provisto por la compañía.
Ejemplo de archivo 1

• archivo no modificado
• vértices binarios:
• facetas binarias:
• Datos descifrados : Este es un .zip que contiene el campo de vértices descifrados y el campo de caras descifradas (mesh2.vertices y mesh2.faces respectivamente). También contiene un archivo de malla .stl que se puede ver / abrir en muchas aplicaciones.

Ejemplo de archivo 2

• archivo no modificado
• vértices binarios:
• facetas binarias:
• Cuadro delimitador: Mín. [-4.6, -40.3, -7.3] Máx. [7.5, -23.1, 2.6]

Notas sobre el campo Vértices

• El encabezado especifica el vertex_count
• El encabezado especifica base64_encoded_bytes que es el número de bytes ANTES de que tenga lugar la codificación base64
• El encabezado especifica un "valor_comprar" cuyo significado aún no se ha determinado
• Los datos en el campo solo contienen los caracteres base64 estándar
• Después de la decodificación de base64 estándar, los datos de salida tienen ... length = vertex_count * 12 = base64_encoded_bytes. ¿Ocasionalmente hay 4 bytes extra en la salida de b64? -la proporción de bytes codificados / decodificados es 4/3, que también es la base típica64

Notas sobre el campo de las facetas

• El encabezado especifica un facet_count

• El encabezado base64_encoded_bytes que es el número de bytes ANTES de que tenga lugar la codificación base64

• La proporción de base64_encoded_bytes / facet_count parece variar un poco. De 1.1 a alrededor de 1.2. Se esperaría una relación de 12 si se codificaran como enteros de 3x4 bytes correspondientes a los índices de vértice. Entonces, o bien este campo se comprime o el modelo se guarda con tiras de triángulos , o ambos: - /

Más espionaje
Abrí el viewer.exe (en un editor hexadecimal) que proporciona la compañía para ver estos archivos (también donde obtuve la información del cuadro delimitador). Aquí hay algunos fragmentos que me parecieron interesantes y que podrían continuar la búsqueda.

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

En LoadXXXXXXInternalEncrypted y SaveXXXXXXInternalEncrypted he bloqueado el nombre de la empresa con XX. Parece que definitivamente tenemos algo de cifrado más allá de una simple variación de tabla base64.

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

Esto me parece una definición de función sobre cómo guardar un modelo cifrado.

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

Ahhh ... ahora eso es interesante. Una clave de cifrado por defecto. Note que hay 27 bytes entre cada uno de esos descriptores y siempre terminan con "ÿÿ". Aquí hay 24 bytes excluyendo "ÿÿ". Para mí, esta es una clave de 192 bits ... pero ¿quién sabe si los 24 bytes corresponden a la clave? ¿Alguna idea?

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

Fragmentos de código
Para ahorrar espacio en este hilo, puse este script en mi buzón para descargar. Lee a través del campo, extrae información básica de los campos de vértices y facetas, e imprime un montón de cosas. Puede anular el comentario del final para que guarde un bloque de datos en un archivo separado para un análisis más fácil.
basic_mesh_read.py

Este es el código que utilicé para probar todas las variaciones "razonables" en la biblioteca base64 estándar. try_all_b64_tables.py

Answer 1

No estoy seguro de por qué cree que los resultados no son números de punto flotante. Los datos de vértices en los "datos descifrados" que proporcionó, contienen como primeros 4 bytes "f2 01 31 41". Dado un orden de bytes LSB, que corresponde al patrón de bits "413101f2", que es la representación IEEE 754 del valor flotante 11.062973. Todos los valores de 4 bytes en ese archivo están en el mismo rango, así que asumo que todos son valores flotantes.