柳鲲鹏

　　上文说CDKEY具有天然容易破解的问题。那么怎么改进呢？就是使用公钥体系，软件自带公钥，公司使用私钥。简单办法：使用许可文件。 复杂方法：联网验证。使用公钥体系。软件工具自带公钥。 联网时，软件向服务器发个消息。 服务器返回一个使用私钥加密的数据。 软件使用公钥解密。 校验。就是检查是否包含特写字串，或者某些字节。　　这样是不是就万无一失呢？也不尽然。可以通过破解软件，找到判断及跳转的那一段代码并进行修改，也能正常使用。　　那我每次对软件进行校验呢？一个是会导致性能问题，另外一个就

　　CDKEY天然的不安全。因为CDKEY制作时使用的是对称算法，在校验的时候，需要加密的KEY。也就是软件安装以后，一定在某个位置保存了这个KEY。找到这个KEY，事情自然好办。　　简单的KEY文件隐藏：改名。 分散。把KEY分成几个文件，放在不同位置。 放在代码里。比如转换为数组放在代码里。 二次加密。就是搞得更啰嗦一些。 代码混乱法。即通过一些位置变换、位变换，让KEY变形。　　无论怎样，这只是治标。我们也不应该花过多精力在这上面。如果对方想用，总是有办法的。我们也鼓励试用，适应产品

　　CDKEY已经产生出来了。也许有朋友会问：吾产生的CDKEY怎么看着不够乱啊？有没有办法？构造原始数据时，让序列号在头部、尾部都有体现。 使用的加密算法。不同加密算法处理结果不同，结合第一点处理。 对构建数据、加密数据进制字节顺序调整。 转换为CDKEY时，字符顺序调整。比如ABCD，你就改成CBAD。　　测试时产生10个，就可以看到混乱程度了。...

　　经过加密，我们得到了16个字节的数据。现在就要转换为显示字串，也就是CDKEY了。怎么转换呢？这是思路：显示的字串，只能是26个字母+10个数字的全部36个或部分。比如说，0和O太类似，以前印刷时不容易区分，所以不用，就变成了34个。泰山OFFICE就使用的34个字符。。 我们把16字节看成一个数。非常大的数。 于是现在的思路就是：如何用34个字符，表示这个数？很简单啊，把10进制转换为34进制就可以了。　　这个转换有点麻烦，可以利用已有的代码，比如JAVA直接提供了BigInteger进制操

　　前文说过， CDKEY原始数据构造好了，直接出CDKEY看起来太有规律，所以要处理一下。怎样处理？加密。加密有几种办法：不可逆加密，错。不可逆加密之后，没法验证数据对错。 非对称加密，即公钥加密，错。加密后的数据太长。 对称加密，长度不变，对。吾以前在研究数据加密的时候，记得有的算法可以做到多少字节处理后，长度依然保持。流加密？Bigfish？ 对称加密，长度变化，对。15字节加密为16字节（8的整数）。　　吾建议使用最后一种，对称加密，长度变化，15字节加密为16字节。这个选择较多，如DE

　　要制作CDKEY，就需要原始数据。这个原始数据的要求是怎样的呢？CDKEY的基础是序列号。 数据长度15个字节。为什么呢？这是加密算法的要求：15个字节加密后变成16个字节，16个字节加密后变成24个字节，24个字节没法处理。 数据应该是可显示字符。每个字节在33-127之间，最大进行是95。具体可以根据自己需要处理了。　　数据结构已经确定了，现在开始构建数据序列号区。6-10个字节。如前所述，序列号要进行进制转换（这不是必须的）。 信息区，比如数据的结构版本号，产品名，产品版本号，国家

　　需要说明的是，CDKEY对于软件的保护是有限的。CDKEY用于大批量软件的授权。人家花钱购买了个软件，怎样证明是购买的呢？有个CDKEY。比如说：如果某单位批量购买泰山OFFICE，就需要一批CDKEY（单个或批量）。 如果是专用软件，比如安装服务器，就没有必要使用CDKEY这种授权方式了。 兴趣爱好。吾看着CDKEY就是觉得好玩，想自己研究学习。　　CDKEY国际水平都是25字长。这是为什么？因为这是算出来的，没法再少了。吾称自己为CDKEY砖家，就是因为吾实现了25字长的CDKEY。　

