CoreModはclassファイルに記述されているASMを直接いじることでかなり自由なModdingを行うことが出来るシステムである。
基本的な解説は、外部サイトに任せる。
build.gradleの設定で自動的にMANIFEST.MFを書き換えできる。
一般的にはクラスロード中に同じクラスをロードしようとすると発生する。
例えばクラスTのコンストラクタ呼び出しでこの例外が発生しているとき、Tを読み込むためにTのCoremodを適用中である。Tを読み込むためのCoremodからTを読み込もうとしたら循環して例外となる。
エントリーポイントとなっている、IFMLLoadingPluginを実装しているクラスに次のアノテーションを付与すれば、そのパッケージ以下はCoremodの適用外となる。
あるクラスAのソースコードA.javaがあり、これをコンパイルしてA.classを得る。そして、あるクラスBを実行すると出力ファイルとしてA.classと同一のものが得られるとき、このクラスBをAのバイトコードダンパーと言うことにする。
バイトコードダンパーは、EclipseにCoreASM Eclipse Pluginを入れ、バイトコードなるビューを表示することで得られる。
以下にバイトコードのビューの使い方を載せる。
現在のフィールド/メソッドのみのバイトコードを表示は、OFFにするとそのまんまバイトコードダンパーのソースコードになっている。これは実行するとバイトコードが得られるメソッドになっているので、mainやFileOutputStreamで実行と保存の機能を追加してやればclassファイルが得られる。
FMLDeobfuscatingRemapperを見るとクラス・メソッド・フィールドのマップが乗っており、クラス用のもの見るとmapとunmapがあって、このクラスを使えばメソッドとフィールドも難読化出来そうである。
・・・と思いきやunmapFieldNameやunmapMethodNameはない。
そしたら難読化設定ファイルから勝手に読み取ってやろうと思うと、GenDiffSet#mainを見るとPath to FML's deobfusication_data.lzmaがargs[2]で与えられており、この変数が門外不出になっている。
仕方がないのでFMLDeobfuscatingRemapperのフィールドのアクセサをCoremodで挿入する究極のゴリ押しで何とかする。