リバース エンジニアが OpenGL アプリケーションにグラフィック デバッガーをアタッチして、シェーダー ソース コードを抽出するのは簡単です。一方、Vulkan はプレーンテキスト シェーダーをグラフィックス API に渡すのではなく、SPIR-V バイトコードを使用していると理解しています。
SPIR-V バイトコードはシェーダー ソースを難読化しますか? それとも逆コンパイルするのはかなり簡単ですか?
リバース エンジニアが OpenGL アプリケーションにグラフィック デバッガーをアタッチして、シェーダー ソース コードを抽出するのは簡単です。一方、Vulkan はプレーンテキスト シェーダーをグラフィックス API に渡すのではなく、SPIR-V バイトコードを使用していると理解しています。
SPIR-V バイトコードはシェーダー ソースを難読化しますか? それとも逆コンパイルするのはかなり簡単ですか?
すべての SPIR-V オペコードの動作を明確に詳細に説明する完全な仕様があります。それはちょっと難読化の反対です。しかし、それだけではありません。
SPIR-V は、「アセンブリ」であるにもかかわらず、ソース プログラムに関する豊富な情報を保持します。これには、構造体の定義、パラメーターと戻り値の型を含む関数の定義、ループと条件付き構造などが含まれます。SPIR-V 用の逆コンパイラーを作成することはまったく難しくありません。
SPIR-V には、オプションで、さまざまな SPIR-V 定義に注釈を付けるテキストのフラグメントを含めることもできます。これは SPIR-V にコンパイルされた環境の関数ですが、出力 SPIR-V には変数名、構造体名などを含めることができます。必要に応じて、これらの OpName 装飾はすべて簡単にカリングできます。
しかし、名前がなくても、重要な構造情報はすべてそこにあります。そのため、未加工の GLSL と比較して SPIR-V から得られるセキュリティはごくわずかです。
実際の難読化は行いません。実際にできることは、変数名を削除することだけです。
アプリケーションが実際の計算を複雑にしたくない場合は、それで十分です。
vulkan は構造化された制御フローを必要とするため、制御フローでは多くのことを行うことができません。各条件分岐にはマージ ブロックが必要であり、すべてのループには厳密な構造があります。
SPIR オペコードは、Java のバイトコードのように動作します。
オペコードからプレーン コードへの可逆性に対する簡単な回避策はありません。Java フィールドで使用されるいくつかのソリューションは次のとおりです。