You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Would be great if --list (-L) argument result table will include info about comression level of encrypted archive. Think it's not so complicated, because zipdetails perl script has that function.
Another interesting approach, if bkcrack could determine packer program (if it's possible somehow) - pkzip, zip/winzip/winrar, 7zip, etc.
The perspective of that functionality - an ability to autopack plaintext with detected packer (but some packers could be proprietary...)
The text was updated successfully, but these errors were encountered:
Think it's not so complicated, because zipdetails perl script has that function.
The compression level information available in ZIP metadata has four possible values (normal, maximum, fast, super fast) so it does not correspond exactly to the compression level used by InfoZIP or 7zip packers for example (which have compression levels numbered from 1 to 9).
In addition 7zip outputs the same 'normal' compression level in the output archive metadata for any compression level as far as I know, so I am not sure showing that information is so useful.
Maybe showing it only when it is not not 'normal' could be nice?
The perspective of that functionality - an ability to autopack plaintext with detected packer (but some packers could be proprietary...)
I plan to eventually implement this with zlib deflate implementation: #84. It would not cover all cases but it would still be something :)
Would be great if --list (-L) argument result table will include info about comression level of encrypted archive. Think it's not so complicated, because zipdetails perl script has that function.
Another interesting approach, if bkcrack could determine packer program (if it's possible somehow) - pkzip, zip/winzip/winrar, 7zip, etc.
The perspective of that functionality - an ability to autopack plaintext with detected packer (but some packers could be proprietary...)
The text was updated successfully, but these errors were encountered: