John the ripper: creazione di regole specifiche

Question

John the ripper: creazione di regole specifiche

#1 da (1 voti)
#2 da (0 voti)

3

Abbiamo una situazione in cui non trovo documentazione su di esso. Stiamo cercando di scalare su più macchine / lavoro suddividendo lo spazio delle chiavi per complessità. È un pugno di alfan completamente casuale a 7 caratteri.

Abbiamo creato una "lista di parole" di 3844 "parole", ovvero tutte le combinazioni di 2 caratteri alfanumerici (62 * 62 = 3844)

aa
ab
ac
..
08
09
00

In CONFIG il piano era di impostare min / max len = 7

Per il ridimensionamento, stavamo pianificando di creare 3844 regole, in cui ogni regola ha afferrato una riga (riga N) dalla lista di parole seguita da qualsiasi alfanum per i caratteri rimanenti. Qualcosa di simile in basso.

[Parola linea N]? x? x? x? x? x = N di regola

Possiamo quindi alla riga di comando, chiamare ogni singola regola, come un lavoro distinto, con tutte le macchine impostate come cloni l'una dall'altra.

1) Come sarebbe una regola come questa (Regola N), posso solo trovare riferimenti ad Az o A0 (cioè tutti gli elementi wordlist, o prepending in tutta la documentazione ed esempi sul web)

2) Eventuali altre impostazioni che potrei mancare per ottenere questo risultato?

passwords password-cracking hashcat john-the-ripper

posta Ryan 11.01.2018 - 19:04

fonte

2 risposte

Leggi altre domande sui tag passwords password-cracking hashcat john-the-ripper

Verifica del ripristino di fabbrica sul telefono? Implementazione della verifica in due passaggi tramite e-mail per le app Web?

score 1 · Answer 1

In passato, quando ho segmentato il crack delle password su molte macchine, ho appena diviso la mia lista di parole in sezioni e ho fornito a ciascuna macchina una sezione di wordlist da provare. Questo sembra molto più semplice della manipolazione delle regole per voce nella lista di parole. (Dopotutto, le regole devono essere applicate alla lista di parole, non a una singola parola.)

score 0 · Answer 2

Il flag " --node " di John è progettato per fare questo.

--node=MIN[-MAX]/TOTAL     this node's number range out of TOTAL count

Citando il documento OPTIONS :

This option is intended to allow for some trivial manually-configured parallel and distributed processing. For example, to split the workload across two nodes (which could be machines, CPU cores, etc.), you'd specify "--node=1/2" on one invocation of John and "--node=2/2" on the other. (If you do this on just one machine and with the same build of John, you will also need to specify different "--session" names for the two simultaneous invocations.) The nodes are assumed to be same speed (if this is not the case, one will get ahead of the other and is likely to be done sooner, unless you're using a cracking mode and settings such that the session is not expected to ever "complete" - which is fine.) If your nodes are of very different speed, you may compensate for that by allocating ranges of node numbers to individual invocations. For example, if you use OpenMP-enabled builds of John on two machines, OpenMP is supported (with good scalability) for the hash type you're cracking, and one of the machines has twice more of similar speed CPU cores than the other, then you may use "--node=1-2/3" on the twice bigger machine (let it be nodes 1 and 2 out of 3 nodes total) and "--node=3/3" on the smaller one.

Efficiency of this approach to parallel processing, as currently implemented, varies by cracking mode and its settings (efficiency is higher for incremental mode and for wordlist mode with many rules, and lower for other cracking modes and for wordlist mode without rules or with few rules), hash type (efficiency is higher for slower to compute hashes), salt count (efficiency is higher for higher salt counts), and node count (efficiency is higher for lower node counts). Scalability may be limited. The highest node count you can reasonably use varies by cracking mode, its settings, hash type, and salt count. With incremental mode, efficiency in terms of c/s rate is nearly perfect (there's essentially no overhead), but some nodes may currently receive too little work - and this problem is exacerbated by high node counts (such as 100 or more) and/or restrictive settings (such as MinLen and MaxLen set to the same value or to a narrow range, and/or a charset file with few characters being used). With wordlist mode, for high efficiency the rule count (after preprocessor expansion) needs to be many times higher than node count, unless the p/s rate is low anyway (due to slow hash type and/or high salt count).

Dovrai anche utilizzare " --fork=[cpu-count] " per sfruttare tutti i core locali.