ちーぎゅうのブログ一覧

前回は、

**「マップ変更とプログラム変更って何が違うの？」**

という話を書きました。

マップ変更は、

もともとECUの中にある設定値を変える作業。

プログラム変更は、

ECUが、

「どんな条件で、何を判断して、どう動くか」

その処理自体を変えたり、

新しく追加したりする作業。

という話でした。

今回は、

じゃあその、

**ECUのプログラムって、どうやって読むの？**

という話です。

ここで出てくるのが、

**逆アセンブル**

と、

**Ghidra**

です。

名前だけ見ると一気に難しくなった感じがします。

自分も最初は、

「急に何の話？」

ってなりました。

でも、

やってること自体は、

そんなに意味不明ではありません。

---

## ECUの中のプログラムは、そのままじゃ読めない

前に書いた通り、

ECUのROMを読み出すと、

中には大量のバイナリデータが入っています。

つまり、

人間が普通に読める、

「アクセルが50％以上なら点火を遅らせる」

みたいな文章が書いてあるわけではありません。

CPUが理解できる形の命令が、

数字として並んでいます。

人間からすると、

そのまま見てもかなり分かりにくいです。

そこで、

その機械向けの命令を、

人間が追いやすい形に変換して見る必要があります。

その作業の一つが、

**逆アセンブル**

です。

---

## 逆アセンブルって何？

かなり簡単に言うと、

**CPUが実行する機械語を、人間が読める命令表現に戻して見ること**

です。

例えば、

ROMの中では、

ただの数字の並びにしか見えない部分でも、

逆アセンブルすると、

「この値を読み込む」

「この値と比較する」

「条件が合えば別の場所へ移動する」

「この場所に値を書き込む」

みたいな処理として見えるようになります。

もちろん、

日本語で、

「ここはフラットフットシフトです」

みたいに出てくるわけではありません。

そこまで親切ではないです。

でも、

**CPUが何をしているか**

を追える形にはなります。

---

## そもそも「アセンブリ」って何？

逆アセンブルの前に、

アセンブリという言葉があります。

アセンブリは、

CPUが実行する命令を、

人間が扱いやすい短い命令で表したものです。

例えば、

「値を読み込む」

「足す」

「引く」

「比較する」

「別の場所へ移動する」

みたいな命令があります。

実際にはCPUごとに命令の書き方は違います。

でも、

考え方としては、

**コンピューターにやってほしいことを、一個ずつ命令で書く**

という感じです。

---

## 逆アセンブルすると何が見えるの？

例えば、

ある処理の中で、

エンジン回転数を読み込んで、

ある数値と比較して、

条件を満たしていれば、

別の処理へ進む。

そんな流れがあるとします。

逆アセンブルすると、

その流れを、

命令単位で追えるようになります。

すると、

「この値を使って何か比較してるな」

「この条件で分岐してるな」

「ここで別の場所の値を読み込んでるな」

みたいなことが分かってきます。

これを積み重ねて、

少しずつ、

「この処理は何のためのものなんだろう」

と考えていきます。

---

## Ghidraって何？

Ghidraは、

こういうバイナリ解析や逆アセンブルをするためのソフトです。

もともとはアメリカ国家安全保障局が開発したソフトで、

現在は一般にも公開されています。

かなり高機能で、

いろんな種類のプログラム解析に使われています。

ECU解析でも、

ROMの中にあるプログラム部分を、

人間が追いやすい形で見るために使えます。

---

## GhidraにROMを入れると、全部分かるの？

ここは大事です。

**そんなに甘くないです。**

ROMファイルをGhidraに入れた瞬間、

全部の意味が自動で分かるわけではありません。

Ghidraは、

「この部分は命令として読めそう」

「この場所は関数っぽい」

「ここからここへ処理が飛んでる」

みたいな解析を手伝ってくれます。

でも、

「これは車速です」

「これはクラッチ信号です」

「これは点火補正です」

みたいな意味までは、

自動では分からないことが多いです。

そこは、

人間側で考える必要があります。

---

## 関数って何？

Ghidraを使うと、

**関数**

という言葉もよく出てきます。

関数は、

簡単に言うと、

**あるまとまった仕事をする処理のかたまり**

です。

例えば、

「センサー値を読む処理」

「点火時期を計算する処理」

「異常を判定する処理」

「何かの補正を計算する処理」

みたいに、

ある目的ごとに処理がまとまっていることがあります。

Ghidraでは、

こういう処理のかたまりを探しながら、

どの関数が、

何をしているのかを追っていきます。

---

## 分岐って何？

ECUのプログラムは、

上から順番に全部同じように動くわけではありません。

条件によって、

進む道が変わります。

例えば、

冷却水温が低いなら、

この処理。

高いなら、

別の処理。

アクセルを踏んでいるなら、

こっち。

踏んでいないなら、

あっち。

みたいに、

条件によって処理が分かれます。

これを、

**分岐**

と呼びます。

BEASTで新しい機能を作る時も、

この分岐がかなり重要です。

---

## 例えばフラットフットシフトなら

フラットフットシフトを作るとしたら、

単純に、

「クラッチを踏んだら点火を切る」

ではありません。

例えば、

・アクセルを一定以上踏んでいる
・車速が一定以上
・エンジン回転数が一定以上
・クラッチを踏んだ
・異常状態ではない

こういう条件を順番に確認して、

全部成立した時だけ、

専用の処理へ進む。

という形になります。

つまり、

ECUの中では、

条件判定と分岐の組み合わせで、

動きを作っていくことになります。

---

## 「値を読む」ってどういうこと？

前回までに、

RAMには、

今のエンジン回転数や、

アクセル開度、

車速、

いろんな値がある、

という話をしました。

プログラムは、

必要な時に、

そういう値を読み出して使います。

例えば、

今のエンジン回転数をRAMから読み込む。

