These are almost all taken from error messages that are specific to one
particular module, and turned into generic errors that can be used for any
module. It seemed like a better idea to provide generic messages than to
encourage infinite proliferation of error codes (which would probably end up
blowing the 255 value threshold sooner or later). It doesn't seem necessary
to provide module-specific error messages for things like "Invalid <X>
filesize", since users should already know what sort of file they're asking
to be parsed.
Useful in cirumstances where you want to work with individual elements
of a vector, typically after you've done some vector-compatible operations
(mass-hashing, for example) but now need to do some non-vector-friendly
work (like executing most decryption algorithms).
These are almost all taken from error messages that are specific to one
particular module, and turned into generic errors that can be used for any
module. It seemed like a better idea to provide generic messages than to
encourage infinite proliferation of error codes (which would probably end up
blowing the 255 value threshold sooner or later). It doesn't seem necessary
to provide module-specific error messages for things like "Invalid <X>
filesize", since users should already know what sort of file they're asking
to be parsed.
If module_hash_binary_parse is completely unable to successfully parse out
any hashes, up until now the output has been
```
Hashfile 'foo': Success
```
which is less than helpful.
This patch allows (but does not require) m_h_binary_parse to report a useful
error response, by returning a negative value. Modules which continue to
return '0 hashes' will get the same less-than-useful behaviour they always
hace.
I've also modified the LUKS module to report a useful error, as a proof of
concept.
Further expansions on this could include:
* Applying similar behaviour to module_hash_binary_count, so it too can
report errors when trying to count hashes. This would require more
co-ordinated change, because m_h_binary_count already uses -1 to indicate
a system error.
* Allow and encourage modules to print their own errors and warnings during
parsing. This would allow for situations where a single hash in a
multi-hash file could be reported as malformed, without having to fail the
whole parse. However, implementing this would, I expect, require modules
to have access to `hashcat_ctx`, which... yeah. Not so straightforward.
