cannot decrypt this compressed folder or change its password(s)

[FrostKnight]

Is it possible to decrypt all encrypted folders in the same zipcrypto at the same time if they have multiple passwords?

By the way, I cannot seem to change a compressed encrypted folder's password(s) either or recover them, etc...

I could use some help, but I am hesitant to put my compressed folder on here. I kind of want to keep it to myself if you know what I mean.

It has ideas of mine that I want kept secret for now. I have this info though:

1 ZipCrypto  Store       f10b2d97          
2 ZipCrypto  Store       493be384            
3 ZipCrypto  Store       c20b6a82          
4 ZipCrypto  Deflate     f169a3b6  
5 zipCrypto  Store       6e9b51d6

My main reason for not wanting to upload is not you, its the fact its a public repo and microsoft, etc...

But anywho, can you help me?

I provided the CRC btw.

[kimci86]

Is it possible to decrypt all encrypted folders in the same zipcrypto at the same time if they have multiple passwords?

This is not implemented at the moment. I figured this is a rare scenario so I did not bother to support it, but there is no theoretical difficulty doing so. If there is some compelling use case, I might consider implementing it in the future.

What you can do for now with the current version of bkcrack is either decipher entries one by one, or change the password for encrypted entries all at once, but this is assuming all encrypted entries were encrypted with the same password. In your case, if deciphering entries one by one is too cumbersome, maybe it would be worth making several copies of your zip archive from which you remove some entries with an archive manager so that each copy contains only entries that used the same password. Then use bkcrack to change the password for each of those partial copies.

By the way, I cannot seem to change a compressed encrypted folder's password(s) either or recover them, etc...

What have you tried so far and what was the result? Were you able run known-plaintext attacks? I see you have several ZipCrypto Store entries so, depending on the file types, it shouldn't be too hard to guess enough plaintext.

I could use some help, but I am hesitant to put my compressed folder on here. I kind of want to keep it to myself if you know what I mean.

Sure, don't put your files here publicly if you don't want to. If you are ok sharing the files with me so I can have a closer look, you can send me an attachment of download link via email. Check my git commits for my email.

[FrostKnight]

Can't find your email for some reason... Btw, I have tried changing password with your software with the following: unlock encrypted archive recover password (too slow) it seems likely I have 20 characters or more. list entries

The other options I couldn't get to work, maybe due to misunderstandings?

I dunno whats going on

[kimci86]

There is some work to do before being able to decipher data or change an archive's password. bkcrack implements a known-plaintext attack. It means you need to provide a piece of data before and after encryption and the tool can use weaknesses of the encryption algorithm to derive a password internal representation. This internal password representation can then be used to decipher data of change an archive's password (assuming entries all have the same password). It can also be used to try to recover the original password. You can see a basic example of how to run a known-plaintext attack, decipher data and recover a password here: https://github.com/kimci86/bkcrack/blob/master/example/tutorial.md So the first step is to find or guess a piece of data that is included in your encrypted archive to run a known-plaintext attack. Let me know if you need more help.

I added my email to my github profile so you can send information more privately if you want.

[FrostKnight]

I actually just got it running like in the guide,

but it didn't give me the keys. whats odder is also this:

0 ZipCrypto Store afd5c43f 7178641 7178653 example/example.zip

More or less, this is what the zip file looks like and yet, I couldn't open it.

More info:

[01:27:13] Z reduction using 85 bytes of known plaintext 100.0 % (85 / 85) [01:27:14] Attack on 98859 Z values at index 6

Keys not found! was basically what I saw after. the xml 1.0 btw.

[kimci86]

Can you please share the exact commands you are running?

[FrostKnight]

Will do,

Can you please share the exact commands you are running?

here:

../bkcrack -L secrets.zip echo -n '<?xml version="1.0" ' > plain.txt /usr/./bkcrack -C Secrets.zip -c Secrets/Secrets.zip -p plain.txt

[kimci86]

The example using <?xml version="1.0" as known plaintext is targeting an SVG file encrypted and stored inside a ZIP file. Your case is different because you are targeting a ZIP file encrypted and stored inside a ZIP file. You need to provide a piece of the data that the original Secrets/Secrets.zip file contains, not a piece of an SVG file.

