说出来,好像有点异想天开的感觉.因为我现在想的是将来AS3编译的SWF的加密方案,而我现在的AS3依然是0状态,说出来的东西没什么根据.而且,到时候,加密和破解技术发展到什么层次,也不能预测.所以,我完全是在凭空想象.
从luzhugao发表了关于SWF的加密与破解一帖到现在,我看到了不少讨论这方面的帖子(包括特别重要的禁止缓存),结论都是"防君子不能防小人".
尽管在前段时间,我跟luzhugao的破解与反破解之争中,luzhugao是胜利者,但是,这说明他已经在加密的道路上取得成功了吗?答案是否定的,当初的挑战是有条件的,就是作为破解方的我,不能使用从缓存里找文件的办法.因此,他只是那场游戏里的胜方,在反破解的道路上,他依然还是要败给破解方.
以上的状况是由当前最流行的加密和破解软件的特点决定的.
常用破解软件:硕思闪客精灵,ASV(Action Script Viewer);
常用加密软件:Flashincrypt,SWF Encrypt.
在用Flash直接生成的SWF里,上面两款破解软件一般都能成功把SWF转成FLA.而加密软件则针对破解软件而进行放破解处理,Flashincrypt加密后,运行一般正常,且硕思已经无法还原,但是ASV可以.SWF Encrypt则是两样都能防,可惜在对复杂文件加密的过程中,容易出错.
在这种情况下,luzhugao对他的SWF做了如下加密操作:
网页里头放进的SWF不是他的大文件,而是一个小SWF,里头用loadMovie调用他的大SWF.其中,小SWF用SWF Encrypt来加密,不会出错,但是大SWF没办法,只能用Flashincrypt,因此,只要不允许在缓存里找,能找到大SWF就很难了.
但是,大SWF依然会存在于缓存里头.在缓存里找出来,用ASV就把核心代码拿到手了.
曾看到过很多禁止缓存的文章,其实最终都不能成功.大多数都只是隐藏.而且,哪怕给你藏住了,有心人可以用FF浏览你的SWF,让缓存赤裸裸地露出来.
现在,我假设当加密与破解软件都升级到AS3版本的时候,依然保持着上述的特点,那么,我就有了一个加密AS3写的SWF的想法.当然,我现在只能想,没有任何理论支持.
既然缓存无法禁止,那么,就只能考虑对SWF进行加密了.但是,如果只用上面的办法,始终无法防ASV.
听说AS3可以读写二进制了,记得我以前学VB编程的时候,是可以用程序自己写加密函数来对文件进行二进制加密的.所以就想到了通过脚本自己加密的办法.
步骤如下:
1 把你要放到网上的SWF准备好.
2 用AS3写一个二进制的加密函数(注意:一定要可逆的,就是要配有一个解密函数).然后,用脚本进行如下操作:
二进制读入SWF文件->得到一个BytesArray->加密算法得到新的BytesArray->用后台程序把新的ByteArray保存为SWF.
3 写一个小的SWF文件,装载被加密的SWF,这里自己设想一个MCLoader类,但不知道能不能写出来.
二进制读入加密SWF文件->得到加密的BytesArray->用解密算法把BytesAray还原成原始SWF的数据->用自己设想的MCLoader类调用loadClip方法,参数不是SWF的路径,而是一个BytesArray->根据BytesArray把SWF显示出来.
那么,装载影片的SWF依然还是比较简单,就一个装载动作,加一个解密函数,可以用SWF Encrypt加密,而被装载的大SWF可以不需要再用软件加密,因为你自己已经用自定义的加密算法作了处理.人家拿到手以后,估计没办法破解.因为ASV我想再聪明,都不会知道你用的二进制加密算法如何.要破到的话,必须知道你的加密或者解密算法.但是你的解密算法已经被SWF Encrypt保护了.加密算法是后台使用的,不会放到网上.
这些就是我闲时无聊想到的,没什么理论支持,大家如果对我这异想天开的东西有什么意见的,狠狠地批一顿吧.
经典这里有讨论
|
