I am interested in understanding the format of the encrypted files produced by the application Data Guardian. From what I can tell some sort of transformation of the password is stored in the field named 'hexIdentifier.' What I find odd is that if two files are saved with the same password, then they both have the same 'hexIdentifier' string. I am not advertising this app and I am not affiliated with the company. I am evaluating the app.
I would be very surprised if it did actually store the password (encoded or not) in the encrypted file because doing so would demonstrate a fundamental lack of understanding of cryptography, in which case, it would be highly recommended to pass over the software if you need the encrypted files to be secure. There is no practical reason to store the password.
Even the low price is not a reason to use it if it does indeed store the password since there are plenty of other programs that are much more secure and even free (in fact, even standard archivers provide secure encryption functionality (without storing the password).
As for Data Guardian, I’ve got some bad news. I did some tests and you and Amazed are correct. It seems that the
If you save the same file over and over with a password of increasing size (eg one character, two chars, three…) it will cause the field to change, but the size remains constant (64-bit), up to eight characters, then from nine to 16 characters, the field changes to 128-bit, and so on. In other words, it chunks (pads?) and encodes the password in 8-character blocks. If it were a hash, the size of the field would remain constant no matter the length of the password. Therefore, it actually encodes and stores the password itself.
There is a DLL in the program folder that indicates that it uses the Blowfish block-cipher (which uses 64-bit blocks—remember the 64-bit chunks above?), so the password is likely encrypted with that as well as the data (though separately from the data as opposed to as part of the same stream, which makes it even more vulnerable).
I’ve already ferreted out several aspects of the algorithm in just a few minutes of merely running in-program tests (while at the same time watching TV) without opening it in a disassembler or looking at a single line of code. I don’t imagine it would be too difficult for someone with the proper motivation to reverse it altogether.
In summary, Data Guardian is not reliable enough if you need encryption (sort of defeats the purpose of the name). If you don’t need the encryption or the data isn’t sensitive, then you can get by with it (it is a specialized record-keeping program as opposed to a generic encryption program). Otherwise if security is necessary, then you would be better off looking for another record management program with stronger encryption or else just use a normal program (or even Data Guardian) and encrypt the saved files with a generic encryption program (or NTFS encryption).
You could also contact the dev and ask if they can implement stronger encryption (even the standard Microsoft crypto API  would be good; also Crypto++ is common since Boost could not add one).