設定値と比較する。

条件に合えば次の処理へ進む。

という流れです。

Ghidraでは、

「どのアドレスから値を読んでいるか」

を追うことができます。

そこから、

「この値って何だろう？」

と考えていきます。

---

## 逆に「書き込む」処理もある

プログラムは、

値を読むだけではありません。

計算した結果を、

RAMへ書き込むこともあります。

例えば、

補正後の値、

現在の状態、

何かの判定結果、

制御中かどうか、

そういう情報を、

別の場所に保存することがあります。

なので、

ある値の意味を調べる時は、

「どこから読まれてるか」

だけじゃなく、

**「どこで書き込まれてるか」**

を見ることも重要です。

---

## 1個の値だけ追っても分からないことがある

例えば、

あるRAMアドレスが、

車速っぽい値だったとします。

でも、

その値だけ見ても、

本当に車速か分からない。

そこで、

その値を使っている関数を追います。

もし、

その値が、

速度制限、

走行中判定、

ギア関連の処理、

みたいな場所で使われていたら、

「車速の可能性が高そう」

となります。

さらに、

実車ログと比べて、

値の変化も一致すれば、

もっと確信が強くなります。

こうやって、

**一つの証拠だけで決めずに、複数の情報をつなげていく**

のが解析です。

---

## Ghidraが便利なのは「つながり」を追えること

Ghidraの強みの一つが、

「この関数をどこから呼んでいるか」

「この値をどこで使っているか」

「この処理の次にどこへ進むか」

みたいな、

プログラムのつながりを追えることです。

つまり、

単に数字を眺めるだけではなく、

**処理の流れを見ることができる**

ということです。

---

## 逆アセンブルしただけで正解とは限らない

ここもかなり重要です。

Ghidraが表示した内容が、

全部そのまま正解とは限りません。

最初の設定が間違っていたり、

CPUの種類を間違えたり、

メモリの配置を間違えたりすると、

解析結果もおかしくなります。

そもそも、

データ領域をプログラムとして誤認することもあります。

なので、

Ghidraでそれっぽく表示されたから、

「これで確定」

とはできません。

---

## CPUの種類も重要

ECUの中には、

実際にプログラムを実行するCPUがあります。

CPUによって、

使える命令や、

命令の読み方が違います。

なので、

逆アセンブルする時は、

対象ECUが、

どんなCPUを使っているのか、

ちゃんと合わせる必要があります。

違うCPUとして読ませれば、

当然、

意味不明な結果になります。

この辺も、

ECU解析ではかなり重要な確認項目です。

---

## BEASTではGhidraをどう使ってるの？

BEASTで新しい制御を作るには、

既存のECUが、

どんな流れで処理しているかを理解する必要があります。

例えば、

クラッチ信号が、

どこで読まれているのか。

アクセル開度が、

どこで使われているのか。

点火制御が、

どんな流れで計算されているのか。

走行モードの状態が、

どこで判定されているのか。

そういうものを、

Ghidraで追っていきます。

---

## でもGhidraだけでは足りない

Ghidraはかなり強力です。

でも、

Ghidraだけで全部分かるわけではありません。

・RomRaiderの定義
・ECUログ
・純正ROMとの比較
・別ROMとの比較
・サービス資料
・実車の動き
・既存の解析情報

こういうものと組み合わせて、

初めて意味が見えてくることがあります。

だからNEXUSでは、

一つのソフトだけを信用するのではなく、

複数の証拠を合わせて判断しています。

---

## AIはここで何をしてるの？

AIには、

逆アセンブル結果を整理させたり、

処理の流れをまとめさせたり、

条件分岐を読み解く手伝いをさせたりしています。

大量のコードを追う時は、

かなり助かります。

ただし、

ここでも、

**AIが意味を断定しただけでは採用しません。**

例えば、

AIが、

「これは車速の処理です」

と言ったとしても、

それだけでは証拠になりません。

実際の参照先、

RAMの値、

ログ、

周辺関数、

既存資料、

そういうものと照合して、

本当にそうなのかを確認します。

---

## ここから解析が一気に面白くなる

ROMを最初に開いた時は、

ただの数字の山です。

でも、

逆アセンブルして、

関数を見つけて、

値の読み書きを追って、

条件分岐を見ていくと、

少しずつ、

「ECUが何を考えてるのか」

が見えてきます。

もちろん、

本当にECUが考えてるわけじゃないです。

ただ、

プログラムの判断の流れが、

少しずつ見えてくる。

ここが、

個人的にはかなり面白いところです。

---

## ここまでのまとめ

今回の話をかなり簡単にまとめると、

**逆アセンブル**

CPU向けの機械語を、

人間が追いやすい命令表現にして見ること。

**Ghidra**

バイナリ解析や逆アセンブルをするためのソフト。

**関数**

あるまとまった仕事をする処理のかたまり。

**分岐**

条件によって、

進む処理を変える仕組み。

です。

そして一番大事なのは、

**Ghidraを開いたら全部分かるわけではない**

ということです。

Ghidraは、

あくまで、

ECUの中身を読むための強力な道具。

そこから意味を確認していくのが、

実際の解析です。

次回は、

**「関数ってどうやって見つけるの？」**

という話に進もうと思います。

ECUの中には、

大量の処理があります。

その中から、

「これは何の処理なんだろう」

と意味をつけていく。

その時に、

何を見て、

どうやって候補を絞っていくのか。

そこを書いていきます。

前回は、

**「バイナリって何？」**

という話を書きました。

ROMを開くと、

人間が読める文章ではなく、

16進数の数字が大量に並んでいます。

そして、

その数字を見ただけでは、

何のデータなのかは分からない。

どこにあるのか、

どう使われているのか、

どう計算されているのか、

そこまで見ていく必要がある、

という話でした。

