对于rar密码有什么好建议吗？？

huangyhg

查看完整版本 : 对于rar密码有什么好建议吗？？

roy2002
2004-05-03, 04:13

rar密码解密除了用穷举，还有什么好办法呢？

doskey
2004-05-03, 11:11

没有, 只能穷举

runjin
2004-05-03, 12:48

最初由 roy2002 发布
rar密码解密除了用穷举，还有什么好办法呢？



请问 谁能等上个几百年呢?

roy2002
2004-05-03, 17:37

要等好久,而且不一定可以

doskey
2004-05-03, 18:05

解RAR的密码基本上不可能.. 除非你有深蓝+N年的时间....:p

huangyhg

标 题: 【原创】一个菜鸟关于winrar密码无法秒破的研究结果
作 者: askyou
时 间: 2008-04-11,15:41
链 接: http://bbs.pediy.com/showthread.php?t=62908

PS：第一次发贴，我是个新手菜鸟，不正之处请高手帮忙指点。
研究的原因：
　　由于有一个重要的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^initVector
    encryptBlock[0]=AES(packblock[0])　　　  ；（KEY为AES的密钥）
　　for i=1　to   块数量-1
           packblock=packblock^encryptBlock[i-1]
           encryptBlock=AES(packblock)　　　；（KEY为AES的密钥）
      next
    ;packblock表示压缩完的每16字节数据
　  ;encryptBlock表示加密完的每16字节数据
;===============================================
　　三、解密的过程
　　由于AES算法是对称的，所以解密的过程，是加密过程的逆运算。但解密时AES算法过程与加密所用的不一样（是因为解密过程中由KEY生成的子密钥表不一样）。仍然需要我们将密码输入，与salt一起生成两个16字节密钥，KEY和initVector。

;===============================================
    packblock[0]=AES1(encryptBlock[0])　　　  ；（KEY为AES的密钥）
　　packblock[0]=packblock^initVector
　　for i=1　to   块数量-1
　　      packblock=AES1(encryptBlock)　　　  ；（KEY为AES的密钥）
　         packblock=packblock^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等，部分数据固定，压缩完的数据是否存在相互牵制的数据？从而把判断提前，这一步，我不知道如何找到压缩完的数据是否存在相互牵制的数据。

　　（完）
　　以上是研究的一点点成果，欢迎大家讨论，至于听说如美国情报机构，完成了对RAR文件的秒破，还有在台湾一论坛上看到，有人提到RAR文件被人秒破过，我不太相信，我觉得美国情报局这样的机构，有可能可以秒破，但应该是建立在已经通过非常规手段，跑出一份对应表，只做查询密码才有可能做到。

huangyhg

有个例外,加密的文件的长度小于等于4字节时,可以秒破
自己不会,不要以为别人也做不到
因为RAR中有CRC32的值,等于提供了4字节的信息约束条件,只要可能的情况总数小于2^32就可能破解,其方法我几年前就写出来公开了
http://bbs.pediy.com/showthread.php?t=8699

实际上,某些情况下,即使超过4字节也是有希望的,举个例子,看雪以前有次活动好象是,要求回帖猜一个6位数字,其值用RAR加密,加密文件公开
假如这个文件里仅仅只有一个6位数字字符串,肯定被我搞定了,因为确定前两位后,后面的可由CRC32逆算法求出(CRC32不是没有逆算法,而是逆算法仅能提供4字节信息),如此算出100种情况.除了正确的那个,后面4字节几乎都不可能是数字(此情况下仍然发生碰撞概率极小,100/2^32).如此即可判断.
假如这个文件长度8字节,也有可能搞定,因为最可能的情况是"k=******"
假如这个文件长度11字节,可以猜测"k等于******",只要能猜出额外的信息就能破解

可惜郁闷的是...实际的情况是16字节,里面除了k之外居然还有一句话,只好放弃了,看雪老大是不是考虑到这点才这么做?