一番目、二番目共に潰してもダメ…そこのロジックを通ってるか、なんかチェックする方法があればそれで見てみる必要があるかな

二番目だけでもダメか…

二番目はoffset 0x905bを0xed→0x90にして、2byte NOPにすれば良いかな。

0x00108e00～0x108e75に違うコントローラのエントリポイントがあって、0x001098dcにこのコントローラのエントリポイントがあるみたいだから…なんとなく、この間が怪しいと見てる。んでもって、in (%dx), %axがあるのは2か所か…最初に見つけた場所(0x109831)が間違いなら、二番目に見つけた場所(0x109026)を潰したらどうなるかなあ

この辺も怪しい？
109020: 8b 55 fc mov 0xfffffffc(%ebp),%edx
109023: 83 c2 14 add $0x14,%edx
109026: 66 ed in (%dx),%ax
109028: 8b 55 fc mov 0xfffffffc(%ebp),%edx
10902b: 83 c2 18 add $0x18,%edx
10902e: ed in (%dx),%eax

見当違いのところいじってる可能性も当然あるからなあ…

とりあえずシステムファイルの圧縮を解いて、バイナリパッチを当てることができる状態までは確立できたか。パッチを用意できるかどうかはまた別の話ってことで。

だめだ、落ちたねえ。

元のファイルは圧縮がかかっているからこれをどうにか解いて、得られたファイルのoffset 0x9861を14→10, 0x9865の66, edをef, 90か。objdumpでも

10982b: 8d 56 10 lea 0x10(%esi),%edx
10982e: 83 c4 08 add $0x8,%esp
109831: ef out %eax,(%dx)
109832: 90 nop

うん、意図した通りになってる。

10982b 8d 56 14 lea 0x14(%esi), %edx
↓
10982b 8d 56 10 lea 0x10(%esi), %edx

109831 66 ed in (%dx), %ax
↓
109831 ef out %eax, (%dx)
109832 90 nop

これ試してみようか？

109826: e8 fc ff ff ff call 109827 <_init-0xf67d9>
10982b: 8d 56 14 lea 0x14(%esi),%edx
10982e: 83 c4 08 add $0x8,%esp
109831: 66 ed in (%dx),%ax
109833: 8d 56 18 lea 0x18(%esi),%edx
109836: ed in (%dx),%eax
109837: 68 e8 03 00 00 push $0x3e8
この辺か？

もしかするとあれかな、VMware Player上のvlanceが何かの拍子にDWIO modeが解除されるバグか何かがあって、それに対処したが故に問題が起こったのかなあ。

Linux最古のpcnet32.cを見るに、チップのプローブで8bitアクセスは使っているけど16bitアクセスは未使用… https://elixir.bootlin.com/linux/2.0.34/source/drivers/net/pcnet32.c#L271