Codificación de punto flotante crudo

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 intentado/aprendido y para el fondo. Está claro que esto no es solo una "variación Base64" y es un poco más complicado.

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

• Wikipedia on Base64
• Base64 can get you pwned (pdf)
• stackoverflow discussion
• Algunos otros

Problema: Tengo un archivo binario que contiene los datos de malla 3D (listas de flotadores y listas de números enteros) correspondiente a las coordenadas x, y, z para cada vértice (flotantes) y los índices de los vértices que componen las caras de la malla (enteros). El archivo está organizado en una especie 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 "vértices "y" /vértices "
2. Esos bytes solamente constan de aa, AZ, 0-9 y +, /, que es estándar para base64
3. Cuando tomo esos bytes, y uso el estándar base64decode 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 y desempaquetar mis bytes decodificados como flotadores de 32 bits, me sale basura ... así que algo es ammis.

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

Aquí hay dos archivos de ejemplo. Extraje el binario sin procesar (no decodificado con b64) de los campos Vértices y Facetas, y proporcioné la información del cuadro delimitador de un "Visualizador" para este tipo de archivo proporcionado por la empresa.
Ejemplo File 1

• unmodified file
• vertices binary:
• facets binary:
• Decrypted Data: Este es un .zip que contiene el campo vértices descifrado y el campo caras descifrado (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 de 2

• unmodified file
• vertices binary:
• facets binary:
• cuadro delimitador: Min [-4,6, -40,3, -7,3] Max [7,5, -23.1, 2.6]

Notas sobre el campo vértices

• La cabecera especifica el vertex_count
• La cabecera especifica base64_encoded_bytes que es el # de bytes ANTES codificación base64 tiene lugar
• La cabecera especifica un "check_value" cuyo significado es aún por determinar
• los datos en el campo sólo contiene los caracteres base64 estándar
• Después de base64 estándar decodificar los datos de salida tiene ... longitud = vertex_count * 12 = base64_encoded_b ytes. Ocasionalmente hay 4 bytes adicionales en la salida b64? relación -el de bytes decodificados codificados/es 4/3 que también es base64 típico

Notas sobre el campo Facetas

• La cabecera especifica un facet_count

• Los base64_encoded_bytes cabecera 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 bastante bit. De 1.1 a alrededor de 1.2. Esperamos una relación de 12 si se codificaron como enteros de 3x4byte correspondientes a los índices de vértice. Así que, o este campo se compresesed o el modelo se guarda con triangle strips, o ambos: -/

Más snooping
Abrí el viewer.exe (en un editor hexadecimal), que se proporciona por la empresa para ver estos archivos (también donde obtuve la información del recuadro delimitador). Aquí hay algunos fragmentos que me parecieron interesantes y que podrían facilitar la búsqueda.

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

En LoadXXXXXXInternalEncrypted y SaveXXXXXXInternalEncrypted he bloqueado a cabo la nombre de la compañía con XX. Parece que definitivamente tenemos algo de encriptación más allá de una simple variación de tabla base64.

SaveEncryptedModelToStream ................. auto ... Pux .... ... Modelo AC Corriente .... ....

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

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

Ahhh ... ahora que es interesante. Una clave de cifrado predeterminada. Tenga en cuenta que hay 27 bytes entre cada uno de esos descriptores y que siempre terminan con "ÿÿ." Aquí hay 24 bytes, excluyendo "ÿÿ." Para mí, esta es una clave de 192 bits ... ¿pero quién sabe si los 24 de esos 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 80 01 00 00 00

fragmentos de código
para ahorrar espacio en este hilo, me pusieron este script en mi drop-box para descargar. Se 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 des-comentar el 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é piensas que los resultados no son números flotantes. 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, eso 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 ese mismo rango, así que supongo que todos son valores flotantes.