Adding PCFGs to Hashcat's Brain

[atom]

I'm very excited about Hashcat's Brain server and have started to look into if it would be possible to incorporate a PCFG guesser into it.

There's a general misunderstanding here. There's no need to add code to the brain if you're adding a new generator to hashcat. What we need to do is to add PCFG to the slow_candidates. In that way it becomes useable directly from hashcat and also for overlays like hashtopolis etc. Beside of that, you can use hashcat in --stdout mode, which then simply runs PCFG through the brain and then outputs the candidates to console.

That's a nicer way of saying it is really slow.

Decision to call this is more like a technical reason. First Idea was to call it on-host genator but there was no shortcut left for -o and -O because both were in use. This story continued with other Idea and the only one left was -S.

A=Alpha characters/Letters
D=Digits
O=Other/Special Characters
K=Keyboard Combos
X=conteXt sensitive replacements (such as <3, #1...)
M=Markov generated string, (currently adding OMEN support right now)

A typical base structure would look like:
Password123! = A8D3O1

Thanks for the explanation. That sounds like a good plan actually. First thing that pops into my mind is it would be ideal to allow multiple of such "masks" to be executed sequentially. And then of course some sort of reader/trainer to create such masks and eventually order them by probability.

---

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.

- atom