我们知道类似WPE等封包重发器是很多GM头疼的一个问题。而RO官服在2011年08月推出的客户端中，已经支持封包加密机制，如果配置得当是可以干掉WPE等封包重发器的。今天我们就重点来研究一下这个神器的封包加密机制的启用方法。
其实在很早之前（2014年初还是2013年底，忘记了），Herclues就已经支持了封包加密机制了，但是rAthena一直没有实装这个功能，直到了2015年的3月1日才首次支持封包加密机制，并默认启用。
但是默认启用带来的效果有好有坏，有些新手可能会发现怎么新的rAthena无论怎么根据《什么是DIFF客户端以及DIFF工具介绍》提到的方法去Diff客户端，都会在选择角色之后出现连接失败的情况。
这其实是因为在Diff的时候有一个关于封包加密的开关，如果这个开关是关闭的，而rAthena编译出来的默认是打开的，那么就会出现服务器无法识别客户端未加密的封包，而导致无法进入地图。
封包加密机制的作用
RO官服的这套封包（严格来说应该是封包头）加密机制，如果配置得当可以干掉所有WPE类似的封包重发器。但是如果想借助这个机制来防止Openkore等脱机外挂的话，还需要你保护好下面提到的三个密钥不要泄露，否则的话只要知道三个密钥，Openkore等脱机外挂还是可以成功连接到游戏服务器的。
但是由于我们三个密钥肯定都写死在客户端exe里面，所以知道方法的人会很容易找到三个密钥分别是多少，为了保护这三个密钥，你可以选择对DIFF完毕的客户端进行加壳处理，以此增加有心人获取你三个密钥的难度。
封包加密机制有哪些重要组成部分
除了客户端和服务端的支持外，最重要的组成部分就是用来加密封包的三个密钥。这三个密钥在2015年3月之后，可以在服务端的db\packet_db.txt中配置。比如我们作为例子来说最常用的2013-08-07客户端，官服默认自带的三个密钥就是：0x7E241DE0,0x5E805580,0x3D807D80，如下图所示：
这三个密钥必须和客户端DIFF的时候配置的密钥一致，否则启用了封包加密机制的客户端将无法连接上启用了封包加密机制的rAthena服务端。
如何配置客户端的三个密钥
在使用NEMO对客户端进行DIFF的时候，你可以看到有以下三个选项，这三个选项就是用来配置三个封包加密密钥使用的，如下图所示：
这三个选项和三个密钥的对应关系如下表所示：
| Packet First Key Encryption | 第一个密钥 |
| Packet Second Key Encryption | 第二个密钥 |
| Packet Third Key Encryption | 第三个密钥 |
如果不把这三个选项启用（点绿），那么默认表示使用官服的密钥，如果想确认或者修改一下密钥，可以启用这三个选项（点绿他们），当你启用他们时，你会看到目前使用的密钥，如下图所示：
可以看到，客户端第一个密钥是7e241de0，这和我们packet_db.txt中配置的第一组密钥0x7E241DE0是相符的，密钥用的是十六进制，里面的英文大小写无关紧要。此外当你要修改这一个密钥时，前面的0x必须去掉。
你可以把这三个选项都一一启用，并确认他们和你的packet_db.txt里面对应的客户端（比如2013-08-07版的客户端）配置的密钥是否相符，最终你会发现都被你点亮成如下图所示的样子：
但是到了这里还没完，我们只是修改（如果你没修改的话，就当做是确认密钥和packet_db.txt配置的是否一致好了）了三个封包密钥。
客户端是否会使用封包加密机制还有另外一个DIFF选项在控制，那就是：Disable Packet Encryption (Recommended)，如果点亮这个选项，让它显示绿色，那么说明封包加密机制被禁用了，如果不点亮这个选项（让它显示红色），那么表示封包加密机制是启用的，如下图所示：
在这个例子中，我们是为了研究启用封包加密机制的，所以我们要点红它~~ 否则的话就连接不上启用了封包加密的rAthena服务端了。至此客户端的DIFF部分已经修改完毕，可以生成客户端了。
特殊情况，第二个密钥和第三个密钥一致
上面讲到的是一般情况，客户端需要的是三个不同的密钥。但是也有一些特殊情况，比如2013-12-23的客户端，它的第二个和第三个密钥就是一致的，而且在NEMO中如果你企图去修改第二个密钥，会得到以下提示信息：
在本文中，实际上是否为这种特殊情况，对于我们学习如何在DIFF时候修改密钥其实无关紧要，但是在后续我们讲解到生成高强度封包密钥时，就会需要对这种情况展开讲解，所以这里先提及一下。
控制rAthena封包加密机制的开关
在rAthena服务端中，你可以通过修改src\config\core.h中的PACKET_OBFUSCATION开关来控制服务端是否启用封包加密机制，如果想要禁用封包加密机制，那么直接在下面这一行左侧加入//注释掉即可，如下图所示：
在这个例子中，我们主要为了研究封包加密机制，所以就不加//了。修改完毕后，重新编译服务端即可，不知道如何编译服务端的同学可见《立刻动手，编译rAthena仙境传说模拟器》。
让rAthena能使用正确的密钥
我们知道packet_db.txt中配置着很多组密钥（每一个版本的客户端都有一组默认加密密钥），在默认的情况下，rAthena会选择最后一组密钥来作为加密密钥使用，但是实际上我们使用的2013-08-07客户端并不是packet_db.txt中的最后一组密钥，所以这会导致rAthena使用最新的2013-12-23的默认加密密钥，这并不适用于我们刚刚在DIFF时所参照的2013-08-07的加密密钥，如下图所示：
为了解决这个问题，我们必须先找到2013-08-07封包的packet_ver是多少，如下图所示是45：
然后告诉rAthena，请使用packet_ver为45的封包对应的那组packet_keys，也就是上图所示的：0x7E241DE0,0x5E805580,0x3D807D80 那么我们应该如何告诉rAthena使用packet_ver为45的这一组封包密钥呢？很简单，在packet_db.txt的顶部，可以看到一个packet_db_ver选项：
将这个值修改为45之后，保存即可。至此我们已经完成了服务端的一切配置。
进入游戏测试一下
最后我们可以测试一下，启用了封包加密机制后是否可以正常的进入游戏，我这已经能够正常进入啦：
密钥的选择是个大学问
有的同学可能会迫不及待的使用WPE等封包重发器来试试看，启用了封包加密机制后，是否可以防止住WPE等封包重发器。然后可能会惊讶的发现：我擦，好像没作用啊？
别着急，这是因为封包密钥的取值是有学问的，如果密钥的组合不正确，那么就形同虚设（而很遗憾，韩服默认情况下所提供的这些密钥，有一些还真就拦不住WPE这种封包重发器）。
或者是出现刚开始还能拦住WPE封包重发器，但是玩家可能在游戏走来走去打几个怪之后，就又可以使用封包重发器了。由于篇幅原因，我们会在之后讲解如何生成靠谱的高强度封包加密密钥。
希望你得到的收获
看完本章后，希望你能习得以下技能，这样等接下来讲解如何使用高强度密钥时，你会更加轻松一些：
1、能DIFF出一个支持封包加密的客户端
2、知道如何在DIFF时修改三个封包密钥，以及可能会出现的特殊情况
3、知道如何控制服务端是否启用封包加密机制