要約

もしも127.0.0.1(localhost)を一番~~面倒くさく~~面白くIPv4表記できた奴が優勝するとしたらと妄想してみた
個人的に　017700000001 が優勝！！!

前書き

SECCON Beginners CTF 2021 に関連して多くの方にご覧いただいております🙇🏻‍♂️
[Web] check_url の問題にに関してなぜ…と思われる方は
何故いろんな表記ができるのか？からご確認ください。

IPアドレスとは

IPアドレスは、IPでネットワーク上の機器を識別するために指定するネットワーク層における識別用の番号。

localhostとは

ローカル・ループバック・アドレス（もしくは単にループバック・アドレスとも言う）
自分自身を表す特別なIPアドレスの1つで、TCP/IPが有効なコンピュータでは常に利用可能なIPアドレス
一般的には「127.0.0.1」というIPアドレス（IPv4の場合）が利用されるが、実際にはIPアドレスの最上位のバイト（最上位の8bit）の内容が127でありさえすればよい(127.0.0.1～127.255.255.254)
今回は127.0.0.1とする。

さっそく試してみる

0, Webサーバーを立てる

適当なフォルダとファイルを準備して、127.0.0.1:8080にWebサーバーを立てる(手抜き)

$ cd /tmp && mkdir test && cd $_ && touch hoge.txt && python -m SimpleHTTPServer 8080

1, `127.0.0.1`

特徴
- 0-255の数字4組 (32ビット)
アピールポイント
- 極めてシンプル、誰にでもわかりやすく愛されるスタイル。
- スラ◯ムのようなわかりやすさ。

curlで確認

$ curl -X GET 'http://127.0.0.1:8080'
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"><html>
<title>Directory listing for /</title>
<body>
<h2>Directory listing for /</h2>
<hr>
<ul>
<li><a href="hoge.txt">hoge.txt</a>
</ul>
<hr>
</body>
</html>

2, `127.0.1`

特徴
- 数字が3組、3組目が16ビット
アピールポイント
- 少し面倒くささを感じるが、まだまだ優しい。初めて出会ったドラ◯ー程度の面倒くささ。

curlで確認

$ curl -X GET 'http://127.0.1:8080'
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"><html>
<title>Directory listing for /</title>
<body>
<h2>Directory listing for /</h2>
<hr>
<ul>
<li><a href="hoge.txt">hoge.txt</a>
</ul>
<hr>
</body>
</html>

3, `127.1`

特徴
- 数字が2組、2組目が24ビット
アピールポイント
- そこはかとなく面倒くさい。しかし、127.1は24ビット計算の部分が1なので十分に優しい。冒険序盤のホイミスライ◯程度の面倒くささ。

curlで確認

$ curl -X GET 'http://127.1:8080'
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"><html>
<title>Directory listing for /</title>
<body>
<h2>Directory listing for /</h2>
<hr>
<ul>
<li><a href="hoge.txt">hoge.txt</a>
</ul>
<hr>
</body>
</html>

4, `2130706433`

特徴
- 数字が1組、 1組目が32ビット
アピールポイント
- だいぶ面倒くさい。初見では何かわからない初見殺し。初めてマホカン◯を見た時のような面倒くささ。
計算方法
- (127 * 256^3) + (0 * 256^2) + (0 * 256^1) + (1 * 256^0)

curlで確認

$ curl -X GET 'http://2130706433:8080'
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"><html>
<title>Directory listing for /</title>
<body>
<h2>Directory listing for /</h2>
<hr>
<ul>
<li><a href="hoge.txt">hoge.txt</a>
</ul>
<hr>
</body>
</html>

5, `0x7F000001`

特徴
- 16進
アピールポイント
- かなり面倒くさい。IPっぽさをなくしてくるあたり、みかわしきゃ◯で地味に攻撃があたらないくらいの面倒くささ。
計算方法
- 数字が1組まで戻す

  7 * 16^7       + F * 16^6      + 0 * 16^5 + 0 * 16^4 + 0 * 16^3 + 0 * 16^2 + 0 * 16^1 + 1 * 16^0

= 7 * 268,435,456 + F * 16,777,216 + 0         + 0         + 0         + 0         + 0         + 1 * 1

= 1,879,048,192   + 251,658,240    + 0         + 0         + 0         + 0         + 0         + 1

= 2,130,706,433

curlで確認

