Determination of the type of hash before starting John
Before you start hacking the John the Ripper hash, you need to understand what exactly lies in the file. The automatic definition of the format in John works, but not always correct. On the CTF, I saw situations where John defined sha512crypt as a general crypt - and silently chewed too much not the wrong algorithm. One wrong --format - half an hour to the wind.
hashid – quick identification of hash
The utility hashid – the main tool for determining the type of hash. Put through pip3 install hashid and takes the hash line directly. The line 5f4dcc3b5aa765d61d8327deb882cf99 – 32 hex symbols, and hashid offer: [+] MD2, [+] MD5, [+] MD4. According to Redfox Security, the output is probably ranked, but without context hashid will not distinguish MD5 from NTLM – both lines of the same length.
The second option is hash-identifier, pre-installed in Kali. Interactive mode: run, insert the hash, get a list of possible formats. For scripting is less convenient, but sometimes more precisely ranks options.
The main thing: neither hashid, neither hash-identifier Do not see the context. A string of 32 hex symbols could be Raw-MD5, MD4, or NTLM. The difference is in the source of the hash. If the dump from SAM on the Windows system (technique OS Credential Dumping: Security Account Manager, T1003.002 by MITRE ATT&CK) is NTLM. If from the web application on PHP - most likely MD5. The context of the task is the first prompter.
Manual signs of hash format
An experienced CTF player determines the format before the launch of utilities - by characteristic markers:
Prefix $1$ – md5crypt (FreeBSD MD5)
Prefix $5$ – sha256crypt
Prefix $6$ – sha512crypt (the standard of modern Linux systems, connected with technology /etc/passwd and /etc/shadow, T1003.008)
Prefix $2a$ or $2b$ – bcrypt
32 hex symbols without prefix – Raw-MD5 or NTLM
40 hex symbols – Raw-SHA1
64 hex symbols – Raw-SHA256
For checking through John: john --list=formats | grep -i 'md5' show all formats with "md5" in the title. The Jumbo version supports over 200 formats – from Raw-MD5 to Django, WordPress (phpass) and Kerberos TGT. If not sure — john --list=formats and grep by keyword. Standard reception.
A separate case is nested encoding. In CTF-draughts is often found base64 on top of hex on top of MD5 (such a doll). If the hash looks like a base64 line, decode the first layer through echo "строка" | base64 -d | xxd and evaluate the result. Sometimes you need to unwind 2-3 layers manually before you get to the real hash.
Working hours John the Ripper
John the Ripper for beginners usually comes down to one team: john hashes.txt. But behind this simplicity is three fundamentally different modes, and the choice between them determines whether you will find the password in seconds or wait until the end of the CTF.
Single Crack Mode
The regime --single First thing to try. John takes the username from the file (format username:hash) and mutates it: adds numbers, changes the register, duplicates symbols, rearranges in places. If the user admin, John will check Admin, admin1, admin123, ADMIN, admin! and hundreds of other variations.
Launch: john --single --format=raw-md5 hashes.txt. In CTF, this mode is unexpectedly effective – the creators of the Tassks often make the password derivative of the username or the name of the task. Checking takes seconds and costs nothing. Sin is not to try.
Wordlist – password selection by dictionary
Wordlist attack on passwords is the main mode for practical work. John takes each word from the dictionary, hashes with the specified algorithm and compares with the target head.
Standard launch: john --wordlist=/usr/share/wordlists/rockyou.txt --format=raw-md5 hashes.txt. Dictionary rockyou.txt – 14 million passwords from a real leak is the starting point in any scenario. In Kali he lies in /usr/share/wordlists/rockyou.txt.gz and requires unpacking through gunzip.
The critical flag – --rules. Without it, John checks the words as it is. C --rules applies mutations: password turns into Password, password1, p@ssword, PASSWORD123!. Rules are customizable in john.conf, and the built-in set already covers common patterns - character replacements, adding numbers, changing the register.
If rockyou does not help, connect custom dictionaries. On CTF, I collect wordlist from a description of the task, file names, metadata, and comments in the code. Often a dictionary of 50 words with the right rules breaks the hash faster than 14 million rows rockyou. Seriously.
Incremental Mode – Brute force attack on hashes
The regime --incremental – classic brute force. John goes through all the combinations of symbols, starting with short ones. Team john --incremental hashes.txt will launch a complete overkill. To limit the set: --incremental=Digits (only numbers), --incremental=Alpha (only letters), --incremental=Alnum (Letters and numbers).
On the CPU, this mode is useless for passwords longer than 7-8 characters - the overtake space grows exponentially. For long passwords, it is more appropriate to switch to hashcat with GPU acceleration. But for short PIN codes and numerical passwords, the incremental mode in John copes quickly - it grabs it here.
Practical workflow: from file to password
Let's look at the typical scenarios that occur on both CTF and real work.
Hashes from /etc/shadow
Classical task – files received /etc/passwd and /etc/shadow (Receiving these files is classified as a T1003.008 technique by MITRE ATT&CK). Procedure:
The first step is to combine the utility files unshadow: unshadow passwd.txt shadow.txt > combined.txt. The second is to run John with wordlist: john --wordlist=/usr/share/wordlists/rockyou.txt combined.txt. The third is to see the results: john --show combined.txt.
A typical mistake is to forget about unshadow and feed John clean /etc/shadow. John can accept the file, but will not always correctly link the hash with the user. unshadow creates a format that John expects – strings where data from passwd and shadow are combined into a single record. Skip this step – lose time on debugging, not on a hack.
NTLM hashes from SAM dump
When working with Windows infrastructure, NTLM hashes are extracted from Security Account Manager (T1003.002). Dump format: administrator:500:aad3b435b51404eeaad3b435b51404ee:8846f7eaee8fb117ad06bdd830b7586c:::. Restoring passwords from Hashes in NTLM format:
john --format=nt --wordlist=/usr/share/wordlists/rockyou.txt ntlm_hashes.txt
Flag --format=nt is mandatory. Without it, John can define the format as LM or generic crypt. For Net-NTLMv2 (intercepted via Responder challenge-response), the format is different: --format=netntlmv2. The confusion between NT and Net-NTLMv2 is one of the most frequent errors in CTFs and exams. These are different algorithms, different formats, different speed of overtaking.
Protected files via *2john
Jumbo version John comes with dozens of utilities to extract the hashes: zip2john, rar2john, pdf2john, ssh2john, keepass2john and others. Workflow standard: first remove the hash (zip2john protected.zip > zip_hash.txt), then pick up the password (john --wordlist=/usr/share/wordlists/rockyou.txt zip_hash.txt), finally look at the result (john --show zip_hash.txt).
The CTF utility *2john – workhorse. Tasks with secure archives, SSH keys with password phrase and KeePass databases are constantly found. Full list of converters: find / -name "*2john*" 2>/dev/null in Kali or directory /usr/share/john/.
Custom rules of mutation in john.conf
Standard Rules --rules cover typical mutations, but for CTFs and target tasks, specific transformations are often needed. The rules are set in the file john.conf in sections [List.Rules:RuleName].
Syntax rules: A – append (add), z by the end of the line, c – capitalize (capital first letter), l – lowercase (all in the lower register), r – reverse (deploy a line), d – (duplicate the word). Example of custom set:
[List.Rules:CTFAppend]
Az"[0-9][0-9]"
Az"!"
Az"2024"
Az"2025"
cAz"[0-9]"
This set takes each word from the dictionary and generates options: word01–word99, word!, word2024, word2025, Word0–Word9. Launch: john --wordlist=custom.txt --rules=CTFAppend --format=raw-md5 hashes.txt. The Jumbo version comes with a set of rules --rules=Jumbowhich covers thousands of combinations of mutations.
On the CTF I create rules for a specific taxa. If the description mentions the year, I add suffixes 2024, 2025. If the hint indicates leet-speak, write the rules of substitution: sa@ (replace a→@) se3 (replace e→3), so0 (replace o→0). Three lines in john.conf – and a dictionary of 100 words turns into tens of thousands of candidates. That's where the magic is, not the size of the dictionary.
John the Ripper in CTF tasks
John the Ripper CTF scenarios have their own specifics. That's what really works.
john.pot and Session Management
All hacked John passwords save in ~/.john/john.pot. When you restart with the same hash, you will see “No password hashes to crack” – this is not a mistake, John just remembers that he has already broken this hash. To restart: Remove the string from john.pot or specify an alternative file via --pot=newpot.txt.
To view all the passwords found: john --show hashes.txt. For a specific format: john --show --format=raw-md5 hashes.txt.
When pressed Ctrl+C John keeps the state in john.rec. Continue the interrupted session — john --restore. The condition is automatically saved every 10 minutes. For parallel work with multiple hashes, use the named sessions: john --session=task1 hashes.txt, then john --restore=task1. On a CTF with several dumps in parallel is an indispensable thing.
Multi-layer encodings and HMAC
Typical CTF-Task: The line looks like base64. Decoding - hex. Transfer hex to bytes – MD5-hesh. Working approach: echo "строка" | base64 -d for each layer, then define the final hash by length. Two or three layers of encodings are the norm for the categories crypto and forensics.
If the task includes HMAC (e.g., HMAC-SHA256), John supports this format. But for HMAC you need a key - if the key is known, it is transmitted in a hash file in a special format. If the key is the desired password, John will pick it up through a wordlist attack.
Custom dictionaries from the context of the task
The most powerful reception on the CTF is to make a dictionary from the task itself. The author's name, the name of the task, the text of the description, the names of the files, the comments in the code - everything goes to the custom wordlist. The utility cewl for parsing web pages or manual collection through grep and awk – often a dictionary of 50 words with the right rules gives a result faster than 14 million lines rockyou. I on several CTFs solved the ducks exactly like this – rockyou is silent, and three words from the description with the suffix 2024! give password in a second.
Cheklist when meeting with the hash
Determine the format: line length, prefix, task context
Confirm through hashid or hash-identifier
Trying --single (if there is a username in seconds)
Wordlist +: rulesyou.txt with --rules
Custom wordlist from context + custom rules
If nothing – incremental on short passwords or switch to hashcat with GPU
Each next step is more expensive than the previous one in time. In the vast majority of CTFs, the password is in steps 3-5. Incremental mode is rarely needed – usually the problem is not in computing power, but in the correct dictionary.
Typical mistakes when working with John the Ripper
Three rakes, which are stable not even beginners.
The wrong --format. If you see a warning detected hash type "X", but the string is also recognized as "Y" – clearly indicate the format. Example: Use the "--format=crypt" option to force loading these as that type instead. On the CTF, the wrong format is the most common cause of the “unhackable” hash. Hesh is not guilty, the one who feeds him is guilty.
Encoding the file. If a file with hashes is created in Windows or copied from a web form, invisible characters may remain: BOM, \r\n instead of \n, spaces at the end of the line. Check through xxd hashes.txt | head and clean through dos2unix or tr -d '\r'. On one CTF, I lost 40 minutes because of an invisible gap after a hash — John loaded 0 out of 1 hash and silently concluded. It's a shame to grind your teeth.
A giant dictionary without rules. The dictionary for 100 GB rules without rules is less effective than rockyou with aggressive mutations. C --rules=Jumbo one word generates hundreds of variations – it covers more real password space than a linear overkill of a huge file. The quality of dictionary and rule preparation determines the success of password recovery from hashes – not the file size or the processor frequency.
Before you start hacking the John the Ripper hash, you need to understand what exactly lies in the file. The automatic definition of the format in John works, but not always correct. On the CTF, I saw situations where John defined sha512crypt as a general crypt - and silently chewed too much not the wrong algorithm. One wrong --format - half an hour to the wind.
hashid – quick identification of hash
The utility hashid – the main tool for determining the type of hash. Put through pip3 install hashid and takes the hash line directly. The line 5f4dcc3b5aa765d61d8327deb882cf99 – 32 hex symbols, and hashid offer: [+] MD2, [+] MD5, [+] MD4. According to Redfox Security, the output is probably ranked, but without context hashid will not distinguish MD5 from NTLM – both lines of the same length.
The second option is hash-identifier, pre-installed in Kali. Interactive mode: run, insert the hash, get a list of possible formats. For scripting is less convenient, but sometimes more precisely ranks options.
The main thing: neither hashid, neither hash-identifier Do not see the context. A string of 32 hex symbols could be Raw-MD5, MD4, or NTLM. The difference is in the source of the hash. If the dump from SAM on the Windows system (technique OS Credential Dumping: Security Account Manager, T1003.002 by MITRE ATT&CK) is NTLM. If from the web application on PHP - most likely MD5. The context of the task is the first prompter.
Manual signs of hash format
An experienced CTF player determines the format before the launch of utilities - by characteristic markers:
Prefix $1$ – md5crypt (FreeBSD MD5)
Prefix $5$ – sha256crypt
Prefix $6$ – sha512crypt (the standard of modern Linux systems, connected with technology /etc/passwd and /etc/shadow, T1003.008)
Prefix $2a$ or $2b$ – bcrypt
32 hex symbols without prefix – Raw-MD5 or NTLM
40 hex symbols – Raw-SHA1
64 hex symbols – Raw-SHA256
For checking through John: john --list=formats | grep -i 'md5' show all formats with "md5" in the title. The Jumbo version supports over 200 formats – from Raw-MD5 to Django, WordPress (phpass) and Kerberos TGT. If not sure — john --list=formats and grep by keyword. Standard reception.
A separate case is nested encoding. In CTF-draughts is often found base64 on top of hex on top of MD5 (such a doll). If the hash looks like a base64 line, decode the first layer through echo "строка" | base64 -d | xxd and evaluate the result. Sometimes you need to unwind 2-3 layers manually before you get to the real hash.
Working hours John the Ripper
John the Ripper for beginners usually comes down to one team: john hashes.txt. But behind this simplicity is three fundamentally different modes, and the choice between them determines whether you will find the password in seconds or wait until the end of the CTF.
Single Crack Mode
The regime --single First thing to try. John takes the username from the file (format username:hash) and mutates it: adds numbers, changes the register, duplicates symbols, rearranges in places. If the user admin, John will check Admin, admin1, admin123, ADMIN, admin! and hundreds of other variations.
Launch: john --single --format=raw-md5 hashes.txt. In CTF, this mode is unexpectedly effective – the creators of the Tassks often make the password derivative of the username or the name of the task. Checking takes seconds and costs nothing. Sin is not to try.
Wordlist – password selection by dictionary
Wordlist attack on passwords is the main mode for practical work. John takes each word from the dictionary, hashes with the specified algorithm and compares with the target head.
Standard launch: john --wordlist=/usr/share/wordlists/rockyou.txt --format=raw-md5 hashes.txt. Dictionary rockyou.txt – 14 million passwords from a real leak is the starting point in any scenario. In Kali he lies in /usr/share/wordlists/rockyou.txt.gz and requires unpacking through gunzip.
The critical flag – --rules. Without it, John checks the words as it is. C --rules applies mutations: password turns into Password, password1, p@ssword, PASSWORD123!. Rules are customizable in john.conf, and the built-in set already covers common patterns - character replacements, adding numbers, changing the register.
If rockyou does not help, connect custom dictionaries. On CTF, I collect wordlist from a description of the task, file names, metadata, and comments in the code. Often a dictionary of 50 words with the right rules breaks the hash faster than 14 million rows rockyou. Seriously.
Incremental Mode – Brute force attack on hashes
The regime --incremental – classic brute force. John goes through all the combinations of symbols, starting with short ones. Team john --incremental hashes.txt will launch a complete overkill. To limit the set: --incremental=Digits (only numbers), --incremental=Alpha (only letters), --incremental=Alnum (Letters and numbers).
On the CPU, this mode is useless for passwords longer than 7-8 characters - the overtake space grows exponentially. For long passwords, it is more appropriate to switch to hashcat with GPU acceleration. But for short PIN codes and numerical passwords, the incremental mode in John copes quickly - it grabs it here.
Practical workflow: from file to password
Let's look at the typical scenarios that occur on both CTF and real work.
Hashes from /etc/shadow
Classical task – files received /etc/passwd and /etc/shadow (Receiving these files is classified as a T1003.008 technique by MITRE ATT&CK). Procedure:
The first step is to combine the utility files unshadow: unshadow passwd.txt shadow.txt > combined.txt. The second is to run John with wordlist: john --wordlist=/usr/share/wordlists/rockyou.txt combined.txt. The third is to see the results: john --show combined.txt.
A typical mistake is to forget about unshadow and feed John clean /etc/shadow. John can accept the file, but will not always correctly link the hash with the user. unshadow creates a format that John expects – strings where data from passwd and shadow are combined into a single record. Skip this step – lose time on debugging, not on a hack.
NTLM hashes from SAM dump
When working with Windows infrastructure, NTLM hashes are extracted from Security Account Manager (T1003.002). Dump format: administrator:500:aad3b435b51404eeaad3b435b51404ee:8846f7eaee8fb117ad06bdd830b7586c:::. Restoring passwords from Hashes in NTLM format:
john --format=nt --wordlist=/usr/share/wordlists/rockyou.txt ntlm_hashes.txt
Flag --format=nt is mandatory. Without it, John can define the format as LM or generic crypt. For Net-NTLMv2 (intercepted via Responder challenge-response), the format is different: --format=netntlmv2. The confusion between NT and Net-NTLMv2 is one of the most frequent errors in CTFs and exams. These are different algorithms, different formats, different speed of overtaking.
Protected files via *2john
Jumbo version John comes with dozens of utilities to extract the hashes: zip2john, rar2john, pdf2john, ssh2john, keepass2john and others. Workflow standard: first remove the hash (zip2john protected.zip > zip_hash.txt), then pick up the password (john --wordlist=/usr/share/wordlists/rockyou.txt zip_hash.txt), finally look at the result (john --show zip_hash.txt).
The CTF utility *2john – workhorse. Tasks with secure archives, SSH keys with password phrase and KeePass databases are constantly found. Full list of converters: find / -name "*2john*" 2>/dev/null in Kali or directory /usr/share/john/.
Custom rules of mutation in john.conf
Standard Rules --rules cover typical mutations, but for CTFs and target tasks, specific transformations are often needed. The rules are set in the file john.conf in sections [List.Rules:RuleName].
Syntax rules: A – append (add), z by the end of the line, c – capitalize (capital first letter), l – lowercase (all in the lower register), r – reverse (deploy a line), d – (duplicate the word). Example of custom set:
[List.Rules:CTFAppend]
Az"[0-9][0-9]"
Az"!"
Az"2024"
Az"2025"
cAz"[0-9]"
This set takes each word from the dictionary and generates options: word01–word99, word!, word2024, word2025, Word0–Word9. Launch: john --wordlist=custom.txt --rules=CTFAppend --format=raw-md5 hashes.txt. The Jumbo version comes with a set of rules --rules=Jumbowhich covers thousands of combinations of mutations.
On the CTF I create rules for a specific taxa. If the description mentions the year, I add suffixes 2024, 2025. If the hint indicates leet-speak, write the rules of substitution: sa@ (replace a→@) se3 (replace e→3), so0 (replace o→0). Three lines in john.conf – and a dictionary of 100 words turns into tens of thousands of candidates. That's where the magic is, not the size of the dictionary.
John the Ripper in CTF tasks
John the Ripper CTF scenarios have their own specifics. That's what really works.
john.pot and Session Management
All hacked John passwords save in ~/.john/john.pot. When you restart with the same hash, you will see “No password hashes to crack” – this is not a mistake, John just remembers that he has already broken this hash. To restart: Remove the string from john.pot or specify an alternative file via --pot=newpot.txt.
To view all the passwords found: john --show hashes.txt. For a specific format: john --show --format=raw-md5 hashes.txt.
When pressed Ctrl+C John keeps the state in john.rec. Continue the interrupted session — john --restore. The condition is automatically saved every 10 minutes. For parallel work with multiple hashes, use the named sessions: john --session=task1 hashes.txt, then john --restore=task1. On a CTF with several dumps in parallel is an indispensable thing.
Multi-layer encodings and HMAC
Typical CTF-Task: The line looks like base64. Decoding - hex. Transfer hex to bytes – MD5-hesh. Working approach: echo "строка" | base64 -d for each layer, then define the final hash by length. Two or three layers of encodings are the norm for the categories crypto and forensics.
If the task includes HMAC (e.g., HMAC-SHA256), John supports this format. But for HMAC you need a key - if the key is known, it is transmitted in a hash file in a special format. If the key is the desired password, John will pick it up through a wordlist attack.
Custom dictionaries from the context of the task
The most powerful reception on the CTF is to make a dictionary from the task itself. The author's name, the name of the task, the text of the description, the names of the files, the comments in the code - everything goes to the custom wordlist. The utility cewl for parsing web pages or manual collection through grep and awk – often a dictionary of 50 words with the right rules gives a result faster than 14 million lines rockyou. I on several CTFs solved the ducks exactly like this – rockyou is silent, and three words from the description with the suffix 2024! give password in a second.
Cheklist when meeting with the hash
Determine the format: line length, prefix, task context
Confirm through hashid or hash-identifier
Trying --single (if there is a username in seconds)
Wordlist +: rulesyou.txt with --rules
Custom wordlist from context + custom rules
If nothing – incremental on short passwords or switch to hashcat with GPU
Each next step is more expensive than the previous one in time. In the vast majority of CTFs, the password is in steps 3-5. Incremental mode is rarely needed – usually the problem is not in computing power, but in the correct dictionary.
Typical mistakes when working with John the Ripper
Three rakes, which are stable not even beginners.
The wrong --format. If you see a warning detected hash type "X", but the string is also recognized as "Y" – clearly indicate the format. Example: Use the "--format=crypt" option to force loading these as that type instead. On the CTF, the wrong format is the most common cause of the “unhackable” hash. Hesh is not guilty, the one who feeds him is guilty.
Encoding the file. If a file with hashes is created in Windows or copied from a web form, invisible characters may remain: BOM, \r\n instead of \n, spaces at the end of the line. Check through xxd hashes.txt | head and clean through dos2unix or tr -d '\r'. On one CTF, I lost 40 minutes because of an invisible gap after a hash — John loaded 0 out of 1 hash and silently concluded. It's a shame to grind your teeth.
A giant dictionary without rules. The dictionary for 100 GB rules without rules is less effective than rockyou with aggressive mutations. C --rules=Jumbo one word generates hundreds of variations – it covers more real password space than a linear overkill of a huge file. The quality of dictionary and rule preparation determines the success of password recovery from hashes – not the file size or the processor frequency.
