Korg .SNGファイルを例として使用したバイナリ形式のリバースエンジニアリング

私たちは素晴らしい時間に住んでいます。 私たちの周りには、電話、コンピューター、スマートウォッチ、その他のガジェットなどの豊富なテクノロジーがあります。 毎日、メーカーはますます多くのデバイスを市場にリリースしています。 それらのほとんどは、短い明るい（またはそうではない）人生に向けられています。リリース時の強力なマーケティング会社、メーカーによる1〜2年の完全なサポート、そしてゆっくりとした忘却。 シンプルなデバイスは、公式サポート期間の終了後も何年も使用できます。 「スマート」デバイスでは、ますます複雑になります。 製造元のサーバー/サービスを切断した後でも、ガジェットが少なくとも機能し続けると便利です。 そして、OS、ドライバー、または他のソフトウェアの次の更新が互換性に勝るものがなければ幸運です。

残念ながら、悲観的なシナリオに従ってイベントはますます発展しています。 また、購入から5〜10年後、技術的にサウンドデバイスが手に入りますが、ソフトウェアサポートがないため使用できません。 もちろん、壊れたガジェットは不快です。 しかし、何とでも互換性のない形式のユーザーデータがある場合は、はるかに不快です。 デバイスの機能が停止した場合、このデータは失われたとみなすことができます。 私の場合、最悪の事態はまだ発生していませんが、警鐘が鳴っています。

そのため、非常に高品質の音楽機器を製造する悪名高い会社コルグがあります。 2010年、趣味で音楽を練習するためにこの会社からシンセサイザーを購入しました。 コルグマイクロステーションはかなり高度なモデルです。 とりわけ、トラックを記録するためのシーケンサーが搭載されており、独自のSNG形式でデータをメモリカードに書き込むことができます。 共通のMIDI形式にエクスポートすることは可能ですが、ほとんどすべてのメタデータが失われます：重ねられたエフェクトとフィルターに関する情報、仮想楽器のさまざまな設定など。 私個人の主な問題は、音楽のアイデアを録音する移行のスピードです。 ミューズは気まぐれな創造物であり、ほとんどの場合、単純なものを即興で演奏したりプレイしたりするだけで興味深いアイデアに出会います。 メニューを歩き回らずに録音ボタンを速く押すほど、将来的に本格的な作品の一部になる可能性のある興味深い断片を繰り返し録音することができます。 もちろん、このアプローチは不完全ですが、趣味について話しているところです。 何らかの方法で、ほぼ10年間、私は約1000の音楽スケッチとSNG形式のスケッチを蓄積してきました。

ベルはシンセサイザーの一連のグリッチの形で鳴り、デバイスを点滅させる必要がありました。 そして、蓄積したすべてのデータをMidi形式に変換することを考えました。これにより、データの保存、整理、編集がはるかに簡単になります。 Googleでのコンバーターの検索では何も得られませんでした。 あらゆる種類のフォーラムで多くのリクエストがあり、その歴史は20年以上続いています。 私が見つけたのは、他の誰かの古いWindowsユーティリティで、私のファイルと自然に互換性がありませんでした。

そして、私はこのSNG形式が何であるかを見てみることにしましたか？ たぶんその中のどこかに落ち着いて、簡単に引き出して保存できる通常のMIDIデータがあるのでしょうか？

「額に」問題を解決する試み

そのため、シンセサイザーの指示から、SNG形式はいわゆる「曲」が格納されているコンテナーであることがわかります。 各曲には、音楽データ、およびサウンドとエフェクトの設定を含む16のシーケンサートラックが含まれています。 シンセサイザーメニューからMidi形式にエクスポートすると、各「曲」は個別の.MIDファイルにエクスポートされ、サウンドとエフェクトのすべての設定が失われます。 なぜなら 私はアイデアを最もシンプルな形で再生しますが、効果はありません。問題は正確に多数のSNGファイルと手動変換プロセスの不便さです。 このプロセスを加速または自動化できるかどうかを見てみましょう。

まず、MIDIデータとは何かを思い出しましょう。 簡単に言えば、これは音楽イベントのストリームです。キーを押して放し、サステインペダルを押して放して、テンポ、パッチ（仮想楽器）、その他のパラメーターを変更します。 各イベントには、ノートの強さやピッチなど、前のイベントとデータの瞬間からの時間差が含まれます。 MIDIファイル形式は非常に単純です。ヘッダーとデータ自体に加えて、実際には何もありません。

ピンクはノートオンイベントです。 淡い黄色は時間のデルタです。 青-ノートオフイベント。

SNGファイルでmidiデータを探してみましょう。 これを行うには、シンセサイザーでいくつかのノートのシーケンスを作成し、両方の形式にエクスポートします。 なぜなら 音楽データがバイナリファイルのどこにあるのか正確にわからない場合は、異なる音符のシーケンスを使用してプロセスを繰り返します。

以下では、HexエディターSynalyze Itを使用します。 将来のその機能は私たちにとって非常に役立つでしょう。 それまでは、バイナリ比較関数を使用してください。

実際、「歌」の名前だけが一致しました。 音符のシーケンスが異なる2つのSNGファイルを比較すると、音楽データが正確に保存されている場所を大まかに推測できますが、現時点ではこれは役に立ちません。データ形式は異なります。 ファイル自体はMidiファイルよりも10倍大きく、多くの追加情報が含まれているようです。 KORGシグネチャは、最初の4バイトと、「ソング」の名前やトラックに割り当てられたパッチ（トーン）の名前など、他の行に表示されます。

データブロックの構造の解析

幸いなことに、バイナリデータの構造の分析と理解を比較的容易にするツールがなかった場合、これを完了することができました。 同じプログラムSynalaze It！を使用すると、バイナリファイルを分析するための「文法」を作成して適用することができます。

文法は、人間が読める形式でバイナリデータを表すことができる階層的な記述構造です。 このプログラムでは、いくつかの形式の文法をダウンロードできます。 たとえば、同じMIDIの場合：

SNG形式の場合、既製の文法は想定されていませんでした。 さて、自分でファイルから何を抽出できるか見てみましょう。

見出しから始めましょう。 通常、この部分には、ファイル署名、バージョン情報、サイズ、データブロックのオフセットが含まれます。 いくつかの異なるSNGファイルを比較した後、不変の部分を見つけ、変化する部分にさらに注意を払います

文法エディターでタイトル構造を作成します。 最初の4バイトは、明らかにファイルの署名です。 次の4バイトがバージョン管理されているとします。 次の数十バイトは変更されず、興味深いものも含まれていません-それらに適切なサイズのbinaryDataを作成します。 そして、楽しみが始まります。 オフセット0x13および0x1bのバイトの動作には、いくつかのパターンがあります。 2番目は、ファイル内の「曲」の数に対応しているようです。 そして、最初のものはヘッダーのデータ量とともに大きくなります-これはサイズのようです、カウントダウンのみがファイルの先頭からではなく、次のバイト0x14から来ます。 この段階では、数値データのタイプについてのみ推測できます。 サイズがUInt32型、つまり 4バイトかかります。 それらを構造に追加します。 これで、ヘッダー構造のサイズ（サイズ+ 20）を設定できます。


次に来るものを見てみましょう。 よく見ると、SNG1、SDK1、SGS1など、3文字の略語がファイル全体に散らばっていることがわかります。 これらの文字はすべてのSNGファイルに含まれているため、特定のブロックの署名であると想定できます。 さらに、これらの署名の1つ前にタイトルが非常に正常に終了しました。 異なるサイズのファイルで次の4バイトの動作を比較します。 データ量が増えると、値が増加することがわかります。

さらにいくつかの実験、分析、計算、および次の図が現れ始めます。




したがって、ファイルはかなり単純なブロックの階層で構成されています。 複数の子ブロックを含むことができる親ブロックがあります。 他のブロックを含まないリーフブロックがあります（バイナリツリーの用語では）。

その後、魔法が始まります。 わずかな文法構造で、ブロックファイル構造を完全に解析できます。

それでは、次のフィールドを持つDataChunkテンプレート構造を作成しましょう（サイズは角括弧で示されています）：

id：文字列[4]
サイズ：Int [4]
階層：Int [4]
データ：構造

