別記事移転
情報まとめ・移転先
✨ https://tech.packetroom.net/chromedll-binary-rewrite-sub-browser-howto
過去執筆した記事群を、上記1つの記事へ移転・統合する路線としました
名残
-
【2022/3月 追記】
- 以下の書き換え値は名残的な意味合いで残している古いものです
- 昨今の比較的新しい書き換え値は、別サイトの記事へ更新・掲載しています。
まずは上で紹介している記事をご覧ください。
-
2021/01/28 v88.0.4324.104
31 D2 85 C9 0F 48 CA 85 C0 0F 48 C2 41 89
↓
31 D2 B9 54 01 00 00 85 C0 0F 48 C2 41 89
- 2020/08/29 v85.0.4183.83(Official Build) (x64)
4C CD 31 D2 85 C9 0F 48 CA 85 C0 0F 48 C2
↓
4C CD 31 D2 B9 54 01 00 00 85 C0 0F 48 C2
- 2019/12/18 v79.0.3945.88(Official Build) (x64)
8B 0B 31 D2 85 C9 0F 48 CA 85 C0
↓
8B 0B 31 D2 B9 54 01 00 00 85 C0
- 2019/08/02 v76.0.3809.87(Official Build) (x64)
31 D2 85 C0 0F 48 C2 85 C9 0F 48 CA 41 89
↓
31 D2 B8 54 01 00 00 85 C9 0F 48 CA 41 89
- 2019/11/01 v78.0.3904.87(Official Build) (x64)
31 D2 85 C0 0F 48 C2 85 C9 0F 48 CA 41 89 07 41
↓
31 D2 B8 54 01 00 00 85 C9 0F 48 C2 41 89 07 41
もしかして:無課金タイマー
やった事や、その流れ等
x64dbg の存在
以前調べ物をしているときに偶然見つけた改竄手法として挙がっていたのがこのツールでした。 知識ゼロのところから、見様見真似で使い方を覚え、アセンブリを齧り...試行錯誤の上、今に至ります。
この神ツールが無ければ、きっと諦めていたことでしょう。
Chromium のソースコード群
https://cs.chromium.org/
GoogleChromeの派生元であるChromiumはオープンソースで開発されており、コードを読むことができます。
当然、GoogleChromeとは異なりますが、大まかな構造は同じなので
「Chromiumが改造できれば、ある程度の応用が効くだろう」と確信していました。
時間をかけてコードを洗い出し、アセンブリと見比べたりしてトライアンドエラーの日々..という作業過程で、このサイトは大変助けになりました。
また、Chromium版ほどの利便性はありませんが、GoogleChrome も、ソースコードが見られます https://chromium.googlesource.com/chromium/src/+/master/
アセンブリ
プログラムのソースコードは「ワタシ チョット ヨメル」レベルなのですが、機械語..を少しだけ人が読めるようにしたアセンブリ言語には全く馴染みがありませんでした。 とにかくググって覚えたり x64dbg と併用して掘り下げていくことで、「雰囲気でちょっと読めるかも」程度にはなりました。
アセンブリのマッピング
x64dbgの 参照文字列検索機能で、ソースコード内の文字列と予測・紐づけを行い、
そのメソッドと思わしき個所を特定していく..という地道な作業でした。
うまく合致できれば、あとはその関数ブロックから呼ばれている(call)ところも芋づる式に特定出来たりと、大変ながらも捗りました。
また、メモがデータベース形式で書きだせるので、(かなり重かったですが)一行一行覚書を割り当てられるのも助けになりました。
何が起こっているのか
※ 個人的な解釈を含みますので、事実と異なっている可能性があります。
Chromiumのレイアウトは、このような仕組みになっているようです https://cs.chromium.org/chromium/src/chrome/browser/ui/views/frame/browser_view.h?l=693
BrowserView という大きな枠組みがあり、その中に様々なレイアウトが子・孫等として格納されています。
最初は、アドレスバー・ツールバーの類を弄るのだと予測を立てて探っていましたが、
思い返せば、結果的にそちらより BrowserView 自体のサイズをいじる方向が適切であったように思います。
BrowserView クラスの中で、 BrowserViewLayout クラスが使われています。
https://cs.chromium.org/chromium/src/chrome/browser/ui/views/frame/browser_view.h?l=584 https://cs.chromium.org/chromium/src/chrome/browser/ui/views/frame/browser_view.cc?g=0&l=2646
BrowserViewLayout クラスを覗いてみると... https://cs.chromium.org/chromium/src/chrome/browser/ui/views/frame/browser_view_layout.cc?l=65
gfx::Size BrowserViewLayout::GetMinimumSize(const views::View* host)
という「如何にも」なメソッドが見つかります。
https://cs.chromium.org/chromium/src/chrome/browser/ui/views/frame/browser_view_layout.cc?l=172
constexpr gfx::Size kMainBrowserContentsMinimumSize(500, 1);
メソッド内にこの処理があり、この 500
という値が、BrowserView の最小幅であるのだと仮説を立てました。
アセンブリのマッピングと併せて BrowserViewLayout::GetMinimumSize()
の場所をバイナリ(アセンブリ)上で特定し、
一部を弄って必ず指定の値を返すように仕向ける、といった寸法です。
54 01 00 00
の値は書き換え後の下限幅に相当し、0x154
(16進数表記) すなわち、実数 340
を表します。
この値を調節すれば下限自体を弄れますので、必要に応じて変えてください。
0
でも行けるとは思いますが、「キリのよい下限サイズ」にしたほうが、ドラッグでサイズも下げやすいと思いますので、実質このくらいが良いのではないかなと個人的には思います。