I have an app that I put out on a public drive for others to download and use. I would like to have the app in some type of password protected self extractor, just in case someone else who I don’t want to have it, gets a hold of it. Can something in XOJO do this? If not, any recommended simple approaches? All users use Mac’s. Thanks
What if you simply add a password screen to your app, with logic that prevents the app from working until the correct password is entered?
It may mean hard-coding the password into your app, but with a little obfuscation code, it can be somewhat hidden.
I’ve done it with a password protected Zip archive file. I use an “Updater” (xojo) app that unzips the file and supplies the password programatically - so the only way to unzip the file is to use the Updater app, or know the password.
If all users are Mac users, an encrypted disk image is an option.
1 Like
All, Thanks for commenting and giving me ideas. Initially I like Tim’s approach. Just tried it out. I think I like it.
This has me thinking.. I have an app that connects to a password protected database. The DB password of course is coded into the app. How safe is this? Can the app be viewed and easily display the DB “Password”? If so, what are my options to make this more difficult/impossible? Thanks again.
Tim, Thanks for the suggestion.
Unsafe
More difficult = obfuscation.
Impossible = Impossible.
1 Like
If the password is stored as a simple string, then yes. With a basic hex viewer tool like HextEdit, strings are searchable inside a compiled binary file. Here’s an example from one of my compiled projects.
But if the string is at least obfuscated, it makes it much more difficult to find or figure out (though not impossible).
1 Like
Rick/Scott
Much Thanks! I found my password within a minute with HEXTEDIT.
Where can I go to learn about “obfuscation” or how do I do it?
Thanks again
Jim
I wrote an app to quickly break up the strings into base64 and then use functions to rebuild. A lot harder to find.
I only use it for keywords “around” registration system. Passwords i might add some encryption as well
2 Likes
Base64 encoding a password might be the way to go. Make the initial password longish (20 to 30 chars), and make it a multiple of (4? 6? - can’t remember). Then when you base64 encode it, the encoded string will not have any trailing == characters which otherwise would hint to a reader that what they have is a base64 encoded string.
Like others have said, I Base64 encode the password. What I then do is break it into several constants, each with varying numbers of garbage characters on either side. The constants do not have “intuitive” names. When I call the password, I concatenate the proper fragments of each constant, then decode the result.
The Zaz is your Xojo friend (The ZAZ: Xojo String Obfuscator). It not only does Base64, but it rearranges the letter order. It something is critical, you can store two halves of the Base64 in different Methods/Constants.
David
Thanks. I’m going to try it out and code it in later today.
Jim
James
Thanks for the summary.
All
Thanks for your comments and suggestions. My plan is to use the Encrypted Disk Image and implement Base64 using ZAZ.
Again Much Thanks!
Jim
Base 64 encodes bytes using a stream of 6 bit codes (encoding chars), so any stream not multiple of 8 (a byte) get a 6 bit filler “=” until reaching that multiple. That means that it encodes 3 bytes into 4 chars. So the multiple is 3 bytes (3*8=24 bit) that are encoded as 4 char codes (4*6 = 24). E.g. the byte “a” encodes as “YQ==”, and “aaa” string encodes as “YWFh”, no fillers.
As mathematically the person writing the decoder can detect a proper end without fillings, most decoders can handle lacking of any trailing “=” without problems.
So, “aaab” is encoded as “YWFhYg==”, but if you just remove all the “=”, it decodes “YWFhYg” as “aaab” without problems.
I remember experimenting that in Xojo and found it is one of those not purist decoders (the majority) and don’t care much about explicit fillers, so a DecodeBase64(“YQ”) should decode as “a” without problems, just remove the trailing "="s
Yeah. I was more worried that anyone trying to peek into the binary might see a “==” and thus guess that some base64 was being used.
It’s a clue for sure. Base64URL makes the data much less obvious, but it’s still only a very light protection.