某网站AJAX的加密压缩传输算法的一点研究

AJAX还是比较强大的!(显然,这是一句废话),最近在研究一个网站的AJAX应用中发现其中的“拓展视野”部分频频被挖掘出来(也由此可见,平 时本人的视野有多么的狭窄了),首先是全站的JS全部使用packed进行了压缩,呃!也不知道这种称法是否正确,就是用eval(function (p,a,c,k,e,d){})的那种世界各地都很流行的压缩方法吧,在实际的观察中,一个压缩后仅为6K,在我将其转化为“肉眼能看清楚的代码”之 后,足足有20K,可见其效果还是相当明显的;此外,用HttpWatch弄到了传输数据后,居然是加密的。。。形如下面这段:

引用

q1YqT81MzyhRsqpWys3MU7Iy0FHKTaxQsjLWUUrLL8pNBMooqeoZpSnV6igVFGUmp2KoVDIzMrIwNdAzMFBC1pOiVFsLAA==


任何一个有些许密码学经验的同志都容易很看出来,这是base64编码(我实在不喜欢称这个为“加密”),没错,和各位看官一样,我很快就用php自带的base64_decode函数对其进行了解密,如果您觉得问题到此为止,那就错了!这时我才稍稍感到了有些震撼,解密出来的数据

大小: 6.92 K
尺寸: 503 x 50
浏览: 5 次
点击打开新窗口浏览全图
呃!一堆乱码,其实应该是二进制数据,加密了(后来知道是压缩了),可是用户是看不懂这些的,客户端是肯定要进行解密的!用什么?AJAX的当然用JS解密了,挖解密函数啊,挖解密函数,看到了如下的精彩代码:

 
XML/HTML代码
  1. 1.var filterList=eval('('+utf8to16(zip_depress(base64decode(g_pgFilterList)))+')');  


utf8to16()和base64decode()都好理解,也再一次证明加密的最后是用base64编码输出的,关键就是这个zip_depress(),zip解压?
是的,千真万确,用JS实现了zip的解压算法!!!到这里我深深的感到了震撼,原来,我知道的真的太少了啊!虽然之前知晓有md5.js,知道JS在运算方面是没有问题的。不会是这家伙自己写的压缩算法吧?经过搜索,我找到了这个算法(Zip inflate)的原版,原来该网站的制作人员修改了函数名,难怪我直接google不到呢?
什么是inflate算法?—

引用

inflate是GZip, PNG等广泛使用的解压算法,linux也使用inflate对内核进行解压.inflate的解压算法使用的第3种快速解压法的一个子集,它不考虑 LONG_CODE,同时把SAME_LENGTH合并到MEDIUM_CODE。而对于规则的SAME_LENGTH编码,比如length和 distance编码,inflate则使用额外的base和extra表示。这是因为在构造一般的查找表时,虽然对于SAME_LENGTH前缀可以不 构造副表,但我们需要另外一个表格来保存符号的顺序,而这个表格的空间可能更大。但对于length和distance编码,他们的顺序是递增的,所以无 需额外的表格来保存符号的顺序。

inflate使用root表示上述的b,查找表的数据结构为code.主表和副同时保存在inflate_state结构中的大数组codes[ENOUGH]中.表的构造函数位于inftrees.c文件的inflate_table中.


令人感到欣喜若狂的是,PHP竟然已经提供的现成函数来解压和压缩inflate,它们是gzinflate()gzdeflate(),哈哈哈!我不禁仰天狂笑的一番,用gzinflate()成功的将上文数据解密,内容是这样的

引用
{"weight":{"min":0,"max":3,"format":"%.2f"},"price":{"min":0,"max":"622850.00","format":"%d"}}


标准的JSON数据啦,不错!这就为以后的AJAX的传输上多了一个选择,虽然还不确定这种方法能否节省流量(因为base64算法会将原始数据“稍稍” 增大),但客户端有了解压算法,服务端的php压缩函数又是现成的,大不了在base64这个环节上大概需要改进下,我想对于大流量的数据应该还是有确切 效果的。嗯,我很满意。

原文地址:http://www.blogguy.cn/show-601-1.html

300*300
  • 没有相关文章
  • 没有评论
 文章首页关于迷茫时代关于我写意人生
版权所有:迷茫时代 All rights reserved   
执行时间:0.00329 秒