今回はそこから一歩進んで、

**ECUチューンって全部同じなの？**

という話を書いていきます。

---

## ECUチューンって聞くと全部同じに見える

ECUチューンって聞くと、

「パソコンつないでデータ変えるやつ」

みたいに見えると思います。

実際、

外から見ればそんな感じです。

でも中でやっていることは、

全部同じではありません。

大きく分けると、

**もともとある設定値を変える作業**

と、

**ECUのプログラムそのものの動きを変える作業**

があります。

この2つは、

似ているようでかなり違います。

---

## まずは「マップ変更」

比較的イメージしやすいのが、

マップ変更です。

前にも少し書きましたが、

マップは、

**条件ごとに使う数値を並べた表**

みたいなものです。

例えば、

エンジン回転数がこのくらい。

エンジン負荷がこのくらい。

その時の点火時期はこのくらい。

みたいな形です。

ほかにも、

燃料、

ブースト、

スロットル、

各種補正、

いろんな設定があります。

こういう、

**もともとECUの中に用意されている設定値を変更する**

のが、

マップ変更です。

---

## 例えばブーストを変える場合

例えば、

純正状態よりブースト目標を少し変えたいとします。

ECUの中に、

ブースト制御用の目標値が用意されていて、

そこを変更できるなら、

その数値を変更します。

つまり、

ECUがもともと持っている、

「ブーストをこう制御する」

という仕組み自体はそのままです。

変えるのは、

**その仕組みの中で使う設定値**

です。

これは、

家に例えるなら、

部屋の温度設定を変えるようなものです。

エアコンそのものを作り直すわけではありません。

---

## 点火や燃料も同じ

点火時期を変更したい。

燃料を変更したい。

こういう場合も、

ECUの中にもともとあるマップを使えるなら、

その数値を変更します。

なので、

一般的なECUセッティングでは、

こういう既存マップの調整がかなり重要です。

ただし、

当然ですが、

数字を変えればいいだけ、

という意味ではありません。

点火時期を進めすぎれば、

ノッキングの危険があります。

燃料を薄くしすぎれば、

エンジンに負担がかかる可能性があります。

ブーストも、

上げればいいわけではありません。

なので、

マップ変更も十分難しいです。

---

## じゃあ「プログラム変更」って何？

ここから少し話が変わります。

プログラム変更は、

**ECUがどう判断して、どう動くか**

その仕組み自体を変える作業です。

例えば、

純正ECUに、

「この条件になったら、この処理をする」

という機能が、

最初から存在していないとします。

その場合、

マップの数字をいくら変更しても、

存在しない処理は動きません。

なので、

新しい条件判定や、

新しい制御処理を追加する必要があります。

これが、

プログラム変更です。

---

## フラットフットシフトを例にすると分かりやすい

例えば、

フラットフットシフトを追加したいとします。

やりたいことは、

アクセルを踏んだままシフトアップする時に、

一時的にエンジン出力を落として、

変速を助けることです。

でも純正ECUの中に、

「この条件ならフラットフットシフトを動かす」

という処理が存在しなければ、

設定値を書き換えるだけでは実現できません。

そこで、

例えば、

・アクセルを一定以上踏んでいる
・クラッチを踏んだ
・車速が一定以上
・エンジン回転数が一定以上
・異常状態ではない

こういう条件を確認して、

条件がそろった時だけ、

一時的に点火や出力を制御する。

という新しい流れを作る必要があります。

これは、

単なるマップ変更ではありません。

---

## オートブリッピングも同じ

オートブリッピングも、

純正ECUにそのまま機能があるとは限りません。

シフトダウン時に、

自動でスロットルを開いて、

エンジン回転数を合わせたい。

そうすると、

・ブレーキを踏んでいるか
・クラッチを踏んだか
・アクセルは踏んでいないか
・車速はどのくらいか
・エンジン回転数はどのくらいか
・どのタイミングでスロットルを開くか
・どのくらい開くか

みたいな判断が必要になります。

これも、

単純に数字を1つ変えれば完成、

というものではありません。

---

## 家に例えると分かりやすい

かなり雑に例えると、

マップ変更は、

**エアコンの設定温度を変える**

ようなものです。

一方で、

プログラム変更は、

**人が部屋に入った時だけ自動でエアコンをつける仕組みを新しく追加する**

ようなものです。

設定を変えるのと、

動き方そのものを追加するのでは、

やっていることが違います。

ECUでも同じです。

---

## どっちが上とか下ではない

ここは誤解されやすいですが、

プログラム変更の方が偉い、

という話ではありません。

マップ変更にも、

かなりの知識が必要です。

むしろ、

実際にエンジンを安全に動かす上では、

燃料、

点火、

ブースト、

各種補正、

こういう既存マップの調整が非常に重要です。

プログラム変更をして、

新しい機能を追加できたとしても、

基本のセッティングが適当なら意味がありません。

なので、

**マップ変更とプログラム変更は、役割が違う**

と考えた方がいいです。

---

## BEASTでやろうとしているのは両方

BEASTでは、

既存の設定値を変更するだけではなく、

場合によっては、

新しい条件判定や、

新しい制御処理を追加する必要があります。

つまり、

**既存の設定を使う部分**

と、

**新しい処理を作る部分**

の両方があります。

ここが、

一般的なECUセッティングだけでは終わらない理由です。

---

## でもプログラム変更は簡単じゃない

プログラムを変更するには、

まず、

純正ECUが今どんな処理をしているのか、

理解する必要があります。

どこからセンサー値を読んでいるのか。

どこで条件判定しているのか。

どこで点火やスロットルを制御しているのか。

どこなら新しい処理を追加できるのか。

追加した処理が、

別の処理とぶつからないか。

処理する時間は足りるのか。

メモリ領域は足りるのか。

異常時にどうなるのか。