DataChunkを継承するparentChunk構造を作成します。 階層プロパティで、固定値0x400を指定します-これは親ブロックのサインです。 必ず[一致する]チェックボックスをオンにしてください。

同様に、childChunkを作成します。 この場合の階層には、0x240100と0x100の2つの値があります。

親parentChunkのデータ構造にparentChunkおよびchildChunk構造への参照を追加します-この方法で再帰を作成します。

最後に、メインノードのparentChunk構造への参照を追加します。

parentChunkのデータ構造内の要素の順序は可変でなければなりません。また、この構造の子の最小数と最大数を設定する必要があります：それぞれ0とUnlimited。

変更を適用し、出来上がり-ファイルはメインブロックに適切に解析されます

データ自体についてはまだ何も知りませんが、ファイル内を簡単に移動し、必要な情報を見つけることに集中できます。

目次を含むブロックの解析

トレーニングのために、SDK1などの単純なブロックを解析してみましょう。 どうやら、目次のようなもの-曲のリストとおそらくいくつかのオフセット/サイズが含まれています。

childChunkを継承するsdk1Chunk構造を作成します。 [固定値]フィールドにブロックの署名を示すIDフィールドを編集します。 [一致する必要があります]チェックボックスを忘れないでください。 ブロックデータでは、「歌」の名前でありながら未知のデータである、かなり明白な繰り返しパターンを観察できます。 繰り返しフラグメントのサイズは64バイトであることに注意してください。 また、ファイルバージョンを異なる数の「曲」と比較することにより、番号が最初の4バイトに格納されていることを確認できます。 簡単な計算といくつかの仮定を行うことで、文法の次のバージョンの構造を取得します。

ここでは、64バイトのsongInfo子構造を作成し、numSongs回繰り返す機能を示しました。 文法を適用した結果は次のとおりです。

さらなるファイル分析は技術的な問題のままです。 「歌」の一般設定とシンセサイザーの個々のトラックのパラメーターを変更しました。 さまざまな変更を加えたファイルバージョンを比較することで、文法を改善および改良できます。 十分な数のそのような反復の後、ファイル内に認識されないデータの断片はほとんどありません。 プロセスに少し夢中になり、ファイルのほとんどすべてのセクションを整理しましたが、これは元のタスクには必要ありませんでした。


このプロセスの詳細を見逃します-将来は、音楽データの分析に直接焦点を当てます。

しかし、それについては次のパートで詳しく説明します。 そこで、データ変換の興味深いタスクに遭遇し（インタビューに非常に適しています）、小さなスクリプトでそれを解決して、かなり珍しいテスト変換結果を聞きます。

予備結果

バイナリファイルのリバースエンジニアリングが必要になる場合があります。 たとえば、デバイスのファームウェアを分析したり、まれなデータ形式から変換したり、デジタル脅威を分析したり、ゲームのセーブをわずかに変更することもできます。 最新のツールを使用すると、これらの問題を迅速かつ効率的に解決できます。 約10年前、私はラップトップのファームウェアを調査していたため、このプロセスには数週間かかることがありました。 次に、データブロックを分析して構造をレイアウトするスクリプトを手動で記述する必要がありました。 新しい部分的に自動化されたアプローチにより、わずか数日でほぼ完全なファイルグラマーを作成しました。

文字列を検索することにより、バイナリファイルの分析を開始できます-最初の手がかりを与え、分析プロセスを高速化できます。 多くの場合、バイナリファイルは、階層構造または線形構造に編成されたデータブロックで構成されます。 この構造を扱うと、さらなる分析がはるかに簡単になります。 ファイルヘッダーは、データブロックのオフセット/サイズに関するヒントを提供できます。 最初の段階では、明らかな構造とブロックの説明に焦点を当てることが理にかなっています。 分析タスクは、さまざまな設定、パラメーター、データを使用してファイルの新しいバージョンを作成できるため、大幅に簡素化されます。 バイナリ表現（エンディアン）の未知のデータ型とバイト順序に関連する多くの困難があります。 次の部分でこれらの質問に触れます。

推奨読書

アンドレアスペナック。 バイナリファイル形式分析にアプローチする方法