0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

bash仮想ネットワークファイルのお相手としての StreamRelay.NET.exe

Last updated at Posted at 2017-07-20

bash仮想ネットワークファイルのお相手としての StreamRelay.NET.exe

bash には仮想ネットワークファイルというものがあって、

bash < /dev/tcp/192.0.2.1/90 > /dev/tcp/192.0.2.1/91

のように、192.0.2.1:90 を入力源、192.0.2.1:91 を出力先というように、ネットワークへリダイレクトする事ができる。
この入出力を一本化(一本のTCPコネクション)する事もできるが、この入力に一本、出力にも一本、合計2本の相手として、通常は、netcat(nc.exe)を2つ起動する事になると思うが、StreamRelay.NET.exe なら一つでよい。


具体例(bash と同等)

bash < /dev/tcp/192.0.2.1/90 > /dev/tcp/192.0.2.1/91

StreamRelay.NET.exe -LocalPort -1 -LocalProgram cmd.exe -RemotePort 90 -RemoteHost 192.0.2.1 -RemoteHost2nd 192.0.2.1 -RemotePort2nd 91 -RemoteSeparateConnection

cmd.exe の入力と出力が、2本の TCP コネクションに分かれるので、上記の bash の簡易リモートシェルと同等になる


具体例(bash の相手)

bash < /dev/tcp/192.0.2.1/90 > /dev/tcp/192.0.2.1/91

StreamRelay.NET.exe -LocalPort -1 -LocalProgram cmd.exe -RemotePort 90 -RemoteHost 192.0.2.1 -RemoteHost2nd 192.0.2.1 -RemotePort2nd 91 -RemoteSeparateConnection

の相手をするには↓な感じ

StreamRelay.NET.exe -LocalPort 91 -LocalPort2nd 90 -RemotePort 0 -LocalProxy netstream:///?OutputLf

無印(「-LocalPort」とか「-RemotePort」)が「Read/Input(読み取り)」。
2番目(「-LocalPort2nd」とか「-RemotePort2nd」)が「Write/Output(書き込み)」

さらに、bashへの入力時に「CrLf」→「Lf」に置換する必要があるだろう。


UDPにも対応

対応してみたけど、↓のUDPの通信が発生しないのでダメかも知れない。

bash < /dev/tcp/192.0.2.1/90 > /dev/udp/192.0.2.1/91

なので、まず出力してUDP通信が発生するようにする

(bash --version && bash)< /dev/tcp/192.0.2.1/90 > /dev/udp/192.0.2.1/91

StreamRelay.NET.exe -LocalPort -1 -LocalProgram cmd.exe -RemotePort 90 -RemoteHost 192.0.2.1 -RemoteHost2nd 192.0.2.1 -RemotePort2nd 91 -RemoteSeparateConnection -RemoteUdp2nd

の相手をするには↓な感じ

StreamRelay.NET.exe -LocalPort 91 -LocalPort2nd 90 -LocalUdp -RemotePort 0 -LocalProxy netstream:///?OutputLf


UDPにも対応(注意点)

UDP にも対応してみたが、UDP の場合は、一度通信が発生しないと接続しないので(つまり、相手から読み込むのに相手がデータを送信しない)、うまく接続できないかもしれない。

StreamRelay.NET.exe側としては、「Remote」と呼称される側の読み込み(RemotePortで指定される接続)がUDPの場合、適当なデータを送信して、接続を確立させる。

一方で、「Local」と呼称される側の書き込み(LocalPort2ndで指定される側の接続)がUDPの場合、相手側で適当なデータを送信してくれないと、接続が確立されない(つまり、書き込みできない)。
さらには、書き込み側の接続が確立できないので、読み込み側の接続だけで、読み書きの接続とするわけにはいかないので、結局「Local」と呼称される側の接続が確立されない、という事になるかもしれない。


具体例(bash の相手)(一つの待機サービスで、接続順で{読み込み→書き込み}で2本で、1本の入出力ストリーム)

StreamRelay.NET.exe -LocalPort 90 -RemotePort 0 -LocalSeparateConnection

一番最初の接続を入力、二番目の接続に出力、というようになる


プラグインstdioTCP.dll

プラグイン stdioTCP.dll は、標準入出力のリダイレクト先をTCPにするので、プラグインstdioTCP.dllを使っても実現できる

具体例(bash と同等)(プラグインstdioTCP.dll)

bash < /dev/tcp/192.0.2.1/90 > /dev/tcp/192.0.2.1/91

StreamRelay.NET.exe -LocalPort -1 -LocalProgram cmd.exe -RemotePort 0 -RemoteInputTCPHost 192.0.2.1 -RemoteInputTCPPort 90 -RemoteOutputTCPHost 192.0.2.1 -RemoteOutputTCPPort 91

具体例(bash の相手)(プラグインstdioTCP.dll)

bash < /dev/tcp/192.0.2.1/90 > /dev/tcp/192.0.2.1/91

StreamRelay.NET.exe -LocalPort -1 -LocalProgram cmd.exe -RemotePort 0 -RemoteInputTCPHost 192.0.2.1 -RemoteInputTCPPort 90 -RemoteOutputTCPHost 192.0.2.1 -RemoteOutputTCPPort 91

の相手をするには↓な感じ

StreamRelay.NET.exe -localport 0 -remoteport 0 -verbose -debugmode -LocalOutputTCPPort 90 -LocalInputTCPPort 91


目次へ戻る

目次というか最初の一歩

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?