UPDATE: let's consider -a 1 w/ -r
the problem here is that devs need to come up w/ a nice and very fast solution to do both the combination and apply rules (possible within the gpu kernel, otherwise it isn't really fast)... this will ofc slow down runs that do not have many rules (or none)... => therefore, separate kernels just to do -a1 + -r need to be coded (and maintained !!!) for each and every hash type ... sounds like a lot of work... it is even more work then you can think of
so -a 1 and -r
should do: combine the two dicts and then apply rules, right?
an alternative ofc could be to let the cpu also do some stuff ( and use only the fast rule engine on gpu device, e.g. cpu does combination and gpu applies rules + cracks - like in -a 0)... dunno if this makes any sense at the end, since cpu is slow + this needs to be implemented + at the end it could be that (following ths cpu+gpu approach), the pipe is even faster
note: w/ combinator.bin + -r in oclHashcat - the result is the same: use cpu for combination + gpu for (rules + cracking)....
So both approaches, may be either:
- difficult to code/maintain and/or
- slow (because cpu is involved)
Therefore, we need to look at a more clever solution.
the problem here is that devs need to come up w/ a nice and very fast solution to do both the combination and apply rules (possible within the gpu kernel, otherwise it isn't really fast)... this will ofc slow down runs that do not have many rules (or none)... => therefore, separate kernels just to do -a1 + -r need to be coded (and maintained !!!) for each and every hash type ... sounds like a lot of work... it is even more work then you can think of
so -a 1 and -r
should do: combine the two dicts and then apply rules, right?
an alternative ofc could be to let the cpu also do some stuff ( and use only the fast rule engine on gpu device, e.g. cpu does combination and gpu applies rules + cracks - like in -a 0)... dunno if this makes any sense at the end, since cpu is slow + this needs to be implemented + at the end it could be that (following ths cpu+gpu approach), the pipe is even faster
note: w/ combinator.bin + -r in oclHashcat - the result is the same: use cpu for combination + gpu for (rules + cracking)....
So both approaches, may be either:
- difficult to code/maintain and/or
- slow (because cpu is involved)
Therefore, we need to look at a more clever solution.