Bumping in hopes of an answer...
I appreciate the help given so far, I just need to understand this one process.
I understand, and even if you don't feel like explaining it yourself, could you please point me in the right direction by linking me to a resource or giving me proper google search terms that will explain how:
8044D00F6EB2E5491CD7AB7E7185D81B67A23C4980F62B2ED0914D32B7EB1C5581
becomes:
0xb54909e60352ef3ebdd448b65beda938e103624b207c91229bde6e9ba60351e1
Thank you in advance for any help finding the answer here...
The problem isn't your understanding of the process (other than perhaps your understanding of the difference between a hex value and an ASCII string representation of that hex value).
The main problem is in your understanding of the tool you've chosen to use:
https://searchcode.com/codesearch/view/11088282/cmdhashgen is a Command Line Utility that can be used to generate
various hashes for a given String or File
Since you don't want to hash the "string", that means that you'll need to create a file that contains ONLY the
32 byte value that you want to hash.
This can be done with xxd if you are using a system that has it...
First use a file editor to create a file that contains the representation that you would have gotten if you had used xxd to convert a file that originally had the value:
0000000: 8044 d00f 6eb2 e549 1cd7 ab7e 7185 d81b ................
0000010: 67a2 3c49 80f6 2b2e d091 4d32 b7eb 1c55 ................
0000020: 81 .
You can see here that if you strip out the first column (which is the byte offset into the file where that line of data occurs) and the last column of dots (which is just a placeholder for the ASCII character that each byte represents) the remaining data is your 8044d00f6eb2e5491cd7ab7e7185d81b67a23c4980f62b2ed0914d32b7eb1c5581.
Next, use the "reverse" functionality of xxd to convert back to a binary representation:
xxd -r fileWeJustCreated > ourNewFileContainingTheDesiredValueToHash
We now have a file named "ourNewFileContainingTheDesiredValueToHash" that contains a 32 byte value.
Hash this file, and the result should be b54909e60352ef3ebdd448b65beda938e103624b207c91229bde6e9ba60351e1. I don't use cmdhashgen, but here's what I get when I use openssl:
openssl dgst -sha256 ourNewFileContainingTheDesiredValueToHash
SHA256(ourNewFileContainingTheDesiredValueToHash)= b54909e60352ef3ebdd448b65beda938e103624b207c91229bde6e9ba60351e1
Now if I simply captured this output, I'd have an ASCII string representation of "b54909e60352ef3ebdd448b65beda938e103624b207c91229bde6e9ba60351e1". Since we need to hash this value, we want the binary output from openssl. openssl has a "-binary" command line option that will output the actual 32 byte value instead of the 64 character ASCII string representation.
openssl dgst -sha256 -binary ourNewFileContainingTheDesiredValueToHash > newerFileContainingFinalValueToHash
We now have a file named "newerFileContainingFinalValueToHash" that contains a 32 byte value. If cmdhashgen does not have the ability to output the 32 byte value, you'll need to repeat the "reverse xxd" process that we did with the previous value to create your file.
I can now hash this file to get the final value that will be used for the checksum:
openssl dgst -sha256 newerFileContainingFinalValueToHash
SHA256(newerFileContainingFinalValueToHash)= 5b0e90510294762f4553a6f717a13d5dce4c4aa6137311b950f2ca90ffc9a035