Exetools  

Go Back   Exetools > General > General Discussion

Notices

Reply
 
Thread Tools Display Modes
  #1  
Old 05-08-2006, 21:33
raja raja is offline
Friend
 
Join Date: Aug 2003
Posts: 31
Rept. Given: 0
Rept. Rcvd 0 Times in 0 Posts
Thanks Given: 0
Thanks Rcvd at 0 Times in 0 Posts
raja Reputation: 0
Excel & Word Password Recovery

Maybe you are aware of h++p://www.decryptum.com
It mentions about itself:
"Decryptumtm is the first instant online Word and Excel password removal service. Decryption time is under 3 minutes, regardless of password length: you don't have to wait days for the file to be unprotected (all other services offer 2 to 14 days turnaround time). You don't have to download and install any software or spend your CPU time running a password recovery tool."

I have tested it with a long/uneasy/foreign-language characters password and it successfully decrypted it instantly - impressing.

My curiosity is: how they have done it and why still no software is available in market which can handle this task. Yes, many vendors along with the owners of decryptum.com are selling various password cracking software but all those are just try&error type.
Reply With Quote
  #2  
Old 05-09-2006, 01:28
aldente aldente is offline
VIP
 
Join Date: Jul 2003
Posts: 266
Rept. Given: 27
Rept. Rcvd 7 Times in 5 Posts
Thanks Given: 35
Thanks Rcvd at 10 Times in 9 Posts
aldente Reputation: 7
Well, it is obviously not that mighty:

Quote:
Sorry, the file you uploaded is encrypted by Microsoft Enhanced RSA and AES Cryptographic Provider (Prototype) and is not supported.
Reply With Quote
  #3  
Old 05-09-2006, 01:38
gigaman gigaman is offline
Friend
 
Join Date: Jun 2002
Posts: 87
Rept. Given: 0
Rept. Rcvd 3 Times in 2 Posts
Thanks Given: 0
Thanks Rcvd at 14 Times in 11 Posts
gigaman Reputation: 4
I guess it works only for the "standard" encryption (the only available in the older versions of MS Office). The key for this encryption was (because of US export restrictions) limited to 40bits.
So, I think they generated the table (of something) for all the possible keys and use it for decryption (which consist of reading the proper value from the table, basically); should be doable with today's hard drive sizes.
Reply With Quote
  #4  
Old 05-10-2006, 17:24
MarkusO
 
Posts: n/a
This can't be really true.

Storing 2^40 keys permuted to 2048 bits (RC4) would need 256 TB of hard disc space. While this could be possible in theory (with todays large datacenters), reading these 256 TB of data would take much longer than 3 minutes.

If you would be using DDR400 RAM in dual-channel mode, you can get around 5 GB/s of memory transfer bandwidth. So you would need at least 15 hours to transfer this ammount of data just in memory. Hard disks of course don't give you 5 GB/s, but only (in RAID0) somewhere up to 250 MB/s (or 60 MB/s for non-RAID). So it would take from 12 days up to 2 months. As you can see, this would never work with permuted keys stored on a hard drive.

Next it wouldn't make much sense. Since all keys need to be checked, one would just need to count from 0 to 2^40 and then do the permutation to 2048 bit. This would be much faster than reading everything from hard disk since RC4 key setup is much faster than a hard drive.

But you should also note that just counting from 0 to 2^40 already takes several minutes, so this company probably is using some kind of exploit.
Reply With Quote
  #5  
Old 05-10-2006, 17:52
Dmit
 
Posts: n/a
Quote:
Originally Posted by MarkusO
This can't be really true.
There are lot of ways to optimize storage and search process.
Quote:
Originally Posted by MarkusO
Storing 2^40 keys permuted to 2048 bits (RC4) would need 256 TB of hard disc space. While this could be possible in theory (with todays large datacenters), reading these 256 TB of data would take much longer than 3 minutes.
There is no need to store 2048 bits for each key. Actually just 40 bits of gamma will lead to very little amount of collisions.

For sorted data you could use binary search instead of linear one. For 2^40 values you need not more than 40 steps.

Also there are time-memory trade-off attack exists (see Rainbow tables for LM Hashes). But, to be honest, such approach has several disadvantages due to its statistical nature.

And, for sure, there are more ways to increase efficiency of keysearch exists
Reply With Quote
  #6  
Old 05-11-2006, 06:04
MarkusO
 
Posts: n/a
Why not?

In RC4 the full 2048 bit are needed for the crypto process. Storing less than 2048 bit per key would be a fatal mistake, since the data to encrypt/decrypt decides which parts of the 2048 bit are used at what time. Storing only the 40 bit password and doing a permutation later is pointless, since you can calculate the next password always just by incrementing a 40 bit variable by 1, which is of course faster than reading the next 40 bit key from a hard drive.

Using binary search instead of linear is no (usefull) option, since I just highlighted that hard drives and even RAM are far too slow.
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



All times are GMT +8. The time now is 22:29.


Always Your Best Friend: Aaron, JMI, ahmadmansoor, ZeNiX, chessgod101
( 1998 - 2024 )