Chinaunix首页 | 论坛 | 博客
  • 博客访问: 8071
  • 博文数量: 1
  • 博客积分: 165
  • 博客等级: 入伍新兵
  • 技术积分: 20
  • 用 户 组: 普通用户
  • 注册时间: 2010-07-10 00:42
文章分类
文章存档

2010年(1)

最近访客

分类: 网络与安全

2010-07-10 00:46:23

  由于有一个重要的Rar文件,极需解开,首先试用了ARPC,但是解压的速度极慢,每秒只有30个左右,所以断了穷举破解的念头,却仍不死心,因为我从不崇尚穷举破解的方法,除非每秒可以跑几千万次的,我或许可以一试,所以决定研究一下Winrar 3.x密码算法,以期是否可以破解该密码。查看了网络上的资料,包括看雪FAQ里的回答,都声称只能用穷举法破解,起先并不理解,但通过研究,我理解了看雪前辈们在FAQ里所说的原因,不禁让我佩服Winrar加密思路的成熟。虽然研究的结果没有什么新意,但我还是决定把我的研究结果与大家一起分享,为那些仍然以为winrar密码可以象破解注册码一样的,通过修改winrar弹出框之类的更改文件流程指向可以达到跳过密码检验的朋友,做一个简要的说明。
  一、Rar文件生成的流程。  Winrar加密文件时,总的分两个步骤:
   1:先把源文件压缩,压成一段数据段。
   2:再将压缩完的数据段加密。
  对于同一个源文件来说,不进行加密,压缩完,其 rar文件中的数据段是一模一样的。但是如果对同一个源文件来说,即使使用同一个密码,加密完rar文件中的数据段是不一样的,这是由于加密的密钥是依赖于一个Salt(8个字节的密钥,用来加密时使用,存放在rar文件头中里)  所以要解密rar加密文件关键在于数据解密这一步,那我们接下来研究一下如何加密的。
  二、加密“压缩完的数据段”的流程
  1、获取密钥:
    将明文的密码与Salt一起,通过HASH算法,生成两个16字节的密钥。(一个是KEY(AES算法的参数),一个是initVector)
  2、以Key和 initVector来加密压缩数据:
    这里,是一个循环加密的结构,每16字节作为一个块,进行加密(这可能正是为什么加密完的文件长度总为16倍数的原因)。加密采用AES算法(RAR采用的是AES的rijndael的标准应用)。这里注意:AES加密前,有一个异或运算,是先将每16字节块与上一个16字节块加密结果进行异或,然后再进行AES算法的。

用一个简单的示意代码看说明:

;===============================================
   packblock[0]=packblock[i]^initVector
    encryptBlock[0]=AES(packblock[0])      ;(KEY为AES的密钥)
  for i=1 to   块数量-1
           packblock[i]=packblock[i]^encryptBlock[i-1]
           encryptBlock[i]=AES(packblock[i])   ;(KEY为AES的密钥)
      next
    ;packblock[i] 表示压缩完的每16字节数据
   ;encryptBlock[i]表示加密完的每16字节数据
;===============================================


  三、解密的过程  由于AES算法是对称的,所以解密的过程,是加密过程的逆运算。但解密时AES算法过程与加密所用的不一样(是因为解密过程中由KEY生成的子密钥表不一样)。仍然需要我们将密码输入,与salt一起生成两个16字节密钥,KEY和initVector
