(03-27-2024, 12:59 PM)xJiiKo Wrote:

Chick3nman dateline='[url=tel:1711523712' Wrote: 1711523712[/url]']
No need to share, I'm pretty sure the problem is the 2147422012. This value is incredibly high, either it's an error or a new value that the modules/kernels aren't ready to support. Changing it to be a smaller number would probably allow the hash to load but, depending on the version, it may impact the ability to crack it. I believe in some cases it won't though, so it's worth a shot.

How do I change it to a smaller number? Just shorten it? Can you give me an example?

(03-27-2024, 09:03 PM)Chick3nman Wrote:

(03-27-2024, 12:59 PM)xJiiKo Wrote:

Chick3nman dateline='[url=tel:1711523712' Wrote: 1711523712[/url]']
No need to share, I'm pretty sure the problem is the 2147422012. This value is incredibly high, either it's an error or a new value that the modules/kernels aren't ready to support. Changing it to be a smaller number would probably allow the hash to load but, depending on the version, it may impact the ability to crack it. I believe in some cases it won't though, so it's worth a shot.

How do I change it to a smaller number? Just shorten it? Can you give me an example?

I believe so, but again I'm not 100% certain as some modes may use that number. This has been an issue with various PDF hashes recently and I think some updates were made to try and address it but they seem not to have fixed your issue.

(03-26-2024, 11:39 PM)xJiiKo Wrote: …My hash starts like this: $pdf$1*2*40*2147422012*1*16* ….

(03-27-2024, 02:59 AM)xJiiKo Wrote:

(03-27-2024, 02:50 AM)JDLH Wrote: Have a look at the example hashes at https://hashcat.net/wiki/doku.php?id=example_hashes .

In the PDF hashes which hashcat and Jack the Ripper use, the first two numbers are a Version and Revision number. What comes after that — the number of fields, and the length of each field — differs depending on the Version and Revision. Which hashcat hash type ("-m" number) you use also differs.

I suggest you find a hash in example_hashes which matches the beginning of your hash: $pdf$1*2* . Then copy the entire example hash, and compare its structure carefully to the structure of the hashes you have. 

I have noticed that some tools which claim to read a PDF file and generate a hash get the hash wrong. Sometimes there is a clear place to file a bug against the tool, sometimes there is not.

I did that, the most similiar one is PDF 1.1 - 1.3 (Acrobat 2 - 4), collider #2
But its still very different...
PDF 1.1 - 1.3 (Acrobat 2 - 4), collider #2 $pdf$1*2*40*-1*0*16*

(03-27-2024, 09:15 AM)Chick3nman Wrote: No need to share, I'm pretty sure the problem is the 2147422012. This value is incredibly high, either it's an error or a new value that the modules/kernels aren't ready to support.…

(03-27-2024, 11:15 PM)JDLH Wrote: I notice a problem. I think it is not the specific problem which is preventing your hash from working, but it is a problem.

(03-26-2024, 11:39 PM)xJiiKo Wrote: …My hash starts like this: $pdf$1*2*40*2147422012*1*16* ….

(03-27-2024, 02:59 AM)xJiiKo Wrote:

(03-27-2024, 02:50 AM)JDLH Wrote: Have a look at the example hashes at https://hashcat.net/wiki/doku.php?id=example_hashes .

In the PDF hashes which hashcat and Jack the Ripper use, the first two numbers are a Version and Revision number. What comes after that — the number of fields, and the length of each field — differs depending on the Version and Revision. Which hashcat hash type ("-m" number) you use also differs.

I suggest you find a hash in example_hashes which matches the beginning of your hash: $pdf$1*2* . Then copy the entire example hash, and compare its structure carefully to the structure of the hashes you have. 

I have noticed that some tools which claim to read a PDF file and generate a hash get the hash wrong. Sometimes there is a clear place to file a bug against the tool, sometimes there is not.

I did that, the most similiar one is PDF 1.1 - 1.3 (Acrobat 2 - 4), collider #2
But its still very different...
PDF 1.1 - 1.3 (Acrobat 2 - 4), collider #2 $pdf$1*2*40*-1*0*16*

Actually, all three of the hash type examples labelled "PDF 1.1 - 1.3 (Acrobat 2 - 4)" start with $pdf$1*2*40*-1*0*16* .  Comparing that to your example, I see what @Chick3nman noted:

(03-27-2024, 09:15 AM)Chick3nman Wrote: No need to share, I'm pretty sure the problem is the 2147422012. This value is incredibly high, either it's an error or a new value that the modules/kernels aren't ready to support.…

Note that the value in the example hashes is "-1", a negative integer. The value in your hash is "2147422012", a large positive integer. This probably does not cause the hashcat "Token length exception" which is blocking you. But, I am pretty sure that the value in your hash is wrong, and is the result of a bug in your pdf-to-hash tool. My suggestion is to ask the developer of this tool to investigate this bug, or to use a different tool to make your hash.

What is the correct value for this field in a hashcat hash for PDF 1.1-1.3?  I do not know whether or where hashcat documents the hash format.  But I believe that this field holds the integer value of the /P key defined in Table 21 "Additional encryption dictionary entries for the standard security handler", section 7.6.4.2 Standard encryption dictionary of the PDF specification, ISO32000-2:2020 (available for download at no cost).  

This integer value "shall be interpreted as an unsigned 32-bit quantity containing a set of flags specifying which access permissions shall be granted when the document is opened with user access. 'Table 22 — Standard security handler user access permissions' shows the meanings of these flags." Table 22 makes it clear that the high-order bits, 13-32, of this quantity should be 1. That is, the full 32-bit quantity should match 0xFFxxxxxx . 

Also, Table 21 says that if the value of the /R key is only 2 if the value of the /P key has bits 7-32  set to 1. So if /R is 2, /P should be 0xFFFFFFxx (where xx is bits 11xx xx00) . Finally, the Note just before Table 22 says that PDF integers are 2's complement values, and since /P bit 32 is 1, the integer is negative.

The integer in your hash is 2147422012. As an unsigned hexadecimal value, that is 0x7FFF0F3C. This clearly does not fit the requirements for a value of /P according to the PDF specification. That is why I think your pdf-to-hash tool has a bug. And, the PDF encryption algorithm 2, used for this version and revision of PDF encryption, incorporates the /P value. Since you don't have a trustworthy /P value, I am not optimistic that hashcat will be able to find the password.

This error doesn't seem like it will cause a hashcat "Token length exception". The integer is 10 digits long, and hashcat appears to accept 11-digit values. So, I think there is also some other problem with your hash. Compare the length of each field (between "*" separators) to the examples. Is there a length difference?

If I am correct, the solution to both problems is to get a better pdf-to-hash tool.

(03-27-2024, 11:20 PM)xJiiKo Wrote: First of all, thank you for your effort! Thank you for wanting to help me. Do you perhaps have another tool for me to pull the hash?

(03-27-2024, 11:20 PM)xJiiKo Wrote: I once wrote you a private message, it would be cool if you replied.