谁能破解梦幻西游给你的传说？
众所周知，你的传奇每分钟都会更换6位密码，俗称动态密码。由于客户端(你的传说)出厂后与服务器没有物理上的直接联系，如何与服务器保持逻辑同步是最大的问题，即如何保证客户端生成的动态密码和服务器验证的动态密码是同一个密码？
猜测:客户端生成的动态密码是与时间相关的动态密码，即密码M与时间t之间存在关系:M=rand(TX)，rand()是随机函数，TX是随机函数的种子，x是另一个因子，比如你的图例序号。
这里，X是服务器端的一个已知变量，已经在工厂设置好了。最大的可能是序列号，服务号或者是你图例的序列号和服务号对应的一个因子。当初始数据被写入产品your legend时，它被植入客户端和服务器端。因为每个你的图例的序列号和服务号都是唯一的，没有你的图例就不可能知道X和动态密码M。
显然只有因子X是不够的，M=rand(X)生成一个密码M，但显然不能动态改变，失去了意义。所以t这个因素是不可或缺的。
说到这里，有人会说，为什么不干脆一起植入T呢？分析之下，植入T后，服务器端T1受服务器端时钟影响，客户端T2受客户端时钟影响，出现问题。如何保证运行一段时间后T1=T2？一种方法是使用高精度材料，保证三年内T1=T2，这显然成本很高。以市面上30元左右的电子表为例，无法保证三年内千元电子表误差不超过1分钟。因此，关于t必须有一个逻辑上的修正。
大胆假设:服务器端固定T0，引入一个因子△t，服务器端植入△t，这是客户端时钟和服务器时钟的差值，即△t = t2-t1。这样，客户端的密码(你的图例)就是M=rand(T2X)，服务器端的密码就是M = rand”(t 1+△t)x”。这样，成千上万的客户端(你的传说)只需要在服务器端记录△ t。这个△t在你的传说中产生的时候就可以被植入服务器记录下来。在这里，双方同步的问题仍然没有解决。
同步的问题可以通过在服务器端动态调整△t来解决。打开你的图例，提交序列号和动态密码时，服务器计算m = rand〖T 1+△t〗x〗在△T的基础上，计算...、△t-5*60、△ T-4 * 60、△ T-3 * 60、△t .具体系列长度视需要而定。因为是随机的6位函数，所以这个数列不会有重复的m。这样就可以计算出△t前后N分钟的差值所产生的密码m，只需要比较提交的动态密码对应序列中的哪个值就可以动态调整△t。假设动态密码与△t-2*60对应的密码相同，可以调整△t=△t-2*60。这样就解决了用户终端(你的图例)从出厂到开通使用的时间误差。这个N是根据实际需要确定的。如果工厂离1月只有几个小时的路程，你的传奇质量会很差。
使用图例时，可以用同样的方式实现同步。确定△t后，服务器只需要计算M 1 = RAND”(T 1+△T-Y)X”、M = RAND”(T 1+△T)X”、M2 = RAND”(T 65438+)在实际使用中，已经检验出你的图例存在时间误差。如果服务器的M与你的图例的M不同，但服务器的M1与你的图例的M相同，则可以实时动态调整△t=△t-y，实现你的图例与服务器的时间同步。有人试图破解你的传说，这似乎很难。一是不知道X，二是不知道△ T，所以你的传说保密性不错。