Hey.
There are actually 2 known problems which I will try to investigate:
1. a problem with the lzma decompression, done by 7z2hashcat.pl, of the header (in case of a "long" file list), probably related to an issue I found with Compress::Raw::Lzma (but I will need some further investigation)
2. in some rare cases the algorithm changes from crc32 (aes_decrypt ($data)) to crc32 (lzma_decode (aes_decrypt ($data)) depending on the data length (i.e. if 7z thinks it makes sense to lzma compress it)... this needs to be implemented in the cracker/hashcat (this case unfortunately also occurs with the 7z archive provided by marpolo, see https://hashcat.net/forum/thread-4328-po...l#pid32826 , I've checked it in detail, i.e. analysed the whole 7z structure of this archive, thanks btw for this example)
for #2 I've already discussed this with @atom and we came to the conclusion that I could implement this via a hook (the hook concept is already "supported" by hashcat), to make this intermediate lzma decompress step.
Unfortunately the hash format (which we btw 1:1 took from john the ripper) does not have a field to indicate if it was lzma compressed (while 7z2hashcat.pl is able to identify all "coders" and has this information). Therefore, we actually have this info, but can't output it into the hash format without changing it (and when we do so we might end up with 2 different hash formats .... but since jtr seems to also rely on 7z2hashcat.pl now, we might decide to just change the hash format, no matter what).
This would mean that the cracker in the future needs to do the following 3 steps (but by changing the hash format we can reduce the number to 2):
1. try if crc32 (aes_decrypt ($data)) matches
2. try if the AES CBC padding attack works (this reduces the data needed withusein the hash format)
3. try if crc32 (lzma_decode (aes_decrypt ($data))) matches (the hook needs to be implemented)
(you might have already guessed it, but to make it very clear: if we know that we need to use method #1 or method #3, we do not need to try both)
I will probably update 7z2hashcat.pl soon, with some fixes and most importantly some warnings/errors such that the user knows what is going on. E.g for the problem "what about bigger 7z archives?", this might be releated to the known problem #1 (the data probably was lzma compressed to safe additional bytes/disk space), I will try to fix the decompression or at least output a warning/error (instead of the "just exit").
For the hook feature (lzma decompression after the decryption step) I will open a github issue soon and try to implement it.
As you see, there are some very unrelated problems, but we will try to fix them 1 by 1.
Maybe in the meantime, you can let me know if you still experience problems with "Wide character in..." output. They should be fixed with next release version of 7z2hashcat.pl (probably version 0.5 or highter) and I actually already pushed a fix to github (see https://github.com/philsmd/7z2hashcat/co...1241e40d1c).
Attention: I didn't provide a new 7z2hashcat.exe release yet, therefore you currently must use the latest source code (not the release version) to test if this problem still exists. If you think that the error still occurs (even with the fix), then please provide/sent me such a 7z file.
Thanks
There are actually 2 known problems which I will try to investigate:
1. a problem with the lzma decompression, done by 7z2hashcat.pl, of the header (in case of a "long" file list), probably related to an issue I found with Compress::Raw::Lzma (but I will need some further investigation)
2. in some rare cases the algorithm changes from crc32 (aes_decrypt ($data)) to crc32 (lzma_decode (aes_decrypt ($data)) depending on the data length (i.e. if 7z thinks it makes sense to lzma compress it)... this needs to be implemented in the cracker/hashcat (this case unfortunately also occurs with the 7z archive provided by marpolo, see https://hashcat.net/forum/thread-4328-po...l#pid32826 , I've checked it in detail, i.e. analysed the whole 7z structure of this archive, thanks btw for this example)
for #2 I've already discussed this with @atom and we came to the conclusion that I could implement this via a hook (the hook concept is already "supported" by hashcat), to make this intermediate lzma decompress step.
Unfortunately the hash format (which we btw 1:1 took from john the ripper) does not have a field to indicate if it was lzma compressed (while 7z2hashcat.pl is able to identify all "coders" and has this information). Therefore, we actually have this info, but can't output it into the hash format without changing it (and when we do so we might end up with 2 different hash formats .... but since jtr seems to also rely on 7z2hashcat.pl now, we might decide to just change the hash format, no matter what).
This would mean that the cracker in the future needs to do the following 3 steps (but by changing the hash format we can reduce the number to 2):
1. try if crc32 (aes_decrypt ($data)) matches
2. try if the AES CBC padding attack works (this reduces the data needed withusein the hash format)
3. try if crc32 (lzma_decode (aes_decrypt ($data))) matches (the hook needs to be implemented)
(you might have already guessed it, but to make it very clear: if we know that we need to use method #1 or method #3, we do not need to try both)
I will probably update 7z2hashcat.pl soon, with some fixes and most importantly some warnings/errors such that the user knows what is going on. E.g for the problem "what about bigger 7z archives?", this might be releated to the known problem #1 (the data probably was lzma compressed to safe additional bytes/disk space), I will try to fix the decompression or at least output a warning/error (instead of the "just exit").
For the hook feature (lzma decompression after the decryption step) I will open a github issue soon and try to implement it.
As you see, there are some very unrelated problems, but we will try to fix them 1 by 1.
Maybe in the meantime, you can let me know if you still experience problems with "Wide character in..." output. They should be fixed with next release version of 7z2hashcat.pl (probably version 0.5 or highter) and I actually already pushed a fix to github (see https://github.com/philsmd/7z2hashcat/co...1241e40d1c).
Attention: I didn't provide a new 7z2hashcat.exe release yet, therefore you currently must use the latest source code (not the release version) to test if this problem still exists. If you think that the error still occurs (even with the fix), then please provide/sent me such a 7z file.
Thanks