考えることが一気に増えます。

だから、

BEASTでは、

いきなり書き換えるのではなく、

NEXUSで解析と確認を進めています。

---

## 「空いてる場所に書けばいい」では済まない

ROMの中を見ていると、

使われていなさそうな場所が見つかることがあります。

でも、

見た目が空いてるから、

「ここに新しいプログラム入れよう」

では危険です。

本当に使われていないのか。

別の用途で参照されていないか。

書き換えても問題ないのか。

プログラムからそこへ安全に移動できるのか。

元の処理へ戻れるのか。

確認する必要があります。

見た目が空いているのと、

**安全に使える領域であること**

は別です。

---

## 新しい機能を作ると「競合」も出てくる

これもBEASTでかなり重要な部分です。

例えば、

フラットフットシフトが、

点火を制御したい。

ローンチコントロールも、

点火を制御したい。

バブリングも、

点火を制御したい。

もし全部が、

同じタイミングで、

「自分の設定を使え」

ってなったらどうするのか。

当然、

優先順位を決める必要があります。

どの機能を優先するのか。

どの条件なら機能を禁止するのか。

異常時は全部止めるのか。

こういう仕組みまで考える必要があります。

単体で動いたから完成、

ではないんです。

---

## だから安全制御が必要になる

新しい機能を追加するなら、

「動かす条件」

だけじゃなく、

**動かしてはいけない条件**

も必要です。

例えば、

センサー値がおかしい。

必要な信号が取れない。

エンジン状態がおかしい。

条件判定が成立しない。

そんな時に、

無理やり機能を動かすのは危険です。

なので、

何かおかしい時は、

追加機能を止めて、

できるだけ純正に近い制御へ戻す。

そういう考え方も必要になります。

---

## NEXUSでは「できそう」と「できる」を分けている

解析をしていると、

「これならできそう」

という場所は結構出てきます。

でも、

できそう、

と、

本当に使える、

は別です。

必要な信号が確認できてるか。

その信号の意味は確定してるか。

処理を追加できる場所はあるか。

元の動作を壊さないか。

実車で確認できるか。

そこまで確認して、

やっと実装候補になります。

なのでNEXUSでは、

**推測の段階**

と、

**確認できた段階**

をなるべく分けて管理しています。

---

## ECUチューンを一言でまとめるのは難しい

ECUチューンという言葉だけだと、

全部同じ作業に見えます。

でも実際には、

既存の設定値を変更するもの。

既存の制御を利用するもの。

プログラムの流れを変更するもの。

新しい処理を追加するもの。

いろんな種類があります。

だから、

「ECU書き換えしてあります」

だけでは、

何をしているかまでは分かりません。

---

## ここまでのまとめ

今回の話をかなり簡単にまとめると、

**マップ変更**

もともとECUの中にある、

燃料、

点火、

ブースト、

補正値などの設定を変更する作業。

**プログラム変更**

ECUが、

どんな条件で、

何を判断して、

どう動くか、

その処理自体を変更したり追加したりする作業。

です。

どちらもECUチューンですが、

やっていることは違います。

そしてBEASTでは、

単純なマップ変更だけではなく、

必要に応じて、

**ECUの動き方そのものを追加・変更する**

ことを目標にしています。

次回は、

**「じゃあECUのプログラムって、どうやって読むの？」**

という話に進みます。

そこで出てくるのが、

**逆アセンブル**

と、

**Ghidra**

です。

今まで見てきた、

ROM、

RAM、

アドレス、

バイナリ。

この辺が、

やっと全部つながってきます。

数字の山だったROMを、

どうやって、

「ここで何をしているプログラムなのか」

という形まで持っていくのか。

次はそこを書いていきます。

前回は、

**「アドレスって何？」**

という話を書きました。

アドレスは、

ECUの中で、

**データやプログラムが置かれている場所を示す住所**

みたいなものです。

今回は、そのアドレスの先に実際に入っているデータの話です。

ECUのROMを読み出してファイルとして保存すると、

中身は普通の文章みたいには見えません。

数字や記号が大量に並んでいて、

最初に見ると、

**「これのどこを読めばいいの？」**

ってなります。

自分も最初はそうでした。

今回は、

その正体である

**バイナリ**

と

**16進数**

について書いていきます。

---

## まず「バイナリ」って何？

バイナリは、

簡単に言うと、

**コンピューターが扱う形のデータ**

です。

コンピューターの中では、

最終的に、

0

と

1

の組み合わせで情報を表します。

これを、

**2進数**

と呼びます。

例えば、

スイッチがOFFなら0。

ONなら1。

みたいな感じです。

実際のコンピューターは、

こういう0と1の組み合わせを大量に使って、

数字、

文字、

画像、

音、

プログラム、

いろんなものを表しています。

ECUの中身も同じです。

---

## ROMファイルもただのデータのかたまり

前回までに書いたように、

ROMの中には、

・プログラム
・設定値
・各種マップ
・補正データ

みたいなものが入っています。

でも、

ROMファイルの中に、

「ここは点火マップです」

「ここは回転数です」

「ここはクラッチ信号です」

みたいに日本語で書いてあるわけではありません。

実際には、

コンピューター用のデータが並んでいるだけです。

だから、

ROMを読み出しただけでは、

何がどこにあるのかは分かりません。

---

## じゃあ16進数って何？

2進数は、

0と1だけで表します。

でも、

人間が見るにはかなり読みにくいです。

例えば、

1101011010110010

みたいな数字が延々と並んでいたら、

正直かなりしんどいです。

そこでよく使われるのが、

**16進数**

です。

16進数では、

0〜9

に加えて、

A〜F

を使います。

つまり、

0
1
2
3
4
5
6
7
8
9
A
B
C
D
E
F

まで使って、

16個の数字を表します。

---

## なんでわざわざ16進数を使うの？

