VC中利用CRC校验码为BMP图设置水印
本文摘自http://dev.yesky.com/249/2129749.shtml
一、 引言
进入数字时代后,我们不得不为电子文档的真实性和原始性的鉴定而苦恼,虽然相应的有了数字签名、身份的安全认证等诸多手段,但对某些特殊行业并不太适合,比如我们在传送电子邮件时希望接收方收到的是从确实是从发送方发出的、并且是发出后未经过任何处理的。这就有两点要求:其一为身份的确认,必须是从发送方发出来的,这方面技术已经比较成熟,可以用数字签名等方式来保证,接收方在验证了数字签名的有效性后即可认为确实是从发送方发来的;第二点要求是该文件在传输过程中不能被经过任何的处理,即该文件的内部结构、内容信息等不能发生任何的改变, 如果发生了变化就应能鉴别出该文件不是最原始的文件,这就需要在发送方独立的根据此文件对该文件的原始性做出判断,数字签名等技术在此就无用武之地了,因为在邮寄中途对文件作改动的破坏者会绕过数字签名,而仅仅对其关心的某段信息进行改动。本文下面就以对BMP位图设置印鉴水印为例对上述问题的解决提供一种思路。
二、 BMP位图的内部结构
由于邮件接收方必须根据收到的仅有的一个文件(此处为一幅BMP位图)对其原始性做出判断,那么用来标识该文件的信息只有隐藏在该文件中才能被接收者识别出来,而且该信息不能隐藏到文件的内容信息区中(此处为位图点阵),因为如果这样的话在设置印鉴的同时就已经把原始内容破坏了,文件也就失去了原始性了。因此我们所设置的印鉴水印必须设置到标识文件结构的保留字段中,所以在处理之前有必要对文件的内部结构作些了解。下表就是我们所要研究的对象BMP位图的内部结构:
从上表可以看出,我们设置的印鉴水印只能放在第6--9字节之间的这两段保留字段中。才不会破坏文件的内容和整体结构。
三、用CRC校验码作为印鉴的可靠性能
在网络通讯中经常会用到CRC循环冗余校验码,并广泛的应用于报文的检错。在网络中对报文检错的工作环境同本文的有些类似:都是接收方根据发送方发来的数据来判断这段数据到底是不是同发送方发送时的内容一模一样。我们不妨把发送方发送出来的BMP位图当作一个大报文,对其加上CRC校验,把通常放在帧尾的CRC校验码放到BMP位图的保留字段中,这样接收方只须象网络中的检验报文一样看看校验码的正确与否即可断定出该位图是否被作过处理。
CRC校验码是基于将位串看作是系数为0或1的多项式,一个k位的数据流可以看作是关于x的从k-1阶到0阶的k次多项式的系数序列。采用此编码,发送方和接收方必须事先商定一个生成多项式G(x),其高位和低位必须是1。要计算m位的帧M(x)的校验和,基本思想是将校验和加在帧的末尾,使这个带校验和的帧的多项式能被G(x)除尽。当接收方收到加有校验和的帧时,用G(x)去除它,如果有余数,则CRC校验错误,只有没有余数的校验才是正确的。具体计算校验和的算法如下:
1. 设G(x)为r阶,在帧末尾附加r个0,将帧扩展到m+r位长。
2. 按模2除法用对应于G(x)的位串去除对应于扩展后的M(x)的位串。
3. 按模2减法从对应于扩展后的M(x)的位串中减去余数,其结果就是要传送的带校验和的帧T(x)了。
我们在使用之前有必要对该校验方法的可靠性能做一下分析,如果内容数据做了改动,正确的T(x)位串变成了T(x)+E(x)。在E(x)中每一位都对应着要转换的一位。如果E(x)中有k个1位,那么就会发生k个单个错误。一旦接收方用G(x)去除,即计算[T(x)+E(x)]/G(x),而T(x)/G(x)=0,所以其结果为E(x)/G(x)。除了是G(x)整倍数的多项式差错检测不到以外,其他错误都可以捕获到。如果E(x)中发生单个位(I 位)错误,若G(x)包括至少I项,就永远也除不尽E(x),换句话说,所有单个位错误都可以被检测出来。另外,如果集中差错长度为r+1时,而且当集中差错和G(x)一样时,被G(x)除的余数也可能为0。根据集中差错的定义第一位和最后一位必须是1,因此,集中差错是否同G(x)一样取决于其余的r-1位。如果所有的0、1排列情况出现概率均等,那么图片被更改而没有被检出的概率就是1/2^(r-1)。按照现在流行的四种已成为国际标准的多项式:V.41的CRC-CCITT、ANSI的CRC-16以及CRC-12和CRC-32,他们的r值分别为16、16、12、32,漏检的概率在0.00000000002~0.000244之间,这样的概率还是令人满意的。
经过以上的分析,采用CRC循环冗余校验码作为检测BMP位图是否被改动的印鉴水印是可靠、合理的。接下来就通过一段Microsoft Visual C++ 6.0的程序片段来完成对此算法的具体实现
四、示例程序的设计实现
首先我们把本文中最关键的用于产生CRC校验和(余数)的函数CheckOut()的实现部分主要代码做了介绍,其中为了减少运算量、方便编程、将烦琐的多项式长除取余的过程按照前面讲述的CRC算法的运算过程和原理将其预先设定在一个256字节长的数组表CheckTable中,实际运算时只须按索引对其查表即可:
该函数的两个入口形参BYTE *byteData和 UINT nCount分别表示要计算CRC校验码的数据流和该数据流的长度。函数返回值为计算出来的CRC校验码,其他函数只须简单的调用此函数即可得到关于某段数据序列的校验码,下面是为BMP 位图设置印鉴的部分主要代码:
至于检验文件是否经过处理的代码和前面的设置印鉴的代码是非常类似的,也是先将文件读取到缓存中,只是要把存放在第六字节保留字段中的印鉴水印重新恢复到数据序列的末尾,然后再把该序列被G(x)除,通过判断能否整除即可断定该文件是否曾被改动过:
小结:
本文对CRC校验在文件印鉴水印方面的应用做了简要的介绍,在对CRC 校验和其他文件格式有了更深入的了解后,对本文的代码稍加改动,就可以对其他格式的文件设置类似的印鉴水印。本程序在Windows2000 Professional下,由Microsoft Visual C++ 6.0编译调试通过
一、 引言
进入数字时代后,我们不得不为电子文档的真实性和原始性的鉴定而苦恼,虽然相应的有了数字签名、身份的安全认证等诸多手段,但对某些特殊行业并不太适合,比如我们在传送电子邮件时希望接收方收到的是从确实是从发送方发出的、并且是发出后未经过任何处理的。这就有两点要求:其一为身份的确认,必须是从发送方发出来的,这方面技术已经比较成熟,可以用数字签名等方式来保证,接收方在验证了数字签名的有效性后即可认为确实是从发送方发来的;第二点要求是该文件在传输过程中不能被经过任何的处理,即该文件的内部结构、内容信息等不能发生任何的改变, 如果发生了变化就应能鉴别出该文件不是最原始的文件,这就需要在发送方独立的根据此文件对该文件的原始性做出判断,数字签名等技术在此就无用武之地了,因为在邮寄中途对文件作改动的破坏者会绕过数字签名,而仅仅对其关心的某段信息进行改动。本文下面就以对BMP位图设置印鉴水印为例对上述问题的解决提供一种思路。
二、 BMP位图的内部结构
由于邮件接收方必须根据收到的仅有的一个文件(此处为一幅BMP位图)对其原始性做出判断,那么用来标识该文件的信息只有隐藏在该文件中才能被接收者识别出来,而且该信息不能隐藏到文件的内容信息区中(此处为位图点阵),因为如果这样的话在设置印鉴的同时就已经把原始内容破坏了,文件也就失去了原始性了。因此我们所设置的印鉴水印必须设置到标识文件结构的保留字段中,所以在处理之前有必要对文件的内部结构作些了解。下表就是我们所要研究的对象BMP位图的内部结构:
| 文件块 | 类型 | 字段 | 地址 | 说明 |
| BMP文件头 | Int | BfType | 0--1 | 规定必须是"BM"作为识别BMP文件的标志 |
| Long | BfSize | 2--5 | 给出了文件的长度,单位为字节 | |
| Int | BfReserved1 | 6--7 | 保留,平时为0 | |
| Int | BfReserved2 | 8--9 | 保留,平时为0 | |
| Long | BfOffbits | 10--13 | 给出了位图阵列相对于文件头的偏移 | |
| 点位图信息 | Long | Width | 18--21 | 给出了位图的宽度 |
| Long | Height | 24--27 | 给出了位图的高度 | |
| Int | BitCount | 28--29 | 像素的位数,如24为24位真彩、8为256色等 | |
| Long | BitSizeImage | 34--37 | 确定图像字节数的多少,但通常此项为0 | |
| 位图阵列 | 从第38字节开始,位图阵列中保存有全部图像像素的RGB三分量值。 | |||
从上表可以看出,我们设置的印鉴水印只能放在第6--9字节之间的这两段保留字段中。才不会破坏文件的内容和整体结构。
三、用CRC校验码作为印鉴的可靠性能
在网络通讯中经常会用到CRC循环冗余校验码,并广泛的应用于报文的检错。在网络中对报文检错的工作环境同本文的有些类似:都是接收方根据发送方发来的数据来判断这段数据到底是不是同发送方发送时的内容一模一样。我们不妨把发送方发送出来的BMP位图当作一个大报文,对其加上CRC校验,把通常放在帧尾的CRC校验码放到BMP位图的保留字段中,这样接收方只须象网络中的检验报文一样看看校验码的正确与否即可断定出该位图是否被作过处理。
CRC校验码是基于将位串看作是系数为0或1的多项式,一个k位的数据流可以看作是关于x的从k-1阶到0阶的k次多项式的系数序列。采用此编码,发送方和接收方必须事先商定一个生成多项式G(x),其高位和低位必须是1。要计算m位的帧M(x)的校验和,基本思想是将校验和加在帧的末尾,使这个带校验和的帧的多项式能被G(x)除尽。当接收方收到加有校验和的帧时,用G(x)去除它,如果有余数,则CRC校验错误,只有没有余数的校验才是正确的。具体计算校验和的算法如下:
1. 设G(x)为r阶,在帧末尾附加r个0,将帧扩展到m+r位长。
2. 按模2除法用对应于G(x)的位串去除对应于扩展后的M(x)的位串。
3. 按模2减法从对应于扩展后的M(x)的位串中减去余数,其结果就是要传送的带校验和的帧T(x)了。
我们在使用之前有必要对该校验方法的可靠性能做一下分析,如果内容数据做了改动,正确的T(x)位串变成了T(x)+E(x)。在E(x)中每一位都对应着要转换的一位。如果E(x)中有k个1位,那么就会发生k个单个错误。一旦接收方用G(x)去除,即计算[T(x)+E(x)]/G(x),而T(x)/G(x)=0,所以其结果为E(x)/G(x)。除了是G(x)整倍数的多项式差错检测不到以外,其他错误都可以捕获到。如果E(x)中发生单个位(I 位)错误,若G(x)包括至少I项,就永远也除不尽E(x),换句话说,所有单个位错误都可以被检测出来。另外,如果集中差错长度为r+1时,而且当集中差错和G(x)一样时,被G(x)除的余数也可能为0。根据集中差错的定义第一位和最后一位必须是1,因此,集中差错是否同G(x)一样取决于其余的r-1位。如果所有的0、1排列情况出现概率均等,那么图片被更改而没有被检出的概率就是1/2^(r-1)。按照现在流行的四种已成为国际标准的多项式:V.41的CRC-CCITT、ANSI的CRC-16以及CRC-12和CRC-32,他们的r值分别为16、16、12、32,漏检的概率在0.00000000002~0.000244之间,这样的概率还是令人满意的。
经过以上的分析,采用CRC循环冗余校验码作为检测BMP位图是否被改动的印鉴水印是可靠、合理的。接下来就通过一段Microsoft Visual C++ 6.0的程序片段来完成对此算法的具体实现
四、示例程序的设计实现
首先我们把本文中最关键的用于产生CRC校验和(余数)的函数CheckOut()的实现部分主要代码做了介绍,其中为了减少运算量、方便编程、将烦琐的多项式长除取余的过程按照前面讲述的CRC算法的运算过程和原理将其预先设定在一个256字节长的数组表CheckTable中,实际运算时只须按索引对其查表即可:
| BYTE CCRCDlg::CheckOut(BYTE *byteData, UINT nCount) { …… static BYTE CheckTable[256]= { 0x00,0x07,0x0e,0x09,0x1c,0x1b,0x12,0x15,0x38,0x3f, 0x36,0x31,0x24,0x23,0x2a,0x2d,0x70,0x77,0x7e,0x79, 0x6c,0x6b,0x62,0x65,0x48,0x4f,0x46,0x41,0x54,0x53, 0x5a,0x5d,0xe0,0xe7,0xee,0xe9,0xfc,0xfb,0xf2,0xf5, 0xd8,0xdf,0xd6,0xd1,0xc4,0xc3,0xca,0xcd,0x90,0x97, 0x9e,0x99,0x8c,0x8b,0x82,0x85,0xa8,0xaf,0xa6,0xa1, 0xb4,0xb3,0xba,0xbd,0xc7,0xc0,0xc9,0xce,0xdb,0xdc, 0xd5,0xd2,0xff,0xf8,0xf1,0xf6,0xe3,0xe4,0xed,0xea, 0xb7,0xb0,0xb9,0xbe,0xab,0xac,0xa5,0xa2,0x8f,0x88, 0x81,0x86,0x93,0x94,0x9d,0x9a,0x27,0x20,0x29,0x2e, 0x3b,0x3c,0x35,0x32,0x1f,0x18,0x11,0x16,0x03,0x04, 0x0d,0x0a,0x57,0x50,0x59,0x5e,0x4b,0x4c,0x45,0x42, 0x6f,0x68,0x61,0x66,0x73,0x74,0x7d,0x7a,0x89,0x8e, 0x87,0x80,0x95,0x92,0x9b,0x9c,0xb1,0xb6,0xbf,0xb8, 0xad,0xaa,0xa3,0xa4,0xf9,0xfe,0xf7,0xf0,0xe5,0xe2, 0xeb,0xec,0xc1,0xc6,0xcf,0xc8,0xdd,0xda,0xd3,0xd4, 0x69,0x6e,0x67,0x60,0x75,0x72,0x7b,0x7c,0x51,0x56, 0x5f,0x58,0x4d,0x4a,0x43,0x44,0x19,0x1e,0x17,0x10, 0x05,0x02,0x0b,0x0c,0x21,0x26,0x2f,0x28,0x3d,0x3a, 0x33,0x34,0x4e,0x49,0x40,0x47,0x52,0x55,0x5c,0x5b, 0x76,0x71,0x78,0x7f,0x6a,0x6d,0x64,0x63,0x3e,0x39, 0x30,0x37,0x22,0x25,0x2c,0x2b,0x06,0x01,0x08,0x0f, 0x1a,0x1d,0x14,0x13,0xae,0xa9,0xa0,0xa7,0xb2,0xb5, 0xbc,0xbb,0x96,0x91,0x98,0x9f,0x8a,0x8d,0x84,0x83, 0xde,0xd9,0xd0,0xd7,0xc2,0xc5,0xcc,0xcb,0xe6,0xe1, 0xe8,0xef,0xfa,0xfd,0xf4,0xf3 }; …… BYTE Result = CheckTable[*byteData]; for(UINT i=1;i<nCount;i++)//对数据流进行CRC校验和计算 { Result = Result^(*(byteData+i)); Result = CheckTable[Result]; } …… return Result;//返回计算出来的CRC校验和。 } |
该函数的两个入口形参BYTE *byteData和 UINT nCount分别表示要计算CRC校验码的数据流和该数据流的长度。函数返回值为计算出来的CRC校验码,其他函数只须简单的调用此函数即可得到关于某段数据序列的校验码,下面是为BMP 位图设置印鉴的部分主要代码:
| …… //首先读取文件到缓存中去,并得到文件的长度 file.Open(FileName,CFile::modeReadWrite); int FileLen=file.GetLength(); //为缓存动态分配内存空间 BYTE* buf; buf=new BYTE [FileLen]; file.SeekToBegin(); file.Read(buf,FileLen); //调用CheckOut函数计算BMP位图的位图阵列部分(38字节以后部分)的CRC校验码 BYTE crc=CheckOut(buf+38,FileLen-38); //在前面提到过模2减法,在以2为模的加、减法中,都是和异或运算相同的。 //把经过模2减法的计算结果保存到BMP位图的保留空间中 buf[6]=0^crc; file.Seek(6,CFile::begin); file.Write(buf+6,1); //释放申请过的内存空间、关闭打开的文件 delete[] buf; file.Close(); …… |
至于检验文件是否经过处理的代码和前面的设置印鉴的代码是非常类似的,也是先将文件读取到缓存中,只是要把存放在第六字节保留字段中的印鉴水印重新恢复到数据序列的末尾,然后再把该序列被G(x)除,通过判断能否整除即可断定该文件是否曾被改动过:
| …… file.Open(FileName,CFile::modeReadWrite); int FileLen=file.GetLength(); …… //读取文件到缓存 BYTE* buf; buf=new BYTE [FileLen+1]; file.SeekToBegin(); file.Read(buf,FileLen); file.Close(); //将印鉴恢复到数据序列的末尾 buf[FileLen]=buf[6]; //计算带有校验码(印鉴)的序列被G(x)标准多项式整除的余数 BYTE crc=CheckOut(buf+38,FileLen-37); //判断crc(余数)是否为0(即能否整除),来判定文件的原始性。 if(crc!=0) AfxMessageBox("警告!文件被改动过了!"); //CRC校验错误!印鉴有损。 else AfxMessageBox("文件没有发生过改动!"); //CRC校验正确,印鉴完好。 delete[] buf; …… |
小结:
本文对CRC校验在文件印鉴水印方面的应用做了简要的介绍,在对CRC 校验和其他文件格式有了更深入的了解后,对本文的代码稍加改动,就可以对其他格式的文件设置类似的印鉴水印。本程序在Windows2000 Professional下,由Microsoft Visual C++ 6.0编译调试通过
浙公网安备 33010602011771号