RAR archive encription
Moderator: BarsMonster
- BarsMonster
- Site Admin
- Posts: 1118
- Joined: Wed Oct 01, 2008 7:58 pm
RAR archive encription
Is there anyone know good info about rar decripting? (something more than "it is just AES")
I.e. how the password is being checked without knowing plaintext, and how decription should look like in general?
Is there any "dumb" source available?
I.e. how the password is being checked without knowing plaintext, and how decription should look like in general?
Is there any "dumb" source available?
-
- Posts: 16
- Joined: Thu Oct 16, 2008 1:27 am
Re: RAR archive encription
Theres not much info considering that the current version of the rar spec is proprietry.
The latest I can find is only 2.02, and that's not even close to when they started rolling out AES in the files. (It was RAR 3.0 when AES was introduced.)
You can find it here: http://www.wotsit.org/list.asp?fc=4 (although most likely useless now?)
All they seem to let on is that it's AES and 128-bit.
The latest I can find is only 2.02, and that's not even close to when they started rolling out AES in the files. (It was RAR 3.0 when AES was introduced.)
You can find it here: http://www.wotsit.org/list.asp?fc=4 (although most likely useless now?)
All they seem to let on is that it's AES and 128-bit.
Re: RAR archive encription
7zip or unix unrar source might help.
Re: RAR archive encription
I wrote a RAR cracker a while ago. I had to study the source code of the Unix version of unrar, because at the time, the format of encrypted archives wasn't documented (not sure if it is today). You should know there are 2 different ways to encrypt a RAR archive; the rar CLI tool exposes them through 2 options:
It goes without saying that bruteforcing a -hp RAR archive is pretty slow because of the 256k rounds. And the whole mechanism seems at first sight pretty secure, unless a flaw is found in the stretching function...
I could dig up my tool if you are interested. It was really just a hundred lines or so built around CryptData::SetCryptKeys...
- -p option, which encrypts only the content of the files in the archive, while file metadata (filenames...) are not encrypted (which is stupid, an encrypted archive should not leak its file list)
- -hp option, which encrypts the internal block headers that contain file metadata
It goes without saying that bruteforcing a -hp RAR archive is pretty slow because of the 256k rounds. And the whole mechanism seems at first sight pretty secure, unless a flaw is found in the stretching function...
I could dig up my tool if you are interested. It was really just a hundred lines or so built around CryptData::SetCryptKeys...
- BarsMonster
- Site Admin
- Posts: 1118
- Joined: Wed Oct 01, 2008 7:58 pm
Re: RAR archive encription
Yeah, that would be very userful. Now I am less scared with it, constant eof is very nice 
256k rounds... That is where we would need GPU, even 50k keys/sec would be a nice improvement over current 2-3k keys/sec.

