social.mikutter.hachune.netMastodonを使った分散型ソーシャルネットワークの一部です。
#あなたがガチ凍結されると<br> 11月中旬くらいかな?俺はておくれだから<br> Twitterからよく舐められるんだけど、<br> ある時Twitterが度が過ぎて俺を凍結<br> してきたわけ、そんで記憶がないんだけど(痴呆)、<br> 相当ボコボコにしちゃったらしい<br> 俺、これでもておくれですよ?

サーバーの情報

105
人のアクティブユーザー

もっと詳しく

「D-STAR 委員会によるユーザーを無視した行動についての申し入れ」に関する 経過のまとめ (2024/2/10) xrf673.xreflector-jp.org/info/
これで知ったのだけど、UDPオプションなるものがあるのか。
datatracker.ietf.org/doc/html/
これについては UDPにオプション領域を追加する仕様 (2023/07/01) asnokaze.hatenablog.com/entry/ を見るのが良さそう。

UDPオプションを踏まえた上で、レピータ管理団体及び JARL・D-STAR委員会等が提供しているプログラム以外を接続されているユーザー の皆様へ (2024/02/21) blog.goo.ne.jp/jarl_lab2/e/5f2 に示されるIPパケットを読み解いてみようか。

goo blogレピータ管理団体及び JARL・D-STAR委員会等が提供しているプログラム以外を接続されているユーザー の皆様へ - D-STAR NEWSD-STARシステムについてD-STARは平成10年に当時の郵政省からJARLが「アマチュア無線の周波数の有効利用を図るためのデジタル化」技術の調査検討について委託を受けたことから始まりました。そのため、調査検討の課程で総務省の当時の考え方などもふまえたシステムとなっており、ネットワーク接続が日本では管理サーバー方式となっているのもそのような理由からです。JARLがD-STARの運用を始めて20年になりますが、当初のゲートウェイサーバーはレピータのみを接続するものでルーター---dsgwd---レピータコントローラーという接続のみでした。郵政省(総務省)からの委託ですのでレピータ装置等はJAIAに要請して入札にて行い、応札してくれたのはアイコムのみでしたので、上記のdsgwd、レピータコントローラーはアイ...レピータ管理団体及びJARL・D-STAR委員会等が提供しているプログラム以外を接続されているユーザーの皆様へ

生存確認の要求側のパケットの例
07:46:45.668636 IP xx.x.x.xxx.60005 > xxx.xxx.xxx.xxx.50100: UDP, length 10
0x0000: 4500 0026 0fee 4000 4011 66d3 xxxx xxxx     E..&..@.@.f.....
0x0010: xxxx xxxx ea65 c3b4 0012 c429 4453 5452     .....e.....)DSTR
0x0020: 0000 7312 0000                   ..s...

IPv4, IPヘッダ長20byte, サービスタイプ00, パケット長38byte, protocol UDP(0x11), checksum 0x66d3, 送信元/送信先は秘匿されている, IPヘッダのオプションは無し。
UDP src port 60005, dst port 50100, データ長18byte, checksum 0xc429

…で、いいのかな。

SASANO Takayoshi

非準拠の例
07:46:45.723745 IP xxx.xxx.xxx.xxx.50100 > xx.x.x.xxx.60005: UDP, length 10
0x0000: 4500 0026 888f 0000 3e11 3032 xxxx xxxx     E..&....>.02....
0x0010: xxxx xxxx c3b4 ea65 0012 825a 4453 5452     .......e...ZDSTR
0x0020: 0097 7212 0000 0000 0000 0000 0000        ..r...........

IPv4, IPヘッダ長20byte, サービスタイプ00, protocol UDP(0x11), パケット長38byte, checksum 0x3032, 送信元/送信先(ry, IPヘッダのオプションは無し。
UDP src port 50100, dst port 60005, データ長18byte, checksum 0x825a

確かにIPヘッダのパケット長を越えちゃいる…

非準拠のパケットとやらが0x2e…46byteあるけども、一つ引っかかるのがrunt packet除けのpaddingなんだよね。

Ethernet上では64byte未満のパケットは棄却されるので、適当にパディングして64byteにする必要があるんだけど…Ethernetフレームって送信MAC address(6byte), 受信MAC address(6byte), Ethernet type(2byte)に加えてFCS(4byte)、18byteのデータが追加される。

46+18=64なんだけど、この推測あってますかね?「バッファオーバーフローと呼ばれる典型的なハッキングの手法の一つ」ではなく。