I’m testing resources in my application to determine if it’s been tampered with.
I read certain files in, create a hash of their binary data, and store it.
This works well EXCEPT the debug build in Windows come up with a different value.
Running from the Mac IDE, both build and debug have the same values.
The built windows app has the same values.
It’s only when debugging on windows that there is a difference.
has anyone else seen this?
It’s only the same in the current running instance.
Use MD5 or SHA1, SHA256 for data hashing
that is not correct. If it was correct then I think the function would be useless.
For objects, it is guaranteed to be unique among all objects currently in existence (though once an object dies, a future object may use the same hash value).
In debugbuilds objects may have more data or less.
Show some code please to help better understand since " create a hash of their binary data, and store it" can be done a million different ways.
Related, you can do hashing via SHA2 digests through classes found in my M_Crypto project.
SHA3 is also working in a different branch of that project.
it reads the file (like a png) into a string variable , which I put in a variant and get the hash value of.
As I said, of all the things I would normally look at, it ONLY differs on debug windows builds.
I’m not sure this would be considered a bug, but you should file Feedback anyway, if you haven’t already.
Having said that, since you’re doing this to secure your app, I would suggest you use a SHA2 hash anyway, like SHA-256. You could make an utility app that scans a folder and returns the hashes within code for copy and paste.
well I develop on Mac and it always works there I just have to detect debug and windows and ignore it then. So this does work for me now.
My customer took over the code and he develops on Windows and has had the issue there.
I’m not quite ready to report this as a bug or feedback yet as it may be a stupid mistake on my end.
A string, try to read it into a memoryblock directly then assing that to the variant and check the hash.
Maybe your string get’s an encoding, that could make things different.
(Could be a bug)
Yes, I thought of that too and verified it’s not the case.
The only think I need to test now is if the Windows debugger is leaving behind old versions of any of the resource and not overwriting them.
So you checked the debugger and what encoding does you string show ? in all cases? Windows, debug/build and macos? are they all Nil encoding? Did you check if there was “00” byte at the end? surely something should be different.
shows no encoding. In all cases.
the 00 byte at the end is a possibility, but it’s odd that it would only differ in that one scenario.
Well it can be a wrong parsing (internally)… a.k.a. a bug.
I shall validate and if that’s the case, I’ll file a report. I have a nagging doubt though - I’m pretty sure I’m doing something wrong.
Check1 you can check the length in the debugger, if that’s the same and the encoding is the same.
if these differ it’s your data being read wrongly or differently.
Check 2 if both are the same check the binary first 4 bytes and last 4 …
if these differ (from other builds/platforms) it’s your data that is different.
Other case.
if those ALL are the same in the debugger (and builds), it’s most likely a xojo bug with the hash function.
the variable size in the debugger is the same on all platforms and matches the files size on disk.
What I can’t answer is if the hash function acknowledges trailing null characters or not.