We can try to guess some parts of the data from the ZIP format specification. Here are some possible ways the file can start (in hexadecimal) that I suggest trying:

• 50 4b 03 04 14 00 00 00 00 00
• 50 4b 03 04 14 00 00 00 08 00
• 50 4b 03 04 14 00 08 00 00 00
• 50 4b 03 04 14 00 08 00 08 00

Assuming the file is smaller that 16 MB from your previous messages, we can also guess that the byte at offset 21 is 00. That is just enough data to run an attack. If you know something about how the file Secrets/Secrets.zip was created, it could help to make more precise guesses and save some computation time.

For now I suggest trying the following commands until one is successful. It might take a little while.

bkcrack -C Secrets.zip -c Secrets/Secrets.zip -x 0 504b0304140000000000 -x 21 00 -e
bkcrack -C Secrets.zip -c Secrets/Secrets.zip -x 0 504b0304140000000800 -x 21 00 -e
bkcrack -C Secrets.zip -c Secrets/Secrets.zip -x 0 504b0304140008000000 -x 21 00 -e
bkcrack -C Secrets.zip -c Secrets/Secrets.zip -x 0 504b0304140008000800 -x 21 00 -e

Let me know how it goes.

[FrostKnight]

Am in the process of trying the second variant of your command above, it uses a hell of a lot of cpu power. This being said, I will let you know if the other three work. The first failed.

Might wait till tomorrow to do the next 3.

[FrostKnight]

Got this error trying to decipher it or change it using the keys I got: End-of-central-directory signature not found. Either this file is not a zipfile, or it constitutes one disk of a multi-part archive. In the latter case the central directory and zipfile comment will be found on the last disk(s) of this archive.

I used this command:

/usr/./bkcrack -C Secret.zip -c Secret/Secret.zip -k ddc62fd3 d8d038eb 2835f489 -d Secretk.zip

Then I proceeded to try and open the zip to no avail.

I don't suppose I did something wrong, or got the wrong keys, right? I mean it only recovers keys that the file has, right?

I also used the one to change password with it using those same keys to change password.

[kimci86]

You might have found a false positive, that is to say a solution which gives deciphered data that matches the known plaintext that was provided but does not match the original file elsewhere. That can happen when we provide the minimum amount of known plaintext, which is 12 bytes. Did you interrupt the attack once this false positive was found, or did you let it finish? Was there only one solution? An attack can lead to several solutions, one of which may be the right one.

Otherwise, it might simply be that the plaintext was not correct. I suggested what I believe is more common but it does not cover all possible ways a ZIP file can start. What do you know about the file Secrets/Secrets.zip? For example, what tool was used to create it? How many entries could it contain? Knowing more information can help us guess more known plaintext correctly. The more contiguous known plaintext we have, the faster the attack runs.

That being said, I think we can take a slow but safe way by guessing some data that should be correct at the end of the file rather than making assumptions about the beginning. If you target a ZIP file Secrets/Secrets.zip that is 7178641 bytes long, stored and encrypted inside Secrets.zip archive, try this:

bkcrack -C Secrets.zip -c Secrets/Secrets.zip -x 7178619 504b050600000000 -x 7178634 00 -x 7178638 000000

Because this guess contains only 8 contiguous bytes (which is the minimum), it will take the longest time an attack can take (depends on your CPU, max about two hours on CPU with 8 threads), but it should succeed. This time we provide a total of 13 bytes of known plaintext (12 on the command line + 1 derived automatically from archive metadata), so there are fewer chances of false positive. Let me know how it goes. If something goes wrong and you need more help, please include the console output in your next message so I can better understand what happens on your side.

[FrostKnight]

I will try that when I have time. I should probably mention,this might really tax my quad core i7 laptop. The other attack previously, brought it up to like 5+ on the load average scale by itself! But anywho, yeah it has 5 encrypted files in it. One is alas, deflate. The rest are stored (thank God!)

Which means most should be easy to open.

[FrostKnight]

