使用ライブラリを簡単に覗く方法~Windows編~
こちらは Unityゲーム開発者ギルド Advent Calendar 2022 14日目の記事です。
概要
実はUnity製のプロダクトでは逆アセンブルや逆コンパイルなどのリバースエンジニアリングを用いずに内部の構造を覗き見れてしまいます。 今回は一番簡単なWindowsでの確認方法を紹介します。 使用しているOSSを参考にしたい場合や、プロジェクトの構成を参考にしたい場合に有用ですが、開発者にとっては簡単に覗き見られるリスクが存在します。 適当な名前でプロジェクトやアセットを作成していたり、不要なファイルを追加しているだけならかわいいものですが、 違法な仮アセットをそのまま残していたり、OSSやライブラリのライセンス表記をせずに使用している場合はバレやすく問題となります。
Unityビルドの構造
Windowsでビルドすると以下のようなフォルダ構成で出力されます。主なリソースは_Dataのフォルダ内に出力されます。
_Dataは以下のようになっています。
この時点で分かることもあります。例えばLevel〇ファイルはシーンファイルなので画面数に比べてファイルが少ないならシーン切り替えではなくプレハブを切り替える運用であるとか、resourcesはResourcesフォルダに依存しているのでサイズが大きいとResouresフォルダを使った運用をしているとかが推測できます。
使用ライブラリの確認
ScriptingAssemblies.json
_DataにあるScriptingAssemblies.jsonはプロジェクトに含まれるAssembly Definition FilesがDLLとして確認できます。最近のOSSやプロジェクトではAssembly Definitionを使用しているものも多いため、ScriptingAssemblies.jsonを見ることで使用しているライブラリ情報が分かってしまうのです。 例えば以下は実際のScriptingAssemblies.jsonの一部ですが、UnityEngineの機能だけでなく、自分で定義したもの(Sample.dll)やUniTaskなどのOSSまで確認できます。
{ "names": [ "UnityEngine.dll", "UnityEngine.AIModule.dll", "UnityEngine.ARModule.dll", "UnityEngine.AccessibilityModule.dll", ...... "Sample.dll", ※自分のプロジェクトのDLL ...... "UniTask.dll", ......
非公開情報や非公開のコードネームで名前付けしてしまうと、その情報が漏れてしまう可能性がありますので気をつけましょう。 (非公開になっているはずの協力会社A社のライブラリをACompany.Libraryなどとして入れてしまうとバレてしまう)
Addressables
Addressables(Addressable Asset System)を使用してLocal向けにビルドを行うとStreamingAssets内にaaというフォルダが出力されます。その中のcatalog.jsonにはAddressablesを使用して出力したアセット情報が入っています。 以下はTextMeshProといくつかの画像・プレハブを追加したプロジェクトのcatalog.jsonの一部ですが、このように含まれているアセットがパス名付きで分かってしまいます。
"m_InternalIds": [ "{UnityEngine.AddressableAssets.Addressables.RuntimePath}\\StandaloneWindows64\\sampleassets_assets_all_3ee2f45a2df087cb8a1cc977ff507570.bundle", "Assets/SampleAssets/Image1.png", ※オリジナル画像1 "Assets/SampleAssets/Image2.png", ※オリジナル画像2 "Assets/SampleAssets/SamplePrefab.prefab", ※オリジナルプレハブ "Assets/SampleAssets/SecretImge.png", ※オリジナル画像、本当は隠しておきたいアセット "DebugUICanvas", "DebugUIPersistentCanvas", "Fonts & Materials/LiberationSans SDF", "Fonts & Materials/LiberationSans SDF - Drop Shadow", "Fonts & Materials/LiberationSans SDF - Fallback", "Fonts & Materials/LiberationSans SDF - Outline", "LineBreaking Following Characters", "LineBreaking Leading Characters", "Scenes/SampleScene", ※シーンファイル "Sprite Assets/EmojiOne", "Style Sheets/Default Style Sheet", "TMP Settings" ],
配布ビルドには含めず追加のリソースとして管理することでStreamingAssetsから除くことはできますが、結局ダウンロードフォルダにも同じ状況で保存されてしまうため隠すことはできません。 ファイル名の情報だけではあり、大きな問題にはなりにくいものの、問題のある仮ファイルを残したままにするのは避けるべきです。(ネットミームの画像を仮素材として使っていた場合など、企業としてはふさわしくないこともある)
また、アセット情報はm_resourceTypesにも追加されます。以下のようにアセットにDOTweenを使っていることが分かります。
{ "m_AssemblyName": "DOTween, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null", "m_ClassName": "DG.Tweening.Core.DOTweenSettings" },
今回はテキストファイルのような簡単に見られるファイルからのアプローチでしたが、もちろんリバースエンジニアリングをするとより細かい情報があらわになってしまいます。対策も可能ですが、開発者の心構えとしては、プロジェクトが外から見られても恥ずかしくない状態にしておきたいですね。
余談
これらの情報を調べてみたきっかけは、有名企業がリリースしたWindows向けアプリなのにも関わらずOSS情報が一切載っていないことへの疑いでした。調べてみると案の定有名なOSSやライブラリ・アセットが数多く使われているようでした。UniTaskやVContainerといったよく使われるOSSだけでなく、UnityScreenNavigatorやNativeWebSocketといったプロダクトでの利用はそこまで聞いたことがなかったOSSまで使われていました。 更にはアセットストアで販売しているアセット群の名前もあり、プロダクトでの実用事例として知ることもできました。アプリの出来はよく、使用ライブラリもまともでアピールできるのにOSSのライセンス表記がない状況で、同じ開発者として寂しく思っています。
正直なところOSSの表記をわざわざ実装したり管理したりには面倒なところがあります。一方で開発者として恩恵を受けている感謝の気持ちはせめてライセンス表記の形で残したいですね。
※たまたま同じ名前で開発した自前ライブラリだったり、裏でOSSの管理者と密約を交わしている可能性もあるため、この情報だけで違反だなんだと決めつけることはできません。