;===============================================    packblock[0]=AES1(encryptBlock[0])     ;(KEY为AES的密钥)   packblock[0]=packblock[i]^initVector  for i=1 to   块数量-1         packblock[i]=AES1(encryptBlock[i])     ;(KEY为AES的密钥)          packblock[i]=packblock[i]^encryptBlock[i-1]          next    ;===============================================
  那判断密码是否正确的在什么地方呢?
  解密的过程是解密后的数据块进行解压缩,然后解成源文件,对该文件进行CRC校验,存在RAR文件中的源文件CRC校验码比较,相同则密码正确,不相同则密码错误。

  四、无法秒破的原因
  从上面,我们了解了RAR文件的整体思路。地球人都知道,解密时,肯定有个步骤是来判断密码的正确与否。而且,依据以往的经验,我们也许可以将某些判断的点移动,那样可以缩减破解的流程思路。那RAR的这一步在哪里?它把校验放在了最后的一步。如果要秒破,我们该怎么做泥?至少我认为目前是不可能的。  我们从解密过程逆反过来看看:
  1、CRC检验这一块修改跳转?根本毫无意义,因为它已经是最后一步了。你可以修改RAR文件头的CRC值,你可以将它改得和你用任意密码解压出来的文件CRC值一样,但你的文件根本就不是原来的文件了。可能已经完全面目全非了。所以,对这一过程不可行。CRC校验本身是不可逆的
  2、那么把判断提前到压缩完的数据?  解压的时候,有没有什么来判断压缩数据是否正确?压缩完的数据,有没有固定的特征,是否可以做为解压的判断,在这一步里,我们也无法找到有效的可用的固定特征。因为这一步涉及到RAR的压缩算法。即使一个源文件,即使你的文件前一部分是完全相同的,只对后面的部分进行改过,那么压缩完,数据也是完全一样的。因为压缩完的数据首先是一个压缩表,后面是编码。文件不一样,扫描完的压缩表也不一样,编码又是依赖于压缩表,所以,这里头找不到压缩完的数据有任何的固定特征可以用来判断的。
  不管压缩数据是什么样的,Winrar都一如既往地进行解压,没有进行压缩数据是否有效的判断。
  3、那假如我们破解了AES了泥?
  由于AES只依赖于KEY,如果AES算法被破解了,我们知道了KEY,我们可以解出压缩完的数据,但是这里有一个问题,还有一个initVector密钥,用来第一个16字节块的异或,你没有initVector参数,你第一个16字节块的数据便无法解得出来。
  4、那就只能从第一步Hash的算法入手
  即使你能破解hash,但hash后的结果泥?没有结果,你怎么返推密码。
  所以综上,我发现rar的加密是由hash和AES两种算法互相牵制,而两种算法当前都无法破解,至少目前还没有办法秒破,也理解了看雪高手讲的道理。
  五、对穷举提高算法效率的一些设想。
  我用汇编写完了RAR穷举解密的算法模块,但是如何提高效率,优化穷举的速度泥?我有如下的想法:
  1、从压缩数据里找寻特征,省掉解压缩、CRC检验代码和生成initVector生成代码。目前,通过多次实验,我找到的一个特征(不知道这个是否正确),即解密完的最后一个16字节块的最后一个字节必须为0。因为经过多次的试验,我发现有加密的数据段长度都会比未加密前的数据长,那么,最后一个16个字节的数据块解密完,多出的部分就都为0,但多出几个字节泥?多次实验,长度不一,我试想着从加密数据段最后一个16个字节块着手,只解这一块,看是否一个字节为0,这样,只解密16个字节的数据,来大大提高效率?如果能进行到这一步了,再通过解全部数据,进行 CRC校验的判断。
  2、如果第一个特征不成立的话,针对特定格式的压缩文件,比如doc、jpg等,部分数据固定,压缩完的数据是否存在相互牵制的数据?从而把判断提前,这一步,我不知道如何找到压缩完的数据是否存在相互牵制的数据。

       更多的分享智慧,在收益宝,通过众多的用户分享智慧。

=================

C:\Program Files\WinRAR\TechNote.txt
                 下列压缩文件格式描述仅对版本 1.50 之后有效
                   RAR 压缩文件格式==



   压缩文件由可变长度的块组成。这些块的顺序可以变化,但是第一块必须是一个在压
缩文件头后的标记块。

   每一块由下列结构开始:

HEAD_CRC       2 字节    所有块或块部分的 CRC
HEAD_TYPE      1 字节    块类型
HEAD_FLAGS     2 字节    块标记
HEAD_SIZE      2 字节    块大小
ADD_SIZE       4 字节    可选结构 - 增加块大小

   只有 (HEAD_FLAGS & 0x8000) != 0 时 ADD_SIZE 才存在

   如果 (HEAD_FLAGS & 0x8000) == 0 则总块大小是 HEAD_SIZE,当
(HEAD_FLAGS & 0x8000) != 0 时,如果 ADD_SIZE 结构存在,则总块大小是
HEAD_SIZE+ADD_SIZE。

   在每一块中 HEAD_FLAGS 的下列位都有相同的意义:

  0x4000 - 如果设置,当更新时旧的 RAR 版本将忽略这个块并删除它。
           如果清除,当更新时块被复制到新的压缩文件;

  0x8000 - 如果设置,ADD_SIZE 结构存在,全部块的大小是 HEAD_SIZE+ADD_SIZE。

  公开的块类型:

HEAD_TYPE=0x72          标记块
HEAD_TYPE=0x73          压缩文件头
HEAD_TYPE=0x74          文件头
HEAD_TYPE=0x75          旧风格的注释头
HEAD_TYPE=0x76          旧风格的用户身份信息
HEAD_TYPE=0x77          旧风格的子块
HEAD_TYPE=0x78          旧风格的恢复记录
HEAD_TYPE=0x79          旧风格的用户身份信息
HEAD_TYPE=0x7a          子块

   注释块实际上只在其它块中使用,并不存在单独的块。


阅读(1412) | 评论(0) | 转发(0) |
0

上一篇:没有了

下一篇:没有了

给主人留下些什么吧!~~