So-net無料ブログ作成

付録基板のhttpサーバをダウングレードしてみた [ColdFire V2]このエントリーを含むはてなブックマーク#

2047506

SilentCにパッチをあてて、httpサーバをダウングレードしてみました。 これも、"masato"さんの尊い人柱レポートのおかげです。

httpサーバのダウングレード

この作業は、SilentCにパッチをあてることになるので、付録基板がEzPORTによるリカバリを必要とするぐらいのダメージを受ける可能性があります。 このため、今まで使ってきた「青号」ではなく「橙号」を出してきました。 皆さんが追試されるときにも十分に注意してください。

ダウン・グレードといっても、大したことはしていません。 httpサーバが返してくる"HTTP/1.1 200 OK"の文字列を"HTTP/1.0 200 OK"に変更するだけです。 この文字列は、以下の場所にあります。

000116b8  74 73 3f 00 46 75 6c 6c  ts?.Full
000116c0  3f 00 48 54 54 50 2f 31  ?.HTTP/1
000116c8  2e 31 20 32 30 30 20 4f  .1 200 O
000116d0  4b 0d 0a 43 6f 6e 74 65  K..Conte

これを書き換えるためにドキュメントには書かれていない"NvmWrite"という関数を使います。 使用したプログラムは、以下のとおりです。

main(){
  long *patch=MemoryAlloc(16);
  long *target=0x116c8;
  do {
    BufCopy(patch,target,4);
    if (*patch!=0x2e312032) {
      PrStr("Invalid Program\r\n");
      break;
    }
    *patch=0x2e302032;
    NvmWrite(target+0xFFF00000, patch, 4);
  } while(0);
  MemoryFree(patch);
}

"NvmWrite"という関数は、FLASHへの書き込みを行うプログラムをRAMに展開して、実行します。 この間、FLASHは、アクセス不能になります。 そのため、書き込みに必要な情報は、すべてRAMに配置しておく必要があります。 このプログラムでも該当アドレスの内容を"MemoryAlloc"関数で確保したヒープ領域に配置して、書き込むべきデータのバッファとして使用しています。

プログラムを実行した結果が、これです。

000116b8  74 73 3f 00 46 75 6c 6c  ts?.Full
000116c0  3f 00 48 54 54 50 2f 31  ?.HTTP/1
000116c8  2e 30 20 32 30 30 20 4f  .0 200 O
000116d0  4b 0d 0a 43 6f 6e 74 65  K..Conte

この方法で、自由自在にパッチが当てられそうなのですが、適用範囲は限定されています。 今回は、0x31というデータを0x30というデータに書き換える「あるビットを1から0に変更するパッチ」だったので、簡単に出来ました。 もち、逆に「0から1に変更する」のだったら、FLASHを一旦消去して、書き換える必要があるので、こんなに簡単にはいきません。

また、このパッチは、該当箇所を余分にプログラムしてしまうことになるので、深く書き込みすぎてしまう可能性があります。 これは、「deep program」と呼ばれる状態で、セルが劣化したり、消去できなくなったりする可能性があります。 このFLASHモジュールの書き込みアルゴリズムがどうなっているのか、明確ではありませんが、あくまでも「消去してから書き込み」というのが正式な手順です。

パケット・モニタで確認

パッチをあてたところで、パケット・モニタで通信状態を確認してみます。

#1	0.000000	192.168.1.2	192.168.1.103
	TCP	1517 > 80 [SYN] Seq=0 Win=16384 Len=0 MSS=1460
#2	0.000394	192.168.1.103	192.168.1.2
	TCP	80 > 1517 [SYN, ACK] Seq=0 Ack=1 Win=1454 Len=0
#3	0.000484	192.168.1.2	192.168.1.103
	TCP	1517 > 80 [ACK] Seq=1 Ack=1 Win=16616 Len=0

おなじみ3ウェイ・ハンドシェイクです。

#4	0.008741	192.168.1.2	192.168.1.103
	HTTP	GET /RiverSeaTemplate.htm HTTP/1.1 
	TCP	1517 > 80 [PSH, ACK] Seq=1 Ack=1 Win=16616 Len=430
#5	0.009719	192.168.1.103	192.168.1.2
	TCP	80 > 1517 [ACK] Seq=1 Ack=431 Win=1454 Len=0