$ curl -X GET 'http://0x7F000001:8080'
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"><html>
<title>Directory listing for /</title>
<body>
<h2>Directory listing for /</h2>
<hr>
<ul>
<li><a href="hoge.txt">hoge.txt</a>
</ul>
<hr>
</body>
</html>

6, `017700000001`

特徴
- 8進
アピールポイント
- かなり面倒くさい。。元が127.0.0.1だから許せるが他のものだと担当者を呼び出したくなる。仲間を呼ぶで呼ばれた敵がさらに仲間をよんだ時くらいの面倒くささ。 ~~１バイト＝６ビットの時代以降、あまり用途がなく馴染みが薄いので優勝!~~
計算方法
- 数字が1組まで戻す

  1 * 8^10          + 7 * 8^9         + 7 * 8^8        + 0 * 8^7 + 0 * 8^6 + 0 * 8^5 + 0 * 8^4 + 0 * 8^3 + 0 * 8^2 + 0 * 8^1 + 1 * 8^0

= 1 * 1,073,741,824  + 7 * 134,217,728  + 7 * 16,777,216  + 0        + 0        + 0        + 0        + 0        + 0        + 0        + 1 * 1

= 1,073,741,824      + 939,524,096      + 117,440,512     + 0        + 0        + 0        + 0        + 0        + 0        + 0        + 1

= 2,130,706,433

curlで確認

$ curl -X GET 'http://017700000001:8080'
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"><html>
<title>Directory listing for /</title>
<body>
<h2>Directory listing for /</h2>
<hr>
<ul>
<li><a href="hoge.txt">hoge.txt</a>
</ul>
<hr>
</body>
</html>

何故いろんな表記ができるのか？

RFC3986の7.4章珍しいIP表記 (7.4. Rare IP Address Formats) に記載がありました。

以下、https://triple-underscore.github.io/RFC3986-ja.html#section-7.4 より引用

IPv4address のための URI 構文は一般的なドット付き数字形式の IPv4 アドレスリテラルのみを認めているが、 URI を処理する多くの実装は文字列リテラルを実際の IP アドレスへと変換するために、gethostbyname() や inet_aton() のような、プラットホーム依存のシステムルーチンを利用する。残念ながら、そのようなシステムルーチンは、しばしば Section 3.2.2 にて記述されるものよりはるかに大きな集合の形式を認め、そして処理を行う。

例えば、多くのアプリケーションは三つの番号のドット付き形式を認め、この場合、最後の部分が 16 ビットの量として解釈され、ネットワークアドレスの最も右 2 バイトに置かれる(例えば、クラス B ネットワーク)。

同様に、二つの番号のドット付きの形式は、最後の部分が 24 ビットの量として解釈され、ネットワークアドレスの最も右 3 バイトに置かれ (クラス A)、(ドットなしの) 単一の数字は 32 ビットの量として解釈され、直接ネットワークアドレスに格納される事を意味する。

更に混乱させる事に、いくつかの実装では、C 言語にて規定されるように、ドット付けされた部分が 10 進、8進、16 進として解釈される事も認める。

先行する 0x や 0X は 16 進を意味する

先行する 0 は 8 進を意味する

さもなくば、その数は 10 進であると解釈される

実用イメージ

相手「私さん、このテスト用Webサーバーってどこ(IP or ホスト)で動かしているですか？」

case1
私「127.0.0.1」
相手「localhostかー」

case2
私「127.0.1」
相手(127.0.0.1って言ったのを聞き間違えたかな...)

case3
私「127.1」
相手(127.1...?)

case4
私「21億3070万6433」(※2130706433)
相手(何を言っているんだこいつ...)

case5
私「0x7F000001」
相手「16進？　え？ IP?」

case6
私「017700000001」
相手「shine」

~~以上より、私の中では 017700000001 が優勝です!~~

127.0.0.1(localhost)を一番面白く表記できた奴が優勝

要約

前書き

IPアドレスとは

localhostとは

さっそく試してみる

0, Webサーバーを立てる

1, 127.0.0.1

2, 127.0.1

3, 127.1

4, 2130706433

5, 0x7F000001

6, 017700000001

何故いろんな表記ができるのか？

実用イメージ

1, `127.0.0.1`

2, `127.0.1`

3, `127.1`

4, `2130706433`

5, `0x7F000001`

6, `017700000001`