Can't seem to find the right compression level.

[dailycodee]

Hello!

I have an archive in .rfs format, 7zip recognizes it as ZipCrypto Deflate:Fastest. (new.rfs)

I have the same archive from earlier versions and know the password for it. (old.rfs)
Password for old.rfs is 4a3408a275b0343719ae2ab7250a8cab0c03b2178a58f2de.
I suspect the password length from rfs.new will be the same. If that helps, of course.

I found files that have the same CRC in both the old and new archive. For example Abnormal00.dds.

My next step was to try to compress this file so that its compressed size coincides with the same compressed file in new.rfs.

This is where I ran into a problem, I think that's why my attempts to find the keys failed.
I would like to ask for help with analyzing this archive.

I was unable to upload these archives to github. So I uploaded them to a third-party file-sharing site
https://file.io/tzQXHjj06TIJ

So I am attaching links to virustotal

https://www.virustotal.com/gui/file/7ec5723cff530865677e7d49a8ffe2de1da7a8b8daeda4e3366626f3d34dc9a1?nocache=1
https://www.virustotal.com/gui/file/6c5cb3eebfbfb7164ae2cde06b461a8269c626a10f062c51922895b33266ce67?nocache=1

[kimci86]

Hello!

Let me explain how I solved this. The first step is to get some known plaintext.
For example we can decipher (without decompressing) Abnormal00.dds entry from old.rfs as the password is known:

bkcrack -C old.rfs -c Abnormal00.dds --password 4a3408a275b0343719ae2ab7250a8cab0c03b2178a58f2de -d Abnormal00.dds.deflate

Because CRC and compressed size match the entry in new.rfs this is probably good to run an attack on new.rfs:

bkcrack -C new.rfs -c Abnormal00.dds -p Abnormal00.dds.deflate

This did not work.
After some other failed attempts with other entries that I expected to work because of matching CRC and compressed size, I thought there must be something wrong with the files.
So I tried again with --ignore-check-byte option. This option removes an assumption about the encryption header.

bkcrack -C new.rfs -c Abnormal00.dds -p Abnormal00.dds.deflate --ignore-check-byte

This was successful! It found the internal password representation c08db5fd 1257de18 05b397b3.
The assumption about the check byte is usually true for valid zip files, but here there is a small inconstency between entries metadata and encryption header that makes the assumption wrong. This is why it was not working without --ignore-check-byte option.

Now that we have the internal password representation, we can do what we want.
For example remove password protection:

bkcrack -C new.rfs -k c08db5fd 1257de18 05b397b3 -D new-without-password.rfs

Or change the password:

bkcrack -C new.rfs -k c08db5fd 1257de18 05b397b3 -U new-with-chosen-password.rfs hello

Note the inconsistency between entries metadata and encryption headers of new.rfs would be the same in new-with-chosen-password.rfs created with the command above. As a consequence, trying to check new-with-chosen-password.rfs consistency with 7z t -phello new-with-chosen-password.rfs for example would fail. This is expected because of the actual inconsistency between entries metadata and encryption headers.

Let me know if that solves your problem and if you have any other question or feedback.

[dailycodee]

Thank you very much for your reply. I have now tried it and I was also able to find the keys.

But then I encountered two problems.

1. Command ./bkcrack.exe -C gui.rfs -k c08db5fd 1257de18 05b397b3 -D test.rfs

Arguments error: unknown option -D. (attached screenshot)

2. When trying to use the command bkcrack -C new.rfs -k c08db5fd 1257de18 05b397b3 -U new-with-chosen-password.rfs hello all goes successfully

But when I try to unpack the files with the given hello password from the archive - I get an invalid password error.

[dailycodee]

I apologize, I didn't notice the release of the new version. I was indeed able to save the archive without password.
But the second problem I wrote about remains relevant

[kimci86]

I forgot to mention option -D was added recently in version 1.7.0.

Regarding extracting the archive with a chosen password, it is showing invalid password errors because of the inconsistency between entries metadata and encryption headers, the same inconsistency that was causing the attack to fail at first. Extracting files successfully would require either an archive manager that can skip the check byte verification, or fixing the entries metadata.
To be more specific, the inconsistency is that entries metadata have the bit 3 of the general purpose bit flag off, but the encryption headers end with a byte from the file's last modification time instead of the CRC most significant byte. (At least this is what I noticed for Abnormal00.dds entry.) Bit 3 of the general purpose bit flag should be set to fix the inconsistency. I am not sure what tool would be best to automate this if you wanted to do that.

[kimci86]

@dailycodee Is there anything left you need help with?

[dailycodee]

No thanks!