理由は、

**2進数をかなり短く書けるから**

です。

例えば、

2進数の

1111

は、

16進数だと

F

です。

2進数の

11111111

は、

16進数だと

FF

になります。

かなり短くなります。

コンピューターのデータを扱う時は、

2進数より16進数の方が人間には見やすいので、

ECU解析でも16進数がよく使われます。

---

## 「FF」とか「00」が大量に出てくる理由

ROMを16進数で表示すると、

例えば、

00
3A
FF
12
8C
7D

みたいな値が並びます。

この一つ一つが、

データの一部です。

よく見るのが、

**00**

や

**FF**

です。

これは珍しいものではなく、

何も使っていない領域だったり、

初期値だったり、

データの一部だったり、

いろんな意味で出てきます。

なので、

「FFがあるから何か特別」

とは限りません。

大事なのは、

**周りのデータや、プログラムからどう使われているか**

を見ることです。

---

## 1バイトって何？

ここで、

**バイト**

という言葉も出てきます。

1バイトは、

一般的には、

**8個の0と1をまとめた単位**

です。

8ビットとも言います。

2進数なら、

00000000

から

11111111

まで表せます。

これを16進数で書くと、

00

から

FF

までです。

つまり、

ROMを16進数で見る時に並んでいる、

00

3A

FF

みたいな2桁の数字は、

1バイト分のデータを表していることが多いです。

---

## でも「1バイト＝1つの意味」ではない

ここもかなり重要です。

例えば、

3A

という1バイトがあったとしても、

それだけで、

「これは58という意味」

とは限りません。

そのまま数字として使うかもしれない。

別の値と組み合わせるかもしれない。

温度を表しているかもしれない。

補正をかけて使うかもしれない。

プログラムの命令の一部かもしれない。

つまり、

**同じ数字でも、使われ方によって意味が変わります。**

ここがECU解析の難しいところです。

---

## 2バイト、4バイトで使うこともある

ECUの中の値は、

1バイトだけで表すとは限りません。

2バイト、

4バイト、

それ以上をまとめて、

一つの数字として使うこともあります。

例えば、

エンジン回転数のように、

0〜255だけでは足りない数字を扱う場合、

複数のバイトを組み合わせて使います。

そうすると、

もっと大きな数字を表せます。

---

## 並び順にも違いがある

さらにややこしいのが、

複数バイトの数字を、

どの順番で保存するかです。

例えば、

ある2バイトのデータがあった時に、

上位側から並べるのか、

下位側から並べるのか、

という違いがあります。

こういう並び方を、

**エンディアン**

と呼びます。

かなり急に専門用語っぽくなりましたが、

今は、

**複数のバイトをまとめて使う時は、並び順にもルールがある**

くらいで大丈夫です。

この辺も、

実際にROMを読む時にはかなり重要になってきます。

---

## 数字がそのまま実際の値とは限らない

例えば、

ROMの中に、

100

という数字が入っていたとします。

でも、

実際の意味が、

100℃

とは限りません。

0.5倍して使うかもしれない。

2倍して使うかもしれない。

一定の数字を足したり引いたりするかもしれない。

つまり、

ECUの中では、

保存されている数字を、

そのまま使わずに、

計算して実際の値に直すことがあります。

この計算ルールを理解しないと、

ROMの数字を見ても、

本当の意味は分かりません。

---

## RomRaiderが分かりやすく見せてくれる理由

RomRaiderみたいなソフトを使うと、

16進数の数字そのものではなく、

点火時期、

燃料、

回転数、

負荷、

みたいな形で見られることがあります。

これは、

どの場所に、

どんなデータが入っていて、

どう計算すれば人間が分かる値になるか、

という情報があらかじめ分かっているからです。

つまり、

RomRaiderが魔法でROMを理解しているわけではありません。

「この場所はこういう意味」

という定義があるから、

人間に分かりやすく表示できています。

---

## 定義がない場所はどうするの？

ここからが解析の世界です。

定義されていない場所は、

そのままでは意味が分かりません。

そこで、

・周りのデータを見る
・プログラムから参照されている場所を追う
・似たROMと比較する
・実車ログと比べる
・既存の資料と照合する

みたいなことをして、

意味を少しずつ絞っていきます。

NEXUSでやっているのも、

こういう作業の積み重ねです。

---

## バイナリエディターって何？

ROMの中身を、

16進数で直接見るためのソフトを、

**バイナリエディター**

と呼びます。

バイナリエディターを開くと、

左側にアドレス。

中央に16進数のデータ。

右側に文字として解釈できる部分。

みたいな表示になるものが多いです。

最初に見ると、

かなり意味不明です。

でも、

前回のアドレスの話と、

今回の16進数の話が分かれば、

少し見方が変わります。

左側は、

「場所」

中央は、

「そこに入っているデータ」

です。

それだけでも、

最初よりかなり分かりやすくなります。

---

## Ghidraでは同じデータを別の見方で見る

バイナリエディターは、

ROMの中に入っているデータを、

そのまま見るのが得意です。

一方でGhidraは、

そのデータの中から、

**プログラムとして実行される部分を解析する**

のが得意です。

つまり、

同じROMファイルを見ていても、

見方が違います。

バイナリエディターでは、

数字の並びとして見る。

Ghidraでは、

CPUが実行する命令として見る。

この違いです。

---

## BEASTでは両方必要になる

BEASTでやろうとしていることは、

単純にマップの数字を変えるだけではありません。

新しい条件を追加したり、

既存の処理を利用したり、

場合によっては新しい処理を組み込む必要があります。

そのため、

データとしてROMを見るだけでなく、

**そのデータがプログラム上でどう使われているのか**

まで追う必要があります。

だから、

バイナリ解析と、

プログラム解析、

両方が必要になります。

---

## 見えている数字だけで判断しない

