2011-02-04

Wake On LANのマジックパケット(!UDP&&!Eth)

色んなマジックパケットを作って試してみた感じ、ペイロード *1の記述があれば、
受け取ったPCはマジックパケットとして認識してしまうみたい。
気になったものをメモ。

例1)不完全なイーサネットフレーム

*Ethernet?*
0x001CC0XXXXXX
0x05DD

*ペイロード*
0xFFFFFFFFFFFF
0x001CC0XXXXXX
0x001CC0XXXXXX
0x001CC0XXXXXX
0x001CC0XXXXXX
0x001CC0XXXXXX
0x001CC0XXXXXX
0x001CC0XXXXXX
0x001CC0XXXXXX
0x001CC0XXXXXX
0x001CC0XXXXXX
0x001CC0XXXXXX
0x001CC0XXXXXX
0x001CC0XXXXXX
0x001CC0XXXXXX
0x001CC0XXXXXX
0x001CC0XXXXXX

一応起動確認。でも、ちょっと不安定。

例2)ICMPに埋め込む



nao@Xubuntu:~/tools$ hexdump WOL.bin 

0000000 ffff ffff ffff 1c00 XXc0 XXXX 1c00 XXc0

0000010 XXXX 1c00 XXc0 XXXX 1c00 XXc0 XXXX 1c00

0000020 XXc0 XXXX 1c00 XXc0 XXXX 1c00 XXc0 XXXX

0000030 1c00 XXc0 XXXX 1c00 XXc0 XXXX 1c00 XXc0

0000040 XXXX 1c00 XXc0 XXXX 1c00 XXc0 XXXX 1c00

0000050 XXc0 XXXX 1c00 XXc0 XXXX 1c00 XXc0 XXXX

0000060 1c00 XXc0 XXXX 1c00 XXc0 XXXX          

000006c

nao@Xubuntu:~/tools$ sudo hping3 10.0.1.255 -1 -c 1 -d 102 -E WOL.bin

起動確認。
今まで、ICMPのデータ部には大して意味のない文字列しか入れたことなかったんですが、
こうやってマジックパケットのペイロードとして認識されるのは、個人的に興味深かったです。
他のことにも応用できるのかも。

*1:同期シーケンス0xFFFFFFFFFFFFと起動したいPCのMACアドレスが16個

2011-02-03

Wake On LANのマジックパケット(!UDP)

コンピュータネットワークプロトコル

id:EijiYoshidaさんの
Windows版のNetcat(nc)を使ったwolのマジックパケットの送信方法
が面白くて、UDPではない方法を試してみました。

起動させたいPCのMACアドレスは0x001CC0XXXXXX、
実際に送信したデータはこんな感じで、起動も確認。

*Ethernet*
0xFFFFFFFFFFFF

0x001CC0XXXXXX((送信元MACアドレスは見ていないと思うので、起動させたいPCと同じにしています。))
0xFFFF

タイプフィールドは1501以上でなければ、という記述を見掛けたのですが、
0x0000(0)や0x05dc(1500)で試しても起動できたので、値はあまり関係ないのかも。

色々試すにはハード的な負担が大きそうな気がするので、このへんにしておきます。笑

追記(2010/02/04)

書き忘れていた脚注を追加。

2011-01-08

ARPフォーマット

コンピュータネットワークプロトコル

イーサネットではMACアドレスを用いて通信をし、
ARPはIPアドレスからそのMACアドレスを調べるためのプロトコル。
IPと同じネットワーク層で動作する。

フォーマット

Hardware Type

ハードウェアの種別。

0x0001 Ethernet
0x000F Frame Relay
0x0011 HDLC
0x0012 Fibre Channel

Protocol Type

プロトコルの種別。

0x0800 IP
0x809B Appletalk

Hardware Length

ハードウェアアドレス長。(バイト)

Protocol Length

プロトコルアドレス長。(バイト)

Opcode

ARPのオペレーションコード。

0x0001 リクエスト
0x0002 リプライ
0x0003 RARPリクエスト
0x0004 RARPリプライ

Sender Hardware Address

送信元のハードウェアアドレス。
(イーサネットの場合は48ビット、6オクテット)

Sender Protocol Address

送信元のプロトコルアドレス。
(IPの場合は32ビット、8オクテット)

Target Hardware Address

ターゲットとなるハードウェアアドレス
(イーサネットの場合は48ビット、6オクテット)
リクエストの場合は00:00:00:00:00:00が入る。

Target Protocol Address

ターゲットとなるプロトコルアドレス。
(IPの場合は32ビット、8オクテット)
この値が自分のものであった場合、受信したノードはリプライを返す。

例)ARPリクエスト

IPアドレス:10.0.0.100
MACアドレス:08:00:27:11:22:33

IPアドレス:10.0.0.200
MACアドレス:??:??:??:??:??:??

PC1がPC2のMACアドレスを知りたい場合は
イーサネットフレームを先頭につけて、

FFFFFFFFFFFF
080027112233
0806

0001
0800
06
04
0001
080027112233
0a000064
000000000000
0a0000c8

となる。

rawframeを使用して実際に送信してみたもの。
PC2(10.0.0.200)から08:00:27:aa:bb:ccが返ってきている。

参考

RFC826(An Ethernet Address Resolution Protocol)
RFC1700(ASSIGNED NUMBERS)

2010-12-11

「グローバル・エンジニア」まつもとゆきひろ (楽天テクノロジーカンファレンス2010)

コンピュータ ustなど

