-
Notifications
You must be signed in to change notification settings - Fork 2.8k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Fix access violation in hashconfig_destroy if hashcat_ctx_t is only p…
…artially initialized. Fix hashcat_ctx leak and refactor module and kernel existence checks.
- Loading branch information
Showing
2 changed files
with
42 additions
and
46 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
6967e70
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jtojanen I think I did not check this PR with enough care. The changes done to user_options.c break --hash-info. See #2859 as a reference.
The fixed values in module_filename () and especially generate_source_kernel_filename () were done on purpose. I think I need to revert the changes in user_options.c, but before I do I want to clarify that the only reason why you changed it was that you can do the test for the -m mode that the user actually selected. Is that right? If yes, that's not what we want to do, because we only want to test for this particular case in which the user did not unpack hashcat correctly. For that purpose using a fixed value fits perfectly.
6967e70
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jsteube I did study the detection algorithm, but it seems that I didn't test all cases. I do understand the reasoning behind fixed values, although 0 and 400 seemed like random magic numbers.
As we already call "hashconfig_init" in user_options.c, which loads and initializes the needed module, tries to read both pure and optimized kernel and sets flags "hashconfig->has_pure_kernel" and "hashconfig->has_optimized_kernel", this is all we need. I only forgot to remove test "if (user_options->hash_info == false)" in interface.c as that blocked the final decision making between pure and optimized kernels. I have committed a fix containing this.
Actually now we can also simplify logics in user_options.c to use "hashconfig->has_pure_kernel == false && hashconfig->has_optimized_kernel == false" instead of retesting kernel in lines 2875 - 2885.
6967e70
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm afraid that's not entirely correct. The original code called hashconfig_init() but the idea is to use a fixed -m value for that, too. That saves us to check if the user-specified -m value is a valid one. But since the -m value will be hardcoded to zero, we do not know about flags "hashconfig->has_pure_kernel" and "hashconfig->has_optimized_kernel", because they will be related to -m 0, not the one the user specified. That causes problem in --hash-info. All this is not necessary if we switch back to the original code base. The question is (and I hope you can answer that) what is it that we lose and can we redo it afterwards in a different way?
6967e70
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have partially reverted this PR (src/user_options.c part) in order to fix #2859. We can redo what's lost after the changes in #2858 are split and described in details, which should also cover the reverted sections from this PR.