Amazingly, it seems to have worked in unencrypting the first part. I still have a few more to do, but the first layer has been taken down. Thank you.

[FrostKnight]

Quick thing to add, is there a way to use less cpu power doing this attack:

bkcrack -C Secrets.zip -c Secrets/Secrets.zip -x 7178619 504b050600000000 -x 7178634 00 -x 7178638 000000

Even if it slows down how fast that works?

It uses a hell of a lot of cpu power. Oh and also,

Btw, I have another file to crack:

0 ZipCrypto  Store       d0bfd0ff      6442048      6442060 Secrets/Secrets.zip
1 None       Deflate     fd24bac2       361626       358665 Secrets/Somethingelse.docx
2 None       Store       d2c77c3a       377376       377376 Secrets/Alsosomethingelse.zip

[kimci86]

is there a way to use less cpu power [...] Even if it slows down how fast that works?

Yes, you can use option -j to select the number of threads running the attack. Example: -j 2 to use 2 threads. This will of course make the attack longer than using all your CPU threads (assuming you have more than 2 CPU threads).

I have another file to crack

Your other ZIP archive also contains a stored encrypted zip so we can probably use the same plaintext near the end of the file as we did before. We need to adjust offsets because the file size is different. The plain data we can use for a stored zip file of size N is:

• offset N - 22 : 50 4b 05 06 00 00 00 00
• offset N - 7 : 00
• offset N - 3 : 00 00 00

So for your file of size 6442048, the command would be:

bkcrack -C your_file.zip -c Secrets/Secrets.zip -x 6442026 504b050600000000 -x 6442041 00 -x 6442045 000000

[FrostKnight]

What you said worked again. Only one small issue, I seem to have found yet again one other folder. I think this was done in my naive days when I thought windows security meant something. lol.

Anywho, can you tell me how you make those calculations?

Reason being, this is a huge bit of info what I just got.

doing /usr/./bkcrack on my last Secrets.zip revealed the below but I put !! on the ones that don't need to be unzipped, because they are not zips and therefore do not matter.

    0 ZipCrypto  Deflate     6dcf6f86       163911       163800 1
    1 ZipCrypto  Store       cfd7957e       269244       269256 2
    2 ZipCrypto  Store       f2356b4e       564855       564867 3
    3 ZipCrypto  Deflate     51095703          250          191 4!!
    4 ZipCrypto  Deflate     164bd9c5           68           79 5!!
    5 ZipCrypto  Store       5748f604        62773        62785 6
    6 ZipCrypto  Deflate     c8104ecf       228070       228152 7
    7 ZipCrypto  Store       58617a79        41022        41034 8!!
    8 ZipCrypto  Store       31064cf8        21965        21977 9
    9 ZipCrypto  Store       696933df        18246        18258 10
   10 ZipCrypto  Store       ded918e9        30794        30806 11
   11 ZipCrypto  Deflate     a72d10f5       404921       404982 12
   12 ZipCrypto  Store       d0ddc420          594          606 13
   13 ZipCrypto  Deflate     33dfcfbf          131          111 14!!
   14 ZipCrypto  Store       62ca5370       110623       110635 15
   15 ZipCrypto  Store       699eb4e2          336          348 16
   16 ZipCrypto  Deflate     ab832627        17154        13503 17!!
   17 ZipCrypto  Deflate     7e364891       163440       163502 18!!
   18 ZipCrypto  Store       9313e1e6        16058        16070 19
   19 ZipCrypto  Deflate     27bc9ecb       160166       156829 20!!
   20 ZipCrypto  Deflate     eff3e235       286187       282894 21!!
   21 ZipCrypto  Deflate     7f01d972       195336       192343 22!!
   22 ZipCrypto  Deflate     e9f9bee3       351775       348848 23!!
   23 ZipCrypto  Deflate     c5386523        18595        15983 24!!
   24 ZipCrypto  Store       05a9a9c7      1273199      1273211 25
   25 ZipCrypto  Store       f1faaa7c       242289       242301 26
   26 ZipCrypto  Store       ecc832ed       696830       696842 27
   27 ZipCrypto  Deflate     75b526d3         3783         1762 28!!
   28 ZipCrypto  Deflate     d894bb67         3276         1545 29!!
   29 ZipCrypto  Deflate     94784391          202          162 30!!
   30 ZipCrypto  Deflate     d34dc69d        17826        14630 31!!
   31 ZipCrypto  Deflate     88c0e100       175323       175390 32!!
   32 ZipCrypto  Deflate     aa93a8c6       153589       153651 33!!
   33 ZipCrypto  Store       0d9be92c       770393       770405 34