#6	0.013506	192.168.1.103	192.168.1.2
	HTTP	HTTP/1.0 200 OK  (text/html)
	TCP	80 > 1517 [PSH, ACK] Seq=1 Ack=431 Win=1454 Len=1377

最初は、HTML文書の要求から。 ColdFireからの返答が"HTTP/1.0 200 OK"になっているのが確認できます。

#7	0.054387	192.168.1.2	192.168.1.103
	HTTP	GET /W.gif HTTP/1.1 
	TCP	1517 > 80 [PSH, ACK] Seq=431 Ack=1378 Win=16616 Len=437
#8	0.055376	192.168.1.103	192.168.1.2
	TCP	80 > 1517 [ACK] Seq=1378 Ack=868 Win=1454 Len=0
#9	0.055416	192.168.1.103	192.168.1.2
	TCP	80 > 1517 [FIN, ACK] Seq=1378 Ack=868 Win=1454 Len=0
#10	0.055472	192.168.1.2	192.168.1.103
	TCP	1517 > 80 [ACK] Seq=868 Ack=1379 Win=16616 Len=0
#11	0.056353	192.168.1.2	192.168.1.103
	TCP	1517 > 80 [FIN, ACK] Seq=868 Ack=1379 Win=16616 Len=0
#12	0.056673	192.168.1.103	192.168.1.2
	TCP	80 > 1517 [ACK] Seq=1379 Ack=869 Win=1454 Len=0

ところが、ブラウザは、同じポートを使い#7でGIFファイル W.gif を要求してきます。 ColdFireは、#7に対する応答として#8を返しますが、同時に#9でコネクションの終了を宣言します。 この部分は、HTTP/1.1だった時と同じです。 ブラウザが、HTTP/1.0を認識していないのか?

#13	0.057777	192.168.1.2	192.168.1.103
	TCP	1520 > 80 [SYN] Seq=0 Win=16384 Len=0 MSS=1460
#14	0.058129	192.168.1.103	192.168.1.2
	TCP	80 > 1520 [SYN, ACK] Seq=0 Ack=1 Win=1454 Len=0
#15	0.058201	192.168.1.2	192.168.1.103
	TCP	1520 > 80 [ACK] Seq=1 Ack=1 Win=16616 Len=0
#16	0.059826	192.168.1.2	192.168.1.103
	HTTP	GET /B.gif HTTP/1.1 
	TCP	1520 > 80 [PSH, ACK] Seq=1 Ack=1 Win=16616 Len=437
#17	0.060798	192.168.1.103	192.168.1.2
	TCP	80 > 1520 [ACK] Seq=1 Ack=438 Win=1454 Len=0
#18	0.062053	192.168.1.103	192.168.1.2
	HTTP	HTTP/1.0 200 OK  (GIF89a)
	TCP	80 > 1520 [PSH, ACK] Seq=1 Ack=438 Win=1454 Len=415

続いて、二回目のコネクションでブラウザが GIFファイル B.gif を要求します。 HTTP/1.1の時には、ここで、GIFファイルを要求するコネクションが二つ同時に飛んできたのですが、今回はひとつだけです。 GIFファイルを受信し終えて、コネクションの終了かと思っていたら、

#19	0.067185	192.168.1.2	192.168.1.103
	TCP	1521 > 80 [SYN] Seq=0 Win=16384 Len=0 MSS=1460
#20	0.067542	192.168.1.103	192.168.1.2
	TCP	80 > 1521 [SYN, ACK] Seq=0 Ack=1 Win=1454 Len=0
#21	0.067606	192.168.1.2	192.168.1.103
	TCP	1521 > 80 [ACK] Seq=1 Ack=1 Win=16616 Len=0
#22	0.075055	192.168.1.2	192.168.1.103
	HTTP	GET /W.gif HTTP/1.1 
	TCP	1521 > 80 [PSH, ACK] Seq=1 Ack=1 Win=16616 Len=437
#23	0.076056	192.168.1.103	192.168.1.2
	TCP	80 > 1521 [ACK] Seq=1 Ack=438 Win=1454 Len=0
