How do I handle this?
When I compile all the graphics that I’m using (pictures I’ve dragged in) are written out to the application’s resource folder.
A client is upset that someone can go in and change those graphics to whatever they want, and basically hijack his application.
How are you all handling this?
Since 1999 I’ve never had a customer worry about this before, but now It’s a roadblock.
You could store your graphics in a local, encrypted SQLite database.
this means I have to go through every graphic I use in the application and retrieve them prior to launch, and then set them in code in the GUI.
I wouldn’t’ be able to set anything in the IDE.
This can’t be the only solution (but I did think of that too).
On macOS, if the application is code signed the resources cannot be replaced.
Anything you do to encrypt or obfuscate the resources means you can’t use them within the IDE. You would have to set all toolbar icons by code, backdrops, and things of the like. So it becomes a balance of how paranoid this client is vs. how much time they’re willing to invest in protecting the resources.
If their concern is someone replacing the resources in their existing app this can be resolved with code signing on Mac (on Windows you could implement your own resources check). If their concern is that someone is going to extract the resources and use them, I would remind them that anything visible on screen can be taken.
If they do wish to spend the time, I might take advantage of the fact that there are few tools to decrypt SQLite databases the way Xojo encrypts them. This might be slower than using an encrypted archive and extracting them.
I need to do the same solution on Mac and Windows or it would be too cumbersome to manage all the code.
This is a PITA.
and how would one reconstruct the x2 and x3 images in code? How would I know which to use?
You would use the Picture constructor where you pass the multiple resolutions: https://documentation.xojo.com/api/graphics/picture.html#picture-constructor(width_as_integer-_height_as_integer-_bitmaps()_as_picture)
The Xojo Framework should select the right one when drawing.
Find out if their concern is replacement or extraction. Replacement would be easier to handle cross platform with signature checks.
All about replacement.
He’s afraid someone will replace all of the resources and release it as their own.
There is some rich demo-mode functionality that could be used even without an activation.
If it’s signed on Windows and Mac, would it complain on launch if someone changed something?
if it did, could they simply re-sign and release?
I think this is more paranoid than needed, but I can’t win this argument.
idea 1
make a file checksum list and verify them all at start. crc32 or something.
idea 2
xor the first byte in the ressource file but then you always need to undone this in a temp file.
idea 3
idea 1 + idea 2
if someone would replace a file the app stops with a error because of wrong checksum.
or if someone just replace a resource file the app can not read because xor would break the file.
or just encrypt the graphics and decrypt them when the app runs
Norman, that’s what I’m going to have to do. Just means I need to write code to handle all the graphics and resources, and I can’t set any in the GUI.
Bit of a PITA.
Then I would do a resources check at launch. Store a hash of what each resource should be, and verify it’s still the same. This should work cross platform. You should code sign the app itself as well so that the internal hashes aren’t changed. A resources check would be simpler than changing out all of your images to load by code.
On Mac, yes. On Windows, the resources aren’t code signed only executables. You’ll have to verify the hashes in your app code. Secure those hashes by code signing the executable.
Yes. This would be a vulnerability with the systems I have imagined through the course of this thread so far. Including hashes in the code for a hash check can be defeated by changing the hashes and then resigning. The attacker would have to be really familiar with how the app operates to pull this off though.
[quote=482528:@Chris Halford]Norman, that’s what I’m going to have to do. Just means I need to write code to handle all the graphics and resources, and I can’t set any in the GUI.
Bit of a PITA.[/quote]
write a little utility that puts all your images in a database
for debug dont encrypt it so you can poke through things
for builds make it be encrypted
and since its a db you can stuff other data in there as well that might be sensitive
is the hash option reasonably secure enough?
If I load the files up as variants and get hashes of them, will that be consistent between launch?
It will be reasonably secure if you code sign the executable to prevent it from casually being changed. The weakness that stands out to me would be If someone is invested enough to find these hashes, replace them, and re-code sign the app. The attacker would need to be aware of the hash check. They would need to be aware of where they are in your executable. They would need to re-create valid hashes.
You can bump the security by doing RSA signatures instead of simple hashes, your would store a signature hash and verify with the public key. This might be even slower? Not certain.
Load the binary data into a memory block for consistency between platforms and launches.
file to base64 set to constant.
Dear lord no, that will be tremendous. If you want simple use MD5.
Edit: Nevermind, you mean as a storage solution not as a file hash 
I can tell you it happened to me.
A rival company went so far as to create a competing app, AND stole my bitmaps to make it.
Its always been a problem on the Mac, less so on older Windows builds that didnt leave the GFX lying around in a resources folder.
[quote]
On macOS, if the application is code signed the resources cannot be replaced.[/quote]
Interesting. Because they absolutely can be on Windows, no trouble.
Im gonna vote for the checksum idea. You can write some code to walk through all the images in the resources folder and verify their checksum against some other file you include in the resources folder that you generate with a small separate utility app and probably should encrypt or otherwise obfuscate. If anything doesnt match, just refuse to run with a warning about the app being corrupt. I wouldnt encrypt the individual images for the exact reason that you mention, then you cant use them normally within the IDE. But a startup step to open a simple, but probably encrypted, text file with an entry on each line with nothing but the file name and the MD5 would be only a small amount of extra work. A little separate utility that you put the same key into that you can drag and drop the resources folder on for it to walk and see every image file and add a line to the file with the MD5 would also be fairly simple. Even if you have hundreds of images it would only take a moment. And honestly, its quite possible you only need to protect the few most obvious ones that would have to be changed if someone was strealing the app. Perhaps just the main header ones with the current company name on them woudl have to be protected. If you only had to do a few of them and they dont regularly change you could even hard code the MD5 into the app. Walk the 5 or 6 header images that would have to be changed if someone was stealing it and verify them. You dont actually have to protect every single one Im betting.
Thanks everyone. And yes James, that’s a great way to go.
Thanks.