Loading a pdf2john hash into hashcat

[viperxpi]

Hello.

I am trying to create a hash for password protected file, and the hash seems to be invalid for use in hashcat, because it does not fit to any of the known templates.

The hash starts with $pdf$2*3*128*4294967292*1*16*29ca320bbda22124 which does not fit any of the "known" hashcat formats (can be seen here: https://hashcat.net/wiki/doku.php?id=example_hashes )

*** I removed the pdf file name/location from the beginning of course.

The command I use is "pdf2john 1.pdf > hash" also tried running the "pl" file - the result is the same.

For some othe rpassword protected files I saw that the result is "legit" but for at least one - the hash is "strange".

I am using Kali linux.

Version: 1.9.0-jumbo-1+bleeding-aec1328d6c 2021-11-02 10:45:52 +0100 Build: linux-gnu 64-bit x86_64 AVX AC OMP SIMD: AVX, interleaving: MD4:3 MD5:3 SHA1:1 SHA256:1 SHA512:1 System-wide exec: /usr/lib/john System-wide home: /usr/share/john Private home: ~/.john CPU tests: AVX CPU fallback binary: john-base-omp OMP fallback binary: john-avx-non-omp $JOHN is /usr/share/john/ Format interface version: 14 Max. number of reported tunable costs: 4 Rec file version: REC4 Charset file version: CHR3 CHARSET_MIN: 1 (0x01) CHARSET_MAX: 255 (0xff) CHARSET_LENGTH: 24 SALT_HASH_SIZE: 1048576 SINGLE_IDX_MAX: 32768 SINGLE_BUF_MAX: 4294967295 Effective limit: Max. KPC 32768 Max. Markov mode level: 400 Max. Markov mode password length: 30 gcc version: 11.4.0 GNU libc version: 2.38 (loaded: 2.38) Crypto library: OpenSSL OpenSSL library version: 030200020 OpenSSL 3.2.2-dev (loaded: OpenSSL 3.2.2 4 Jun 2024) GMP library version: 6.3.0 File locking: fcntl() fseek(): fseek ftell(): ftell fopen(): fopen memmem(): System's times(2) sysconf(_SC_CLK_TCK) is 100 Using times(2) for timers, resolution 10 ms HR timer: clock_gettime(), latency 62 ns Total physical host memory: 3865 MiB Available physical host memory: 2745 MiB Terminal locale string: en_US.UTF-8 Parsed terminal locale: UTF-8

[viperxpi]

@claudioandre-br

testing on ubuntu with the latest available version brings the exact same result

$pdf$2*3*128*4294967292*1*16*29ca320bbda221242527333cca5f87c6*32*4fa

ser@user-VMware-Virtual-Platform:~/src/john/run$ john --list=build-info Version: 1.9.0-jumbo-1+bleeding-367d6438e6 2024-07-11 20:18:14 +0200 Build: linux-gnu 64-bit x86_64 AVX2 AC OMP OPENCL SIMD: AVX2, interleaving: MD4:3 MD5:3 SHA1:1 SHA256:1 SHA512:1 Deploy: sandboxed as a Snap app System-wide exec: /snap/john-the-ripper/current/bin System-wide home: /snap/john-the-ripper/current/bin Private home: ~/.john CPU tests: AVX2 CPU fallback binary: john-avx-omp OMP fallback binary: john-avx2 $JOHN is /snap/john-the-ripper/current/bin/ Format interface version: 14 Max. number of reported tunable costs: 4 Rec file version: REC4 Charset file version: CHR3 CHARSET_MIN: 1 (0x01) CHARSET_MAX: 255 (0xff) CHARSET_LENGTH: 24 SALT_HASH_SIZE: 1048576 SINGLE_IDX_MAX: 2147483648 SINGLE_BUF_MAX: 4294967295 Effective limit: Number of salts vs. SingleMaxBufferSize Max. Markov mode level: 400 Max. Markov mode password length: 30 gcc version: 13.2.0 GNU libc version: 2.39 (loaded: 2.39) OpenCL headers version: 1.2 Crypto library: OpenSSL OpenSSL library version: 0300000d0 OpenSSL 3.0.13 30 Jan 2024 GMP library version: 6.3.0 File locking: fcntl() fseek(): fseek ftell(): ftell fopen(): fopen memmem(): System's times(2) sysconf(_SC_CLK_TCK) is 100 Using times(2) for timers, resolution 10 ms HR timer: clock_gettime(), latency 48 ns Total physical host memory: 3868 MiB Available physical host memory: 2136 MiB Terminal locale string: en_US.UTF-8 Parsed terminal locale: UTF-8

[claudioandre-br]

testing on ubuntu with the latest available version brings the exact same result

$pdf$2*3*128*4294967292*1*16*29ca320bbda221242527333cca5f87c6*32*4fa

The hash above looks fine to me. I'm afraid john is doing exactly what it has to do. As an example:

$ wget https://raw.githubusercontent.com/openwall/john-samples/main/PDF/pdf_samples/PDF-Example-Password.pdf
[...]

$ /snap/john-the-ripper/current/bin/pdf2john.pl PDF-Example-Password.pdf | tee pdf.hash
PDF-Example-Password.pdf:$pdf$2*3*128*-4*1*16*34b1b6e593787af681a9b63fa8bf563b*32*289ece9b5ce451a5d7064693dab3badf101112131415161718191a1b1c1d1e1f*32*badad1e86442699427116d3e5d5271bc80a27814fc5e80f815efeef839354c5f

$ john pdf.hash 
Using default input encoding: UTF-8
Loaded 1 password hash (PDF [MD5 SHA2 RC4/AES 32/64])
Cost 1 (revision) is 3 for all loaded hashes
Will run 8 OpenMP threads
Note: Passwords longer than 10 [worst case UTF-8] to 32 [ASCII] rejected
Proceeding with single, rules:Single
Press 'q' or Ctrl-C to abort, 'h' for help, almost any other key for status
Almost done: Processing the remaining buffered candidate passwords, if any.
0g 0:00:00:00 DONE 1/3 (2024-08-17 10:33) 0g/s 139955p/s 139955c/s 139955C/s Pdfpdf1900..Ppassword1900
Proceeding with wordlist:/snap/john-the-ripper/current/bin/password.lst
Enabling duplicate candidate password suppressor
test             (PDF-Example-Password.pdf)     
1g 0:00:00:00 DONE 2/3 (2024-08-17 10:33) 1.695g/s 81086p/s 81086c/s 81086C/s 123456..franklin
Use the "--show --format=PDF" options to display all of the cracked passwords reliably
Session completed. 

The same FILENAME:$pdf$2*3*128*[...] pattern.

I don't know if it's expected to work the same way elsewhere.

Anyway, if your file does not work on john please add an example file, with a known password, and add more detais about how you are using john, the exact command you are using, the CLI output and so on.

Someone will help you properly, I can't do more than that.

[solardiz]

So I thought it could be the -4 vs. 4294967292 discrepancy (I wonder where it comes from), but it seems not. I am able to get either kind of "hash" cracked by hashcat's mode 10500. I first tested with the sample hash @claudioandre-br posted above:

$pdf$2*3*128*-4*1*16*34b1b6e593787af681a9b63fa8bf563b*32*289ece9b5ce451a5d7064693dab3badf101112131415161718191a1b1c1d1e1f*32*badad1e86442699427116d3e5d5271bc80a27814fc5e80f815efeef839354c5f

and it got cracked with:

./hashcat -d 1 -a 0 -m 10500 pdf.hash example.dict -r rules/best66.rule

then I edited the file to use 4294967292:

$pdf$2*3*128*4294967292*1*16*34b1b6e593787af681a9b63fa8bf563b*32*289ece9b5ce451a5d7064693dab3badf101112131415161718191a1b1c1d1e1f*32*badad1e86442699427116d3e5d5271bc80a27814fc5e80f815efeef839354c5f

and it also got cracked with the same command.

$ ./hashcat --version
v6.2.6-851-g6716447+

Maybe the issue existed prior to this hashcat commit:

commit cf3ab8e2dc78906717108d9a909694dd5f3cecf2
Author: Gabriele Gristina <matrix@users.noreply.github.com>
Date:   Tue Apr 11 21:17:25 2023 +0200

    Handle signed/unsigned PDF permission P value for all PDF hash-modes

@viperxpi Since you were using outdated JtR, perhaps you were also using outdated hashcat? Please upgrade and try again.

[solardiz]

The hash starts with $pdf$2*3*128*4294967292*1*16*29ca320bbda22124 which does not fit any of the "known" hashcat formats (can be seen here: https://hashcat.net/wiki/doku.php?id=example_hashes )

I disagree that it does not fit those. Have you even tried loading it with one of the PDF modes of hashcat, or is this issue report based solely on your reading of the hashcat wiki? The wiki does list $pdf$2 as mode 10500.

[solardiz]

Looks like there's nothing for us to do on this (non-)issue, so I'm closing it, but please feel free to add comments.

[magnumripper]

So I thought it could be the -4 vs. 4294967292 discrepancy (I wonder where it comes from)

Fun fact: The explanation is that those two are "the same number" (in hexadecimal notation it's 0xFFFFFFFC) represented as signed or unsigned integer respectively (I'm sure you spotted that, but maybe not other readers). Some time ago (years) both hashcat and JtR had problems recognizing one or the other but nowadays both support either representation.