In Xojo 2021r3.1 if I do right click App > Encrypt “App”, I see it hides its properties until I do right click App > Decrypt “App”. But when it’s encrypted, after building the .exe I can still open it in NotePad++ and I can see all the properties names and values in plain text. I figured this encryption is only inside the IDE and nothing else.
Is there a way to encrypt properties such a way that people cannot get the values by opening my built .exe in NotePad?
The encryption you are referring to, is encryption of source code, you can’t edit it anymore and can send it as an external module to someone else this way, to use your proprietary code without having access to your code. We are not talking about the binary code, that’s another issue, and a broken issue. You should use Build Settings → Shared → and unset the “Include Function Names” switch (that should be really “exclude or obfuscate symbols”) and this feature simply does not work in Xojo. It’s just a button meaning nothing there.
So, no. The Xojo compiler does not generate a good private binary, you are deeply exposed.
Yes, I am already not building with function names, but I would rather have function names than all the variable names and values in plain text 
That is a major issue. Like what if I wanted to sell my built app?
You think so, they are all there.
Variable (and properties and function) names could be hidden. Depending on the case, symbols stripped or obfuscated by the compiler/linker, but values are what they are, hiding them, if necessary, is on you.
Don’t overthink it. My app is open source and I still make a living off it.
Right, this works for business apps sold to a market audience that has lots of money, no time to waste and very little knowledge of the dark web, but if you’re making games targeting younger people with less money to spend, lots of free time on their hands and an advanced knowledge of illegal websites, then you can pretty much forget about making money with an open source game. You’ll sell a couple licenses and then go broke with your game on ThePirateBay.org with little to no recourse.
If Xojo was open source, we wouldn’t be charged 149$ USD for a 1 year license. Before, when Xojo was named RealBasic, almost all releases were immediately put on torrent (or LimeWire back then) trackers and got heavily pirated. There is still to this day, working download links to RealBasic 2005, etc… Nowadays with Xojo, you’re linked to their server for activation. This kind of binary needs to be encrypted, otherwise Xojo will end up on torrent sites again, like its predecessor.
So, in a nutshell, the only thing Xojo can compile to is plain text, correct? No way to have the binary encrypted or at least parts of it? I understand that even if the built binary was encrypted, one could just take a look at RAM while executing my built app and get the values out, with some effort, but at least it wouldn’t directly be readable by anybody simply by opening my .exe in NotePad!
Do you really think so? https://usebeacon.app/. The repo is GitHub - thommcgrath/Beacon: An editor for the Beacons in Ark: Survival Evolved. This is specifically in the gaming industry targeting younger people. I sold 27 copies yesterday.
As for your question, no protecting the source is not possible in any language. Obfuscation is the best you can do, because the machine still needs to be able to understand the logic. Decompilers exist and can reassemble the logic. So most compilers will rename methods and variables to obfuscate their intention, making the decompiled code harder to understand. This has the side effect of producing harder-to-understand stack traces. This is why map files exist for minified javascript, for example.
The reason why Xojo isn’t pirated more is because I built them a good system. Yes, piracy used to be easy when they used a serial number system. Serial numbers can always be broken. Today they use private keys, and piracy dropped significantly. The only way to defeat it is to replace the public key inside the binary. Not impossible, but generally not worth it. Most people don’t want to run unsigned binaries found on shady websites. This isn’t an anecdote, I literally wrote Xojo’s license system and watched the effects before and after. I still monitor piracy sites for not only my own stuff, but Xojo too.
If you have a good app that is accessible at a reasonable price, people won’t bother with piracy. It’ll still exist to some degree, but you’ll cut it down a ton.
You’re targeting an audience of what? 16 million ARK owners? You’re not starting a new game, you’re making a tool for a well established game. That’s not what I’m planning on releasing, so it can’t be compared.
EDIT: 20 million owners now *
You’re right, I’m targeting a niche. In fact, a niche of a niche, because my tool is really only for server admins. Most players have no use for my app. A standalone game has a much larger potential audience.
I would rather discuss a solution to my question than to debate on the need for a solution to my question. There are probably other developers with other projects that would probably use Xojo if encryption could be done and they now probably use something else instead because it can’t be done in Xojo.
I’m not trying to attack/diminish you or your product, but my point was that tools/mods for a well established game with 20+ million owners is much, much easier to make money off compared to releasing a new game and that even if half of ARK admins using your tool wouldn’t pay a cent to you, you’d still be making a ton of money, regardless of how many people just grab the source and never pay you. Yes, the audience POTENTIAL is restrained per se (to MILLIONS of players) but the immediate visibility is insanely large so it pays off fast.
Can we discuss a solution now or is my question too dumb?
Just out of curiosity, what’s your kind of game idea? Not what is it, but what genre? Board, action, shooter, 2D, 3D, etc?
TL;DR completely unrelated to my question
I’ve been approached by a game designer for making a video game version of a board game that he created last year. The game is 2D as almost all board games, but I’d make it 3D since his game has some pieces that can be stacked on top of each other. We played physically on a table with a cardboard prototype. A regular 4 player game took 7.5 hours the other day. Way too long for my taste (and probably for many, many other gamers only looking for 2 hours gameplay I would think). There are lots and lots of tiny pieces and complicated rules to look up on paper, so making it a video game will greatly increase the gameplay speed, I’d guesstimate by 300%.
Planning on making it using WebGL. 2 years ago, I’ve programmed a Minecraft-style prototype in WebGL from scratch and it works fine even on an old iPhone 7 in vanilla Safari. Getting approx 30 fps out of full screen gameplay so I figure it would work well inside a Xojo HTMLViewer control with an even more modern device. If other devs make similar binaries out of Java, I would guess the performance should not be too bad in a Xojo WebKit embed.
No need of such level of detail, but using a web component on it it will make it even less protected. As a 3D game, I would say that you should watch a more proper tool for that than Xojo, as Unity
For a 2D game, without FPS worries, Xojo could be indicated.
It’s not dumb at all. The issue is really two sides of the same coin. I think I recall Arbed being able to muck up a project before build, but I could be wrong. It’s not a tool I’ve ever had a need for. Otherwise, you’d have to just be aware of this behavior and name your sensitive components accordingly. There isn’t really a solution, which is why I was trying to allay your fears.
The “include function names” checkbox used to give you the choice, but for one reason or another that doesn’t seem to work.
The idea was that I would inject JS source and construct DOM after the HTMLViewer has loaded a blank page, so I would imagine right clicking the HTMLViewer control and selecting view source would yield a hacker nothing useful. But if the Xojo built .exe is literally readable by a human as plain text, this would make it very easy to steal the whole JS code, even if it were encrypted and stored externally, since the decryption key would still be written in the .exe as plain text I’m now thinking about obfuscating it with concatenation and alteration operations, but I fear the Xojo compiler will simplify it back to square one upon building the binary. More testing needed!
Even if this Xojo function would work it wouldn’t even be useful to me. I would much rather have all the function names written in plain text and all the values encrypted than the opposite.
This part you can do it by yourself easily. One usual simple but not extreme secure (just for the sake of example) way to hide the plain text values as not human readable ones, is storing string constants as base64 encoded ones and decode them at runtime.
Yes, something like what you just suggested… something that requires computation before the real value is usable, probably not as simple as Base64 decode tough. I will test to see what kind of optimization the compiler does at build time, but given the messages posted on here, I guess this will be “good enough” for my Xojo needs. Not much else better we can do, I guess.
In any case, I’m well aware that no matter what I do, somebody inspecting RAM could still see the real value at some point, unless I very quickly overwrite it with garbage after using it to decrypt the payload, which in turn also needs to quickly be disposed of after being injected in the DOM of the HTMLViewer… which in turn can also be read by inspecting RAM
I’m not sure what you mean by values. You could obfuscate the names of methods, classes, variables, parameters, etc. but values… do you mean the values passed into methods? That would be 100% up to you. And doesn’t really make sense either. Also, I wish you’d stop saying encrypt, because that’s not a thing in this case. Even if your binary was encrypted, Windows (or whatever system you’re running) would need the ability to decrypt it in order to run it, making the encryption completely pointless. If Windows can decrypt it, so could anybody else. Obfuscation is best you can do.
Thom, I’m so sorry. Instead of the word “encryption”, I guess I could have used the word “encoding” then. Imagine a payload ENCODED in a file so people don’t know what it is and cannot make use of it. Then my Xojo app takes that file and DECODES it into an usable payload. Does that make sense to you now? That’s what I’m trying to accomplish. The issue is that the cipher to DECODE this payload is a value in my Xojo built app that can literally be read by anybody in plain text. Just open my .exe in NotePad and you’ll see the cipher key written as clear as day, in plain text.
Anyway, thanks for your idea Rick, that’s where I was before starting this topic and I guess that’s what it will remain for now.
That’s easy enough to obfuscate too. Don’t store the plain text of the cipher key in your app. Encode that (even if base64) and store that in the code instead. Then just decode that at runtime. It is still in memory for those who go to that level of effort, but it is not as readily viewable in NotePad or whatever.
If you use base64, use a string length that does not encode to ending in one or two equal signs to help make it less obvious it is a base64 value.
Better yet also/alternatively encrypt it using a string that will appear in your app anyway (e.g. the application name) so they will not realize that is also part of a key. And use multiple pieces of string data to create the cipher key, making it even less obvious.