#24	0.077340	192.168.1.103	192.168.1.2
	HTTP	HTTP/1.0 200 OK  (GIF89a)
	TCP	80 > 1521 [PSH, ACK] Seq=1 Ack=438 Win=1454 Len=425

コネクションを終了させる前に二つ目のGIFファイル W.gif の要求が始まってしまいました。 GIFファイルを受け取って、今度は本当に通信終了だよね。

#25	0.168419	192.168.1.2	192.168.1.103
	TCP	1520 > 80 [ACK] Seq=438 Ack=416 Win=16201 Len=0
#26	0.168786	192.168.1.103	192.168.1.2
	TCP	80 > 1520 [FIN, ACK] Seq=416 Ack=438 Win=1454 Len=0
#27	0.168861	192.168.1.2	192.168.1.103
	TCP	1520 > 80 [ACK] Seq=438 Ack=417 Win=16201 Len=0

次のパケットは、ブラウザから送信されます。 これは、#18に対する返答で、返答までに要した時間は、約0.1秒でした。 ColdFireは、#26でコネクション終了を宣言し、#27でブラウザが受信確認を送ります。

#28	0.269074	192.168.1.2	192.168.1.103
	TCP	1521 > 80 [ACK] Seq=438 Ack=426 Win=16191 Len=0
#29	0.269476	192.168.1.103	192.168.1.2
	TCP	80 > 1521 [FIN, ACK] Seq=426 Ack=438 Win=1454 Len=0
#30	0.269553	192.168.1.2	192.168.1.103
	TCP	1521 > 80 [ACK] Seq=438 Ack=427 Win=16191 Len=0

続いて、#24に対する返答が#28で返されます。 返答までの所要時間は、0.2秒です。 ColdFireは、#29でコネクション終了を宣言し、ブラウザが#30で受信確認します。

#31	5.933938	192.168.1.2	192.168.1.103
	TCP	1520 > 80 [FIN, ACK] Seq=438 Ack=417 Win=16201 Len=0
#32	5.934275	192.168.1.103	192.168.1.2
	TCP	80 > 1520 [ACK] Seq=417 Ack=439 Win=1454 Len=0
#33	5.934329	192.168.1.2	192.168.1.103
	TCP	1521 > 80 [FIN, ACK] Seq=438 Ack=427 Win=16191 Len=0
#34	5.934683	192.168.1.103	192.168.1.2
	TCP	80 > 1521 [ACK] Seq=427 Ack=439 Win=1454 Len=0

ここから、前の実行結果と多少異なっています。 ブラウザが"FIN"を送信するのは、5.5秒後です。 前回は、8秒かかっていました。 また、ColdFireも今回は、"FIN"に対して"ACK"を確実に返しています。 そのため、パケットの送受信は、ここで終了します。

本日の考察

  1. httpサーバをHTTP1.0にダウン・グレードすると、ブラウザは同時に複数の通信を要求する振る舞いはしない。
  2. ただし、データ転送が終了した後でもコネクションは張られたままなので、複数コネクションを行っているようにも見える。
  3. ブラウザが"FIN"を発行するタイミングが早いので、ColdFireは、"ACK"で応える事が出来る。

GIFファイルの数をもっと増やしたらどうなるんでしょうね。

参考文献

Interface (インターフェース) 2008年 09月号 [雑誌]

Interface (インターフェース) 2008年 09月号 [雑誌]

  • 作者:
  • 出版社/メーカー: CQ出版
  • 発売日: 2008/07/25
  • メディア: 雑誌

nice!(0)  コメント(2)  トラックバック(0)  このエントリーを含むはてなブックマーク#

nice! 0

コメント 2

hamayan

コネクションの切断を待たずに送って来ましたか。
うーん、判らん。

ブラウザを変えてやったらどうなるのかなぁ。OperaとかIEとかクロームとか(笑)。

by hamayan (2008-10-01 17:59) 

noritan

IEで試してみましたが、若干早いだけで、Firefoxの時と同じやりとりでした。
httpプロトコルのレイヤーは、共通なのかな?

by noritan (2008-10-01 22:56) 

コメントを書く

お名前:
URL:
コメント:
画像認証:
下の画像に表示されている文字を入力してください。

トラックバック 0

トラックバックの受付は締め切りました

この広告は前回の更新から一定期間経過したブログに表示されています。更新すると自動で解除されます。