例えば、

ある場所に、

01

という数字があったとします。

それを見て、

「ONだな」

と決めつけるのは危険です。

01が、

単純なON/OFFの1かもしれない。

何かの番号かもしれない。

プログラム命令の一部かもしれない。

別のデータと組み合わせるものかもしれない。

なので、

**数字がそれっぽく見える**

というだけでは意味を確定できません。

NEXUSでも、

この辺はかなり慎重に扱っています。

---

## ここまでのまとめ

今回の内容をかなり簡単にまとめると、

**バイナリ**

コンピューターが扱う形のデータ。

**2進数**

0と1だけを使って表す数字。

**16進数**

2進数を人間が見やすい形に短くまとめて表す方法。

**1バイト**

一般的には8ビット分のデータ。

16進数では、

00〜FF

で表せます。

そして一番重要なのは、

**ROMに並んでいる数字を見ただけでは、その意味は分からない**

ということです。

どこにあるか。

どう使われているか。

どんな計算をされているか。

周りの処理はどうなっているか。

そこまで見て、

初めて意味が分かってきます。

次回は、

**「マップ変更とプログラム変更って何が違うの？」**

という話を書こうと思います。

ECUチューンというと、

全部同じように見えます。

でも、

設定されている数字を変えるのと、

ECUが動く仕組みそのものを変えるのでは、

難しさが全然違います。

ここが分かると、

BEASTで何をやろうとしているのかも、

かなり見えてくると思います。

前回は、

**「RAMって何？」**

という話を書きました。

ROMが、

**ECUの中に保存されているプログラムや設定データ**

だとしたら、

RAMは、

**今この瞬間に使っているデータを一時的に置いておく場所**

という話でした。

今回は、そのROMやRAMの中身を見ていく時に必ず出てくる、

**アドレス**

について書いていきます。

ECU解析を始めると、

いきなり、

0x00000000

0x12345678

みたいな数字が大量に出てきます。

最初は正直、

「なんなんこれ」

ってなります。

でも実際は、そんなに難しく考えなくて大丈夫です。

アドレスは簡単に言うと、

**データが置いてある場所を示す住所**

です。

---

## アドレス＝住所

例えば家なら、

東京都○○区○○町1-2-3

みたいに住所があります。

それと同じで、

コンピューターの中でも、

「このデータはここにある」

という場所を区別する必要があります。

その場所を示す番号が、

**アドレス**

です。

例えば、

ある場所にエンジン回転数の値が入っていて、

別の場所に車速の値が入っている。

さらに別の場所に点火マップがある。

そういう時に、

「どこのデータを見ればいいのか」

を区別するために使います。

---

## ROMにもRAMにもアドレスがある

アドレスは、

ROMにもRAMにもあります。

ROMなら、

保存されているプログラムや設定データの場所。

RAMなら、

走行中に使っている値の場所。

という感じです。

例えば、

ROMのあるアドレスに点火マップがある。

RAMのあるアドレスに現在のエンジン回転数が入っている。

こういう形で、

「何がどこにあるか」

を追いかけていきます。

---

## なんで16進数で書いてあるの？

ECU解析をしていると、

アドレスはだいたい、

**16進数**

で書かれています。

例えば、

0x1000

0x1A20

0x800000

みたいな形です。

ここで出てくる、

**0x**

は、

「これは16進数ですよ」

という意味で付けられることが多いです。

普段使う数字は、

0から9までの10個を使うので、

10進数です。

16進数は、

0から9に加えて、

A、B、C、D、E、F

を使います。

例えば、

10進数の10は、

16進数ではA。

15はF。

16になると、

10と書きます。

最初はややこしく見えますが、

ECU解析では16進数が当たり前に出てきます。

ただ、

最初から全部暗算できる必要はありません。

大事なのは、

**「アドレスは場所を示す番号」**

と分かっていれば十分です。

---

## なんで普通の数字じゃダメなの？

別に10進数でも表せます。

でも、

コンピューターの中では、

2進数との相性がいいので、

16進数がよく使われます。

2進数は、

0と1だけで表す数字です。

コンピューターは内部的に、

この0と1を使って動いています。

16進数は、

この2進数を短くまとめて見やすくできるので、

プログラムやメモリの場所を扱う時によく使われます。

人間側からすると、

0と1が何十桁も並ぶより、

16進数の方がまだマシです。

まだマシなだけです。

---

## アドレスが分かると何ができるの？

アドレスが分かると、

「どこに何があるか」

を追えるようになります。

例えば、

この場所にエンジン回転数がある。

この場所にアクセル開度がある。

この場所に点火マップがある。

この場所に制御プログラムがある。

こういう情報が分かってくると、

ECUの中身をかなり具体的に見られるようになります。

逆に、

アドレスが分からないと、

大量のデータの中から目的のものを探せません。

なので、

ECU解析ではかなり基本的な考え方です。

---

## でも「アドレスが分かった＝意味が分かった」ではない

ここはかなり大事です。

例えば、

ある場所に、

1234

という数字が入っていたとします。

その場所のアドレスが分かっても、

その1234が何を意味するかは、

別問題です。

エンジン回転数なのか。

車速なのか。

温度なのか。

何かの補正値なのか。

単位は何なのか。

そのまま1234なのか。

実際には計算して別の値として使うのか。

こういうことを確認しないと、

意味は分かりません。

つまり、

**場所が分かること**

と、

**中身の意味が分かること**

は別です。

---

## 同じ値でも意味が違うことがある

さらにややこしいのが、

同じような数字が何個も出てくることです。

例えば、

100

という数字があっても、

100km/hかもしれない。

100℃かもしれない。

100％かもしれない。

何かの内部計算値かもしれない。

だから、

数字だけ見て、

「これ車速だ」

と決めつけるのは危険です。

前回も書きましたが、

ECU解析では、