CDKEY简介及应用场景 CDKEY数据构造 CDKEY加密 CDKEY转换 CDKEY混乱 CDKEY破解 CDKEY升级思路

　　有人听了就奇怪，这CDKEY长度不是随意的吗？当然不是随意的。经过一套流程下来，长度是固定的。而这个算法流程导致长度是固定的，要改长度就要改流程。关于CDKEY长度，吾经历过三个阶段：长度29　　多年以前，那位张同事搞了个CDKEY算法（永中OFFICE），长度是29。大家知道正常来说CDKEY长度应该是25，怎么是29呢？他表示没办法。按照这套算法，必须是29，一个也少不了。　　吾随即说，29也太怪异了，你改为30也行啊。他说不行（据此可以判断算法是抄的）。可以被一个字节的0，那也太明显了。

　　很多人因为某些情形，使用了一些破解软件。有的破解软件会提供一个CDKEY产生机。有人觉得奇怪，这是怎么搞出来的？　　这个问题的产生，其实是因为CDKEY的机制。CDKEY使用对称算法，软件本身带有解密用的密钥。只要找到这个密钥，产生CDKEY自然就简单了。　　为什么要使用对称算法呢？首先要排除不可逆算法。如果使用不可逆算法，无法判断结果是否正确。 如果使用非对称呢？非对称产生的密文太长（最少32字节，一般是64字节），转移为CDKEY太长了（起码40），很不方便。　　其实，如果有人想买，

　　之前同事已经做过一版（吾当时就指点了思路，不听）。做出来的CDKEY实在是太业余，意思就是看着不够乱。　　按理说，这工作已经完成了，头目也满意了，又跟吾无关，吾凑什么热闹？没看到也就算了，既然看到了，看着这样的工作，吾实在是……觉得太可笑，太丢脸……爱管闲事的毛病又来了。怎么办？没有人，而且除了吾别人也没那个能力，所以只能自己亲自搞了。　　很久以前，某同事搞过CDKEY。他自己也很得意，简单的说过流程。他为什么会？因为他以前搞过（应该是从别人接手的，他也确实学会了）。吾亦没在意。对于别人来说工作

具体错误：javax.crypto.IllegalBlockSizeException: Data must not be longer than 117 bytes at com.sun.crypto.provider.RSACipher.doFinal(RSACipher.java:347) at com.sun.crypto.provider.RSACipher.engineDoFinal(RSACipher.java:404) at javax.crypto.Cipher.doFinal

　　既然是CDKEY，肯定要加密。那么使用什么算法呢？首先想到的就是非对称加密，如RCA。为什么呢？因为只要公开公钥，私钥不需要公开啊。试了一下：最短密钥长度512，7个char加密后是64字节。CDKEY一般是5x5、5x6、6x6，64表示起来怎么也得72字节吧？　　如果是证书类，比如许可文件，完全可以使用RSA，因为内容可以长一些，1K都可以。只能使用对称加密。对称加密有个坏处，就是密钥是随产品走的。作为CDKEY，也只能这样了。...

DES加密时正常，解密时出错了：java.security.InvalidKeyException: Parameters missing at com.sun.crypto.provider.CipherCore.init(CipherCore.java:469) at com.sun.crypto.provider.DESCipher.engineInit(DESCipher.java:186) at javax.crypto.Cipher.implInit(Cipher.java:805)

　　有效期有两种：永久有效。这个自然不用多说。 年限。这个要以启用时间开始计算。　　永久有效自然不用提了。那么如何控制有效期呢？有两种思路联网时向服务器发送询问消息，服务器返回有效情况。如果是隔离网呢？要么不报错（让用户尽量使用，或者提示联网）；架设认证服务器，由服务器通过代理访问外网检查有效情况。 在机器中记录一些信息。通过更改机器时间是绕不过去的，别人重装机器就可以。 二者结合。现在网络这么发达，总有联网机会。　　要补充的是，有效期处理不宜过于复杂。别人要破解办法多了去了。...

　　比如说，在CDKEY中生效时间，假设是2021/1/1，有效期三年。吾买了之后，直到2022年才用，难道吾有效期就变成两年了？没这个道理吧？　　包含产生时间更是没有任何意义。