更新 元の質問は、この問題に対する適切な質問ではなくなったため、これをそのままにして、私が試した/学んだことと背景を示します。これが単なる「Base64 バリエーション」ではなく、もう少し複雑であることは明らかです。
背景: 私は主にオープン ソース プログラムの Blender で使用するために Python 3.x でプログラミングしています。私は初心者/アマチュアレベルのプログラマーですが、大きな概念をかなりよく理解しています。質問に関連するこれらの記事を読みました。
問題: 各頂点 (floats) の x、y、z 座標に対応する 3D メッシュ データ (float のリストと整数のリスト) と、メッシュの面を構成する頂点のインデックス (整数)。ファイルはxmlのような感じで整理されています...
<SomeFieldLabel and header like info>**thensomedatabetween**</SomeFieldLabel>
「頂点」フィールドの例を次に示します。
<Vertices vertex_count="42816" base64_encoded_bytes="513792" check_value="4133547451">685506bytes of b64 encoded data
</Vertices>
- " Vertices " と " /Vertices "の間には 685506 バイトのデータがあります
- これらのバイトは、base64 の標準である aa、AZ、0-9、および +/ のみで構成されます
- それらのバイトを取得し、Python で標準の base64decode を使用すると、513792 バイトが返されます
- vertex_count="42816" が信じられる場合、各頂点の x、y、z を表すために必要な 42816*12 バイトがあるはずです。42816*12 = 513792. すばらしい。
- ここで、デコードしたバイトを 32 ビット浮動小数点数としてアンパックしようとすると、ゴミが発生します...何かがおかしいのです。
どこかに追加の暗号化ステップがあると思います。おそらく、変換テーブル、ローテーション暗号、またはある種のストリーム暗号がありますか? バイト数は正しいのに結果がそうではないのは奇妙です。何か案は？ファイル拡張子が *.mesh に変更された 2 つのサンプル ファイルを次に示します。このファイル形式を公開したくはありません。モデルを使用できるように、Blender のインポーターを書きたいだけです。
以下に 2 つのサンプル ファイルを示します。Vertices フィールドと Facets フィールドから生のバイナリ (b64 デコードではない) を抽出し、会社が提供するこのタイプのファイルの「ビューアー」からバウンディング ボックス情報を提供しました。
サンプルファイル 1
- 変更されていないファイル
- 頂点バイナリ:
- ファセット バイナリ:
- 復号化されたデータ: これは、復号化された頂点フィールドと復号化された面フィールド (それぞれ mesh2.vertices と mesh2.faces) を含む .zip です。また、多くのアプリケーションで表示/開くことができる .stl メッシュ ファイルも含まれています。
サンプルファイル 2
- 変更されていないファイル
- 頂点バイナリ:
- ファセット バイナリ:
- 境界ボックス: 最小[-4.6, -40.3, -7.3] 最大[7.5, -23.1, 2.6]
頂点フィールドに関する注意事項
- ヘッダーは vertex_count を指定します
- ヘッダーは、base64 エンコードが行われる前のバイト数である base64_encoded_bytes を指定します
- ヘッダーは、重要性がまだ決定されていない「check_value」を指定します
- フィールドのデータには、標準の base64 文字のみが含まれています
- 標準の base64 デコード後、出力データは... length = vertex_count*12 = base64_encoded_bytes になります。b64 出力に 4 バイト余分にあることがありますか? -エンコード/デコードされたバイトの比率は4/3で、これも典型的なbase64です
ファセット フィールドに関する注意事項
- ヘッダーは facet_count を指定します
base64 エンコードが行われる前のバイト数であるヘッダー base64_encoded_bytes
base64_encoded_bytes/facet_count の比率はかなり異なるようです。1.1から約1.2まで。頂点インデックスに対応する 3x4 バイトの整数としてエンコードされている場合、12 の比率が期待されます。したがって、このフィールドが圧縮されるか、モデルが 三角形のストリップで保存されるか、またはその両方が行われます :-/
詳細スヌーピング
会社から提供されているこれらのファイルを表示するための viewer.exe を (16 進エディタで) 開きました (ここでもバウンディング ボックスの情報を取得しました)。以下は、私が興味深く、さらに検索を進めることができるいくつかのスニペットです。
f_LicenseClient...Ì.@...m_wApplicationID.....@...f_bSiteEncryptionActive.....@...f_bSaveXXXXXXInternalEncrypted.....@.... ..f_bLoadXXXXXXInternalEncrypted...¼!@......f_strSiteKey....†......
LoadXXXXXXInternalEncrypted と SaveXXXXXXInternalEncrypted で、会社名を XX でブロックしました。単純なbase64テーブルのバリエーションを超えた暗号化が確実に行われているようです.
SaveEncryptedModelToStream.................Self...pUx....モデル...^×C....ストリーム....
これは、暗号化されたモデルを保存する方法に関する関数定義のように見えます。
DefaultEncryptionMethod¼!@.......ÿ.......€...€ÿÿ.DefaultEncryptionKey€–†....ÿ...ÿ.......€... .ÿÿ.DefaultIncludeModelData –†....ÿ...ÿ.......€...€ÿÿ.DefaultVersion.@
ああ…今それは面白いです。デフォルトの暗号化キー。これらの各記述子の間には 27 バイトがあり、常に「ÿÿ」で終わることに注意してください。「ÿÿ」を除く24バイトです。私には、これは 192 ビットのキーです...しかし、これらの 24 バイトすべてがキーに対応するかどうかは誰にもわかりません。何かご意見は？
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