Btw, can you even decrypt word processor documents with this tool?

I kid you not, I have 33 files in this last secrets.zip

I really did believe back then that the more folders you compressed under different encryptions made files more secure. problem being, microsoft and security go together like urine and sandwiches

[FrostKnight]

Actually, foolish of me to forget this, but its possible, that it might be simpler than that, I might just need to crack one password, so its up in the air I think.

[kimci86]

If I understand correctly, you have another archive which contains some stored encrypted zip files. So you can choose one of them to run a known-plaintext attack using the same data near the end of the file as we did before, adjusting the offset with the file size. Let's say for example you choose the last one (index 33), the original size is 770393, so based on my previous message, the command would be:

bkcrack -C your_file.zip --cipher-index 33 -x 770371 504b050600000000 -x 770386 00 -x 770390 000000

Then assuming all the entries in your encrypted archive were encrypted using the same password, you can decipher what you want or change the password to extract what you want. Does that help?

[kimci86]

@FrostKnight Did you manage to decrypt your files? Do you have more question or feedback?

[FrostKnight]

@FrostKnight Did you manage to decrypt your files? Do you have more question or feedback?

I have maybe four more actually, all are in zips as docx's.

Index Encryption Compression CRC32    Uncompressed  Packed size Name
----- ---------- ----------- -------- ------------ ------------ ----------------
    0 ZipCrypto  Deflate     b4a98507        24830        21835 Secret.docx

Index Encryption Compression CRC32    Uncompressed  Packed size Name
----- ---------- ----------- -------- ------------ ------------ ----------------
    0 ZipCrypto  Deflate     bb3798d5        21193        18110 Secret.docx

Index Encryption Compression CRC32    Uncompressed  Packed size Name
----- ---------- ----------- -------- ------------ ------------ ----------------
    0 ZipCrypto  Deflate     d49f0386        66087        62625 Secret.docx

Index Encryption Compression CRC32    Uncompressed  Packed size Name
----- ---------- ----------- -------- ------------ ------------ ----------------
    0 ZipCrypto  Deflate     8a2a1b60        33591        30646 Secret.docx

I think these might actually be the final ones within the archives I have been searching.

At least of the ones I mentioned to you. I don't know if you can get inside of them due to them being deflate though.

[kimci86]

In the case of compressed docx, it would probably require to know an entire file to get valid compressed plaintext. If you do not have such file, using bkcrack might be too hard. See also a related answer here: https://github.com/kimci86/bkcrack/issues/81#issuecomment-1279449618

[FrostKnight]

In the case of compressed docx, it would probably require to know an entire file to get valid compressed plaintext. If you do not have such file, using bkcrack might be too hard. See also a related answer here: #81 (comment)

If you mean the whole filename as in, what name the file is called, I could give it to you privately. But if you mean everything in the docx, then no. I don't even know its been so long. lol

[kimci86]

I meant the file content, not the just filename. Maybe the filename can indirectly help finding the file content, for example if there is a backup somewhere, but what is really necessary in the end for an attack is the original docx file content.

[FrostKnight]

I meant the file content, not the just filename. Maybe the filename can indirectly help finding the file content, for example if there is a backup somewhere, but what is really necessary in the end for an attack is the original docx file content.

Yeah uh... I don't have any access to the actual original docx file content.

I did at least decrypt most of what I wanted though. So if this is how it is, so be it.

I was just hoping is all. ;)

If there is nothing else you can do, feel free to lock.

I alas, don't have what I need.

[kimci86]

Understood, I guess bkcrack cannot be used further in this case. I close this issue then.