Codexで解読：壊れたCronosデータベースの復元
Reverse engineering the storage format for an undocumented database
CronosProデータベースファイル（CroBank.dat、CroIndex.dat、CroStru.dat）は、既存ツールで解析できないため壊れていると思われていました。この記事では、Codexを使用してファイル構造を分析し、オープンソースのCronodumpを改良して、KODエンコードされたスキーマを統計的手法とハンガリアンアルゴリズムで復元したプロセスを解説します。圧縮と保護の違い、KODテーブルの仕組み、構造的検証の重要性など、Cronos形式の逆解析の詳細を初心者にもわかりやすく説明します。
KODテーブルは順列でなければならないため、各バイトに独立して最高スコアを選ぶことはできません。代わりに、一意性を強制しながら最適なマッピングのセットを選ぶ必要があり、これは古典的な割り当て問題であり、SciPyのハンガリアンアルゴリズムで解決しました。
- whsoul
通りすがりに、こんな経験についてコメントを残しておきます。
Kafka検索ツールを開発していたとき、Avro + schemaRegistry、protobuf、ConnectJson（スキーマ付きJSON）など、多くの種類のデコード形式をサポートする必要がありました。
先頭バイトを見てデシリアライザの種類を推奨するようにしました。
ユーザーが最終的な選択をした後、最初のデータデシリアライズ中にエラーが発生しても問題ありません。
しかし、多くの場合、エラーは発生せず、もっともらしく間違った解析データで素通りしてしまいます。
そこで私の解決策は、事前にデコードしたサンプルを10件ユーザーに表示し、目視でデシリアライザを1つ選んでもらうことでした。
ConnectJsonは、すべてのメッセージにデータとスキーマが埋め込まれているため信頼性があります（ただし大きい）。
私の場合、スキーマレジストリを使用していて、サーバー1にはスキーマ番号10があり、サーバー2にもスキーマ番号10がありますが、それは異なります。
誤ってサーバー2を選択してしまい、データ解析は進みましたが、もっともらしく間違ったデータになりました。
何かが間違っていることを見つけて修正するのに長い時間がかかりました。
- elias1233
AIによって増幅されたこのリバースエンジニアリングの新しいトレンドが大好きです。私自身もこのようなプロジェクトを数多く行ってきました。
- gotosun1
KODキーはどこから来るのですか？CronosProをリバースエンジニアリングすることで復元できますか？