john icon indicating copy to clipboard operation
john copied to clipboard

[ENHANCEMENT] - Implement command for deleting cache (.pot file) or not generating .pot file in a cracking session

Open D3vil0p3r opened this issue 3 years ago • 1 comments
trafficstars

Hello, If I cracked one password and some days later I am in the situation where I should crack the same password, I get the output:

john zip.hash --wordlist=$SECLISTS/Passwords/Leaked-Databases/rockyou.txt

Using default input encoding: UTF-8
Loaded 1 password hash (PKZIP [32/64])
No password hashes left to crack (see FAQ)

where it is not immediate to understand if the password has been already cracked or not, so for being sure, each time I should go to delete the .pot file.

Is it possible to implement an argument for deleting or, better, not generating the .pot file?

D3vil0p3r avatar Sep 18 '22 13:09 D3vil0p3r

it is not immediate to understand

I agree john can be improved. Well, but, it said:

  • it loaded one hash and;
  • no hash left to crack.

So, the loaded hash is already cracked.

for being sure, each time I should go to delete the .pot file.

There is a better approach, use --show or show=left.

john zip.hash --show

It is safer to force people to read and understand the current message. Maybe john can print a note about --show if any hash is loaded.


If you are playing and testing with john (and you have only easy to crack hashes), you can keep you pot file using some bash-fu.

tmpfile=$(mktemp /tmp/pot.XXXXXX) && john zip.hash --wordlist=$SECLISTS/Passwords/Leaked-Databases/rockyou.txt -pot=$tmpfile

claudioandre-br avatar Sep 18 '22 16:09 claudioandre-br

I don't really view what's proposed here as an enhancement. I expect that whoever would know about the proposed "command for deleting cache (.pot file) or not generating .pot file" (if we were to add it) would just as likely know about john.pot and how to delete a file manually if they want to.

If anything, we could possibly revise the message "No password hashes left to crack (see FAQ)" e.g. to be "No password hashes left to crack (are already in %s, see FAQ)" and substitute the john.pot pathname in there. Should we? If not, then let's just close this issue with no action.

solardiz avatar Oct 19 '22 16:10 solardiz

BTW, revising that message might not be good enough because it only addresses the special case when all loaded hashes were already cracked, not when only some were. To address the latter case, we'd also need to revise the "Remaining ..." message, or print an extra message (maybe while in a novice user mode?)

solardiz avatar Oct 19 '22 16:10 solardiz

Hey @solardiz In my honest opinion, also implementing only a message informing the user that the hash in input has been already cracked could be good, because the main issue is the misunderstanding on the output message when the user tries to crack an hash that already cracked time ago and it is stored in .pot file.

So I agree to add a message informing the user that one (or more) of the hashes inside the input file have been cracked (possibly with the hash itself for identifying which of the hashes in input has been cracked).

D3vil0p3r avatar Oct 19 '22 17:10 D3vil0p3r

Just putting try --show in there (when applicable) could be nice:

diff --git a/src/john.c b/src/john.c
index 75463966e..93ea966a6 100644
--- a/src/john.c
+++ b/src/john.c
@@ -1235,8 +1235,8 @@ static void john_load(void)
                if (!database.password_count) {
                        log_discard();
                        if (john_main_process)
-                       printf("No password hashes %s (see FAQ)\n",
-                           total ? "left to crack" : "loaded");
+                       printf("No password hashes %s\n",
+                           total ? "left to crack (try --show)" : "loaded (see FAQ)");
                        /* skip tunable cost reporting if no hashes were loaded */
                        i = FMT_TUNABLE_COSTS;
                } else

I doubt any more complex logic will help a lot. Some users will never get it anyway. In fact I think it's just fine as-is.

magnumripper avatar Oct 19 '22 20:10 magnumripper

Maybe we could make it All loaded hashes are already cracked (are in %s), use "--show", where the %s would be substituted with john.pot pathname.

However, we probably also need to deal with the case when only some of the hashes were previously cracked. Should we possibly display Some loaded hashes are already cracked (are in %s), use "--show" just before the Remaining ... line?

Edit: or omit the word loaded from these?

possibly with the hash itself for identifying which of the hashes in input has been cracked

It can sometimes be millions of hashes, or/and it/they can be very long (sometimes even gigabytes per "hash", for some things we support), and I don't like special-case output for having just one short hash.

solardiz avatar Oct 19 '22 20:10 solardiz

Maybe we could make it All loaded hashes are already cracked (are in %s), use "--show", where the %s would be substituted with john.pot pathname.

However, we probably also need to deal with the case when only some of the hashes were previously cracked. Should we possibly display Some loaded hashes are already cracked (are in %s), use "--show" just before the Remaining ... line?

Edit: or omit the word loaded from these?

possibly with the hash itself for identifying which of the hashes in input has been cracked

It can sometimes be millions of hashes, or/and it/they can be very long (sometimes even gigabytes per "hash", for some things we support), and I don't like special-case output for having just one short hash.

I agree with this statement. But I don't know if omit loaded or not... If managing millions of already cracked hashes is heavy, on my opinion could be also enough leaving a message on console by expliciting that some hashes have been already cracked and the results can be found in %s (path to .pot file). In this way, the user is totally aware that his/her result could be already in that file.

D3vil0p3r avatar Oct 19 '22 23:10 D3vil0p3r

(...) where the %s would be substituted with john.pot pathname.

FWIW there's also the [List.Extra:Potfiles] list in the config file, empty by default but possibly populated by user. If not empty, listing the main pot file path could be misleading. OTOH I'd assume any user having that configured savvy enough not to need any hint.

magnumripper avatar Nov 30 '22 14:11 magnumripper

I think we should do this:

+++ b/src/john.c
@@ -189,6 +189,7 @@ uint64_t john_max_cands;
 static int children_ok = 1;
 
 static struct db_main database;
+static int loaded_extra_pots;
 static struct fmt_main dummy_format;
 
 static char *mode_exit_message = "";
@@ -959,6 +960,8 @@ static void load_extra_pots(struct db_main *db, void (*process_file)(struct db_m
                struct stat s;
                char *name = (char*)path_expand(line->data);
 
+               loaded_extra_pots = 1;
+
                if (!stat(name, &s) && s.st_mode & S_IFREG)
                        process_file(db, name);
 #if HAVE_DIRENT_H && HAVE_SYS_TYPES_H
@@ -1232,6 +1235,13 @@ static void john_load(void)
                if (database.password_count && options.regen_lost_salts)
                        build_fake_salts_for_regen_lost(&database);
 
+               if (john_main_process && database.password_count < total)
+                       printf("Cracked %d password hashes%s%s%s, use \"--show\"\n",
+                           total - database.password_count,
+                           loaded_extra_pots ? "" : " (are in ",
+                           loaded_extra_pots ? "" : path_expand(options.activepot),
+                           loaded_extra_pots ? "" : ")");
+
                if (!database.password_count) {
                        log_discard();
                        if (john_main_process)

solardiz avatar Jul 11 '23 19:07 solardiz