Line Length Eccezione in hashcat

0

Sonomoltonuovonellospezzareunapassword,quindimidispiacesesembrostupido.

StocercandodiottenerelamiapasswordamministratoredalmiosecondoPC(l'hopersa).HotrovatoilfileSAMconkalilinuxeconbkhiveesamdumphoottenutol'hash.PensochesiaunNTLMmapotreisbagliarmi(nonlofaccioorasemièpermessopostarel'hashquindinonlofarò).Hoprovatoarompereilcodiceconhashcat,madàunerrore(eccezionedellalunghezzadellalinea).Questoèilcodicechehoprovato:

hashcat-m1000-a0-ocracked.txt--remove/root/Desktop/hashes.txt/usr/share/sqlmap/txt/wordlist.txt

Cosac'èdisbagliatoinquesto?

EDITlocapiscooramadiceche0/1èstatoripristinatoenelfilecracked.txtnonc'èniente---->

    
posta Jorrit 17.06.2015 - 18:42
fonte

1 risposta

1

In primo luogo, una risposta alla domanda del richiedente originale (ora antica).

A differenza di alcuni strumenti (come ophcrack), gli hash NTLM devono essere separati nei loro componenti LM e NTLM affinché hashcat li attacchi separatamente,  solo hashes:

$ cat lm.hashes
[lm-hash1]
[lm-hash2]

$ cat ntlm.hashes
[ntlm-hash1]
[ntlm-hash2]

... o con utenti (che richiede l'utilizzo del parametro hashcat --username ):

$ cat lm-users.hashes
user1:[lm-hash1]
user2:[lm-hash2]

$ cat ntlm-users.hashes
user1:[ntlm-hash1]
user2:[ntlm-hash2]

Questo post di Didier Stevens illustra come utilizzare le crepe LM (maiuscole e minuscole) per poi attaccare gli hash NTLM sensibili al maiuscolo / minuscolo.

In secondo luogo, dal momento che il numero di visualizzazioni che questa domanda ha (3K in questo scritto!) è una testimonianza di quanto spesso questo errore confonda le persone, ecco una risposta più generale.

hashcat genera il temuto errore "lunghezza della linea" quando hashcat riceve qualcosa che ha cercato di interpretare come hash, ma i dati ricevuti non sono la lunghezza prevista per il tipo di hash richiesto.

Lo dico in questo modo specifico perché è importante capire che alcune attività naturali potrebbero causare questo in modi sorprendenti. Quando lavori con la riga di comando di hashcat, è facile passare casualmente qualcosa che hashcat si aspetta sia un hash, ma non lo è - tanto che c'è una voce delle FAQ di hashcat per l'errore .

I trigger comuni includono:

  • Gli hash non sono il tipo che si pensa di essere, quindi la lunghezza dell'hash non corrisponde al tipo richiesto. Questo è spesso il più comune e la prima cosa da verificare. Il modo migliore per verificare è provare lo stesso comando con l'hash di esempio corrispondente in la lista degli hash di hashcat di esempio .

  • Gli hash hanno caratteri imprevisti alla fine (spesso spazi vuoti).

  • Gli hash forniti includono utenti o sali quando non sono previsti (oppure non contengono quelli, e sono attesi). Ad esempio, potresti fornire hash in un "username: hash" o in un formato simile, ma hashcat non può sapere se "string: string" è davvero "hash: salt" o qualcos'altro invece (usa --username se hai bisogno di lavora sugli hash "username: hash").

  • (Ho salvato quello più strano per ultimo): Quando passi un file contenente un elenco di hash sulla riga di comando, ma il file non esiste. Questo perché di una stranezza in come hashcat elabora la riga di comando. La sintassi per "hashcat [literal-hash-to-crack]" e "hashcat [file-contenente-hashes-to-crack"] è esattamente la stessa . Ciò significa che se si passa un file ma non esiste, hashcat dice a se stesso "hmm, quella cosa che hanno chiesto di decifrare non era un file, forse stanno provando a specificare un hash direttamente?". Poiché il nome del file non ha quasi mai la stessa lunghezza degli hash del tipo di hash di destinazione, otterrai l'errore "lunghezza errata" quando ciò che significa in realtà "il file non esiste".

Quindi, finché interpreti l'errore come "c'è qualcosa che non va nel mio input" e indaga su ciascuna di queste possibilità, dovresti essere in grado di risolvere eventuali errori di "lunghezza della linea".

    
risposta data 26.10.2017 - 05:10
fonte

Leggi altre domande sui tag