macOS 27 Golden Gate Betaにて、Wacom Centerが起動しない・応答しない問題の原因と解決策。

この問題は、macOS 26.0 Tahoe Betaの当時にも起きていた問題です。その問題が、macOS 27.0 Golden Gate Betaで再度発生しました。

Tahoeの当時も、Golden Gateの今も、Wacom Center 6.4.9-2にダウングレードすることで問題は一時的に解決できますが、Cintiq 24などの、6.4.10以上を必要とするデバイスでは、デバイスが認識されず、この方法では解決できません。

この問題は、6.4.10 / 6.4.11 / 6.4.12 などの旧バージョンや、6.4.13の、2026年7月7日の最新バージョンでも起きる問題となっています。再現性があり、必ず起きる問題です。

問題の原因
この問題の実態
Wacom Centerの基本動作の解析
この問題の解決方法
署名問題の解決へ
認証が変更されたことによる、macOSの権限設定問題
App Group問題
最終的な判断
結論＝ワコムのせいです。
同じ問題に陥っている人向けの助言
macOS 27.0などの未定義OSにて、Wacom Centerを問題なく起動するために行なったプロセス

問題の原因

結論から言いますと、この問題は、Wacomが対応OSバージョンを、バージョン名でハードコードしていることが根本的な原因です。Wacomサポートに問い合わせたところ、Wacom Center 6.4.9から6.4.10へアップグレードする際、大きな仕様変更があったため、と説明を受けました。その際、変調防止のためかなんなのか意図は不明ですが、OSのバージョン名を、ハードコードされたバージョン名と一致するか確認するプロセスが入っているようです。

こちらが、Wacom_IOManagerの実行ファイルを分析して得られた文字列です。それぞれのバージョンを、明確にハードコードして処理していました。マイナーアップグレードに備えて、26.8や26.9などというバージョンまで含めているものの、macOS 27.xの文字列が追加されていません。その結果、macOS 27.0 Golden GateのDeveloper Betaから起動しようとすると、正常に起動できず、ドライバーが応答しない、という問題が起きてたわけです。

この問題の実態

このOSの未定義問題に関わる判定は、以下のようなソフトにそれぞれ起きていました。

/Applications/Wacom Tablet.localized/Wacom Center.app
/Applications/Wacom Tablet.localized/.Tablet/WacomTabletDriver.app
/Applications/Wacom Tablet.localized/.Tablet/WacomTouchDriver.app
/Applications/Wacom Tablet.localized/.Tablet/TabletDriver.app
/Library/PrivilegedHelperTools/Wacom_IOManager.app
/Library/PrivilegedHelperTools/com.wacom.DataStoreMgr.app

上記のそれぞれの.appにて、macOSのバージョンを確認する内容がハードコードされていました。

複数のバイナリから、以下のファイルを読み込む動作をおこなっています。
/System/Library/CoreServices/SystemVersion.plist

ここで、macOSのバージョンを読み取り、取得したOSの名前が未定義なら、起動しないような仕組みとなっていました。Wacomの想定外のOSバージョンを検知すると、そもそも起動しない、という動作になっていた、ということになります。

Wacom Centerの基本動作の解析

今回分析・逆エンジニアリングをするにあたって、Wacom Centerの起動の際のプロセスを分析してみました。

Wacom Centerは単一のアプリではなく、起動時に、TabletDriver、IOManager、DataStoreMgrなどの付属のプロセスからの応答を確認する、という仕組みになっています。ただ、このような「バックエンドのプロセス」が、上記のOSバージョンの判定が未定義になっていた、ということが原因となり、正常に起動しなかった。結果、タブレット側からの信号はしっかりとコンピュータに渡されているにもかかわらず、そのデータの処理を行うバックエンドプロセスの不在により、Wacom Centerから、タブレットが認識できていなかった、というのが問題の原因でした。

そのため、Wacom Centerからは「タブレットドライバが反応していません。Wacom Centerを再起動してください」というエラーメッセージを表示するようになったわけです。

この問題の解決方法

色々悩みましたが、Wacom側が「macOS 26.9」という、未使用バージョンまでもハードコードしていたことに注目し、runtime用に、偽のOSバージョン判定用のplistを作成しました。

ファイルは適当に/Library/WacomSV.plistなどというファイルを作成して、その中に、以下のような内容を作成しました。

ProductName = macOS
ProductVersion = 26.9
ProductUserVisibleVersion = 26.9
ProductBuildVersion = 26A5378j

ビルドバージョンは、macOS 27.0 Golden Gate Developer Beta 3のものをそのまま書いただけです。ただし、macOSのバージョンを26.9に認識させ、Wacom側のOSバージョン認証をバイパスする形です。

