tedsmith/quickhash

Hash values for .app files on macOS?

seamusdemora opened this issue · 6 comments

seamusdemora commented

Love your app - been using it for years. I have a question though - one that I discovered very much by accident.

  1. I used your app on macOS to calculate a SHA-1 digest on a "file" with the .app extension. It gave me a value. So far so good...

  2. I had what's supposed to be a copy of that same file on another macOS system. This other system did not have Quick Hash installed, but I knew I could calculate the hash value from the command line through either openssl dgst -sha1 <file>, or shasum <file>.

However - when I tried using those command line tools, they both failed. They failed because .app "files" are not really "files" at all - they are directories with files in them.

This brings up at least two questions:

  1. How does Quick Hash calculate the digest value for .app files on macOS?

  2. I've not delved into this 2nd question, but I'm posting here in hopes that you have:

Using this command: codesign -dv --verbose=4 <file> (where file is the same .app file as above) yields a verbose output with several hash values presented (mostly SHA-256). However, none of these values match the SHA-256 value calculated by Quick Hash.

To clarify: I'm just trying to understand how Quick Hash does this so I'll know I'm getting a computation of the entire .app file, and not just (for example) a part of it.

tedsmith commented

Hi

In answer to Q2, the codesign syntax you refer to (codesign -dv etc) is the syntax for verifying publisher signatures in codesigned applications. It is not for generating a hash of the binary itself. I stopped providing codesigned copies of QuickHash last year because it was costing me more for the certificate than people were willing donate for codesigned copies throughout a year. So the signatures you are seeing are, I suspect, that of any existing codesign values or some other return values that codesign has found in any given binary you are pointing it at (which might not be verified signatures if the file is not officially signed). They are not hash values of the files.

As for Q1 : As you will see here, I hash the files using the full path to the inner binaries. But for completeness, I also zip the .app and then provide a hash of the zip for exactly this reason. I then tell the user to unzip the zip and hash using syntax such as :

openssl sha1 /Applications/QuickHash.app/Contents/MacOS/QuickHash (which is the actual binary)

Hope that helps?

seamusdemora commented

Thanks for that. This is very interesting! First of all I should say that IMHO Apple's "official" codesigning for apps is useless - not because of the technology, but because of what it means in terms of the quality of the app. I'll stop there, but I wanted you to know the fact that your app isn't "codesigned" was not the cause of my questions.

The file that I am working with - the one that generated my questions - is one of Apple's files - an installer app for High Sierra: Install macOS High Sierra.app.

All that said, here's the question re-phrased:

QuickHash will calculate a value for Install macOS High Sierra.app. But what (file/data/??) is it in this .app file that QuickHash is calculating a hash value for?

tedsmith commented

I understand your question. Sorry for not answering.

Typically, .app "files" are shown as 1Kb link files (shortcuts) on my system. OSX, unlike the equivalent on Windows, conceals that more effectively from the user, though. If you use ls -lsh in the terminal for many .app files, they will show as maybe just 96 bytes, but Finder might show them to be 1Kb (1,000 bytes), and their disk block allocation size could be 8Kb. However OSX reports it, it is its representation of the size.

If you try and hash such a file with Quickhash, it will likely return what is known as the initialisation default hash that you get when attempting to hash a zero byte file. For SHA-1, this always stars DA39...0709. This is because its "kind of a file" but "not a file". So OSX says it has a size, but it kind of doesn't, in as much as there is no binary data "in it" to hash. So it can't do what it does on other systems (Windows and Linux) when you present QuickHash with a zero byte file, which is to ignore it and just display zero byte file status. But equally it can't return an actual hash value either. So you get the default initialisation hash for whatever algorithm you are using.

If you try to hash using openssl, you will also likely just get errors returned for the same reason. If you are seeing otherwise, let me know and I'll look into it further.

So this loops me back to my previous answer, which is to hash the content of the .app by direct path reference, and not the .app itself at its top level. Hopefully that helps?

seamusdemora commented

That makes sense now, and thanks for the anatomy lesson on .app files - I didn't realize they were this arcane. However: wouldn't it be "better" to either:

  1. Output a simple, intelligible error message

  2. Report/output to the user that the hash value is not an actual hash of the contents, or

  3. "traverse" the app file, and hash everything in it (everything it makes sense to hash I guess)

Perhaps I'm a rare case, but I'd prefer to know what happened - even if I don't understand the construction of an app bundle/file.

tedsmith commented

Yes, you are probably right. To be honest, I had never noticed that particular behaviour with .app files. That said, obviously I can't forsee every use of the program across all three platforms despite my best efforts.

The user manual does make reference to initiation hash digests for zero byte\invalid files, though not to the detail of app files specifically.

I guess the most simply solution is to show an alert if an initialisation hash is returned, which it won't be for most instances except particularities like this one and I suspect there will be others that are yet to be realised. Option 3 would be a bit tricky, because then the "File" sector tab would have to be changed to also account for "folder like" files. And I can't add a type check for every file either, because that would slow the program down unnecessarily just to identify if an app file is one of maybe thousands selected.

But yes, I accept the concern. I will keep it in mind.

Ted

  • 👍1
seamusdemora commented

That's good news. Would you mind re-opening this until you decide on. direction? I'll get a notification that way.