事象

Live Shareのクライアント側のみ、シンタックスハイライトやらLintやらとにかく拡張機能の類が信頼設定してるのに機能しなくなる

原因

LiveShareのクライアント側は、Virtual Workspace機能を用いており、拡張機能がこれに対応していない場合有効にならない。

対策

無理やり拡張機能を仮想スペースでも有効化するよう設定を流す。
VSCodeの共通設定を開いて、
"extensions.supportVirtualWorkspaces": { "<extensionID>": true }
を追加する。<extensionID>はUnique Identifierの事であり、例えばeslintならdbaeumer.vscode-eslintである。

詳細はこれをよんで
https://code.visualstudio.com/blogs/2021/06/10/remote-repositories

子孫要素のLoadイベントを単一のElementで拾いたい

問題点

imgタグは自身の読み込みが終わった時にloadイベントを発火させる。
例えばあるコンポーネントを末端までスクロールさせるJavascriptを書きたいが、画像の読み込みは非同期で行われるので、
末端までスクロール→画像が読み込まれ高さが変わる→現在のスクロール位置が末端じゃなくなる
という事象が起こりうる。
ウィンドウ全体の要素を対象に準備が終わったことを検知するなら、windowのloadイベントやdocumentのonChangedReadyStateが存在するが、こいつらはSPAのようなモダンなページでは機能しやがらない。
とはいえ、子要素のimgやらvideoやらに全部loadを書くのもアホらしいので、上記の例ならスクロール処理をしたいコンポーネントに一個loadを書いておきたい気分になる。
特にNuxt(Vue Router)みたいなフレーム上ではぶら下がってるコンポーネントが単離されてたりするので、そのコンポーネントにloadイベントの集約と発火をさせるのはものすごく馬鹿らしい。

続きを読む →

ゲーム内データをプログラムから覗こう

この記事は、下記記事の続きだ。
https://drroot.page/wp/?p=222

概要

前回は人力で引っこ抜いてきた静的メモリアドレスだが、Cheat Engineにはポインタスキャンというステキ機能が備わっている。
通常のスキャンだけでは静的アドレスを特定できない場合、特定したいメモリアドレスの共通の親ポインタを探す必要がある。
今回はSteam版EDF4.1を例に、Cheat Engineで静的メモリを探し当てる方法を纏めてみた。
尚、中間言語を介するUnity製のゲームなんかはこの方法が使えないので注意。あくまでネイティブバイナリ限定だ。

前提

ゲームでよくあるチートは「HPをいじる」だ。EDFでは体力値をアーマーというので、以下APと表記する。
メモリスキャンでAPのアドレスを見つけ、エディットすればゲーム内のAPを幾らでも上げられる…というところまでは多くの解説が転がっている。
しかし、「このアドレスを対象に、別のプログラムからAPを監視する」なんてことをやろうとすると躓く事になる。
APのアドレスはゲームを起動する度に（何ならミッションを選び直す度に）変化するからだ。

何故このような挙動をするかというと、ゲームに関わらず多くのプログラムは、メモリを必要な時に確保して必要な時に開放する。
Cなら昔ながらのmallocによる動的確保、オブジェクト指向言語ならnew演算子によるインスタンスの生成などがそうだ。
つまりどこかに静的=何度起動し直しても同じメモリに配置されるポインタ変数があり、そいつが目的のAPのアドレスを指している事が予想される。
ポインタスキャンとは、目的の変数を元に、その変数を指し示すポインタを探してくれる機能だ。

共通ポインタを見つける

ポインタスキャン

毎回起動したらアドレスが変わるのだから、最低でも2回ほどゲームを起動し直し、目的の変数への道筋を探す必要がある。
2パターンのスキャンマップを生成し、どちらの場合でもヒットする変数が見つかれば勝ちと言えるだろう。

まずは目的の変数を見つけ、変数リストに突っ込んでおく。今回の例はAPの最大値だ。
次に右クリメニュー→Generate Pointermapを選択。ファイル保存画面が出るので、わかりやすい名前をてきとーにつけて保存。
早い話がメモリをダンプしてるので、若干時間はかかるものの特に設定等は不要で終わる。

ゲーム一式を再起動したら、もう一度AP最大値を探し直す。
見つかったらそのアドレスに対し、今度は「Pointer scan for this address」を選ぶ。
すると下記画像のような画面が出る。

