あけましておめでとうございます（2月）。
前回「次回は手持ちのM4 Pro Mac miniでアレコレ検証した結果を元に、今のHackintoshを置き換えうるMacの構成・拡張」を〜、などと抜かして何も書かないまま2025年が終わってました。すみません。途中まで書いてたんですけどその間に確立した新ソリューションで書いた分がポシャったりしているうちに放置してしまい・・・ただ、何から順に投稿するか意識しだす更に何も書かなくなってしまうのでもうしばらく寝かせます。
さて、普段から誰のためになるか意識して書いてるわけでも無いですが、今回はいつにも増してだからなんやねんという日記です。
前半はTahoe HackintoshでOCLP Root Patchを適用する話なので少しは役に立つかもしれません。後半はこれを調べる中で整理した、誰も興味の無さそうなRoot Patch+AMFIPass動作機序の話の続きです。
Tahoe Hackintosh + OCLP
結論から言うと、OCLP-Modを使えばVenturaくらいまでvanillaで動いていたHackintoshであればTahoeでもちゃんとWiFi/オーディオが動くようになります。
OCLPのTahoe対応はthe upcoming winterに出せたらとアナウンスされていましたが、2026年2月時点でリリースされていません。
ただ一定程度開発は進んでいて、Sonoma以降必要になったWiFiパッチやTahoeから無くなってしまったオーディオ（AppleHDA.kext）を復活させるパッチは実装されています。つまり、これらのパッチしか必要としない比較的最近のMacとそれに準ずる構成のHackintoshであれば既に動く状態にはなっています。
ただ、これらのパッチが組み込まれたバージョンは公式にリリースされていないので、現時点では開発チーム外により野良ビルドされたOCLPを使う必要があります。
余談：比較的最近(2017~)のMacでTahoeを実用的に動かすニーズは、スペック的に無理のある古いMac(~2015あたり)でホビー的に動かすニーズより高いと思いますし、野良ビルドが氾濫するよりも公式が小出しにリリースして徐々に対応機種を広げていった方が良いと個人的には思うんですけどね。OCLP開発者ではないので内部でどういう議論がされているかはわかりませんが・・・
自分が把握している野良ビルドは以下の2つ。これらから更にforkされたものは追ってません。
が、後者は12月末の更新でオーディオパッチが適用できなくなりました。直せはしますしどうすれば動くかは後述しますが、そこまでして後者を使いたい人はあまりいないと思うので基本的に前者を使うことになると思います。
前者のOCLP-ModはIntel WiFi対応していたり中国向けにgithubが使えない環境で動くようになっていたりする改造版OCLPです。UIも中国語化されていますが、ボタンの位置などは本家と変わらないのでまあなんとかなるでしょう。
Tahoe自体のインストールができていて、Sequoia以前でOCLP Root Patchが適用できるセットアップができていれば、あとはAMFIPass.kextがTahoeでも動作するよう -amfipassbeta ブート引数を追加するだけで、OCLP-Modを使用してTahoe向けのWiFiとオーディオのパッチを適用することができます。
実用的な話はここで終わり。
〜〜〜〜
とまあ一般的にはここまでで良いのですが、OCLP-Modは公式版に比べて手が入りすぎていてTahoeのためだけに導入したくないというのも個人的な感覚。特にオーディオパッチはSequoia 15.6のAppleHDA.kextを使用するOCLP-Mod独自のもので、26.0 Beta 1のAppleHDA.kextを使う本家とは異なるパッチになっています（TahoeはBeta 1までAppleHDA.kextが残っていたのでそれを使っている）。使ってて違いはわからないけども。
一方後者のlzhoang2801版は公式の開発ブランチに最小限の変更を加えてWiFi/オーディオ/Metal(?)パッチ専用にしたもので、Root Patchの元になるバイナリ(PatcherSupportPkg)は公式リポジトリから持ってきているので、自分としてはできればこちらを使いたい。
で、なんで動かなくなったかという話なんですが。lzhoang2801版は元々OCLP-Modと同じようにPatcherSupportPkgも独自ビルド版を使っていたところ、こちらは公式版PatcherSupportPkgにWiFiパッチが組み込まれたのを機に公式版を持ってくるように変更されました。が、公式版PatcherSupportPkgにはまだオーディオパッチが組み込まれて無いんですよねｗ それで動かなくなったと。いや気づかないんかいって思うんですが。私が何か見落としてるんですかね。
というわけでオーディオパッチを組み込む方法を考えていきます。ほぼ個人的備忘録。
まずOCLPのRoot Patch用資材がどう構築されているかという話なんですが、
- Root Patch用バイナリ群はPatcherSupportPkgリポジトリに配置
- PatcherSupportPkgのリリースビルド時にバイナリがUniversal-Binaries.dmgに固められる
- OpenCore-Patcher.pkgのビルド時にUniversal-Binaries.dmgを取ってきて組み込む
- ここでバイナリにAMFIPass.kext向けの署名がされる
- Universal-Binaries.dmgはインストールされたOpenCore-Patcher.appの中に格納される
となっています。lzhoang2801版OCLPは公式版PatcherSupportPkg 1.9.6のUniversal-Binaries.dmgを使っていますが、1.9.6にはTahoe用のWiFiパッチに必要な「13.7.2-25」は含まれてますがオーディオパッチに必要な「26.0 Beta 1」が入っていません。というわけでこれを組み込めば良いわけです。
「26.0 Beta 1」はどこにあるんだというとcrystall1nedev/PatcherSupportPkgにあります。crystall1nedevはOCLPのコミッターなので、ここのバイナリは基本的に本家に入ってくるはず。ということでこれを使いたいですね（※というか、ここにあるAppleHDA.kextは後述のKDKに含まれるApple純正そのものなので明らかにクリーンです）。
しかしcrystall1nedev/PatcherSupportPkgは本家にPRを出すための開発リポジトリなのでUniversal-Binaries.dmgはビルドされていません。また、forkして自分でビルドしたとしてもここで解説した本家(dortania)の署名ができないので今度はWiFiパッチが壊れます（オーディオパッチには影響しないのですが、その理由は後述）。
さてどうしたものか。
1つはUniversal-Binaries.dmgをバラして「26.0 Beta 1」を組み込んで再圧縮することです。まあ正直これで良いんじゃないかなと思います。ちなみにUniversal-Binaries.dmgにはパスワードがかかっていますがスキャン防止程度の意図なのか「password」なので問題なくバラせます。
ただ、どうしようかなと実装を眺めていたら、OCLP開発者向けにUniversal-Binaries.dmgを触らずRoot Patch資材に任意のファイルを追加する機構を知ったので、今回はそれを試してみることにしました。
Universal-Binaries.dmgをマウントするためのロジックを見ると、Universal-Binaries.dmgとは別に「DortaniaInternalResources.dmg」が存在すればそれをマウントし、Universal-Binaries.dmgをマウントした領域にオーバーレイする処理もあることがわかります。どうやらこのDortaniaInternalResources.dmgに「26.0 Beta 1」を固めて配置すれば良さそうです。
まずはこのDortaniaInternalResources.dmgを作ってみます。
作成するスクリプトはありますが、これを直接使えるようセットアップするよりは中身を読んでコマンドラインから同じように作ったほうが手っ取り早そうです。
DortaniaInternalResourcesディレクトリを作ってcrystall1nedev/PatcherSupportPkgから取ってきた「26.0 Beta 1」を配置して、dmg化するだけです。
$ find DortaniaInternalResources -maxdepth 5
DortaniaInternalResources
DortaniaInternalResources/26.0 Beta 1
DortaniaInternalResources/26.0 Beta 1/System
DortaniaInternalResources/26.0 Beta 1/System/Library
DortaniaInternalResources/26.0 Beta 1/System/Library/Extensions
DortaniaInternalResources/26.0 Beta 1/System/Library/Extensions/AppleHDA.kext
$ hdiutil create -srcfolder DortaniaInternalResources DortaniaInternalResources.dmg -volname 'Dortania Internal Resources' -fs HFS+ -ov -format ULMO
......................................................................
created: /path/to/DortaniaInternalResources.dmg
これだけですね。元のスクリプトでは暗号化なしdmgを作ってからパスワード化変換していますが、パスワードかけなくても問題なかったです。ちなみに私以外誰も問題にならないでしょうが、zfs上の作業ディレクトリではhdiutilがエラーになりAPFSの作業ディレクトリを用意する必要がありました。
作成したDortaniaInternalResources.dmgはOCLPをインストールした上で /Library/Application Support/Dortania/OpenCore-Patcher.app/Contents/Frameworks に配置します。
$ sudo cp DortaniaInternalResources.dmg /Library/Application\ Support/Dortania/OpenCore-Patcher.app/Contents/Frameworks/
Contents以下の構成がOCLPバージョンによって差異があるようなのであまり確信はないですがlzhoang2801版についてはこれで動きました。本来は Contents/Resources に配置して Contents/Frameworks からsymlinkを貼るのが正解のようですが直接配置でも可。バージョンによっては Contents/MacOS に置く必要があるかもしれません。まあ迷ったら全部に転がしましょう。
最後に以下のおまじないをします。
$ touch ~/.dortania_developer
開発者用の機能だからなのか、ホームディレクトリにこのファイルが置かれてないとDortaniaInternalResources.dmgを読み込まない機構があるためです。
ここまでやったら、lzhoang2801版OCLPでオーディオパッチを含むRoot Patchが適用できるはずです。ちゃんと設定できていればDortaniaInternalResources.dmgを読み込む際のパスワード入力画面が出ますが、設定していないので空欄でマウントできます。
ただ、自分の環境だと再起動時の要パッチ自動検知後のパッチ適用が失敗します。おそらく自動検知からのOCLP起動はrootで動いていて .dortania_developer をチェックできてないせいじゃないかと思うんですが、/var/root に .dortania_developer を置いても相変わらず動きませんでした。まあダイアログを無視して改めてOCLP起動すれば適用できるので別に良いかなと・・・
というわけでOCLPアプリこそ野良ビルドですが、公式版Universal-Binaries.dmgと公式に組み込まれる予定の26.0 Beta 1のAppleHDA.kextを導入しているのでシステムの状態としてはOCLP 3.0.0が出たときと同じになっているはず。
まあOCLPはRoot Patchをrevertして入れ直せば後からいくらでも公式版Root Patchに入れ替えられるので、現時点で野良パッチにしていても後を引くことはないんですけど、気分的にはOCLP-Modを使うよりこっちの方が良いですね。
Root Patch + AMFIPass考察その2
さてここからは更に実用と関係ない話を書いていきます。
以前Root PatchとAMFIPassの関係を書いたとき、ざっくり言うとRoot Patch用のバイナリにDortania独自署名を施した上でAMFIPass.kextで独自署名を許可している、と推測しました。が、今回はDortania署名を組み込めない野良ビルドのOCLPを使いつつAMFIPass.kextによるAMFI無効化回避が可能でした。なんで？
まず上述の野良ビルドのうちlzhoang2801版OCLPは既に言及した通り公式のUniversal-Binaries.dmgを使っているのでDortania署名が入っています。
PatcherSupportPkgを独自ビルドしているOCLP-Modは？というと、ビルド時署名はせず公式のUniversal-Binaries.dmgをバラしたDortania署名済みバイナリから組み直しているので動く、というカラクリです。
というわけで既に公式PatcherSupportPkgにマージされているWiFiパッチが野良ビルドでも動作する仕組みは説明できます。が、OCLP-Modで独自に追加されたりDortaniaInternalResources.dmgで手動追加したオーディオパッチが動くのはなんで？という疑問は残ります。
これは以前の「全てのバイナリに独自の署名を施し」という説明が不正確で、実際には「Apple署名の無い(剥がれた)バイナリに独自の署名を施している」ので、Apple署名があるバイナリはそのままRoot Patchで使ってもAMFIPass有無に関わらず動く、ということでした。ちゃんと見ればApple署名があったら独自署名実施はスキップするようになってます。
つまり、WiFiパッチはApple署名が無いのでDortania独自署名+AMFIPassが必要で、オーディオパッチはApple署名があるから野良で導入しても動く、ということでした。
ざっと見たところFrameworkがDortania署名、kextがApple署名なことが多く、例えば以下のようになっています。
$ codesign -dvvv ./13.7.2-25/System/Library/PrivateFrameworks/IO80211.framework/Versions/A/IO80211 2>&1 | grep Authority
Authority=OpenCore Legacy Patcher Software Signing
Authority=Dortania Code Signing Certification Authority
Authority=Dortania Root CA
$ codesign -dvvv ./14.5/System/Library/Extensions/AppleUSBAudio.kext/Contents/MacOS/AppleUSBAudio 2>&1 | grep Authority
Authority=Software Signing
Authority=Apple Code Signing Certification Authority
Authority=Apple Root CA
IO80211.frameworkはDortania署名、AppleUSBAudio.kextはApple署名であることがわかります。Tahoe用オーディオパッチも対象はAppleHDA.kextだけなので、Apple署名が付いてます。
Frameworkが独自署名になる理由としては以下の理由が推測できます。
- Apple署名のバイナリを入手できない
- バイナリに何らかの改造を施す必要がある
まず 1. についてですが、macOSはVenturaからFrameworkやkextの単体バイナリがインストールされなくなりました。じゃあどうやって動いてるんだというと、最初から各種Frameworkやkextが固められたキャッシュが配置され、そこから読まれています。そのため、インストールイメージから署名済みバイナリを取り出すことができなくなりました。
ただ、kextについてはRoot Patchでも使われる開発者用のKDK(Kernel Development Kit)に含まれているので、ここから署名済みバイナリを取り出すことができます。
Frameworkにはそういったものが（多分）ないので、OCLPではキャッシュを分解してRoot Patch用Frameworkを再構成しているんじゃないかと思います。なのでバイナリとしては独自なものとなり、再署名が必要なんじゃないかなと。
次に 2. のパターン。Root Patchは抽出元のmacOSバージョンが同じでも適用先バージョンごとにバイナリが分かれていることがあります。例えば以下のように。
$ md5 ./13.7.2-*/System/Library/PrivateFrameworks/IO80211.framework/Versions/A/IO80211
MD5 (./13.7.2-22/System/Library/PrivateFrameworks/IO80211.framework/Versions/A/IO80211) = 4197576627518913626b0ff33cdae0c3
MD5 (./13.7.2-23/System/Library/PrivateFrameworks/IO80211.framework/Versions/A/IO80211) = 4197576627518913626b0ff33cdae0c3
MD5 (./13.7.2-24/System/Library/PrivateFrameworks/IO80211.framework/Versions/A/IO80211) = bd8ed9eafd4abf0aae0012fd11a5b66b
MD5 (./13.7.2-25/System/Library/PrivateFrameworks/IO80211.framework/Versions/A/IO80211) = bd8ed9eafd4abf0aae0012fd11a5b66b
この場合、13.7.2が元ネタになるmacOSバージョン（Ventura）、22〜25が適用先のmacOSカーネルバージョン（Ventura/Sonoma/Sequoia/Tahoe）を指しています。適用先にVentura自身があるのが不思議ですが、実際は使われてなさそうに見えます。
そして、22/23と24/25で中身(ハッシュ)が違うことがわかります。なので、おそらく13.7.2から抽出しただけでなく、適用先のカーネルバージョンで動作するようシンボルの変更など何らかの改造が行われているんだと思います（逆アセしてみればちゃんと理解できそうですが、そこまでのモチベーションはない）。となると、仮にApple署名済みバイナリを取得する方法があったとしても改造した時点で剥がれてしまいますので、再署名が必要になっちゃいますよね。
というわけで、野良ビルドのRoot PatchでなんでAMFIPassできるのか？という背景を理解することができました。今回はたまたまDortania署名が必要なWiFiパッチまでは公式でビルドされていて、Apple署名が残っているkext適用だけで済むオーディオパッチのみ野良だったから適用できたわけですね。
また、DortaniaInternalResources.dmgの存在も知ったので、kextを追加でブチ込むだけだったらオレオレOCLPを作ることも可能そうです。
OCLP 3.0.0が出るまでの過渡期の知見であり、しかもTahoeが最後のIntel macOSな以上今後役に立つことのない情報ですが、個人的には理解が深まって楽しかったです。
0 件のコメント:
コメントを投稿