socket( PF_INET, SOCK_RAW, IPPROTO_TCP );
在RedHat 6.1下这两种socket都可以正常建立，内核支持了的。但是对于Solaris 2.6，假如以root身份truss跟踪这两个函数，发现第二个socket建立的时候 内核不支持这种情况下指定IPPROTO_TCP，库函数本身做了处理：
so_socket(2, 4, 6, "", 1) Err#98 EPROTOTYPE
stat("/dev/rawip", 0xEFFFFAC4) = 0
so_socket(2, 4, 6, "/dev/rawip", 1) = 4
setsockopt(4, 65535, 4105, 0xEFFFFBB4, 4) = 0
从执行效果看，这样的处理和Linux下的意义不同了。
假如考虑广泛兼容性，应该扔弃第二种socket，全部以IPPROTO_RAW方式出现。这样的话，理论上可以考虑不用TCP/UDP协议，但是涉及client/server模式，显然应该继
续使用TCP/UDP。从突破防火墙角度看，还是以鬼子的ACK方式为好。UDP通信被很多防火墙屏蔽，TCP也好不到哪里去。而且按照目前的设想，等于仅仅使用TCP的头部概 念，并没有使用TCP协议的超时、重传等机制，更没有有限状态机介入，为什么不使用UDP呢？还是应该从防火墙角度考虑这个设计选择，具体问题具体分析吧。现在的难点是完全使用IPPROTO_RAW，写没多大问题，读有了麻烦，又需要重翻UNP；此外， 丢包是毫无疑问的，因此必须尽量设计成无状态方式(NFS Server就是一个例子)，这 个也仅仅是说说，技术问题尚未可知。
关于内核传递IP报文到一个raw_socket，有几点需要注重，我们分别探讨之：
1) TCP/UDP报文(IP报文负载为TCP/UDP)"永远"不会传递给raw_socket。Stevens介绍
的时候以BSD家族为例。
对于Linux显然已经不适用这个结论，socket( PF_INET, SOCK_RAW, IPPROTO_TCP )
就可以接收到TCP报文，Linux内核是给了这个机会的，此时正常的TCP协议层也会收到TCP报文(后面我们会写测试代码验证它)。于是造成潜在的安全隐患，在无需
数据链路层和网卡混杂模式介入的情况下，利用raw_socket监视发往本机的TCP报文。尽管只有root才可以创建raw_socket，但获得创建raw_socket的机会和获得完整root权限相比要大得多。对于Solaris系统，内核应该是没有支持
socket( PF_INET, SOCK_RAW, IPPROTO_TCP )方式，尽管以root身份执行库函数并没有报错(此时库函数自己做了其他处理)。
对于Windows 2K，从backend拖回来的程序执行效果以及袁哥分析代码的结论看，2K可能支持socket( PF_INET, SOCK_RAW, IPPROTO_TCP )这种方式。抓包分析
backdoor的client/server通信，发现除了预料中的ACK，还夹带有RST，只能说明2K内核传递IP报文到raw_socket的同时传递给了正常的TCP协议层，RST是由正常
TCP协议层发出的。NT/9x估计没戏。
考虑我们要达到的目的，假如内核不给这个机会(传递TCP报文到raw_socket)，意味着ACK方式破产。UDP自然也不用想了。虽然Linux可以，但我们希望得到一个更广泛兼容的backdoor。可以从数据链路层考虑这个问题，牵扯的问题更多，没有太大必要。
2) 对于伯克利实现而言，内核一般处理了几种常见ICMP报文(3种，回应请求、时间戳请求、地址掩码请求)，其余未处理ICMP报文交给raw_socket。注重内核并没有
处理上面三种请求报文的应答报文，想想ping.c的实现，假如内核处理icmp echo reply，即使指定IPPROTO_ICMP，处于应用层的ping也没有机会得到应答报文。这里所说内核处理，都是指处理入IP报文，对于发送IP报文，基本上任
由应用程序处理的，所以ping可以发送自己的icmp echo request。
Linux/Solaris的实现有差别，提供给应用层更多机会。内核处理了icmp echo request，同时会交给socket( PF_INET, SOCK_RAW, IPPROTO_ICMP )，不同于BSD
实现。内核未处理的icmp报文依旧交给raw_socket。这给我们一个机会，编写自己的icmp daemon，利用被内核传递到raw_socket的icmp报文进行交互式通信。从突破防火墙角度考虑，比较现实，一般治理员会答应icmp echo request进入。治理员要是在防火墙上过滤了icmp echo request，估计我们也没有机会在这种敌人内部安装icmp daemon，走先。
3) 所有的IGMP报文交给raw_socket。
同上，可以利用。现在的操作系统好象已经开始在内核里处理igmp，那样的话，机会不大。而且防火墙对IGMP报文比较敏感。
socket( AF_INET, SOCK_RAW, IPPROTO_IGMP )，Linux上可以接收到IGMP报文， Solaris上不行。
4) 假如内核无法理解IP报文头中高层协议类型，传递该报文给raw_socket。
内核无法理解的，对于防火墙也是无法理解的，除非不考虑突破防火墙的网络拓扑，否则暂时别想。此外从前面的测试中看到，Linux/Solaris下必须精确指定第
三个参数可以接收匹配IP报文，假如要利用内核无法理解之协议类型，必须确保该类型可以指定在第三个参数中。
5) IP分片一定是在内核中重组完成了才会传递给raw_socket。
换句话说，raw_socket无法分析IP分片，数据链路层可以。这里隐含着一个意思，IP分片重组永远在内核完成，一旦这部分的处理代码出了问题，就是内核的麻烦，所以死得快。
6) 假如内核决定传递一个IP报文到raw_socket，则系统中所有进程创建的所有raw_socket都会收到这个IP报文，这是一个潜在的安全问题。
我们在测试程序中创建socket( PF_INET, SOCK_RAW,
IPPROTO_ICMP )，启动了两
个实例，然后从其他主机ping本机，两个实例都收到了icmp echo request。
7) 创建socket( PF_INET, SOCK_RAW, 0 )，并且不调用bind、connect，这样的
raw_socket接收所有内核传递上来的IP报文。第三个参数是指定匹配的，假如非
零，不匹配的IP报文不会被传递给该raw_socket。对于这种系统，企图监视本机
所有入IP报文，不需要数据链路层介入，也不要求网卡混杂模式，简单创建一个
raw_socket，指定第三个参数为0即可。
遗憾的是，我们在Linux下测试，根本就不支持第三个参数指定为0，指定成
255(IPPROTO_RAW)也无法达到Stevens描述的效果，255主要用于发送，Stevens介
绍的可能仅仅是BSD实现吧。
关于这个，觉得看看Linux关于raw_socket的实现部分比较好，瞎猜也不是办法。
8) 有些代码使用了raw_socket，并未指定IP_HDRINCL选项。1988年为了解决
traceroute问题引入了一个patch，创建SOCK_RAW时，指定第三个参数为
IPPROTO_RAW(值255)，效果和指定IP_HDRINCL选项一样，还更方便些。
--------------------------------------------------------------------------
/*
* For Solaris
* gcc -O3 -o raw raw.c -lsocket -lnsl
*
* For Linux
* gcc -O3 -o raw raw.c
*/
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#define SUCCESS 0
#define FAILURE -1
int recvSocket;
u_char packet[ 1500 ];
void Close ( int fd )
{
if ( close( fd ) == -1 )
{
perror( "close" );
exit( FAILURE );
}
return;
} /* end of Close */
void outputBinary ( const unsigned char * byteArray, const size_t byteArrayLen )
{
u_long offset;
int i, j, k;
fprintf( stderr, "byteArray [ %lu bytes ] ---- \n", byteArrayLen );
if ( byteArrayLen
{
return;
}
i = 0;
offset = 0;
for ( k = byteArrayLen / 16; k 0; k--, offset += 16 )
{
fprintf( stderr, "%08X ", offset );
for ( j = 0; j
{
if ( j == 8 )
{
fprintf( stderr, "-%02X", byteArray[i] );
}
else
{
fprintf( stderr, " %02X", byteArray[i] );
}
}
fprintf( stderr, " " );
i -= 16;
for ( j = 0; j
{
/* if ( isprint( (int)byteArray[i] ) ) */
if ( ( byteArray[i] = ' ' ) && ( byteArray[i]
{
fprintf( stderr, "%c", byteArray[i] );
}
else
{
fprintf( stderr, "." );
}
}
fprintf( stderr, "\n" );
} /* end of for */
k = byteArrayLen - i;
if ( k
{
return;
}
fprintf( stderr, "%08X ", offset );
for ( j = 0 ; j
{
if ( j == 8 )
{
fprintf( stderr, "-%02X", byteArray[i] );
}
else
{
fprintf( stderr, " %02X", byteArray[i] );
}
}
i -= k;
for ( j = 16 - k; j 0; j-- )
{
fprintf( stderr, " " );
}
fprintf( stderr, " " );
for ( j = 0; j
{
if ( ( byteArray[i] = ' ' ) && ( byteArray[i]
