https://drroot.page/wp/wp-content/uploads/2022/09/shibes.html
https://shibe.online/
しばいぬAPIのクライアントページを作成した。
公式サイトでも出来る事だが、ボタン一つで更新をかけられるようになっている。
https://drroot.page/wp/wp-content/uploads/2022/09/shibes.html
https://shibe.online/
しばいぬAPIのクライアントページを作成した。
公式サイトでも出来る事だが、ボタン一つで更新をかけられるようになっている。
https://drroot.page/wp/?p=227
この記事でアプリケーション(Node.js)からブラウザのフリして配信のチャットを引っこ抜くコードを紹介したが、正規表現でContinuationを引っこ抜く処理に抜けがあり、上位チャットしか取ってこれてない状態だった。
というわけで上位でなく全体のコメント向けContinuationを取得するコードも書いた。以下でcontinuation keyがstringとして得られる。
// videoId=配信ページとかのURL末尾のID
const res = await axios.get('https://www.youtube.com/live_chat', {
headers: "user-agent":
"Mozilla/5.0 (Windows NT 6.3; Win64; x64) " +
"AppleWebKit/537.36 (KHTML, like Gecko) " +
"Chrome/86.0.4240.111 Safari/537.36",
params: { v: videoId }
});
const html: string = res.data;
const matchedCtn = html.matchAll(
/"reloadContinuationData":.*?"continuation":"(.+?)"/g
);
const matchedCtnList = [...matchedCtn];
// matched = Regex結果の集合 一個の結果が更に配列でマッチ結果を持つ
// Youtubeの場合matched[0]が上位チャット、matched[1]が全体チャットの筈
const continuation = matchedCtnList[1][1];
AOM-5024は、一般向けにバラ売りされているマイクカプセルの中では最高音質のものだ。
https://www.marutsu.co.jp/RatedList.jsp?goodsClassCode1=15&goodsClassCode2=0062&goodsClassCode3=0005&ids=0&resultsMaxShowLine=100&resultsShowPageNumber=1&resultsSortColumn=ratedValue8%3ADESC&rohs=0&sdg=0&shopNo=3
以前(2年半も前!?)にファーストインプレッション記事を書いたのだが、この時は3線式改造ができないものだと思われていた。
https://drroot.page/wp/?p=119
3線式改造というのは、エレクトレットコンデンサマイク(以下ECM)の内蔵FETが通常ソース接地回路になっているのを、ソースフォロアに改造して歪み率や最大入力レベルを改善する改造だ。
細かい話はShinさんの~というブログの記事を参照すると良い。
https://ameblo.jp/shin-aiai/entry-11840658464.html
ところがこの記事にコメントをくださった謎の人物がおり、海外のフォーラムでこのマイクを分解している画像へのリンクをいただいた。感謝。
https://imgur.com/t/microphone/sEYEgP3
この画像はマイク本体を引っ剥がした裏面の回路まで載っており、何故3線改造が上手く行かなかったか、どうすれば出来るのかが分かる代物だった。
マイクカプセルの裏側をよーーーく見ると、個体にもよるんだがGND端子のすぐ上あたりに2つのスルーホールが見える場合がある(以下乳首)。
この2つを周囲のランドから切り離す事で、ソースとGNDを分離することができる。
乳首は上記画像の赤丸で囲った部分がそうなのだが、カプセルによっては透けて見える場合とそうでない場合があるので基本は決め打ちになる。
ソース端子を真上の空間ごとごそっと切り出す感じでランドを削ればうまくいくぞ。
ソース端子を削り出したところ。GNDははんだ付けする場所がないので、「+」とかかれているあたりをこれから削り出す。
GNDの削り出しまで行ったあと、配線したところ。そこそこのサイズなので、EM158とかとくらべりゃ遥かに作業しやすい。
ブレッドボードで組んだ感じは文句なしに過去最高のノイズ性能で、良質なファンタム電源があればバイノーラル音声作品とかにも耐えうる性能を確信している。
そもそもデータシート上でSN比80dBなので、Free Space(通称白耳)と同じ性能を持っている事はたしかなわけだ。
今の所あれこれ回路を組んでる状態なので、ちゃんとモノを作って上げるのは後日になる予定。
DapLinkはCMSIS DAPの上位互換的なデバッガ兼ライタ。
Mbed Studioは標準でDapLinkとやり取りする機能が備わっているので、コイツが動くボードを安価で用意できると非常に開発が楽になる。
このDapLinkにはスイッチサイエンスのLPC1114ボード向けのビルドが存在し、DapLink公式で1114と入力すると出てくるファーム「0254_lpc11u35_ssci1114_0x0000.bin(現時点)」が相当する。
11u35と1114は秋月でどちらも手に入る。昔は1114のDIP版が120円とかで買える時代があり、今手元にあるのはその時買い溜めたものだが、SSOP28版でもピンアサインは同じ。
ただしお値段がDIP化基板無しで300円する。
https://akizukidenshi.com/catalog/g/gI-10224/
11u35は何度か取り上げているが、発振子とレギュレータ搭載済みのものが850円で買える。マイコン単体でも売ってるが、乗ってるものを自前で揃えたら850円じゃ済まないのでこっちの方が良い。
https://akizukidenshi.com/catalog/g/gK-12144/
もちろん「トラ技ARMライタ」でも良い。秋月ボードとピンのレイアウトは異なるが、ポートに付けられた名前は互換している。
11u35へのファーム書き込みはいつものようにISP押しながらRSTでOK。
この2つを下記のように配線する。
LPC11u35 | LPC1114 | せつめい |
---|---|---|
P0_8 | SWDIO | SWDIO |
P0_7 | SWCLK | SWCLK |
P0_19 | dp15 | Serial_MtoS |
P0_18 | dp16 | Serial_StoM |
p0_2 | dp23 | nRst |
もちろんGNDとVout -> Vinも忘れずに。
MbedStudioからROMの書き込みやデバッグができれば成功。
一度できれば同じ11u35を使いまわして、1114をプログラミングできるのでお安く済むという算段である。
別にマイコンとかそんな使う予定無いけど…って人は11u35一個買って終わりなんだけど。
で、このピン設定やら何やらは一体どこから来たんだという話。
DapLinkのGithubを見るとコードが入っているんだが、デバッガが11u35の場合のポーティングは「DAPLink/source/hic_hal/nxp/lpc11u35/」
に存在する。
この下のIOConfig.hにピンの設定が書かれており、1114では使用していないJTAG関係のポートも設定されている。
ちなみにプログラムの書き込みはシリアル通信で行われるが、SWDを用いた書き込みではFlash Argorythmと呼ばれる仕組みで書き込みを行うのでISPピンは設定しなくても良い。
具体的にはSWDでターゲットのRAM領域に直接ISPっぽい事をするプログラムを送信(このプログラムがFlash Argorythm)、続いてシリアルでファームを送るという手順を踏んでいる。
https://qiita.com/dabodabo/items/f8b52413849291a2d462
秋月で取り扱いが始まったFMラジオモジュールRDA5807は、作例こそあるもののいまいち情報が足りてないようだ。
https://akizukidenshi.com/catalog/g/gM-17245/
今回はMbed環境下で挙動を確認してみた。
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
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ビット長でメモリを扱う必要があるので注意。
Xcom Enemy Withinにて発生し、Xcom Chimera Squadではさらに悪化したこの問題。
ゲーム起動後、時間が経過するにつれて「システムの割り込み/System Interrupt」プロセスのCPU使用率が上がっていき、それにともなって音声がプツッたりFPSが落ちたりする。
ゲームの設定ファイルやらNvidiaの設定やら、あらゆる問題をあたっても直らなかったが、数年を費やしとうとう原因を特定した。
何かしらのハードウェアが悪さをしている。
つまり、USB機器を全部引っこ抜いてゲームを起動し、再発しなければ一本ずつUSB機器を差し直して犯人を特定しろということだ。
UE3は謎の最適化をしており、その影響でこのような事になるらしい(そもそもシステムの割り込みが出てくる時点でハード周りが確黒だ)。
参考にしたフォーラムでは特定のマウスが原因との事だったが、自分の環境ではDUAL SHOCK2とUSB パッドの変換器が犯人だった。
これを外すだけで問題が起こらなくなった。そんな程度の事に全く気づかなかったとは…。
これでようやく宇宙人共を快適に叩き殺せるぞ!