BTW, this is a great discussion. Thanks to all who are participating.
To be clear, I am not that worried or interested in obfuscating the SOURCE code, since I’m not distributing the source. Wait… that IS correct, isn’t it? If I do a build in Corona it’s actually compiling to something binary or machine code, right? Right?
Holy Schnikes… if that assumption is incorrect then I must take a big step back to reevaluate. :blink:
Lua is compiled into bytecode when built and that can be easily extracted from apks.
Corona compiles your Lua source code into standard Lua bytecode. There are decompilers and programs that revert the bytecode back to Lua. With Lua Protect, the bytecode is encrypted along with a few other security measures, so it is much harder to revert it.
Dave
I’ve had to DMCA for ripped assets but never for code. Concentrate on what _ needs protecting _.
Thanks! I will dig into this just a bit more, then. I am used to decompilers/disassemblers that revert back to ‘a version of the source code that operates identically’ but not the exact same source code (e.g. variables have generic names, comments are gone, some optimizations may have occurred, etc.)
Dave, let me (us?) know if you need beta testers when the time is right.
Yeah I guess it is better to make an app that everyone wants to copy and then copy it than to make an app and protect it when no one wants to copy it. 
A most salient point. 
Will do, thanks.
Thanks again for all of the feedback.
I am now in the process of ripping out large quantities of code and local storage for things like badges, rankings, etc. and disabling the ability to participate-in and enjoy those things unless registered and logged-in on our server. So this means that casual players will be able to install and play immediately just for giggles, but then if they want to participate in the game community and be ranked, earn badges, etc. they must be registered and logged-in. THEN, when they want to play multi-user games (and also turn off advertising) they will have to do the IAP to unlock these features.
I think this is a saner way to accomplish what I was trying to do, but willing to hear feedback if anyone finds a flaw in this reasoning.
Now, I think the only thing left for me to figure out is how to validate (server-side) with both app stores whether or not the user has truly paid for the unlocked version. Can anybody recommend any good links/tutorials for that?
@coronasdk66 - please keep us posted. I’m keenly interested in how you will implement the server-side validation
Will do soon. Did most of the new work today.
Dave, sorry if this is a silly question. But, if some encryption is used, then the app must have the key to decrypt and run the app right? If that’s the case, how can the key itself be secured? First thought I had was that the key could come from a server, but that doesn’t help at all since the code that accesses the server would have to be not-encrypted since we don’t have a key yet. So, how does the decryption could work?
It’s not a silly question at all. I’m glad you are questioning because it is something I’ve spent a lot of time on. Obviously it doesn’t help if I tell how I handle it in a public forum
Dave
Basically I will leave settings I don’t really care about (like whether the user preference for music and sound effects is ON or OFF) on the device. If they want to mess with those, that’s fine. I will also store high score, # games played, etc. on the device and they will be the authoritative numbers for game play UNTIL THE USER ESTABLISHES AN ACCOUNT (meaning registers with an email, a game nick and a password). So for a casual player (who is only playing the single-player game) they do not have to take the time to establish an account.
However, they MUST register if they want to do things like play multiplayer games, see themselves on the leaderboard, earn badges, etc. Once they register, the high score, number of games played, badges won storage will be on the server, and that storage will be the authoritative source for these numbers. Even if they’ve manipulated their high score and # of games played locally (prior to registration) it won’t really matter, because those numbers are for single-player games and they only show to the player, not to the community.
When they login, a unique session ID will be created for that login session and any previous active sessionIDs will be expired. This has the effect of ‘logging out’ any other devices logged-in with those same credentials, even if that player is in the middle of a game, so should discourage account sharing. Other things will also go into the creation of this session ID (like IP address, device Unique ID, etc.) to further protect. And since these things could also be spoofed by a clever person, the server will also watch for other scenarios (like… did this registered user start/finish a game while another was already in progress?) and will (probably) summarily invalidate all sessions that appear to be duplicates. The server will also have the ability to ban a player’s login for a certain amount of time based on perceived bad behavior (so perhaps if this happens repeatedly in the same hour, the player’s account will be suspended for 5 minutes on the first offense, an hour on the second, etc.)
There are some other techniques going on behind the scenes to watch for cheats as well, but I do not wish to divulge those here.
To be clear, I know that this is likely to be a never-ending cat and mouse game, but by moving as much as possible to server-side (as was correctly suggested in this thread) I think (hope?) we will be able to tweak the monitoring and responses locally without having to roll-out a lot of app updates every time we see a new technique for trying to bypass the system.
Although I am concerned about those who would patch the app locally to try and get a free version (i.e. theft) I am currently more concerned about those who would ‘cheat’ their scores and sully the experience for the rest of this game’s community.
FEEDBACK/CRITICISM IS WELCOME