**それっぽい**

と、

**確認できた**

を分ける必要があります。

---

## プログラムもアドレスを使って動いている

アドレスは、

データだけじゃなく、

プログラムの場所にも使われます。

例えば、

ECUの中に、

「エンジン回転数を読む処理」

「点火時期を計算する処理」

「異常を判断する処理」

があるとします。

こういう処理にも、

それぞれ場所があります。

プログラムは、

ある場所から別の場所へ移動しながら、

順番に処理を実行していきます。

なので、

Ghidraみたいな解析ソフトでECUの中身を見ると、

アドレスと一緒に、

「この場所では何をしているのか」

を追っていくことになります。

---

## Ghidraを見るとアドレスだらけ

GhidraでECUのプログラムを見ると、

画面の左側に、

アドレスがずらっと並びます。

最初は、

意味不明な数字が大量に並んでいて、

かなり圧があります。

でも、

全部を覚える必要はありません。

大事なのは、

「この処理はどの場所にあるのか」

「このデータはどこから読まれているのか」

「この値はどこに書き込まれているのか」

を追っていくことです。

アドレスは、

そのための目印です。

---

## BEASTでもアドレスはかなり重要

BEASTで新しい制御を追加するには、

既存のECUが、

どこで何をしているのかを把握する必要があります。

例えば、

クラッチ信号を使いたい。

アクセル開度を使いたい。

車速を使いたい。

走行モードを判定したい。

そういう時に、

その情報がECU内部のどこにあるのか。

どこから読み出されているのか。

どの処理で使われているのか。

そこを調べる必要があります。

だから、

アドレスの特定は、

BEASTの機能を作るためのかなり基本的な作業になります。

---

## NEXUSでは「場所だけ」で確定しない

NEXUSでは、

「このアドレスっぽい」

だけでは採用しません。

例えば、

ある場所がアクセル開度っぽく見えても、

実際に値がどう変化するか。

他の処理からどう使われているか。

ログと一致するか。

周辺のコードがどうなっているか。

そこまで確認して、

初めて、

「これはアクセル開度として使えそう」

という判断に近づきます。

アドレスを見つけること自体より、

**その場所の意味を確認すること**

の方が大事です。

---

## ROMアドレスとRAMアドレスは同じもの？

ここは少し注意が必要です。

ROMとRAMでは、

それぞれ別のメモリ領域として扱われます。

なので、

同じようにアドレスが付いていても、

意味は違います。

ROM側のアドレスは、

保存されているプログラムや設定データの場所。

RAM側のアドレスは、

実行中に使う値や計算結果などの場所。

という感じです。

さらに、

実際のECUでは、

メモリの配置やアクセス方法がCPUやECUの設計によって決まっています。

この辺はかなり深い話になるので、

今は、

**ROMにもRAMにも、それぞれ場所を示す住所がある**

くらいで大丈夫です。

---

## アドレスを間違えるとどうなる？

ECU解析で怖いのがここです。

もし、

本当は別の意味を持つ場所なのに、

「ここを書き換えればいい」

と勘違いして変更すると、

想定していない動作になる可能性があります。

設定値ならおかしな制御になるかもしれない。

プログラム部分なら、

処理そのものが壊れる可能性もあります。

なので、

アドレスを見つけたからといって、

すぐに書き換えるわけではありません。

何が置いてある場所なのか。

どこから使われているのか。

変更したら何に影響するのか。

そういう確認が必要です。

---

## ここまでのまとめ

今回の話をかなり簡単にまとめると、

**アドレス**

コンピューターの中で、

データやプログラムが置かれている場所を示す番号。

です。

家の住所と同じようなものだと思えば、

かなり分かりやすいです。

ROMにもアドレスがある。

RAMにもアドレスがある。

プログラムにもアドレスがある。

ただし、

**アドレスが分かっただけでは、その中身の意味までは分からない。**

ここが重要です。

次回は、

**「バイナリって何？ 16進数で見るECUデータ」**

について書こうと思います。

ROMを読み出すと、

人間が普通に読める文章が出てくるわけではありません。

実際には、

大量の数字の並びとして出てきます。

その数字が何を意味しているのか。

どうやって人間が読める形にしていくのか。

そこをできるだけ分かりやすく書いていきます。

前回は、

**「ROMって何？」**

という話を書きました。

ROMは簡単に言うと、

**ECUを動かすためのプログラムや設定データが保存されているもの**

です。

今回はその続きで、

**RAMって何？**

という話です。

ECUを解析していると、

ROMと同じくらい、

RAM

という言葉もよく出てきます。

最初は名前も似てるし、

「結局どっちもデータ入ってる場所でしょ？」

くらいに思ってました。

でも実際は、役割がかなり違います。

---

## RAMって何？

RAMは、

**Random Access Memory**

の略です。

難しく聞こえますが、

ECUの中でいうと、

**今この瞬間に使っているデータを一時的に置いておく場所**

みたいなイメージです。

ROMが、

「保存されているプログラムや設定」

だとしたら、

RAMは、

「今まさに動いている最中のデータ」

に近いです。

---

## 例えばエンジン回転数

エンジンが止まっている時は、

回転数は0です。

エンジンをかければ、

800回転くらいになったり、

アクセルを踏めば、

3000回転、

5000回転、

7000回転、

とどんどん変わります。

この、

**今のエンジン回転数**

みたいな値は、

ずっと同じではありません。

走っている間、

常に変化しています。

こういう値は、

ECUの中で一時的に使う必要があります。

そのためにRAMが使われます。

---

## アクセル開度も同じ

アクセルを踏んでない時は0％付近。

少し踏めば20％。

もっと踏めば50％。

全開ならかなり大きな値になります。

これも走行中ずっと変化します。

ECUは、

今のアクセル開度を見て、

燃料、

点火、