ここで「Use saved pointer map」にチェックするとファイル選択ダイアログが出るので、さっき保存したポインタマップを選択。
その後セレクトボックスから最大アーマーの値を選ぶと、手元の変数も含めて共通の親ポインタをスキャンしてくれる。
設定周りは適当で構わないが、「Max different offset per node」はチェックした上でせいぜい5か6くらいがお勧めだ。
このオプションは何世代まで親の変数を探すかの設定だが、1増やす毎に計算量が指数関数で増える。
なので4あたりから始めて、ヒットしなければ増やすくらいの感覚で良い。

スキャン結果を読む

ポインタスキャンが終わると、共通の親ポインタの一覧がどかっと出てくる。

この時、"~exe"+XXXXXXXXの形式になっている事が重要だ。
exeファイルの配置されるアドレスは不定だが、その後ろのオフセットアドレスは静的だからだ。
なので、OSにexeファイルのアドレスを聞く→オフセット値を足す→そのアドレスの値を読む→オフセットを足す…としていけば目的のアドレスに辿り着ける。

さて、スキャン結果をざっと見た感じ、どうやら目的地への道筋は無数にあるようだ。
何も長ったらしい道筋をわざわざ選ぶ理由は無いので、今回は決め打ちでOffset 3までで辿り着ける下記ルートを選択する。
"EDF41.exe"+00CC84E8 -> 28 -> 130 -> 8 -> 168

あとはコードを書けばプログラムから各種値をすっこ抜ける。
コードは前回記事とほぼほぼ共通なのでそっち参照。
ただし、前回が32ビットアプリ向けだったのに対し、今回は64ビット長でメモリを扱う必要があるので注意。

https://github.com/taizan-hokuto/pytchat
本記事で書いたコードは、ほぼ上記Pythonリポジトリの劣化品だ。

続きを読む →

クソ悩んだ

https://drroot.page/wp/?p=201
この記事は、上記記事の続きだ。

概要と症状

2021年1月末現在、こんな感じで再現できる。

vue-cli-pluginでプロジェクト作成
↓
vue add electron-builderコマンドでElectron-builderブチ込む
↓
yarnなりnpmなりでserialportを入れる（というか、ネイティブ向けパッケージを入れる）
↓
electron:serveすると普通に動く
↓
electron:buildしたexeを実行しても即座に終了してなんも起きない
↓
気づいたらelectron:serveも即終了するようになってる

エラーコードも何も起きず、正常終了するフリして即落ちするからマジで何かと思った。

原因

electron-builderが、buildコマンド時にネイティブパッケージを変なふうにリビルドするのが原因。
どうもこの時おかしなリビルドをするらしく、起動後即座にbindings（ネイティブバイナリと橋渡しするやつ）を掴み損なって落ちるらしい。
これもビルド時のログを5千億回くらい読み直してようやく理解できたんだが、どうも「electron-rebuild -f -w serialport」すべきところを「npm-rebuild」してるらしく…
もしかしたら、electronにバンドルするnodeではなく、開発で使ってるnpm向けにビルドしちゃってるんじゃないだろうか。

直し方

electron-builderに、ビルド時の余計なネイティブパッケのリビルドやめろと伝えれば良い。
ドキュメントによれば、npmRebuildをfalseにすればいいとある。
https://www.electron.build/configuration/configuration#configuration

electron+vue構成の場合、プロジェクトのルートにvue.config.jsを作り、そこにbuilderへ渡すオプションを書ける。
https://nklayman.github.io/vue-cli-plugin-electron-builder/guide/configuration.html#configuring-electron-builder

今回はserialportを使っているので、こいつをビルドから除外するコードも含めると（前回記事参照）こんな感じだ。

module.exports = {
  pluginOptions: {
    electronBuilder: {
      externals: ["serialport"],
      builderOptions: {
        npmRebuild: false
      }
    }
  }
};

で、もしこの症状に陥った場合、既にBuilderがゴミをリビルドしてしまっているので、もっかい手動でネイティブバイナリのリビルドをする必要がある。
即ち、「electron-rebuild -f -w serialport」を叩き直せばいい…このあたりは前回記事の内容を参照だ。

ちなみに

yarnを使ってるだけでも、何かしらaddした時この余計なリビルド処理が発生しやがるぞ。どうしろってんだ。
今の所気付き次第Rebuildする以外に思いつかんね。