You might get into trouble if Endianness changes.There are conversion functions like NtoBE (https://lazarus-ccr.sourceforge.io/docs/rtl/system/ntobe.html). Example:
I thought the problem may be that on byte isn't sufficient for that huge number so i think 4 bytes to store the number would do the trick.
and a handle to the file (hItem) must be stored in the buffer at offset 4, i.e. directly after the DWORD valueThere: Directly after the DWORD-Value.
Sadly the function still doesn't work.You cannot expect the debugger to show you a DWORD stored in a byte array because the debugger is told that there is an array of bytes not DWORDs. That's why it's showing a value that is "different" (it really isn't) than what you are expecting. It's showing the last byte of the DWORD instead of the whole DWORD (as it should.)
I'll attach a picture with the values that are currently inside the buffer.
EDIT: The original C-Declaration is
Available in v16.8 and later. May be used to retrieve the hash value of a file if one has been computed or to get it computed if not. Whether or not a hash value has been computed previously can be checked separately by calling XWF_GetItemInformation if required (as prior to v19.7 this function did not check that and returned TRUE already if no I/O error occurred). To find out the type of hash value, call XWF_GetVSProp with XWF_VSPROP_HASHTYPE1 or XWF_VSPROP_HASHTYPE2.
When the function is called, the buffer is assumed to start with a DWORD value. That value determines what the function does. The same buffer will be used to accommodate the requested hash value when control is returned to the caller (if the function succeeds). The required buffer size depends on the hash type. The following DWORD values are currently defined:
- Case 1: < 0x00000100:
0x01: flag to retrieve the primary hash value
0x02: flag to retrieve the secondary hash value, requires v18.0 SR-12, v18.1 SR-7, v18.2 SR-5, v18.3 SR-4 or later
0x10: flag to make this function compute the requested value(s) during the call if the hash value is not stored in the volume snapshot yet, which requires v19.7 or later, and a handle to the file (hItem) must be stored in the buffer at offset 4, i.e. directly after the DWORD value
Note that only v19.7 and later can retrieve or compute two hash values at the same time. The buffer must be large enough to accommodate both hash values. If two hash values are requested and retrieved, the first hash value will be stored at the start of the buffer (buffer offset 0). The offset in the buffer where the second hash value starts depends on the size (and thus the type) of the first hash value. Prior to v19.7 you needed two separate calls to retrieve both hash values.- Case 2: >= 0x00000100:
Subject to change at any time (yes, literally): In v18.8 and later, this function may also be used to retrieve pre-computed PhotoDNA hash values from the volume snapshot. For that purpose the buffer must be filled with a DWORD value of 0x00000100 or greater. 0x00000100 retrieves the 1st, 0x00000101 the 2nd, 0x00000102 the 3rd, and 0x00000103 the 4th PhotoDNA hash value (only 1 at a time). Note that for most files with graphical data, if at all, X-Ways Forensics computes only 1 such hash value. More than 1 hash value may be present if the user requested additional matching attempts with horizontal flipping and/or if X-Ways Forensics is uncertain about the vertical orientation of certain TIFF files. Note that it depends on the user whether or not PhotoDNA hash values are permanently stored in the database, which is a precondition for this function to work. The buffer must have space for 144 bytes when retrieving PhotoDNA hash values. The function returns TRUE if a PhotoDNA hash value was available and actually copied into lpBuffer.