年末近いというのに…

 少しは楽、っていったい何から楽になったのかちっともわからん。
 あれもこれもやらねばならぬし、お客さんは30日まで営業だし。
 まあ、仕事がないよりはマシなのであまり嘆かないようにしようとは思う…がそれにしても（笑

 今日はひさびさに緊急で古臭い仕事をした。
 古いプログラムで、EXEしかない。自分で作ったやつじゃないので、どんなになってるかちっともわからん。
 そんなプログラムを修正しなければならんという。
 というわけで、できるだけの情報をもらい、久々にバイナリエディタなどで実行モジュールの中身をそのままみる用意をする。
 どこまでできるかわからないが、逆アセンブラも用意して、とりあえず逆アセンブル。う～ん、シンボルがわからないから大変だなぁ。C++Builderで作成した、ということなので、もうすっかり忘れてたコンパイラの癖を思い出して、アセンブルコードから問題箇所を特定しようと。
 うむ。確かにこれはMicrosoft系じゃなくて、Borland系のコンパイラだとはわかる（笑
 switch-case文とか特徴あるんだよね。
 とはいえ、EXEが1M超えてるから大変だよ、探すの。
 時間かければわかるとは思うが、時間がないのだ。
 30分くらい眺めてこの手法はあきらめた。
 というわけで、バイナリエディタで直接16進ダンプから捜索することにする。
 staticで確保してる配列があって、初期値もあるので、そこはすぐ発見。このテーブルの値をまずは修正。
 問題は、それを参照してるコードの処理の修正だ。
 その部分であろう、という、おそらくこれかも、というソースコードの一部があったのでそれから類推する。まあ、処理上そんなに変更ないだろうという箇所なので、そこをどうやって特定するかを考える。
 ラッキーなことに即値が使われてるじゃん。intだから32bitで当然のことながらリトルエンディアンなので、4byteの16進数表記で検索すると…３ヶ所見つかった。たった３ヶ所か、ラッキー！
 で、そのあたりのバイナリみて、命令を予測。ふむ。おっと、直前にも違う値の即値が使われてるじゃん。
 近接してる２つの即値で照らし合わせると、一ヶ所に特定できた。
 さて、昔のパッチの様に、jmpさせてその先で処理書いてretさせるのかあ、86系の命令セット思い出さないとだめかなぁ、と思ったのだが、なんとその即値を変更すれば処理上うまくいくことを発見。楽チンじゃん～！

 というわけで、残り30分で、即値で書かれていた部分の値を変更することで完璧直りました。
 ん～、こういうのうまくいくと嬉しいね。
 ほとんど完全にあきらめていたお客さんも喜んでくれたし。
 ちょっと仕事した気がします（笑