I need Help with a ZIP encrypted

Hi everyone, I sent this message to some users of wechall, and I want to publish here, because other persons can learn with this issue.

This message's aim is to request you help on a pretty urgent issue.
If someone can give me a hand with this, I will be grateful forever.

Here's the situation:
Just a few weeks ago, I backed up a folder with a bunch of files (aprox 900 GB of data). It was a Windows 2003 Server and I used the option Send To --> Compressed File which generated a .zip file. Then I transferred the zip file to another server via FTP.

Last Monday I tried to extract the content of the zip and it keeps requesting a password when using winzip (I never set a password to it), when using winrar it says: Unknown compression method.

I had a look at the file's header and is "50 4b 03 04 14 00 01 00 63".

The section of the header that is repeated all over the file is "01 00 63", that flag indicates that the zip file isn't corrupt.

Then I compressed a handful of files using winzip and the AES encryption method and I found that those are similar to the ones on the file that I'd like to recover:
AES 128 - 50 4b 03 04 14 00 02 00 63
AES 256 - 50 4b 03 04 14 00 03 00 63

I started a known plain-text attack with 'pkcrack.exe' by using a handful of files which are within the zip file but it did not work. I had a look at the documentation and it seems like the tool doesn't support AES encryption.

After all that, I started a brute-force attack and a dictionary one (The dictionary had over 20 million words and some that I always use for passwords)... these two approaches failed though.
That attack was performed with Elcomsoft Advanced Archive Password Recovery.

The last thing I did was switching the header "01 00 63" for "02 00 08" attempting to 'fool' the compressing tool and pretend that the file had no password but then, when I try to unzip I get an error message:
"invalid compressed data to expand (inflate) the file".

My zip file has very sensitive data. I was the only person who had access to it so it's very unlikely that someone set a password to the zip.
Besides the file's modification date is the same one as the date when I created the file.

I would greatly appreciate any help or hint that you guys can provide on this.
HaDeS

Was the FTP a binary mode or a text mode transfer? Because if it was a text mode, then it is "normal" that your zip went wrong.

I sent a message to TheHiveMind, and he replied me that "try to check whether there are any 0x0a bytes in the file that are no t directly preceded by a 0x0d byte" to find if I used binary mode or text mode, and I found some 0a 0d bytes and others 0a 0x bytes.
At the moment, I think that isn't a error of transmision.
I tried to repair the zip file with WinRar, and the output is the same file that I have, but without modifications.
Thanks for the reply Z,
HaDeS

My guess would also be that you used text mode to transfer the binary file.
Good luck it seems to be reversible according to this page: http://www.orafaq.com/forum/t/100512/0/

EDIT:

seems like the reversibilty depends on if the file went from linux to windows or the other way round...
If you transfered from linux to win it is reversible, if you transferred from win to linux you might be screwed

Thanks Gizmore,
I replace all the 0d 0a bytes in the text to 0a, like the script. But when I opened the .zip file appears a message box that says "Zip file corrupt, posible cause: file transfer error", so a file transfer error is discarded. I'm 90% secure that I transfered the file with binary mode and not text mode.

Is this ZIP file a big one file, or it is split into smaller parts like < 2GB. Maybe something with the big file handling went wrong, but if this is the situation - I don't know what to do.

I think the file transfer was okay too, but still:
If you FTPed this file *from* a windows machine in ASCII mode, then you're screwed.
It'll have replaced all occurrences of 0d0a with 0a. Good luck figuring out which 0a needs a 0d in front
To check, see if your file has any 0d0a in it. If there are none then the chance that this happened is big

You can also take a closer look at the headers inside the zip file. Some info here: ftp://ftp.info-zip.org/pub/infozip/doc/appnote-iz-latest.zip and here http://www.winzip.com/aes_info.htm


Now about the encrypted file:

It looks like your "Send to -> Compressed File" is associated with WinZip.
Since the target file was encrypted, the chances are that the WinZip installation on that W2k3 box is configured to encrypt files by default. If you have left the WinZip settings on that machine alone the chance is good that you can recover the password it used.

Your version of winrar balks at the compression method "63" which is a winzip AES encrypted special value. The actual compression method is found in an AES extra data field.