ただし、このファイルを作成するだけでは、Wacomドライバが正常にこのファイルを読んでくれません。システムファイルの書き換えは、他のアプリやサービスにも広範囲に影響を及ぼすため、リスクが大きすぎます。

そのため、今回はWacom側のソフトにおける、バイナリの参照文字列を以下のように置き換えました。

置き換え前：/System/Library/CoreServices/SystemVersion.plistを参照
置き換え後：/Library/WacomSV.plistを参照

変更すべき箇所が多かったため、カスタムスクリプトを作成して、一括で参照先を置き換える形をとりました。

厄介なことに、このパッチは別のディレクトリでおこなっていましたが、Wacomのタブレットのドライバーのパスが、またこれもハードコードで、固定パスを示しているせいで、パッチしたファイルを読み込まず、パッチ前の純正のファイルを読み込もうとする問題も起きていました。Wacom Centerを起動した際、バックエンドドライバーも同時に起動する仕組みでしたが、パッチしたWacom Centerを、パッチしたディレクトリで開いても、純正のバックエンドドライバーを起動する、という動作になってしまうことがありました。

この問題も同様に、

/Applications/Wacom Tablet.localized/.Tablet/WacomTabletDriver.app
/Applications/Wacom Tablet.localized/.Tablet/WacomTouchDriver.app
/Applications/Wacom Tablet.localized/.Tablet

といった固定パスを示すコードを、パッチ後のファイルを指すように一括で置き換えて解決しました。

ただ、このパッチがWacom公式によるものではなかったため、このままではWacom_IOManagerが正常に起動しないことに気付きました。どうやら、Wacom_IOManagerには、Wacom helperやドライバーに対して、コードの署名を検証する作業を行なっているようでした。

処理的には、AppleのSecStaticCodeCheckValidityWithErrorsを呼び出し、その結果次第でコードの完全性を検証したとみなし、失敗すると起動しない、という分岐処理がされているようでした。

今回はバイナリをパッチしていたため、Wacom側のApple Developer ID署名が維持できていません。そのため、ad-hoc署名で再署名を行いましたが、それでも有効なコードとして認識されませんでした。

結果、OSバージョンの認識は26.9になっているのにもかかわらず、署名エラーによりバックエンドドライバーが起動しない、という別問題が起きてしまいました。

署名問題の解決へ

Wacom_IOManager.app/Contents/MacOS/Wacom_IOManagerの、arm64の実態に対して、署名検証の失敗時に起こる拒否分岐をバイパスする仕組みを追加することで、この起動不可問題を解決しました。

具体的には、SecStaticCodeCheckValidityWithErrorsの呼び出し後の条件分岐を、以下のように変更しました。

変更前：cbz w0, valid_path
変更後：unconditional branch to valid_path

バイトで表すと、該当箇所のc0 01 00 34を0e 00 00 14に置き換えた、ということになります。

これにより、ad-hocで再署名されたWacom helperが、WacomのIOManagerの内部検証で拒否されることなく、サービスの待受状態の判定に正常に進めるようになりました。

認証が変更されたことによる、macOSの権限設定問題

問題はまだまだありました。上記の署名問題も含め、Wacomがパッチを作成してくれれば起きない問題ですが、バイナリを直接変調したため、今度は「アプリの実態が変更された」とみなされ、macOS側でアプリが入力イベントを検知するためのkTCCServiceAccessibilityおよびkTCCServicePostEvent権限が付与されていない、と扱われ、拒否されてしまっていました。

よって、実際のWacom関連のプライバシー設定の許可を取り消し、今回置き換えたアプリに権限を付与し直す形で問題を解決しました。

App Group問題

WacomTabletDriverでは、環境設定の保存先としてApp Group / group containerを取得する処理が行われていました。

-[OFileSystem getContainerPreferencesFolderURL]
-[OFileSystem getAppGroupPreferencesFolderURL]
-[OFileSystem getAppGroupPreferencesFolderURL:]
CMacPrefsInterface::Init()

上記のようなコードが実体から確認できました。

ただし、こちらに関しても、アプリの署名をし直したせいか、macOS 27のApp Groupの仕様変更があったのかは不明ですが、この処理が拒否されることにより、Wacom Centerは起動するが、実際にペンの動作や入力を受け付ける動作が欠如していた、という状態になりました。

そのため、以下のような修正を行いました。

offset 0x1dd1e10
対象: -[OFileSystem getContainerPreferencesFolderURL]
変更前: fd7bbfa9
変更後: 8c620614

offset 0x1dd1ed8
対象: -[OFileSystem getAppGroupPreferencesFolderURL]
変更前: 02008052
変更後: 5a620614

