(1)序列号保护机制
数学算法一项都是密码加密的核心，但在一般的软件加密中，它似乎并不太为人们关心，因为大多数时候软件加密本身实现的都是一种编程的技巧。但近几年来随着序列号加密程序的普及，数学算法在软件加密中的比重似乎是越来越大了。
我们先来看看在网络上大行其道的序列号加密的工作原理。当用户从网络上下载某个shareware——共享软件后，一般都有使用时间上的限制，当过了共享软件的试用期后，你必须到这个软件的公司去注册后方能继续使用。注册过程一般是用户把自己的私人信息(一般主要指名字)连同信用卡号码告诉给软件公司，软件公司会根据用户的信息计算出一个序列码，在用户得到这个序列码后，按照注册需要的步骤在软件中输入注册信息和注册码，其注册信息的合法性由软件验证通过后，软件就会取消掉本身的各种限制，这种加密实现起来比较简单，不需要额外的成本，用户购买也非常方便，在互联网上的软件80%都是以这种方式来保护的。
我们注意到软件验证序列号的合法性过程，其实就是验证用户名和序列号之间的换算关系是否正确的过程。其验证最基本的有两种，一种是按用户输入的姓名来生成注册码，再同用户输入的注册码比较，公式表示如下：
序列号 = F(用户名)
但这种方法等于在用户软件中再现了软件公司生成注册码的过程，实际上是非常不安全的，不论其换算过程多么复杂，解密者只需把你的换算过程从程序中提取出来就可以编制一个通用的注册程序。
另外一种是通过注册码来验证用户名的正确性，公式表示如下：
用户名称 = F逆(序列号) (如ACDSEE,小楼注)
这其实是软件公司注册码计算过程的反算法，如果正向算法与反向算法不是对称算法的话，对于解密者来说，的确有些困难，但这种算法相当不好设计。
于是有人考虑到一下的算法：
F1(用户名称) = F2(序列号)
F1、F2是两种完全不同的的算法，但用户名通过F1算法的计算出的特征字等于序列号通过F2算法计算出的特征字，这种算法在设计上比较简单，保密性相对以上两种算法也要好的多。如果能够把F1、F2算法设计成不可逆算法的话，保密性相当的好;可一旦解密者找到其中之一的反算法的话，这种算法就不安全了。一元算法的设计看来再如何努力也很难有太大的突破，那么二元呢?
特定值 = F(用户名，序列号)
这个算法看上去相当不错，用户名称与序列号之间的关系不再那么清晰了，但同时也失去了用户名于序列号的一一对应关系，软件开发者必须自己维护用户名称与序列号之间的唯一性，但这似乎不是难以办到的事，建个数据库就好了。当然你也可以根据这一思路把用户名称和序列号分为几个部分来构造多元的算法。
特定值 = F(用户名1，用户名2，...序列号1，序列号2...)
现有的序列号加密算法大多是软件开发者自行设计的，大部分相当简单。而且有些算法作者虽然下了很大的功夫，效果却往往得不到它所希望的结果。其实现在有很多现成的加密算法可以用，如RSADES,MD4,MD5,只不过这些算法是为了加密密文或密码用的，于序列号加密多少有些不同。我在这里试举一例，希望有抛砖引玉的作用：
1、在软件程序中有一段加密过的密文S
2、密钥 = F(用户名、序列号) 用上面的二元算法得到密钥
3、明文D = F-DES(密文S、密钥) 用得到的密钥来解密密文得到明文D
4、CRC = F-CRC(明文D) 对得到的明文应用各种CRC统计
5、检查CRC是否正确。最好多设计几种CRC算法，检查多个CRC结果是否都正确
用这种方法，在没有一个已知正确的序列号情况下是永远推算不出正确的序列号的。
(2)如何攻击序列号保护
要找到序列号，或者修改掉判断序列号之后的跳转指令，最重要的是要利用各种工具定位判断序列号的代码段。这些常用的API包括GetDlgItemInt, GetDlgItemTextA, GetTabbedTextExtentA, GetWindowTextA, Hmemcpy (仅仅Windows 9x), lstrcmp, lstrlen, memcpy (限于NT/2000)。 | 
