2012-02-22 21 views
23

Aggiornamento La domanda originale non è più la domanda appropriata per questo problema, quindi ho intenzione di lasciare questo solo per dimostrare ciò che ho provato/imparato e per lo sfondo. È chiaro che questa non è solo una "variazione Base64" ed è un po 'più coinvolta.Codifica in virgola mobile Raw

programma in python 3.x principalmente per l'utilizzo con il programma open source Blender. Sono un programmatore principiante/dilettante ma capisco abbastanza bene i grandi concetti Ho letto questi articoli pertinenti alla mia domanda.

Problema: Ho un file binario che contiene i dati maglia 3D (gli elenchi dei carri e liste di numeri interi) corrispondente alle coordinate x, y, z per ogni vertice (float) e gli indici dei vertici che compongono le facce della mesh (interi). Il file è organizzato in una sorta di sentimento xml'ish ...

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

Ecco l'esempio dal campo "vertici"

<Vertices vertex_count="42816" base64_encoded_bytes="513792" check_value="4133547451">685506bytes of b64 encoded data 
</Vertices> 
  1. Ci sono 685506 byte di dati tra "vertici "e" /vertici "
  2. Tali byte costituiti solo da aa, AZ, 0-9, e +,/che è standard per base64
  3. Quando catturo quei byte, e uso standard base64decode in python, ottengo 513792 byte indietro
  4. Se vertex_count = "42816" può essere creduto, ci dovrebbero essere 42816 * 12 byte necessari per rappresentare x, y, z per ogni vertice. 42816 * 12 = 513792. eccellente.
  5. Ora, se provo a decomprimere i miei byte decodificati come galleggianti a 32 bit, ottengo la spazzatura ... quindi qualcosa è ammis.

Sto pensando che ci sia un ulteriore passaggio crittografico da qualche parte. Forse c'è una tabella di traduzione, un codice di rotazione o una specie di codice di flusso? È strano che il numero di byte sia corretto ma che i risultati non sono quelli che dovrebbero limitare le possibilità. Qualche idea? Ecco due file di esempio con l'estensione del file modificata in * .mesh. Non voglio pubblicare pubblicamente questo formato di file, voglio solo scrivere un importatore per Blender in modo da poter usare i modelli.

Ecco due file di esempio. Ho estratto il binario non elaborato (non decodificato in b64) dai campi Vertices and Facets e fornito le informazioni del riquadro di delimitazione da un "Viewer" per questo tipo di file fornito dalla società.
Esempio File 1

  • unmodified file
  • vertices binary:
  • facets binary:
  • Decrypted Data: Questo è un .zip contenente il campo vertici decrittografato e il campo facce decrittografato (rispettivamente mesh2.vertices e mesh2.faces). Contiene anche un file mesh .stl che può essere visualizzato/aperto in molte applicazioni.

Esempio File 2

Note sul campo vertici

  • L'intestazione specifica il vertex_count
  • L'intestazione specifica base64_encoded_bytes che è il # di byte prima della codifica Base64 si svolge
  • L'intestazione specifica un "check_value" il cui significato è da determinare
  • I dati nel campo contengono solo i caratteri base64 standard
  • Dopo la decodifica base64 standard i dati di output hanno ... length = vertex_count * 12 = base64_encoded_b ytes. Occasionalmente ci sono 4 byte extra nell'output del b64? rapporto -il codificati/decodificati byte è 4/3 che è anche tipico base64

Note sul campo faccette

  • L'intestazione specifica un facet_count
  • I base64_encoded_bytes intestazione che è il numero di byte PRIMA che la codifica base64 abbia luogo

  • Il rapporto di base64_encoded_bytes/facet_count sembra variare abbastanza bit. Da 1.1 a circa 1.2. Ci aspetteremmo un rapporto di 12 se fossero codificati come interi 3x4byte corrispondenti agli indici dei vertici. Quindi, o questo campo è compresesed o il modello viene salvato con triangle strips, o entrambi: -/

Più snooping
Ho aperto il viewer.exe (in un editor esadecimale), che è previsto dalla società per visualizzare questi file (anche dove ho ottenuto le informazioni del riquadro di delimitazione). Ecco alcuni frammenti che ho trovato interessanti e potrebbero favorire la ricerca.

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

In LoadXXXXXXInternalEncrypted e SaveXXXXXXInternalEncrypted ho bloccato il nome della società con XX. Sembra che abbiamo sicuramente qualche crittografia oltre una semplice variazione della tabella base64.

SaveEncryptedModelToStream ................. Auto ... PUX .... modello ... AC .... flusso ....

Questo per me sembra una definizione di funzione su come salvare un modello crittografato.

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

Ahhh ... ora che è interessante. Una chiave di crittografia predefinita. Si noti che ci sono 27 byte tra ciascuno di questi descrittori e terminano sempre con "ÿÿ". Ecco 24 byte escludendo "ÿÿ". Per me, questa è una chiave a 192 bit ... ma chissà se tutti i 24 di quei byte corrispondono alla chiave? qualche 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

Frammenti di codice
per risparmiare spazio in questa discussione, ho messo questo script in il mio drop-box per il download. Legge attraverso il campo, estrae le informazioni di base dai campi dei vertici e delle faccette e stampa un sacco di cose. Puoi annullare il commento alla fine per fare in modo che salvi un blocco dati in un file separato per un'analisi più semplice.

Questo è il codice che ho usato per provare tutte le variazioni "ragionevoli" sulla libreria standard di base64. try_all_b64_tables.py

+3

Sei sicuro che i valori codificati siano float a 32 bit? Se è così, sono rappresentati con [LSB] (http://en.wikipedia.org/wiki/Least_significant_bit) o ​​[MSB] (http://en.wikipedia.org/wiki/Most_significant_bit)? –

+0

Non ne sono completamente sicuro, ma sono abbastanza fiducioso dato il rapporto tra byte e vertici. Per quanto riguarda LSB o MSB, quelli sono nuovi termini per me, quindi sto indagando. Sembra che questo sia lo stesso di endianness ma l'articolo di Wiki dice che non lo è. Quindi, ho bisogno di capovolgerlo un po 'di più. Ho provato a disimballare sia little endian che big endian. – patmo141

+0

È lo stesso di endianess, quindi almeno questo è fuori dal tavolo –

risposta

1

Non sono sicuro del motivo per cui si pensa che i risultati non siano numeri in virgola mobile. I dati dei vertici nei "dati decrittografati" che hai dato, contengono come primi 4 byte "f2 01 31 41". Dato un ordine di byte LSB, corrisponde al modello di bit "413101f2", che è la rappresentazione IEEE 754 del valore float 11.062973. Tutti i valori di 4 byte in quel file si trovano nello stesso intervallo, quindi presumo che siano tutti valori float.

+0

Ciò è corretto, i "dati decrittografati" sono 4 byte float. Questi dati particolari sono stati decifrati da un'applicazione di terze parti. Quindi, i dati nel file originale vanno da float grezzi -> crittografati -> base64encoded. Il mio obiettivo è di andare al contrario. Crittografato -> float grezzi che al momento non sono stato in grado di fare. Quando ho scritto questa discussione per la prima volta, ho pensato che fosse una variazione Base64, ma ulteriori indagini hanno portato alla conclusione che è anche crittografato. Scuse per la confusione. – patmo141

+1

Forse i "dati crittografati" sono in realtà solo un flusso di float in _binary_? – jpaugh