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
Describe the feature
Hashcat used to use a padding attack to crack 7z archives - I've verified that the files from the specific version of 7zip used in file X will most likely have used null padding bytes, so I'd like to compare hashcat's speed in cracking X to JtR (and also wouldn't mind being able to use hashcat features), as I've determined that the padding attack seems much faster.
Current behavior
as of 1f93d20, aa14b4e and af3619f, truncated (padding based) 7zip hashes are unsupported, and return a token length exception.
Expected behavior
When providing hash with type $7z$128$... hashcat correctly parses it and perhaps displays a big red or yellow warning, but still proceds to crack it, perhaps after seeking user confirmation or by a command line switch if necessary
Hashcat version (please complete the following information):
OS: Any
Distribution: ..
Version: 6.2.6 (beta)
Additional context
Add any other context or screenshots about the feature request here.
The text was updated successfully, but these errors were encountered:
GitHub is for bugs and features - not for support
For support, please use the hashcat forums https://hashcat.net/forum/
Check the FAQ
Some items that might appear to be issues are not issues. Please review the hashcat FAQ https://hashcat.net/wiki/doku.php?id=frequently_asked_questions before submitting a bug report.
Describe the feature
Hashcat used to use a padding attack to crack 7z archives - I've verified that the files from the specific version of 7zip used in file X will most likely have used null padding bytes, so I'd like to compare hashcat's speed in cracking X to JtR (and also wouldn't mind being able to use hashcat features), as I've determined that the padding attack seems much faster.
Current behavior
as of 1f93d20, aa14b4e and af3619f, truncated (padding based) 7zip hashes are unsupported, and return a token length exception.
Expected behavior
When providing hash with type $7z$128$... hashcat correctly parses it and perhaps displays a big red or yellow warning, but still proceds to crack it, perhaps after seeking user confirmation or by a command line switch if necessary
Hashcat version (please complete the following information):
Additional context
Add any other context or screenshots about the feature request here.
The text was updated successfully, but these errors were encountered: