Please note, this is a STATIC archive of website hashcat.net from 08 Oct 2020, cach3.com does not collect or store any user information, there is no "phishing" involved.

hashcat Forum

Full Version: New password guessing method
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Hi all,


I have created a somewhat new password guessing method. And, I'm really interested in adding this method to hashcat, thus, contributing to hashcat's source code. I don't know where to start. Any help would be appreciated.


The method is pretty much an amalgamation of hashcat's mask, combination, dictionary and rules. Each new password is generated based on a pattern of password parts and patterns are extracted from existing password ditctionaries.


For example the pattern "N|c s Y" is a pattern for passwords beginning with a Capitalized Name, then a Special character and finishes with a Year. The result will be passwords such as:
Hank@1998
Eli$2020
Satoshi-2008


I already have developed the code to generate the passwords using golang. And, I have been able to use it with hashcat in "stdin mode". It works perfectly and the results are promising. But the problem is in fact the speed. It is pretty slow probably because of the relatively limited CPU-GPU bandwidth.


Where can I start my journey toward the goal of adding my passwords generation idea to hashcat? Is there any convention that i should be aware of?


Thanks.
Here's a copy from a previous discussion on a different guesser (it was not yet implemented).

---
Good thing is, to get this flying, we can distribute the effort.
First thing is that PCFG needs to provide five functions for hashcats slow candidate interface to attach it to hashcat. This would be your part.
If you can write PCFG so that it provides these functions I'll embedd this into hashcat. There's no need for you to learn about all the internal structures. I'll extend the slow_candidates.c, add the PCFG commandline options and checks and setup the needed structures. I mean of course if you want to we can do this, but I think there's nothing wrong with teaming up and/or work separation.

The five functions in general are the following (there's no template yet so I'm more like thinking loud here):
sc_pcfg_init - A function which resets all internal structures of the generator as it would be started freshly from the commandline. It will also provide the mandatory and optional parameters a user can specify in a struct. It will return a context to work with. The context enables multi threading functionality.
sc_pcfg_keyspace - A function which simply returns the total number of candidates which the generator will create based on the parameter configuration. If the total number is unknown this has some disadvantages. For instance, the ETA can not be computed or it may not be possible to distribute it via hashtopolis. In this case return (u64) -1 and hashcat will assume the generator will give a negative returncode in the seek/next function (explained next).
sc_pcfg_seek - Seek to a specific candidate position. This is mandatory, the parameter will be just a number. Will also have a returncode if there's no such position
sc_pcfg_next - Output the next password candidate (based on the context)
sc_pcfg_shutdown - A cleanup function

If you can agree to this, I'll formalize the structure in a C header and you can extend it with PCFG parameters you need.

Ideally you can provide some sort of C code which I can simply include to slow_candidates.c then we can get this flying really fast. An alternative would be a .so and/or .dll library which I can hook up and which makes you free in the language you want to use.
---

Replace PCFG with your guesser.
The example you describe can be easily solved using hashcat's rules (and in fact already has many years ago, see the korelogic rules).

Unless you cannot use rules to express your mutations you should use them for performance and ease of use.