256k rounds... That is where we would need GPU, even 50k keys/sec would be a nice improvement over current 2-3k keys/sec.
Re: RAR archive encription
Here you go. Note that actually the right way to check the validity of the password is try to decrypt the first few bytes of one of the file blocks: the plaintext datastructure is supposed to be a header whose structure is well documented (http://fts.ifac.cnr.it/cgi-bin/dwww/usr ... ote.txt.gz) and which contains a CRC. If the CRC is valid, you can assume the password was correct. I prefer my end-of-archive method though, it's less code 
I just noticed that rar (at least version 3.71) uses the same 64-bit salt for all blocks (ie. all files) and also uses AES in ECB mode ! This is a typical amateur mistake that makes possible a number of theoretical attacks (but none, I think, that could help us improve the bruteforcing speed). I don't find this surprising though. Tools where encryption is an afterthought always get it wrong. Sigh.

I just noticed that rar (at least version 3.71) uses the same 64-bit salt for all blocks (ie. all files) and also uses AES in ECB mode ! This is a typical amateur mistake that makes possible a number of theoretical attacks (but none, I think, that could help us improve the bruteforcing speed). I don't find this surprising though. Tools where encryption is an afterthought always get it wrong. Sigh.
- Attachments
-
- unrarhp.tar.gz
- (7.7 KiB) Downloaded 987 times
-
- Posts: 11
- Joined: Wed Nov 12, 2008 2:31 am
Re: RAR archive encription
Any development news for RAR CUDA password cracking?
Re: RAR archive encription
There is the cRARk BETA version with CUDA support at http://www.crark.net.
the sources for CUDA engine are also provided. If anyone could help optimize it, please
contact the author.
the sources for CUDA engine are also provided. If anyone could help optimize it, please
contact the author.
Re: RAR archive encription
First RAR cracker for ATI HD 48xx GPUs can be found here: http://golubev.com/rargpu.htm.
Shortly, HD4850 about 19x times faster than single core of Q6600 @ 2.4Ghz. There no CUDA version yet and basically program is just "proof of concept". But can be used in many situations
.
Shortly, HD4850 about 19x times faster than single core of Q6600 @ 2.4Ghz. There no CUDA version yet and basically program is just "proof of concept". But can be used in many situations

Re: RAR archive encription
why don't you want to compile al the stuff with calclCompile() for different cores? why r700, only?
p.s.:watcom c++ i thought no one use it now
p.s.:watcom c++ i thought no one use it now

Re: RAR archive encription
There are two reasons:ash wrote:why don't you want to compile al the stuff with calclCompile() for different cores? why r700, only?
1. Kernel compilation takes A LOT of time and (more important) memory. And there is kernel for each possible length == 16 kernels to compile. I'm working on 8Gb system and this amount of RAM simply not enough to compile everything. It takes 1+ hour, Windows starts to swap everything, memory usage peaks at 16Gb for kernel with length == 18... Shortly, it's just terrible, better to precompile them.
2. Cards other than HD48xx simply isn't good enough for integer math. I've tried another algo (winzip w/ aes) and got 140K on HD4850 vs only 4K on integrated HD3200. There no 35x difference in 3D between them ofc. Dunno about other cards though.
Yeah, I'm that old and lazy to switch to another compilerash wrote:p.s.:watcom c++ i thought no one use it now


Re: RAR archive encription
kernel for every pass length-terrible.
execution of calclCompile()- takes 1+ hour o 8 gb mem.
for example bars via brook.dll makes compilation of shader in executable and it takes not too much...
firstly i thought you'd made precompilation because of crackers could watch yours shader, but in total that's not good-intresting to test it on all devices(i guess).
2.clause due to sp count difference.
p.s.: to hide shaders i'd precompiled my shaders and after making Disassembling and after that compilation with targer supported devise ISA value, but it doesn't takes so much time.
can you give some links on decryption rar algo, plz
execution of calclCompile()- takes 1+ hour o 8 gb mem.



for example bars via brook.dll makes compilation of shader in executable and it takes not too much...
firstly i thought you'd made precompilation because of crackers could watch yours shader, but in total that's not good-intresting to test it on all devices(i guess).
2.clause due to sp count difference.
p.s.: to hide shaders i'd precompiled my shaders and after making Disassembling and after that compilation with targer supported devise ISA value, but it doesn't takes so much time.
can you give some links on decryption rar algo, plz
- BarsMonster
- Site Admin
- Posts: 1118
- Joined: Wed Oct 01, 2008 7:58 pm
Re: RAR archive encription
In BarsWF it also takes long in my measures - I was asking at AMD forum why It takes ~1-2 seconds to execute first callash wrote:kernel for every pass length-terrible.
execution of calclCompile()- takes 1+ hour o 8 gb mem.![]()
![]()
![]()
for example bars via brook.dll makes compilation of shader in executable and it takes not too much...
firstly i thought you'd made precompilation because of crackers could watch yours shader, but in total that's not good-intresting to test it on all devices(i guess).
2.clause due to sp count difference.
p.s.: to hide shaders i'd precompiled my shaders and after making Disassembling and after that compilation with targer supported devise ISA value, but it doesn't takes so much time.
can you give some links on decryption rar algo, plz


Re: RAR archive encription
If you want to get good speed -- it's the only way possible. Pavel's crark's performance suffer because he doesn't pay attention to this thingash wrote:kernel for every pass length-terrible.

Well, kernels are quite complex with lots calls/rets, that's the reason I guess. Unfortunately it's nearly impossible to code in hardware ISA instead of IL.ash wrote:execution of calclCompile()- takes 1+ hour o 8 gb mem.![]()
![]()
![]()
Because compiling one MD5_Transform isn't complex at allash wrote:for example bars via brook.dll makes compilation of shader in executable and it takes not too much...

As I already wrote -- only HD48xx will show good results, so no real point to test on anything else.ash wrote:firstly i thought you'd made precompilation because of crackers could watch yours shader, but in total that's not good-intresting to test it on all devices(i guess).
RAR sources are enoughash wrote:can you give some links on decryption rar algo, plz

Re: RAR archive encription
And it was me who replied whyBarsMonster wrote:I was asking at AMD forum why It takes ~1-2 seconds to execute first call

Re: RAR archive encription
Actually, compilation of md5 takes~ 50 ms. 1-2 sec on brook- due to OOP realization of last and compilation, linking, ...In BarsWF it also takes long in my measures - I was asking at AMD forum why It takes ~1-2 seconds to execute first call I would prefer more like 0.1 sec
i thought it's well known stuff

i know, actually, i edit kernel in runtime and then compile, and working with new one: for example-multihash is not well implemented on constant kernel- it needs resort and recompilation of new kernel;If you want to get good speed -- it's the only way possible. Pavel's crark's performance suffer because he doesn't pay attention to this thing . My implementation is very close to theoretical limits of GPU.
calclCompile() just assembles shaders to obj- interesting why it takes so much time to put CALL/RET in codeBecause compiling one MD5_Transform isn't complex at all . My kernel for winzip w/ AES (which in fact required just 2 SHA1_Transform 1000 times) also compiles very fast, just milliseconds. But RAR's "password to key" routine is very GPU unfriendly.
not all got r700-like devicesAs I already wrote -- only HD48xx will show good results, so no real point to test on anything else.
yours shader-pleaseRAR sources are enough . SetCryptKeys implemented on GPU, AES init & decoding on CPU as it doesn't takes too long. Final validation done after decrypting 32 bytes of RAR header using some heuristics (like header type can only be 0x74 or 0x7A, version to extact >= 29, etc).

Re: RAR archive encription
calclCompile() not "just assembles" it, in fact, trying to agressively optimise everything. Check out code produces by brook+ -- it simply terrible. If you'll write a = b + 5 + 5; it'll be compiled into +5 +5 not +10. All optimisation done in calclCompile() call.ash wrote:calclCompile() just assembles shaders to obj- interesting why it takes so much time to put CALL/RET in code
I guess for lots of "call/rets" compiler trying to do something like "whole program optimisation" which takes a lot of time for complex kernels.
Time to get one of themash wrote:not all got r700-like devices

Sorry, I have no plans to release sources atm.ash wrote:yours shader-please
Re: RAR archive encription
And now nVidia "CUDA" cards also supported
. http://www.golubev.com/rargpu.htm.
On 8600 GT it's about 2x times faster than single core of Q6600 @ 2.4Ghz. So (estimated) about 12x faster on GTX 260 w/ 192SP.
Need some heavy testing though, just first CUDA version.

On 8600 GT it's about 2x times faster than single core of Q6600 @ 2.4Ghz. So (estimated) about 12x faster on GTX 260 w/ 192SP.
Need some heavy testing though, just first CUDA version.
Re: RAR archive encription
Thanks IvanG, that's a great tool !
Do you think it's also possible to use CUDA on non-"Encrypt filenames" files ?

Do you think it's also possible to use CUDA on non-"Encrypt filenames" files ?
Re: RAR archive encription
Yes, it's possible. But it requires more complex password validation -- need to decrypt and unpack protected file instead of simple header's bytes check.lemon wrote:Do you think it's also possible to use CUDA on non-"Encrypt filenames" files ?
Re: RAR archive encription
tha same solodnikov,openwatcom,loadlibrary, getprocaddress- some dejavu-like stuff;but solodnikov got some more interesting stuff-asprotect;
icc -more suitable, then watcom,it like borland compilers put data and code into the same section
-overplay of code cache
nvcuda?-don't like wrappers?
what cuda:ptx or kernel?
hope ptx?
do you use cpu for calculation, cauze i saw it got some long function with a lot cyclic rotations?
source:no need of souce just main proc in asm, plz
icc -more suitable, then watcom,it like borland compilers put data and code into the same section


nvcuda?-don't like wrappers?
what cuda:ptx or kernel?
hope ptx?

do you use cpu for calculation, cauze i saw it got some long function with a lot cyclic rotations?
source:no need of souce just main proc in asm, plz

Re: RAR archive encription
I know (as well as I knew Solodovnikov IRLash wrote:but solodnikov got some more interesting stuff-asprotect;

It doesn't matter at all. All "heavy" computations done in GPU. It's possible to optimize CPU routines, yes, but as they take like 1% of time it won't increase total performance a lot. And if I'll decide to include CPU support I'll use assembler anyway.ash wrote:icc -more suitable, then watcom,it like borland compilers put data and code into the same section-overplay of code cache
![]()
Don't like unneeded code which leads to compatibility problems.ash wrote:nvcuda?-don't like wrappers?
cubin ofcash wrote:what cuda:ptx or kernel?
hope ptx?

Final password's validation needs some SHA1 & AES and done in CPU.ash wrote:do you use cpu for calculation, cauze i saw it got some long function with a lot cyclic rotations?
Main proc written in pure C and having a lot of "comments" in form of references to strings (like "Cannot init CAL structs.", "Error <here>, error <there>"). It can be analyzed in no timeash wrote:source:no need of souce just main proc in asm, plz

I guess you don't have any supported videocard that's why you trying to disassemble .exe instead of simply run it

Re: RAR archive encription
shit, won't be new versionsI know (as well as I knew Solodovnikov IRL ). Just FYI -- ASProtect is no more Solodovnikov's thing, StarForce purchased ASPR year+ ago.



1%- i saw. Intrinsics? asm is in heavy use for crackmes or virii or some selfwritten packers, anyway that's yours decision.It doesn't matter at all. All "heavy" computations done in GPU. It's possible to optimize CPU routines, yes, but as they take like 1% of time it won't increase total performance a lot. And if I'll decide to include CPU support I'll use assembler anyway.
actually, cudart.dll use dynamic aka runtime linking of nvcuda.dll, so (i guess) they(nvdia-guys) going to release(change) more frequently nvcuda.dll which isDon't like unneeded code which leads to compatibility problems.
distributing with nvidia's drivers,so wrappers won't make any compatibility inconviniences.all developers play with curart.dll apis, all i know.
wright choise.cubin ofc . Just no point to have uncompiled kernel.

...plz answer more quicker, in 20 min. i'd known thatFinal password's validation needs some SHA1 & AES and done in CPU.

plz make cpu-support...Main proc written in pure C and having a lot of "comments" in form of references to strings (like "Cannot init CAL structs.", "Error <here>, error <there>"). It can be analyzed in no time .



actually, i got 4870, but you're wright i hadn't run it -first stuff-disassembling in wmware---aka paranoiaI guess you don't have any supported videocard that's why you trying to disassemble .exe instead of simply run it .

Re: RAR archive encription
I finally did an official release of the unrarhp brute forcer I mentioned 1+ year ago in this thread:
http://blog.zorinaq.com/?e=15
Better late than never
http://blog.zorinaq.com/?e=15
Better late than never

RAR file password
Hello ....................
Actually i'm working on rar/winrar file,
for recover the password.
but still i'm not decrypting the file and not recover the password using brute force.
i know the sallt value whivch is of 8 Byte long.
i have classes used in encryption "rijndael.cpp" and "sha1.cpp"
but i'm not getting the Aeskey which is of 16 byte long .
what is the process for recover the password for rar file for version 2.x/3.x.
i am using brute force for generate the password and read the file data and 8 byte salt value.
plz can anyone help me about this...........
Have a nice day.
Actually i'm working on rar/winrar file,
for recover the password.
but still i'm not decrypting the file and not recover the password using brute force.
i know the sallt value whivch is of 8 Byte long.
i have classes used in encryption "rijndael.cpp" and "sha1.cpp"
but i'm not getting the Aeskey which is of 16 byte long .
what is the process for recover the password for rar file for version 2.x/3.x.
i am using brute force for generate the password and read the file data and 8 byte salt value.
plz can anyone help me about this...........
Have a nice day.
Who is online
Users browsing this forum: No registered users and 1 guest