Quote from Z

Is this ZIP file a big one file, or it is split into smaller parts like < 2GB. Maybe something with the big file handling went wrong, but if this is the situation - I don't know what to do.

The data inside de zip file is aprox 900 GB of data, but the zip file is aprox 300 MB, so I think that there isn't an error in the file handling.

Quote from Kender

It'll have replaced all occurrences of 0d0a with 0a. Good luck figuring out which 0a needs a 0d in front
To check, see if your file has any 0d0a in it. If there are none then the chance that this happened is big

I found some 0d 0a and other 0d 0x bytes all over the file.

Quote from Kender

You can also take a closer look at the headers inside the zip file. Some info here: ftp://ftp.info-zip.org/pub/infozip/doc/appnote-iz-latest.zip and here http://www.winzip.com/aes_info.htm

Thanks, an imagen would clarify the situation.
Click To view the image of the Zip file structure that I have
In that image we can extract the headers (Appear in order of boxes):
*Local file header signature (4 bytes) 0x04034b50 (PK)
*Version needed to extract (2 bytes) 0x0014
*General purpose bit flag (2 bytes) 0x0001 ('As for any encrypted file, bit 0 of the "general purpose bit flags" field must be set to 1 in each AES-encrypted file's local header and central directory entry.')
*Compression method (2 bytes) 0x0063
*Last modified file time (2 bytes) 0x8ec1
*Last modified file date (2 bytes) 0x3789
*Crc-32 (4 bytes) 0x00000000 ('For files encrypted using the AE-2 method, the standard Zip CRC value is not used, and a 0 must be stored in this field.')
*Compressed size (4 bytes) 0x00000a83 (2691 bytes)
*Uncompressed size (4 bytes) 0x00005400 (21504 bytes)
*File name length (2 bytes) 0x0027 ('xExchange/AMI Price Scatter Example.xls 27h bytes 39 bytes long')
*Extra field length (2 bytes) 0x000b ('The extra data header ID for AES encryption is 0x9901. The fields are all stored in Intel low-byte/high-byte order. The extra data field currently has a length of 11: seven data bytes plus two bytes for the header ID and two bytes for the data size. Therefore, the extra data overhead for each file in the archive is 22 bytes (11 bytes in the central header plus 11 bytes in the local header)').
"xExchange/AMI Price Scatter Example.xls"

And here's come the extra data field of 11 bytes:
*Extra field header ID (2 bytes) 0x9901
*Data size (2 bytes) 0x0007
*Integer number version specific to the vendor zip (2 bytes) 0x0002
*2-character vendor ID (2 bytes) 0x4541 (AE)
*Integer mode value indicating AES encryption strength (1 byte) 0x03 ('256-bit encryption key')
*The actual compression method used to compress the file (2 bytes) 0x0008

And the next part of the archive is the compressed and encrypted data.

Quote from Kender

Since the target file was encrypted, the chances are that the WinZip installation on that W2k3 box is configured to encrypt files by default. If you have left the WinZip settings on that machine alone the chance is good that you can recover the password it used.

The server was formated a few weeks ago, and the data is irrecoverable

And that's all, anyway, I'm not giving up hope.
Thank you very much Z and Kender for the reply. With that analysis I'm sure that the file is encrypted with AES 256.

I found something that might help you:

Most ZIP-utilities do not have support for AES encryption and thus will not be able to unzip files created with BitZipper 4.1 or newer. BitZipper 4.1 is compatible with WinZip 9, and both utilities can unzip AES-protected ZIP-files created by the other.

Do not rely on the encryption algorithm alone when protecting your data. Be sure you select a password or rather a "pass phrase" which is difficult to guess but still easy for you to remember. Always use a mix of lowercase/uppercase letters, digits and special characters.

Only the content of files stored in a ZIP-file is encrypted. The file name, date, size and attributes are stored in unencrypted form in the ZIP-file header and can be viewed without a password, by any tool that can access a ZIP-file.

I don't have the password, read my first post and here you'll find all the information about the issue.
I found a manual that's hard to find about an analysis of winzip encryption method, but I don't understand somethings (Analysis of WinZip Encryption Method by Tadayoshi Kohno