Protecting Resource Folder

Just as an aside, I’m curious about this as I do this all the time and so far the OS has never complained. I don’t THINK that the gatekeeper stuff runs at any time after the app is first run. I have an app with “plugins” as separate files inside the resources folder, these are scripts run as separate apps and I routinely send people test versions and updates and just tell them how to copy the new script inside the application they installed. This has never resulted in any kind of error either on my own systems or any of my users as we do this.

If you changed the resources and tried to distribute the app then yes, I believe, but haven’t tested, that it would throw up an error about the app being corrupt. If you’re a developer though I don’t think there is any problem with erasing the original signature files and creating new ones based on your own key is there? I could make any changes to the app and as long as I re-signed it then the signatures would match wouldn’t they? Assuming the people trying to steal your app were also developers. If not then they could just delete all the signature resources and data files inside the app and release it as unsigned and while there would be an extra step at launch it would still work for most everybody. So I”m not entirely sure the signature stuff helps someone in Chris’s shoes? Or perhaps I don’t understand it fully, actually I know I don’t understand it fully :wink: and I”ve just been lucky.

what would stop someone from replacing the images & the check sum file ?

just a heads up that a seriously dedicated developer can remove the signature and then alter things however they want
i’ve seen a proof of concept of this
thankfully the person who demo’d it isn’t inclined this way

creating a checksum without knowing how they was made is difficult, it could also be a binary file.

documentation.xojo.com/api/cryptography/crypto.html

and btw with effort and time someone could rewrite your app.

having the checksummed file and a list of checksums probably gives a person much more information than you really want or need to expose
its why I’d personally go for the encrypted sqlite database
its easy to produce
easy to read and write and is only one items rather than a bunch that might clue and attacker in
and if you REALLY are paranoid you can encrypted then items in an encrypted database making the entire process even tougher to hack

Did you tell your user about how much this will cost him/her to secure the images ?

On the other hands, with a block editor (no, I do not know one that actually exists, but such beast existed long time ago *) one can make subtential changes (to texts for example).

  • In 1986, at Apple Expo Paris, I saw all kind of strange things done on an Apple computer (the file Menu spelled eliF for example); some people even use that to remove the copy protection shema (from floppy disks), etc.

What the client also have to do is his own home work: secure its computer (both with passwords and room locking)…

It all depends on the amount of time and money the Client is able (want) to spend to achive that goal.

I came up with a solution that is easy to implement, takes very little effort to maintain, and should be reasonably hack resistant.
If anyone wants to hack my apps bad enough they will succeed.
It would be nice if XOJO apps could help with this out of the box.

[quote=482564:@Chris Halford]I came up with a solution that is easy to implement, takes very little effort to maintain, and should be reasonably hack resistant.
If anyone wants to hack my apps bad enough they will succeed.
It would be nice if XOJO apps could help with this out of the box.[/quote]
If you can open a Feature request, please do so. Thanks.

You know I thought that was true… but I just did something (based on a suggestion from another member) that actually worked. And it involved adding an entire folder of files deep inside the Xcode bundle. I would have thought that Apple would have created safeguards to keep this from happening.

For those interested. Using Mojave and Xcode 11.3.1 you cannot compile and sideload an app onto a real device that is running iOS13.4. Technically this requires Catalina and Xcode 11.4. The suggested solution (which works perfectly) was to find a folder in the Xcode 11.4 Bundle that contained the iOS13.4 configuration information (it happens to be named ‘13.4’) and drop it in the Xcode11.3 Bundle . Now I can compile and load Xcode projects onto my iPhone7 running iOS13.4

[quote=482564:@Chris Halford]I came up with a solution that is easy to implement, takes very little effort to maintain, and should be reasonably hack resistant.
If anyone wants to hack my apps bad enough they will succeed.
It would be nice if XOJO apps could help with this out of the box.[/quote]

Thats about why Apple has the form of signing it does
MS not so much