Linuxの改造とパッチ投稿(pending) Apple Magic Keyboard JIS版をLinuxで動かすぞ！

WHO AM I ? ● 森 瑞穂(@morimolymoly) ● 電気通信大学永遠のM2 ● 趣味: 音楽/VALORANT/セキュリティ関連 ● 研究: VMMを用いた高速なバイナリトレーサー ● 未踏スパクリ@2019 ● セキュリティの会社でセキュリティの…エンジニア？やってるんですけど！ ● 最近だと…… ○ Smishingで落ちてきた検体を解析したり ○ フェスというフェスがなくなったり ○ 来年からはセキュリティエンジニア見習い予定 (卒業できれば)

Agenda 1. 背景 2. 問題箇所の説明 3. 場所の特定 4. デバッグ 5. 修正のためのあれこれ 6. パッチ投稿

LinuxでJIS版Magic Keyboardが使えない！ ● 1万円だして(高額)購入してペアリングするも、’ろ’、’|’、英数、かなの4キーが反応し ない ● パイプ使えないなんてソリティアして時間潰すしかない😂 ● この時点で使えないよ〜という類似する問題を指摘するブログが引っかかる ○ https://github.com/cb22/macbook12-spi-driver/issues/34 ○ https://atori.xyz/archives/277 ● scancodeがドライバの範囲外を指しているとか……？

初期調査 ● xevコマンドでキーが認識されているか確認する ○ 認識されない ○ keycode: 97(ろ), 132(|)、131(英数)、130(かな) が認識されるべき ● これはカーネルの問題では……？🤔🤔🤔 ● 一通りユーザランドで調査できることはやった上でカーネルランドへ潜りましょ う！！！！！ ○ 今回は完全にカーネルなのでカーネルを読んでいきます

とりあえず関連してそうなパッチを探す ● Linux kernelのような巨大なソフトウェアをいじるときはpatchを探して大まかな修正 箇所を見積もるのが速い気がする ● “apple magic keyboard patch”でググるとでてくる ○ http://lkml.iu.edu/hypermail/linux/kernel/1808.2/04900.html ● drivers/hid/hid_apple.c ○ HIDサブシステムのなかの Appleのファイル ● hid-core.cとhid_apple.cあたりに問題がありそう？

HIDサブシステムってなに？？？ ● Human Interface Deviceとのことでキーボードやマウスなどを示すもの ○ USBからBluetoothまで拡張されていった経緯があるらしい ● まずデバイスがReport Descriptorをカーネルに送る ● ユーザがデバイスを操作するとレポートがカーネルに送られる ● カーネルはReport Descriptorを使ってレポートを読み、イベントを処理する ● この一連のシステムのこと、らしい ● ざっくりとした理解！

原因を特定する1 ● hid-apple.cのあらゆる箇所にprintkを仕込む😎
 ● hid_driver構造体のなかのevent(apple_event)を監視した ● 結果、機能しないキーの情報が一切hid_appleに届いていないことがわかった。 ● これは別の箇所をデバッグする必要 ● がありそう……

原因を特定する2 ● 先程の通り、hid_core.cを起点にイベントなどが発せられるようだ ● ...-> hid_report_raw_event -> hid_input_fieldと関数を下っていく ● するとhid_input_fieldからhid_process_eventが呼ばれ、hid_appleにイベントをフィ ルタした上で渡していることがわかった。 ○ その間、hid_appleでやったprintk debugを同じ用に入れて入力をトレース ○ 結果、特定の入力がドロップされていることを確認 ● 原因が特定できた😎😎😎

hid-coreのハック ● hid_input_fieldから特定の条件分岐を経て、hid_appleにイベントが通知される -> ここを通るようなパッチを作れば良さそう！ ● logical_maximumとmax_usageってのが絡んでいるらしい ○ なにこれ？ ● 理解はしないでlogical_maximumとmax_usageに大きな値を入れたらうごいた！ ○ hid_add_fieldなるところでこれらが設定されていた ○ なにをしたのか理解しなければ ……

Report Descriptorの調査 ● HIDデバイスはホストとレポートという形でやり取りする ● Report DescriptorとはHIDデバイスからホストへレポートを送るときの取り決めをす るもの ○ logical_maximumやmax_usageはそれぞれ、レポート中の値の上限と使用する値の上限を意味す る ● 先程の汚いハックで解決したのはここのディスクリプタの値が間違って？いたから だった ● で、ここらへんで先人のかたが着手している記事を見つける ○ https://qiita.com/uskf/items/1170728d1c5c83432c6e ○ 数時間返して……😇😇😇

修正箇所 ● hid_driver構造体にはreport_fix_upでReport Descriptorを修正する機能が備わっ ている ● ここでLogical MaximumとMax Usageをかえてやれば良い

修正箇所 ● hid_driver構造体にはreport_fix_upでReport Descriptorを修正する機能が備わっ ている ● おや……🤔🤔🤔 ● 既にやられているっぽい

修正 ● ありがたく参考にさせてもらうが、rdescという配列をゴリゴリ弄っている ● 意味不明 ● 意味不明 ● 意味不明 ● rdescを頑張って調べる

修正

修正 ● なるほど！kernelでparseされたやつをみて間違っているところのindexをrdescに 入れればよいのか！ ● [ ]でくくったところが ● 修正箇所 ● 0x65が上限だとたしかに ● キーを受け付けない……

修正

パッチ投稿 ● はぁ…はぁ…あとはパッチを送るだけだ……(ここまで徹夜) ● Linux nextやmainlineのカーネルにパッチを適応させる ● あとはgit commit -s(Signed-off-by付き)でコミット ● git format-patchでパッチを生成 ● get_maintainer.plスクリプトで誰にメールを送るかを確認(パッチを食わせるとわか る)(linux-inputなどが出てきたが一応送るべきかも？) ● git send-emailでメンテナの方々、メーリスを含むようにメールを送る ● おわり！

ひたすら待つ！ ● ひたすら待つ ● なにが何でも待つ ● 投稿したパッチがイケてないなあと思っても待つ ● とにかく待つ

全然反応来ないけど自分は使えてるので満足です！ ● 結果、全然反応が来ません！！ ○ おそらくJIS版のMagic Keyboardは優先度が低いのだろう ○ でも使えないのはイケてないよね ● 独立してカーネルドライバをリリースしました ○ hid-appleに更新がアレば追従しようと思うので LinuxでJIS版Magic Keyboardが使いたい方はぜひ 利用してみてください ○ https://github.com/morimolymoly/hid-apple ● 僕は毎日使っています。JIS版Magic Keyboardサイコー！

Applied!

ご清聴ありがとうございました！