当SYN数据包的发送速度大幅提高后，校验和计算成了自然成了不可忽视的一部分。
传统的Checksum算法网上随便一搜一大堆，甚至不少攻击器也是用此算法。该算法并没有什么缺点，具有普遍性，可计算任意数据任意长度的Checksum。对于SYN包那样很短并且每次都是固定长度的包，这种算法显然有些累赘了。我们不妨仔细分析下Checksum算法的原理:
USHORT ChechkSum(USHORT *buffer, int size)
{
DWORD chkSum = 0;
while(size > 1)
{
chkSum += *buffer++;
size -= sizeof(USHORT);
}
if(size)
chkSum += *(UCHAR*)buffer;
chkSum = (chkSum >> 16) + (chkSum & 0xffff);
chkSum += (chkSum >> 16);
return (USHORT)(~chkSum);
}
下面不考虑长度为奇数的情况。先看循环里面的代码，事实上只是把这些数据当作一个USHORT[]，计算这个数组的和而已。即使数据的内容不一样，但只要这个累加的和不变，那后面不管对其做什么运算，函数结果肯定是一样的。简单的说：不同的数据可能有相同的和，必然也有相同的校验和。比如1+2+3=3+2+1=2+2+2，和都是6，所以他们也有相同的校验和。
既然是这样的算法,我们就可以大作优化了。比如一个固定数组：USHORT A[10]。他的和一共有65535*10+1种情况。这个应该很好理解：如果10个数全是0，那和也是0；反之全是最大数65535，那么和是655350；其余情况就在这之间波动。由此可见，N字长的数据校验和其实也只有65535*N+1种情况。在本程序中计算TCP校验和的数据有20字长(40字节)，其结果也只有1,310,699种。如果你在思考的话一定也想到了经典的空间换时间算法。没错，正是如此！即使事先把这几个数的校验和全部计算好保存起来，也仅需2.5M的内存空间。不过问题是，以后如何去利用表里的这些缓存数据？
因为这是一张“和”与“校验和”的映射表，所以当“和”确定后即可获得“校验和”。因此在预先填充数据包的时候，可变的字段一定要置0，然后计算出这个半成品包的“和”当作“基值”。以后当可变部分填上数据时，比如IP头填上了id字段，那么这个IP头的“和”就是：基值+id，校验和当然就是：表[基值+id]。o(1)的复杂度，够快吧！
当然，如果可变字段超过2个字节就不能这么简简单单的加上就可以了，还要对其做高位合并计算。比如IP头的SrcIP（4个字节）填上了数据，那么：
表[基值 + SUM(SrcIP)]
才是其正确的校验和,具体的SUM运算可以用个宏来定义:
#define HI(VALUE) (VALUE >> 16) #define LOW(VALUE) (VALUE & 0xFFFF) #define SUM(VALUE) (HI(VALUE) + LOW(VALUE))
缓存表的初始化：
USHORT TableChkSum[MAX_TBL_SIZE];
/**************************************************
* 函数：InitChkSumTable
* 注释：初始化Checksum映射表
* 缓存: 字段和(sum) -> 校验和(checksum)
**************************************************/
VOID InitChkSumTable()
{
UINT i;
UINT chkSum;
for(i=0; i<MAX_TBL_SIZE; i++)
{
chkSum = SUM(i);
chkSum += HI(chkSum);
TableChkSum[i] = (USHORT)~chkSum;
}
}
随时随地看视频
