当初某商城的电子书不提供下载,只能在线阅读。而阅读器的界面实在反人类,因此有了分析的想法。 这方面已经有一篇前人的经验总结。虽然因为时间久远已经失效,但其中的原理是相通的。 首先用chrome查看网络通信,发现每次翻页都会产生一个请求,显然这是每一页的内容。根据前文所述,这是一个带文件头的加密swf,但这次的文件头与文中说的不一样,应该是改了算法。 继续按文中的思路,反编译reader.swf,不出所料在application.view.DupLoader发现了感兴趣的东西。画成示意图如下。 其中唯一的难点是最开始的密文怎么得到。脚本中是一个名为hexKey的变量,逐步追踪,线索指向application.view.reader,最后才弄明白这是名为AMF的flash通信协议,可调用服务器端的函数。于是用pyamf模拟,发现返回值是固定的,后面就偷懒直接用了。 整体而言,这套加密方法还是比较清晰的。主要原因是正文的内容实在太多,没法实时加密,只能事先加密之后存储,这样就只能在文件头上想办法,于是就有了上面迭床架屋式的加密。受限于flash的处理能力又没办法做得很复杂,于是就变成现在这样了。 分析完毕用python写个脚本测试。发现前20页(商城中可以免费试读的部分)正常,后面的取不到,怀疑是没加cookie认证失败造成的。由于python的cookiejar与chrome的格式不太兼容,又重新换回wget,就是最终的程序了。 取到swf之后用swf2video批量转换成png,再用freepic2pdf合并成pdf,最后用briss切边,就可以放进eink里看了。不足之处是图片格式的pdf体积较大,可以再用其他软件优化。 最后放出python脚本的代码,供研究讨论
[培训]内核驱动高级班,冲击BAT一流互联网大厂工作,每周日13:00-18:00直播授课