offset 0x1dd1ee0
対象: -[OFileSystem getAppGroupPreferencesFolderURL:]
変更前: ff0301d1
変更後: 58620614

さらに、システム設定の初期化結果を成功に扱わせるために、CMacPrefsInterface::Init()の戻り値も変更しました。

offset 0x1801ef8
対象: CMacPrefsInterface::Init() return status
変更前: e00315aa
変更後: 00008052

変更前: mov x0, x21
変更後: mov w0, #0

このような変更により、Group Containerへのアクセスが拒否されても、ユーザ環境設定側にフォールバックして、初期化失敗で固まらないような状態を実現できました。

最終的な判断

結果的に、Wacom Center 6.4.13-4バージョンを、macOS 27 Golden Gateから問題なく起動・使用することに成功しました。

問題の根本的な原因は、AppleではなくWacom側にあります。

macOSのバージョンを厳密にチェックして、リストにないOS名が確認された場合に、起動に失敗する、というプロセスを入れていたせいで、macOSの大きなバージョンアップが行われるごとに同じ問題が再発している状態となっていました。

今のままだと、macOS 27.0が正式リリースされ、Wacom側が対応アップデートを行なったとしても、macOS 28がリリーズされれば、確実に同じ問題が再発するだけになります。

コードを見た感じ、OS名が「Unknown」になっていても処理できるように設計しているようでしたが、macOS 27など、定義されてないOS名を検出した際、それを「Unknown」側に流す処理が不在していた、というのが根本的な原因だったと思われます。こちらの本文に書かれているその他の問題に対しては、Wacomではなく第3者がアプリのバイナリを書き換え、認証を取得して、署名し直す、という過程で起こる問題であって、Wacomが問題を解決してくれれば起きないはずの問題でした。

結論＝ワコムのせいです。

問題は明白です。AppleのmacOS 27.0側の問題ではありません。

この問題は、Wacom側がSystemVersion.plistのProductVersionを確認した際、それがリストに含まれてないもの、意図してなかったものの際、Unknownに流す例外処理を行わずに起動に失敗するように設計したため、同じ問題が繰り返し起きている、というのが根本的な原因です。

同じ問題に陥っている人向けの助言

プログラミングや逆エンジニアリングに詳しい方でないと、試さないことを強くお勧めします。

権限や署名関連の問題がいくつもあり、ワコムの単純な条件分岐が悪さをしており、その修正は、署名や権限設定まわりの内容を大きく変えなければなりませんでした。

まだmacOS 27.0 Developer Beta / Public Betaにアップグレードしていないのなら、Wacomから正式リリースが出るまでに、アップデートを行わないことを強くお勧めします。

それでも、すでにmacOS 27.0にアップデートしてしまった、という方のために、今回私がおこなった問題の解決を再現するための方法を、以下のように頒布いたします。

macOS 27.0などの未定義OSにて、Wacom Centerを問題なく起動するために行なったプロセス

まず、こちらのプロセスはシステムファイルをいじるため、sudo権限での実行が必要です。

また、システムファイルをいじるため、環境によっては予期しない問題が起きるかもしれません。実行はあくまでも自己責任でお願いします。

また、このプロセスはarm64のバイナリの修正を伴うため、Apple Silicon Macでのみ動作します。そして、Wacom Centerの6.4.13-4のインストールが必要で、そのファイル本体は変更しませんが、そのファイルを参照するような内容が含まれています。他のバージョンでは動作しない可能性があります。

プロセスでは、/Library/WacomP/{日付}のパスを作成し、そこにコピーを作成、そのコピーを修正する、という仕組みで動作するようになっています。

このプロセスは、ターミナル・zshを使用します。ターミナルやzshが何かわからない方は、実行しないことを強くお勧めします。

以下に添付している.zshファイルを、ターミナルからsudo権限で実行してください。

wacom_macos27_beta_guided_repair.zshZIPファイル / 6 KB

ダウンロード

zipファイルの解凍後、入っているzshコマンドに実行権限を付与し、ターミナルからsudoで実行してください。

パッチの作成後、Wacom Centerの起動は、以下のスクリプトをお使いください。

start_patched_wacom_runtime.zshZIPファイル / 614 B

ダウンロード

こちらのファイルを、直接Finderから実行せず、ターミナルからファイル名を指定して実行してください。すると、パッチ済みのアプリが起動するはずです。

起動前に、runtime=の部分の日付・時刻を、実際作成された各自自分のパスに置き換えてください。このまま実行すると、動作しません。

上記の内容が何を言ってるのかわからない方は、Wacomの正式リリースを待ちましょう。