github/hashcat
1
Fork 0
mirror of https://github.com/hashcat/hashcat synced 2024-11-20 23:27:31 +01:00
Code Releases Activity

Merge pull request #3383 from philsmd/dev_guide_benchmark_settings

Browse Source 
update dev guide: add notes about benchmark settings
This commit is contained in:
Jens Steube 2022-07-16 20:22:31 +02:00 committed by GitHub
commit 700e36b0f1
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 15 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

15
docs/hashcat-plugin-development-guide.md
View File

@ -244,6 +244,9 @@ Namely, these configurations take place in a variety of optional functions that
* module_salt_type() * module_salt_type()
* module_st_hash() * module_st_hash()
* module_st_pass() * module_st_pass()
* module_benchmark_mask()
* module_benchmark_charset()
* module_benchmark_salt()
At first glance, this looks a bit overwhelming. But in fact, all of these functions (apart from the first three) are only configuration parameters. You may wonder why we have not designed the module by simply setting a macro/number item for each of the configurations. But we wanted to give you the opportunity to change this configuration at runtime and not just at compile time. For example, if you only want to use a specific optimizer but only if the user runs the kernel on a GPU and not if the user runs it on a CPU. But this actually goes into deep detail. In reality, it usually looks like this: At first glance, this looks a bit overwhelming. But in fact, all of these functions (apart from the first three) are only configuration parameters. You may wonder why we have not designed the module by simply setting a macro/number item for each of the configurations. But we wanted to give you the opportunity to change this configuration at runtime and not just at compile time. For example, if you only want to use a specific optimizer but only if the user runs the kernel on a GPU and not if the user runs it on a CPU. But this actually goes into deep detail. In reality, it usually looks like this:
@ -518,6 +521,18 @@ The --example-hashes command line argument together with a specific hash mode (-
This is the password to crack the hash given in module_st_hash() for the self-test functionality. This is the password to crack the hash given in module_st_hash() for the self-test functionality.
### module_benchmark_mask() ###
This is a mask that is hash mode specific and is normally used whenever the mask that should be used in benchmarks is of a very specific length and/or pattern. This could be a dynamic string, but in general try to use a variable called `BENCHMARK_MASK`.
### module_benchmark_charset() ###
This is a custom charset setting (like `--custom-charset1`) that always needs to be synchronized with the default benchmark mask (see `module_benchmark_mask ()`, or the default one if not set). This setting does only affect `--benchmark` and you can use this charset within your mask with `?1`. Try to use a variable called `BENCHMARK_CHARSET` for this string whenever possible.
### module_benchmark_salt() ###
This is a salt that is hash mode specific and allows you to set a `salt_t` structure dynamically. This could sometimes be needed if custom iteration counts or salt lengths are needed for a specific hash mode.
### module_hook_extra_param_init() and module_hook_extra_param_term() ### ### module_hook_extra_param_init() and module_hook_extra_param_term() ###
These two functions were added to hashcat beginning with version 6.2.0 when it was required for a module to use a 3rd party library from inside a hook function. However, the module developer is free to decide how to use this buffer (it doesn't have to be a library handle). Generally, it is a buffer that the module developer would use for something that they need to initialize and terminate only once on startup and shutdown for performance reasons. These two functions were added to hashcat beginning with version 6.2.0 when it was required for a module to use a 3rd party library from inside a hook function. However, the module developer is free to decide how to use this buffer (it doesn't have to be a library handle). Generally, it is a buffer that the module developer would use for something that they need to initialize and terminate only once on startup and shutdown for performance reasons.