I was looking through one of my compiled XoJo projects using a hex editor. I can see variable names, method names, and more. This isn’t very secure from hackers.
Is it possible to compile in such a way that these names aren’t displayed? I’m not super worried about text such as names since I can encrypt that if I want and it wouldn’t be easily visible. But it would be nice if all the source code names didn’t show up.
What can be done that’s reasonably simple and straight forward to handle this?
I really wouldn’t spend time worrying about this. A hacker isn’t going to use a hex editor, they will decompile your code. All you can do is make it a bit harder for them. And yourself.
My 2¢.
To be honest, I’m not really that worried about a hacker. It’s more about keeping the honest people honest.
Here is a link to Obfuscating Code:
Make sure that you make a copy, otherwise your original code will be scrambled too. 
It has come up in the past that the compiler switch for obfuscating method names has not actually worked in some time. You can find the thread by searching the forum for the name of the switch (it’s on Shared build settings).
I tread lightly because that thread derailed and it’s a tough conversation to have publicly. I am also light on specifics because I’m legitimately on my mobile lol.
Hopefully this is enough to lead you to the thread and bug report. If not send me a Direct Message and I’ll help you find the links you need when I’m at my desktop.
Thanks Tim, I did see some old threads, but they really didn’t seem that useful to me. It would be nice if all the names didn’t show up, but since that’s not the case, I’ll just use cryptic names and encrypt data I don’t want easily viewed.
I’m not writing anything that what justify the time it would take to hack into it, or that would be of enough interest to even attract a serious hacker. I just didn’t want a somewhat technical person to be able to browse my compiled program with a Hex Editor and easily change a trial date or registered user name. I can easily hide this info. As I mentioned in a previous response, I’m just trying to keep the honest people honest!
If your app is signed, they wouldn’t be able to do that.
If you’re on a Mac, take a look at Hopper sometime. On other platforms, look for a disassembler. (Perhaps others here have suggestions.). It will help you see how easy or hard you’ve ultimately made it.
Are you meaning this, which I use all the time to obfuscate raw text:
https://thezaz.com/code/obfuscate/
Alternatively, doesn’t Shared > Include Function Names reduce hacker’s ability to easily find ‘special’ methods?
I’ve still been finishing up some things on the App, so I haven’t gone through the Sign and Notarized steps on it yet.
The version I was looking at with a Hex Editor was on Windows.
Steve, if hackers really want to get to the core of any program, they can do so even without the name of properties and methods.
But they will only will be interested in doing so if your program is successful enough…
And yet people can change the contents of the resources folder to their heart’s content, changing bitmaps, amending /deleting language files and so on.
Here’s a neat trick that might work for some situations: include a text file containing XojoScript code that you load up and compile at runtime. The file itself can be encrypted so it can’t be read - hide the decryption key in several pieces spread out in the code - so that the only time the code is actually complied is in RAM which is considerably harder to inspect and decompile.
As Far As I Know, a hacker is happy when a challenge comes… The software “value” (in $, secrecy, etc.) is not really an incentive.
Now, using Var1, Var2, Method1, MLethod2, Function 1, Function2, etc. is possible (with lot of comments in the code, so you are able to understand what the code do), but is it worth the time / challenge / risk ?
Only you have that answer.
You can do something about that if you want. A common way is to make a json file that contains the name and a SHA hash of every file in the resources and libs directories and then sign that file too. When you launch your app, check the signature on the hash file and then check the hashes on all of the libs and any resources that are auto loaded into the app. Anything you load manually you could check when they’re loaded.
But let’s say you go to all that trouble and then simply call Quit if something is wrong. That’s what the hacker would work around, the quitting of your app, not the signature, because it’s far easier to do.
As Xojo started to show all the internals without protection, hideously removing the functionality of “Include Function Names = False”, but not removing the now useless option that people believe that works, they started to make things very simple, not to hackers, but regular citizens, to guess things about projects just reading the “binary” in a text editor without decompiling it. That’s a mess in multiple ways. Xojo should put back such functionality obfuscating the real names with short labels and optionally producing a compiler report with the substitution list to consult later in case of crashes as:
App xxxxxx, version xxx.yyy.zzz.nnnnnn compiled at date, time.
Symbols:
a01 = App.whatever
a02 = Window2.GetSaltedMD5WithSaltAsBilly
a03 = ...
Even the size of the app will shrink
I remember that if they removed function names, then introspection could not work anymore.
anyway that’s a thing I could accept if I really want to obfuscate the app.
And the crash logs wouldn’t contain important information.
I guess that it should be very rare if any that in a introspection we could get some mess due to symbol substitution instead of symbol removal. If any, compiler warnings should be emitted in the possible forecasted affectable parts. The dev should make choices.