Development
リソース開発
FiveM 向けのスクリプト・MLO・GFX を開発しています。対象の多くは公開仕様が無く、動かして確かめるまで正解が分かりません。このページには「検出できます」「追えます」と書くかわりに、実際のクラッシュダンプ・実際の検出結果・実際に直した 8 バイトを、その場で触れる形で 3 つ置きました。
How to read this page
数字には、条件をつける。
GTA V / FiveM のファイル形式には、公開された仕様書がありません。変換ツールを逆コンパイルしても、 8.5MB の静的リンク C++ からは読めるソースには戻らず、文字列も難読化で潰してあります。 だから必要なのは他社の実装ではなく、観測できる事実としての形式そのものでした。
このページに出す数値は、何件を・どういう条件で測ったかを必ず併記します。 いずれも野澤組が自身のデータセットを測ったもので、第三者による測定ではありません。
- fxo-core の自動テスト0 failed / 2 ignored（2026-09-01）
- 970passed
- Enhanced 変換の全数掃引26.65 GB・panic 0・異常終了 0
- 37,350ファイル
- RPF の全数検査360 本すべて・不合格 0
- 777,725エントリ
- 読んだ配置エンティティ独立実装との突き合わせで不一致 0
- 1,071,023件
- 形式が判らなかったもの1 件ずつ調べて「不明」で残り 0
- 626件
Measuredこの節で測ったもの ── fxo-core の自動テスト。テストバイナリを実行して 970 passed / 0 failed / 2 ignored、所要 48.5 秒（2026-09-01、手元の環境）。ソースは 104 ファイル・99,723 行で、その中にテストが 972 個あります。
変換の掃引は 26.65 GB・12 並列で 48.4 分、panic 0・異常終了 0・時間切れ 0。RPF は 360 本 777,725 エントリを全数検査して不合格 0（一意な名前 254,041）。配置エンティティ 1,071,023 件は独立実装との突き合わせで不一致 0 件で、推測した座標は 1 件もありません。
Evidence 01 ／ Dynamic analysis
このレジスタを、読んでみてください。
変換した資産が実機で落ちる。しかしログは残らず、手元にあるのはミニダンプだけでした。そこから読めたことを、実際の画面ごと置きます。
0:110> .ecxr rax=0000000000000000 rbx=000000006d657461 rcx=000000f7d561e010 rdx=5a55555500002104 rsi=0000000000000000 rdi=000000005004c000 rip=00007ff76463c32f rsp=000000f7d561ddc8 rbp=000000f7d561de30 …（r8〜r15・フラグ・セグメントの 5 行は省略） GTA5_Enhanced!Ordinal0+0x127c32f: 00007ff7`6463c32f cc int 3
rbx
0x6d657461 ＝ "meta"。壊れているのはコードではなくデータで、 しかもシェーダーの目印を読んでいる最中に止まっている、と分かります。
- int 3（ExceptionCode 0x80000003）
- アクセス違反ではありません。ゲームが自分で置いた停止命令です。だから「何を確かめて止めたか」さえ読めれば、書き間違えている場所が特定できます。
- rbx = 000000006d657461
- レジスタに文字列が入っています。下位 4 バイトは ASCII で meta。壊れているのはコードではなくデータで、しかもシェーダーを読んでいる最中だと分かります。
- rdx = 5a55555500002104
- 探していたアドレスの上位 32 ビットが 0x5a555555。アドレスとして成立していません。
.ecxr で例外時のレジスタへ切り替え、kb でコールスタックを 13 段（00〜0c）取ったところ。 上の等幅テキストは、この画面からの書き写しです。値は加工していません。
Ordinal0+オフセット でしか読めません。 そのため !analyze -v は別のダンプでも WRONG_SYMBOLS のバケットに落ちます（その出力はこの画面には写っていません）。自動解析は使わず手で降りています。Measuredこの節で測ったもの ── 手元のミニダンプを自作の解析器（40 行弱の Node.js）で一括分類しました。 停止位置は 1 か所ではなく、0x80000003（int 3）が GTA5+0x127c32f / +0x127bc94（3 回）/ +0x1edc041、 ほかにアクセス違反が複数。単一のアサートではなく、壊れたデータをそのつど違う形で読んで落ちています。
Open ／ Still unsolved
8 件、順に消えた。まだ答えは出ていない。
ここから先は、いまも解けていない側の話です。多数のモデルを同時に読む大規模 MLO の実機クラッシュは、 2026-08 時点で未解決のまま残っています。ミニダンプにはレジスタ・スタック・一部のメモリしか入っておらず、 リソース名もファイル名もエラー文も入っていません（.ydr で全文検索して 0 件）。指しているアドレスを覗いても 16 バイト × 30 行がすべて ?? でした。
静的に読める範囲はそこで尽きたので、実機で 1 変数だけ変えた版を作り、置いて、 落ちるかどうかを見るしかありませんでした。
- 01
単体のモデルが壊れている
否定二分探索で犯人とされた 1 本だけをこちらの変換にする
落ちない
- 02
メモリ量（フットプリント）
否定同じ 16 本を 1 ページに詰めて 115MB へ肥大化させる
落ちない（落ちる 31 本の側は 104MB）
- 03
ページ枚数が多すぎ／少なすぎ
否定落ちる版と落ちない版でページ枚数を数える
落ちる版のほうが枚数は少ない
- 04
構造がページ境界をまたぐ
否定コリジョンまで辿って全数検査
またぎ 0（参照実装も 0）
- 05
vtable の「ポインタもどき」
否定0 埋め版と、非 null の非ポインタ版を作る
両方落ちる
- 06
シェーダー +0x39 の 1 バイト
否定参照実装と同じ値にする
落ちる
- 07
ShaderGroup +0x30 の残骸
否定0 にする
落ちる
- 08
PagesInfo +0x10 の未初期化 cd cd
否定0 にする
落ちる
外れた 8 件の副産物
⑤で 0 埋めしたら、クラッシュが「アドレス 0 を実行」に変わりました。 ＝あのスロットは実際に使われる vtable だと裏が取れた。0 にしてはいけない、という知識が残ります。 外したものも数えて残すのは、二度と同じ道を歩かないためです。
- 実機は 1 回では判定しない。同じ資産が落ちたり動いたりした
- 最低 3 回、毎回サーバーを再起動し、確認する経路も固定する
- 結果は「n 回中何回クラッシュしたか」で記録する
Measuredこの節で測ったもの ── クラッシュした回数。同じ MLO を参照実装だけで変換した版は 3 回中 0 回、 こちらの版は 3 回中 3 回クラッシュしました。＝環境要因ではなく、掘る場所はこちらの出力側で正しい、 というところまでが確定です。落ちるのは単一ファイルの欠陥ではなく本数の効果で、.ydr 125 本のセットのうち 16 本までは落ちず、31 本で落ちました。真因は未特定です。
Evidence 02 ／ Root cause
先頭の 8 バイトを、箱の座標で潰していた。
ここからは、解けたほうの話です（前節の大規模 MLO とは別件で、コリジョン付きの単体プロップが落ちていた件）。
参照実装の出力と比べて残る差は「ページの割りかた」だけに見えました。そこで中身を 1 バイトも変えず、ページ割りだけ変えた 3 版（現状・小ページ・1 枚）を実機で試したところ、3 版とも落ち、参照実装の版だけ動きました。ページ割りは無罪。ここで仮説を捨て、コリジョン側へ絞り込みます。
+0x00 は Nodes ポインタのまま。読み込み時に区画表へ入る
gen9 のコリジョン木（phBVH）は、先頭 +0x00 にノード配列へのポインタ（8 バイト）、+0x08 にノード数を持ち、箱と量子化の値は +0x20 起点に並びます。こちらの requantize は、その箱を +0x20 ではなく +0x00 起点で書いていました。＝先頭 8 バイトのポインタを、箱の float で上書きして潰していた。ゲームは読み込み時にそこをポインタとして解決しようとして、壊れた値で停止していました。 コリジョンを持つ .ydr だけが落ちていた理由も、これで説明がつきます。
![停止位置の直後を逆アセンブルした実際の出力。[rcx+8] を読み、null 検査のあと [rax+0Bh] のバイトを比較する小さな述語関数が並び、??? が関数の切れ目を示している](/_next/image?url=%2Fservices%2Fdevelopment%2Fdump-disasm.png&w=3840&q=75)
u）を逆アセンブルしたところ。[rcx+8] を読み、null なら失敗、+0Bh のバイトが 0 でないかを返す小さな述語関数が並んでいます。??? はパディングで、ここが関数の切れ目です。loop: cmp r10, r8 ; 表の終端に到達したか je int3 ; 見つからずに終端 → 停止 mov rsi, [r10] ; 区画の開始アドレス cmp rsi, rdx ja int3 ; 開始 > 探すアドレス → 停止 mov rax, [r10+8] ; (ページ番号 << 56) | サイズ mov rdi, 0x00FFFFFFFFFFFFFF and rdi, rax ; 下位 56bit = サイズ add rsi, rdi ; 終了 = 開始 + サイズ cmp rsi, rdx jbe int3 ; 終了 <= 探すアドレス → 停止
停止の判定そのものは手前側にありました。上は手元の記録からの書き起こしで、 左のスクリーンショットに写っている行ではありません。 ＝「このアドレスは、宣言されたどの区画にも入っていない」という判定です。副産物として形式の事実が 1 つ確定しています── 区画表のエントリは 16 バイトで、[+0] が開始アドレス、[+8] が（ページ番号 << 56）｜ 長さ（下位 56 ビット）。ゲーム本体の機械語から読み取った観測事実で、 他社ツールの実装を写したものではありません。
実機で確認
表示・当たり
修正版を実機に載せ、鳥居が表示されることと当たり判定が働くことを確認した
横断検証
68 / 68
変換 238 ファイル中のコリジョン木 68 個すべてで、先頭 8 バイトがポインタのまま残っていた（破損 0）
回帰テスト
1 本
旧挙動なら必ず落ちる検査を先に書いてから直した（Nodes ポインタが残ることを確かめる 1 本）
Measuredこの節で測ったもの ── 修正後の横断検証。変換 238 ファイル中の BVH 木 68 個すべてで Nodes ポインタが健全（破損 0 件、2026-08-15 実測）。
この 1 件は、静的な突き合わせでは見つかりませんでした。参照実装と「値が一致」しているかで検査していたので、 置き場所の誤りに気づけなかったからです。実機での二分（ページ / コリジョンの切り分け）で初めて特定できました。
Static analysis
仕様が無い形式は、測って解く。
勘で当てるのではなく、標本を取って検算します。当たらなかったものは推測で埋めず「不明」のまま残します。
01名前の逆引き
総当たりでハッシュが完全一致したものだけ辞書に残す
296 件を回復。外れは「不明」のまま。逆引き辞書は 613,006 件で、別名で同じハッシュになる衝突は 38 件（0.0062%）
02シェーダーのパラメータ表
69 ファイルから辞書を作る
独立した 4,690 ファイル・21,941 シェーダーで不一致 0・辞書漏れ 0
03頂点宣言（FVF）
表を引くのではなく式で解く
806 ファイルから 18 種。実測 18 種に対し 18 / 18
04リソース型のカタログ
型名文字列と参照関数を機械的に対応づける
212 種を抽出（別に数えた総数は 214 種で、内訳の合計 212 と 2 種食い違います。原因が確かめられていないので、少ないほうの 212 種を載せています）
05ページの最小単位
参照実装の出力を全形式・全数で計測する
7 形式 3,530 ファイルで例外 0。0x2000 未満は 1 件も無い。変換前には 0x200 の区画を持つものが 164 件あったので新しい版だけの制約と判定でき、こちらが破っていた .ydr 27 件（.ybn の 4 件を含めて 31 ファイル）を直した
06書庫の取り込み
3 系統の道具で数え、件数が一致してから載せる
zip 13 / 13・rar 16 / 16・エントリ 3,233 / 3,233 を実展開して CRC まで検証。zip slip 0 / 3,233
07分からなかったもの
626 件を 1 件ずつ調べる
「分からない」で残ったものは 0 件
形式は実装ではなく、観測できる事実です。既知の資産を通し、前後を突き合わせ、標本を増やして検算する。 当たらなかったものは推測で埋めず「不明」のまま残します。読み取るのは形式という事実だけで、実装は独自に書きます。
Evidence 03 ／ Machine vision
28 件の検出が、9 個のボーンになるまで。
Assetto Corsa の車体を FiveM に持ち込むとき、学習済みモデルが 4 視点のレンダからパーツを探します。下の枠は、野澤組のツールが実際に出力した detections.json の座標をそのままレンダに重ねたものです。図解ではなく、出力そのものです。
検出データは FXO が実際に出力した detections.json をそのまま使用しています（Ultralytics carparts-seg / YOLOv11）。検出結果は編集画面で修正・追加でき、左右対称コピーにも対応します。
detections.json ── 28 件
- ミラー10
- ドア8
- バンパー2
- ホイール2
- ヘッドライト2
- トランク2
- ボンネット1
- テールライト1
- ドア — カテゴリ未対応
- ホイール — 名称対応が優先
ボーンにならなかった内訳
- カテゴリ未対応（ドア）
- 8
- メモのみ（ホイール）
- 2
- 別の視点から出た同じパーツで重複
- 9
289生成されたボーン
- bonnet
- boot
- bumper_f
- bumper_r
- headlight_l
- headlight_r
- mirror_l
- mirror_r
- taillight_l
Confidence::Low
reason: "画像認識(YOLO): {view}（左右は要確認）"
28 件の内訳は ミラー 10・ドア 8・バンパー 2・ホイール 2・ヘッドライト 2・トランク 2・ボンネット 1・テールライト 1。信頼度は 0.271〜0.743（平均 0.429）。視点別では 右 12・左 7・前 5・後 4 です。
この 28 件を実装に通すと、生成される GTA ボーンは 9 個だけです。ドア 8 件はカテゴリ未対応で無視、ホイール 2 件はホイールの名称対応が優先なので（必須ホイールが名前で見つからないときに限り）メモが 1 行残るだけ、 残る 9 件は別の視点から出た同じパーツで、既に作ったボーンと重複します。8 + 2 + 9 + 9 = 28 です。
その 9 個は、すべて Confidence::Low のまま人に返ります。理由欄には「画像認識(YOLO):{view}（左右は要確認）」と書かれます。AI の推定は必ず低信頼で人に渡す、が方針ではなくコードとして存在します。
実際、headlight_l は左視点から、taillight_l は右視点から出ています。 左右の割り当ては画像の左右から機械的に決めているだけで、本当に確かではありません。 コードが「左右は要確認」と書いているのは、そのためです。
Measuredこの節で測ったもの ── 4 視点 28 件の検出（信頼度 0.271〜0.743、平均 0.429）から生成された GTA ボーンは 9 個、うち Confidence::High は 0 個。座標は detections.json そのままで、こちらが作った数字は 1 つもありません。
掲載しているレンダは、素の出力 2,852 × 796 を 1/2 に縮めた 1,426 × 398 です。座標は正規化されているので、寸法によらず一致します。
Rendering under constraints
描画は、推測しないで決める。
FiveM のブラウザ UI は Chromium 103 に固定されています。無いものを嘆く前に、使えるものを数えます。
Chromium 103 ── FiveM の UI はここで固定
- :has()105
- コンテナクエリ105
- color-mix()111
- oklch()111
- View Transitions111
- Popover API114
- text-wrap: balance114
壁の内側に残っていたもの
- backdrop-filter: url(#svgFilter)
- SVG feDisplacementMap
- Canvas 2D / WebGL
屈折率 1.5 で、スネルの法則を解く。
使える・使えないをビルド設定で担保してから設計に入ります。上の 3 つが残っていたから、SVG の変位フィルタで屈折を作る方針を選べました。
変位量は経験則で決めていません。縁の断面から入射角を求め、屈折率 1.5 でスネルの法則を解いて出しています。色収差は同じ入力を R / G / B で倍率を変えて 3 回変位させ、合成しています。
面全体をぼかすと、せっかく曲げた縁が消えてただのすりガラスになります。変位マップと同じ距離計算からマスクを作り、 ぼかしを内側だけに閉じ込めました。変位マップの生成コストは、出力画素数に上限を設け、結果を 48 件のキャッシュに載せて一定に保っています。
こちらの別実装では、毎フレーム内容が変わる面に CSS のフィルタ列を掛けていたため、フレームレートが 56〜65 から 19 へ落ちました。光学処理をすべてフラグメントシェーダへ移し、描画間隔を間引いて 44 まで戻しています（2026-08、手元の環境での実測）。計測してから直す、の一例です。
どれが前面に来るかは、推測しない。
ゲーム内 UI は、どの描画がどの前面に来るかが文書化されていません。そこで描画順 0〜7 を 8 本の色帯として同時に画面へ出し、上半分を DrawRect、下半分を scaleformで描いて、実際に見えたものを数えました。左端が 0、右端が 7 です。
> oni_phone_order
[order] drawing bands seconds=20 bands=8
note="leftmost band = order 0, rightmost = order 7.
top half = DrawRect, bottom half = scaleform"
currentOrder=1そのときのコンソールからの書き起こし（読みやすいように折り返しています）。実験条件そのものです。 掲載しているのは 1 回分の記録（currentOrder=1）で、8 通りすべての画面は撮っていません。
What we make
つくれるもの。
スクリプトから 3D 空間、グラフィックスまで。サーバーを構成する要素を一貫して制作します。
どの土台にも、置ける。
スクリプト開発
FiveM サーバーへ機能を足すスクリプトを開発します。代表例は端末リソース ukkun_phone_pro。Qbox / QBCore / ESX Legacy / ox_core を実行時に自動判別し、どれも入っていなければ単体で動きます。 必須の依存リソースはありません。
- 自動判別する土台
- 4 種
- SDK の UI 部品
- 30 種
- 標準アプリ
- 11 個
- テスト
- 45 ファイル
原本から、リソースまで。
MLO 制作
インテリアやマップロケーションを 3D で制作します。Blender の原本から FiveM リソースまでを内製で通し、 書き出しの手順は自作のアドオンにまとめてあります。GTA V 向けの入出力には Sollumz（第三者が配布している Blender アドオン）も併用していて、画面右端の縦タブがそれです。当たり判定・オクルージョン・ ライティングの作り込みまで含みます。
シーン全体の統計（Blender の表示）
- オブジェクト
- 39
- 頂点
- 413,197
- 辺
- 803,302
- 面
- 405,092
- 三角形面
- 674,886
選択中の 1 オブジェクト（立方体.005）
- 寸法
- 82.3 × 153 × 38.2 m
- モディファイア
- ワイヤーフレーム ＋ 細分化（カトマルクラーク Lv3）
三角形面 674,886 は細分化モディファイアを適用した状態のビューポート統計で、出荷するメッシュの量ではありません。 寸法は選択中の 1 オブジェクトのもので、建物全体の寸法ではありません。掲載しているのは制作中の画面です。
同じモデルから、図面が出る。
野澤組のツールの 3D プレビューから、三面図と等角図を自動生成します。アプリの「規格系列」設定は JIS（Z 8311 / B 0001）、用紙 A3・横・第一角法・尺度 1:1（現尺）で、表題欄には実測の 2,236 × 4,550 × 1,190 mm が入ります。
3D 書き出しは 11 形式（OBJ / GLB / glTF / STL / PLY / COLLADA / FBX / USD / X3D / VRML / OFF）。
見た目の細部まで。
GFX・グラフィックス編集
ミニマップ・ローディング画面・HUD などの GFX を、サーバー独自のものへ差し替えます。 .gfx は内製のワークベンチで読み、ベクタ形状とシンボルを一覧して差し替えます。 既存リソースの見た目の改修にも対応します。
Discipline
検査が通ることと、検査できていることは違う。
数字が良いことと、正しく測れていることは別です。自分の検査器の欠陥も含めて書きます。
参照実装と値を比べない
参照実装は構造ごと組み直すので、値だけ合わせると壊れます。同じ値かで検査していたときは 572 / 572 一致と報告していましたが、元データと突き合わせる検査に替えて実測すると一致は 0 / 40。こちらは全 ytyp を壊していました。
検査が通ることと、検査できていることは違う
実例が 3 つ。検査器が「対象 0 件・違反 0 件」という無意味な合格を出していた。境界検査に、追記する 13 種類のうち 2 種類しか載っていなかった。ポインタの並びだけ見て中身を見ておらず、同じ内容を 12 組持つはずの領域が 11 組ゼロのまま出ていた。
- 参照実装
- 30,525 組
- こちら
- 33 組
新しい検査は、まず参照実装と元データに当てる
自分の出力に当てる前に、参照実装と元データに当てて違反 0 になることを確かめます。検査器の妥当性を先に立証してから使う、という順番です。
実機は 1 回では判定できない
同じ資産が落ちたり動いたりしました。最低 3 回・毎回サーバー再起動・経路を固定して「n 回中何回」で記録します。実機に置いて初めて見つかった不具合は 8 件（うち 1 件は 2026-08-15 に特定したコリジョンの不具合）。どれ 1 つとして、静的な検証では見つかりませんでした。
良い数字を、自分で下げた
99.37%99.02%
Enhanced 変換のescrow を除く成功率を、99.37%（36,494 / 36,726）から 99.02% へ自分で引き下げました。読めないものを「成功」として通すのをやめた分です。
下げるきっかけは、自分で見つけた水増しでした ── 変換に成功した .ydr / .ydd / .yft のうち大きいほうから 400 件を取り、合計 32,767 頂点を超える 297 件を参照実装に通したところ、28 件（9.4%）は参照実装が上限超過で断りました。当時のこちらは、同じ 28 件を「成功」と報告していました。 .ybn 単体では断っていた上限を、.ydr / .yft に埋め込まれたコリジョンでは見ていなかったためです。
その検査を器によらず同じ上限で行うように直し、全件で数え直すと 208 件。 これを断るようにしたのが、99.37% から 99.02% へ下がった中身です。 断った側を参照実装と突き合わせた 73 件は、73 件とも同じ判断でした。
確定しているのはここまでです。断ったファイルが実機で本当に読めないかどうかは、実機では確かめていません （参照実装が同じ理由で断るところまでの確認です）。標本は大きいほうから 400 件なので、 これより小さいファイルは調べていません。
Measuredこの節で測ったもの ── 参照実装との突き合わせ（2026-08-11 実測）。当時「成功」と報告していた大きいファイル 400 件のうち、合計 32,767 頂点を超える 297 件を参照実装に通し、28 件が上限超過で断られました （内訳：頂点数超過 12 件・BVH のプリミティブ数超過 16 件）。同じ原因を全件で数えると 208 件で、現在はこれを変換前に断ります。
Status
いま、どこまで出来ているか。
誇張のかわりに状態を書きます。どこまで信じてよいかを、読む側で判断できるように。
- 提供中
リソースの走査・検査・修復・変換（Legacy）
ブラウザ版の検出ルール 32 種／デスクトップ版のリソース信頼性監査 18 種・サーバー起動チェック 8 種。数えかたが違うため、合算せず分けて掲載しています
- 提供中
3D モデルの書き出し
11 形式（OBJ / GLB / glTF / STL / PLY / COLLADA / FBX / USD / X3D / VRML / OFF）
- 研究中
.ytyp / .ymap / .ybn の Enhanced 変換
実機で動作を確認
- 未解決
.ydr の Enhanced 変換
コリジョン付きの単体プロップは実機で動作（このページの 8 バイト）。大規模 MLO は落ちる。単一ファイルの欠陥ではなく本数の効果で、.ydr 125 本のうち 16 本までは動き 31 本で止まる。原因がこちらの出力側にあることは確定、真因は未特定
潰した仮説 8 件を見る - 未解決
.ytd の Enhanced 変換
読み込まれるがテクスチャが真っ黒。見立てはあるが未修正
- 未確認
.ydd の Enhanced 変換
.ydr と同じ経路だが実機未確認
- 対応しない
.yft の Enhanced 変換
フラグメント構造が未解読のため、変換を断っている
- 研究中
Blender を使わない .ydr の直接生成
内製のリーダーでの読み戻しまで確認。実機検証の記録は無い
- 対応しない
escrow（FiveM の有料リソース保護）
検出して知らせるだけ。復号・回避は行わない
Measuredこの節で測ったもの ── 書き換える動作の既定値。書き換えを指示せずに 10 動作を全実行し、前後の SHA-256 が 14 件とも一致しました（変化 0）。既定では何も書き換わりません。
Contact
調べるところから、ご相談ください。
- 相談
- 要件の整理
- 設計・お見積り
- 実装・検証
- 納品・改修
期間と費用は規模により異なります。まず要件を整理したうえでお見積りします。 「動くはずのものが動かない」「落ちるが理由が分からない」という段階からのご相談も承ります。
掲載内容についての注意
- 掲載している数値は、いずれも野澤組のデータセットでの実測値です（2026-08〜2026-09-01 時点）。対象件数と測定条件を併記しています。第三者による測定ではありません。
- WinDbg の画面は、上端のタイトルバーと、ダンプの絶対パスが写る範囲を切り落とした以外は無加工です。同じ節に載せている等幅テキストは、その画面からの書き写しで、値は加工していません。
- 停止の判定条件として載せている 12 行は、手元の記録（int 3 の手前を ub で取った出力）からの書き起こしです。並べているスクリーンショットはその停止位置の直後（u）で、別の範囲です。
- パーツ検出のデモは、野澤組のツールが実際に出力した detections.json（28 件）の座標をそのままレンダに重ねたものです。図解ではありません。掲載しているレンダは素の出力 2,852 × 796 を 1/2 に縮めたもので、座標は正規化されているため寸法によらず一致します。
- コリジョン木の図は、先頭 0x30 バイトのレーンの意味だけを描いたものです。実際に落ちたファイルから読み出したバイト列は載せていません。
- 研究段階・未解決の項目は、そのように明記しています。到達点は変わります。掲載している画面は開発中のものを含み、実際の表示や項目は変更される場合があります。第三者が配布しているリソース名・サーバー名・その配布 URL・作業用の絶対パスは、切り取るか伏せています（FiveM 公式のシンボルサーバの URL は、どこからシンボルを取ったかの出典なので伏せていません）。
- 逆解析は、野澤組の製品の相互運用と、自分の出力が実機で落ちる理由の調査のために行っています。読み取るのは形式という観測できる事実だけで、他社ツールのコードを実装へ移植することはありません。
- FiveM の有料リソース保護（escrow）の復号・回避は行いません。検出して知らせるだけです。野澤組のツールの静的解析はヒューリスティックであり確定判定ではありません。無検出は安全の保証ではありません。解析は端末の中で行い、解析するファイルは外へ送りません（ログイン・更新の確認・フィードバックの送信と、利用者が選んだ AI 補助・外部連携のときは通信します）。