楽天テクノロジーカンファレンス2010

http://tech.rakuten.co.jp/rtc2010/

プログラム

http://tech.rakuten.co.jp/rtc2010/program.html

USTREAM

http://www.ustream.tv/recorded/10230498

2010-12-10

index

コンピュータ ustなど

このカテゴリーは個人的に気になったust等をメモろうかと。

2010-11-29

VRRPの動作

コンピュータネットワーク pcap

VRRPの動作を見るために作った検証用のネットワークです。
VRRPはマルチキャストなのでPC上でキャプチャ。
下のpcapを見ながら読んでください。(VRRPパケットのみフィルタしています)

vrrp.pcap

動作

1.最初にR2のみでVRRPを有効化
　　　　「NO.1-4」
　　　　プライオリティ90のR2がマスタールータ。

2.R1でもVRRPを有効化
　　　　「No.5-13」
　　　　R2は自分よりプライオリティが高いVRRPパケットを受信したので、
　　　　バックアップルータとなり、プライオリティ100のR1がマスタールータとなる。

3.R1/R3間を切断
　　　　「No.14-16」
　　　　R1はR3にフォワードできなくなったので、
　　　　あらかじめ設定された、プライオリティ80のVRRPパケットを送信。

　　　　「No.17-」
　　　　自分よりプライオリティの低いVRRPパケットを受信したR2は
　　　　バックアップルータから再びマスタールータになる。

2010-11-25

ネットワークなCTFっぽいもの〜01の楽しみ方

コンピュータ

遅くなってしまいましたが、これの楽しみ方です。

まず、ざっと見た感じで気になるところ。

- ipv6が動いてる？
- ルーティングはOSPF？
- VRRPでルータの冗長化
- ICMPのデータ(@&Hya+psL(!k+LlkNMp10}_ldo*^~^w@)
- 10.0.64.12と10.0.0.5が通信している
- 10.0.64.12=サーバ
- 10.0.0.5=クライアント
- HTTP
- Basic認証(joe:joe)
- ファイルをダウンロードしている

とりあえずファイルを抽出してみる。



Preferences>Protocols>HTTP>Reassemble HTTP bodies spanning multiple TCP segments

にチェックが入っていれば、



File>Export>Objects>HTTP

でファイルを抽出できる。

ファイルをチェック。

$ file file
file: RAR archive data, v1d, os: Win32

$ unrar e file

Extracting from file

Enter password (will not be echoed) for dum:

Enter password (will not be echoed) for text:

No files to extract

パスワードが要求されるので"joe"や"@&Hya+psL(!k+LlkNMp10}_ldo*^~^w@"を試してみる。



$ unrar e file 
Extracting from file
Enter password (will not be echoed) for dum: 
Extracting  dum                                                       OK 

text - use current password ? [Y]es, [N]o, [A]ll y
Extracting  text                                                      OK 

All OK

"@&Hya+psL(!k+LlkNMp10}_ldo*^~^w@"が通った。

$ file *
dum: data
file: RAR archive data, v1d, os: Win32
text: Non-ISO extended-ASCII text, with CRLF line terminators

$cat text
・・・・・・・・

文字化けして読めないので、手っとりばやくエディタでｗ

$ gedit text &

windowsのfsutilコマンドを使ってみました。

例)fsutil file createnew dum 1572864

ん…？



$ hexdump -C dum | less

00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

 *

00180000

なんだかオール0っぽい感じ。

ということで、このrarはフェイクでしたｗ
ではどこなのか。

ネットワークによく触れている人は違和感を感じていたかもしれないのですが、
VRRPのアドバタイズの間隔がデフォルトより長いんですよね。

VRRPとは(ざっくりと)

- ルータを冗長化するプロトコルで、デフォルトゲートウェイが故障した時などに、自動的にマスタールータからバックアップルータに切り替わる
- VRRPパケットを用いてマスター、バックアップを決める
- マスタールータがVRRPパケットを送信する
- 自分よりプライオリティの低いVRRPパケットを受信、もしくは一定時間マスタールータからVRRPパケットが届かなかった時、バックアップルータがマスタールータに変わる
- 一定時間とは(アドバタイズ間隔×3+α)秒
- テキスト認証(平文)とMD5による認証がある

このネットワークではVRRPのアドバタイズがデフォルト1秒→約5秒に変更されている。
ということは、マスタールータが落ちたとバックアップルータが判断するまでに、
通常の(3秒+α)→(15秒+α)かかってしまう。
やっぱりちょっと変。

VRRPパケットのみ抽出してみる。

途中でマスタールータが変わっている。
変わった前後のパケットを見てみる。

プライオリティが変わっているわけでもなく、アドバタイズの間隔も変わっていない。
あれ？おかしくない？

送信元10.0.64.3のVRRPをじっくり見てみる。
No147だけAuth Typeが1になっていて、Authentication stringに値が入っている。
6e656b6f→neko
で、答えがnekoでした。

純粋にネットワークだけで作ろうと思っていて、途中のファイルも明らかにダミーと分かるようにしたのですが、
もうちょっとひねればよかったです。
実は99%が生のパケットなので、実際にネットワークを考えて組むのが楽しかったり、また大変だったりでした。

一応めげずに第二弾の案はあるのですが、中々思うようにpcapとして形にできないので、いつになることやら…
もしできたらまたお付き合いいただければと思います。
ありがとうございました。

~~#数日中にVRRP環境におけるバックアップルータ→マスタールータの遷移のキャプチャをのせようと思います。~~
こちらです。