スロットル、

ブースト、

いろんな制御に使います。

なので、

こういう現在の状態を表す値も、

RAM上に置かれて使われます。

---

## RAMにはどんなデータがあるの？

ECUによって違いますが、

例えば、

・エンジン回転数
・車速
・アクセル開度
・スロットル開度
・吸気量
・吸気温度
・冷却水温
・過給圧
・空燃比に関係する値
・ノッキングに関係する値
・各種補正値
・スイッチやセンサーの状態
・制御中かどうかを示す状態

みたいな、

**走行中に変わる値**

がRAM上で扱われます。

もちろん、

全部がそのまま分かりやすい名前で置いてあるわけではありません。

そこが解析の面倒なところです。

---

## ROMとRAMの違い

かなりざっくり言うと、

**ROMは「保存されているもの」**

**RAMは「今使っているもの」**

です。

例えば点火時期を決める時。

ROMの中には、

「この回転数と負荷なら、基本の点火時期はこのくらい」

という設定データがあります。

一方、

実際に走行している時は、

エンジン回転数、

負荷、

水温、

吸気温度、

ノッキング補正、

その他いろんな条件を見ます。

その時その時の値を使って、

最終的な点火時期を決めます。

つまり、

ROMにある設定だけ見ても、

実際に今どんな制御をしているかは、

全部は分かりません。

---

## ROMだけ見てればいいわけじゃない

ここはかなり重要です。

例えばROMの点火マップを見て、

「ここは20度だから、実際も20度で点火してる」

とは限りません。

走行中は、

いろんな補正が入るからです。

水温が高い。

吸気温度が高い。

ノッキングが出た。

別の補正条件に入った。

こういう時は、

元のマップの数字から変わることがあります。

つまり、

**ROMは設計図や基本設定**

で、

**RAMは実際にその瞬間どう動いているか**

を見るための重要な手がかり、

という感じです。

---

## ECUログとRAMはかなり関係が深い

ECUログを見る時は、

エンジン回転数、

アクセル開度、

スロットル開度、

ブースト、

点火時期、

燃料補正、

みたいな値を記録します。

こういう値は、

ECUが走行中に扱っているデータです。

つまり、

ECUログを見るというのは、

ある意味、

**ECUがその瞬間に何を見て、何を計算していたかを追いかける作業**

でもあります。

NEXUSで実車ログを重要視している理由もここです。

ROMだけでは、

「この処理がある」

というところまでは分かっても、

「実車で本当にその信号がこう動いた」

までは確認できないことがあります。

なので、

ROM解析と実車ログの両方が必要になります。

---

## RAMの場所が分かると何ができるの？

例えば、

「今のクラッチ状態」

「今のアクセル開度」

「今の車速」

「今の走行モード」

みたいな値が、

ECU内部のどこで扱われているか分かれば、

新しい制御を作る時に使える可能性があります。

例えばフラットフットシフトなら、

「クラッチを踏んだ」

だけでは足りません。

アクセルを十分踏んでいるか。

車速が一定以上か。

回転数が高いか。

異常状態ではないか。

そういう複数の条件を見て、

初めて制御を動かす形になります。

そのためには、

ECU内部で、

**現在の状態を表している値がどこにあるのか**

を知る必要があります。

---

## ただし「見つけたっぽい」はダメ

ここもNEXUSでかなり大事にしている部分です。

解析していると、

「これ回転数っぽい」

「これ車速っぽい」

「この値、クラッチ信号じゃない？」

みたいな候補が出てきます。

でも、

似ているだけでは使えません。

本当にその信号なのか。

どんな単位なのか。

値はどう変化するのか。

別の処理でも使われていないか。

実車ログと一致するか。

そこまで確認して、

初めて使える候補になります。

なので、

**それっぽい値を見つけること**

と、

**意味を確認できた値を見つけること**

は別です。

ここはかなり重要です。

---

## 電源を切るとRAMはどうなる？

RAMは、

一時的に使うためのメモリです。

そのため、

基本的には電源が切れると、

中のデータは保持されません。

次にECUへ電源が入った時、

また必要な値が作られて、

走行中にどんどん更新されていきます。

一方、

ROM側のプログラムや設定データは、

電源を切っても残ります。

この違いも、

ROMとRAMを理解する上で分かりやすいポイントです。

---

## BEASTではRAMの情報がかなり重要

BEASTで追加したい制御は、

ほとんどが、

「今どういう状態なのか」

を判断する必要があります。

例えば、

今何回転か。

今何km/hか。

アクセルをどれくらい踏んでいるか。

クラッチを踏んでいるか。

どの走行モードなのか。

今ほかの制御が動いているか。

こういう情報がなければ、

安全に制御を動かせません。

なので、

BEASTを作るためには、

ROMの中にあるプログラムだけでなく、

**実行中に使われるRAM上の情報を理解する必要がある**

ということになります。

---

## ここまでのまとめ

今回の内容をかなり簡単にまとめると、

**ROM**

ECUを動かすためのプログラムや設定データが保存されているもの。

**RAM**

エンジンが動いている間、その瞬間の状態や計算結果などを一時的に扱うためのもの。

です。

ROMだけ見れば、

ECUがどんな設定や処理を持っているかが分かります。

RAM側を見ると、

ECUが実際に今どんな値を使っているかを追えるようになります。

両方を見ることで、

初めて、

「ECUの中で何が起きているのか」

が少しずつ見えてきます。

次回は、

**「アドレスって何？」**

という話を書こうと思います。

ROMにもRAMにも、

データが置かれている場所があります。

その場所を示すのが、

アドレスです。

ECU解析をしていると、

16進数の数字が大量に出てきます。

最初は本当に意味不明です。

でも、

「ただの住所」

だと思えば、

かなり分かりやすくなります。

次はそこをなるべく簡単に書いていきます。