プログラムデータを他のシステムに渡す変換ツールの解析をしてくれと、
またリバースエンジニアリングか。この職場に来てこういうネタは事欠かない。
ただ、そこまで難しいことはしてないんじゃないかと思うので、
サクッと解析して、新システムに適合した仕様を決めないとならん。
このツールはモトローラのSレコードを入力にするのだが、
入力ファイルに比べて出力ファイルのサイズが大幅に小さくなっているので、
「もしかして圧縮しているのでは?」という疑問を投げかけてきた。
それって入力のサイズってバイナリのサイズ? Sレコードのサイズ?と聞いて、
実際にファイルサイズを確認してみると、Sレコードのサイズだった。
5年前にBlogに書いてたな。
Sレコードはバイナリデータを16進数の文字列で記載する方法だから、
単純に考えても容量は2倍、実際にはレコード種別・データ長・アドレス・チェックサムも加わるので3倍近いサイズになる。
そうして考えるとほぼ同サイズ、少しヘッダが加わった程度のサイズである。
このことを「コート10枚ぐらい着てきたやつをパンツ一丁にしたような」と例えたが、
Sレコードの容量ってそんなに大きいんですね。
このBlogにSレコードのネタを書いたのが5年前って、もうそんな昔からあの仕事してるのか。
この記事を書いたのは、とある古いマイコンが製造中止になるということで、
その代替手段の開発のために、そのマイコンのコンパイラの出力形式であるSレコードを触る必要があった。
2つの出力ファイルをくっつけて1つの出力ファイルを作ってとやる必要があり、
それでネタにしたのだが、なんとこの代替策、まだ完成していないのだ。
社内外……いやほとんど社外でいろいろトラブルがあってね……
今回の変換ツールはこれとは別の仕事の話である。
で、その古いマイコンの代替手段に関係して作ったプログラムの評価を最近やってたんだよね。
今回の評価のターゲットは主に暴走対策である。
プログラムが想定外の暴走をしたときに停止してエラー情報を表示できますよねというテストである。
このプログラムが暴走しても致命的な問題を起こす可能性は低いのだが、
- エラー情報が表示できないと電源回路の故障などと区別が付かない
- 例外発生時の挙動が不定になるケースがある
という問題があり、暴走対策の処理をいくつか追加している。
ただ、普通にプログラムを動かしても暴走はそうそう起こせない。
そこで、Sレコードで出力されたプログラムデータを書き換えて、
例外が起きる命令を並べたり、無限ループに突っ込むように命令やジャンプ先のアドレスを書き換えたり……
そんなことをやって評価していたのである。
例外を起こすためには変な命令を食わせるしか方法はなかなかないので、
そうなるとプログラムデータ自体を書き換えるしかないと。
それなら無限ループを発生させるのもプログラムの書き換えでやってしまえと。
ICEでループ変数を書き換えても暴走は模擬できるのだが、
ICEを接続するとウォッチドッグタイマーが無効化されてしまう。
レジスタをインクリメントするところをNOP命令に差し替えるとか、
そんなので無限ループを模擬してましたけどね。
Sレコードは16進数なのでテキストエディタで容易に編集できる……
と思いきや1行ずつチェックサムが付いているのでチェックサムの計算が面倒だった。
Excelで計算するワークシートを作ってチェックサムを算出してたけど。
アセンブラどころか、Sレコードいじって機械語を直編集とか、普通はやらんわな。
でも、今回のケースはそうでもしないと実現できないものだったので。
そんなことばっかりやってるから、お得意のリバースエンジニアリングとか言われるんだけど。
まぁ今回解析するのはアセンブラじゃないので。