Creating Closed Source Apps

[MaxV]

Hi all,
I don't understand the question, an Android app generated by livecode it's an APK file.
The APK file content is like this:

Code: Select all

├── AndroidManifest.xml
├── classes.dex
├── lib
│   └── armeabi
│       └── librevandroid.so
├── META-INF
│   ├── CERT.RSA
│   ├── CERT.SF
│   └── MANIFEST.MF
├── res
│   ├── drawable
│   │   └── notify_icon.png
│   └── layout
│       └── livecode_inputcontrol.xml
└── resources.arsc

Where are the source files that a user could read?

[trevix]

Let me explain my case:
It's common, at least for me, to create an App using a splash standalone and LC stack(s) that get opened by it. For a lot of reasons...
The standalone doesn't need to be protected. As you mentioned
The stacks script need to be protected, at least passwording some scripts.
Because the fact that some operations are not possible with a password protected stack (like cloning and copying), on opening, the standalone must passkey the stacks.

The problem is that anyone can find the stacks inside the bundle and:
- open them in LC community with a lock messages (so it is of no use to put in the preopenstack a "quit if")
- paste a button with a script like (save the script of this stack...)
- save the stack
- etc

I hope I have been clear. My main problem is the fact that pass keying is not reversible by script without removing the stack from memory.
Trevix

[FourthWorld]

When you're copying and pasting objects, the one thing you know about those objects is that they all use the same script. Seems a good candidate for a behavior script, which would not only centralize code but also obviate the issue with needing to protect code in the unlocked document stack.

[trevix]

It's more complex then this.
I fully use behaviors when possible and I am grateful of them, but it is not possible in my case.
I must use cloning and copy of controls, cards, stacks.

[FourthWorld]

I hope I have been clear. My main problem is the fact that pass keying is not reversible by script without removing the stack from memory.

Setting the passkey only affects the stack in memory; the on-disk copy won't be affected unless you set the password to empty and then save it. So the only risk is with RAM dumps, but really that's a risk for all programs: every decrypted password exists in RAM at least momentarily, and all executable code can be disassembled to discern the algos.

[FourthWorld]

It's more complex then this.
I fully use behaviors when possible and I am grateful of them, but it is not possible in my case.
I must use cloning and copy of controls, cards, stacks.

Behaviors aren't limited to controls; any object can use a behavior script.

[jacque]

You can set a behavior on a whole stack. It will act exactly as if the stack itself had the script.

That seems like the solution to me.

Edit: I see Richard beat me to it.

[trevix]

Sorry guys but this doesn't work for me.
There are tons of reasons why I need cloning and copying and I cannot continuously remove stacks from memory and reload them, in order to reinstate the password protection, like drag/drop controls between different stacks, saving copies of substacks as stacks, etc. And most controls and stacks already use behaviors from a Library stack.
(It all comes to the fact that my App uses templates, that are controls and stacks).

I'll take my chances with encryption.

[jacque]

I think you'll be fine using encryption only, but you may have missed the point about behaviors.

We're proposing that you put the scripts you want to protect into a button in your app stack. Remove the scripts entirely from the template, leaving only the most basic stuff that isn't important (navigation, for instance.) Remove all protection from the template.

When the app opens a new template, it should set the behavior of the clone stack to the script of its button. The cloned template will behave as though the script were in its own stack. (Another way to do it is to insert the script into back, if that will work better.)

Now you have an open clone with no limitations, which acts as if your original script were part of it. There will be nothing of value in it for anyone to steal.

[MaxV]

Trevix,
I suppose that you use the splash screen technique, so in the end you have to embed some livecode source files in your app like images, sounds and other external files.
These files will be placed in your app on mobile devices in specialFolderPath("engine") folder.
So follow these steps:

• create a folder named "encrypted"
• add that folder to the Copy Files application settings
• now code as usual your app, with all source files in the same main stack folder
• add this code to the mainstack or current card:

########CODE to copy and paste#######
on saveStackRequest
set itemDel to "/"
set the defaultFolder to item 1 to -2 of (the effective fileName of this stack)
put the files into tFileList
filter tFileList with "*.livecode"
repeat for each line tLine in tFileList
put url ("binfile:" & tLine) into temp
encrypt temp using "aes192" with key "zSJmf1pHKa42+mdZfGEM+A=="
put it into URL ("binfile:encrypted/" & tLine)
end repeat
pass saveStackRequest -- or the stack won't be saved
end saveStackRequest

On PreOpenStack
if the environment is "mobile" then
set the defaultFolder to specialFolderPath("engine")
set the defaultFolder to "encrypted"
put the files into tFileList #these are just livecode sources
repeat for each line tLine in tFileList
put url ("binfile:" & tLine) into temp
decrypt temp using "aes192" with key "zSJmf1pHKa42+mdZfGEM+A=="
put it into URL ("binfile:" & specialFolderPath("Documents") & tLine)
end repeat
set the defaultFolder to specialFolderPath("Documents")
end if
end PreOpenStack
#####END OF CODE generated by http://tinyurl.com/j8xf3xq with livecode 9.0.0-dp-6#####

[jacque]

These files will be placed in your app on mobile devices in specialFolderPath("engine") folder.

Actually, on mobile, you need specialFolderPath("resources"). Apple no longer allows resource files in the engine folder. LC will try to remap calls to the engine folder, but it's better to just use "resources" in file paths, since that will find the correct location on any OS.

set the defaultFolder to specialFolderPath("engine")

This will fail on iOS for the above reason.

[trevix]

I am familiar with everything have been said.
I think that I should have worried about security before deciding the structure of my App, because it is not as simple as I thought.
The structure of my App is like this:

-. my App works fine on desktop(Win & OS X) and iPad
- there is a stack (A) that, making it a standalone, copy stack (B) inside the bundle. (the real development is stack B)
- stack (A) will act as splash screen, load the prefs and make the user choose the language on first launch or upgrade.
- the localization implies that stack B get loaded, all the labels and pertinent stuff get changed to the chosen language and then copied from the bundle to a user folder ("application support" on OS X). In the bundle there are also all the dialogs for every language.
- same thing for upgrades: stack (A) download from the web stack (B) and save it in a user folder, changing it to the pref language.

What is my App (called "Flow Reminder") ?: A tool (OSX,PC,Tablets),for lawyers and fiscal consultants, to keep track of multiple choice time deadlines, based on programmable templates. (I should have done a game...)
Here is my pitch:
https://youtu.be/5ZsQdx1bceU

I may have problems explaining myself about this security thing and be patient with me. Let me try again.

Documents shared by the users (shared trough desktop and web), are in effect LC stacks. Most of the scripts are behaviors on stack (B), so they are protected, because stack (B) will be decrypted when launched.
Shared documents, by their own nature, gets copied and cloned by scripts of stack (B).
Using the password protection on these documents is of no use because I have to passkey them on opening. The repeated need for copying, cloning, saving, opening makes this method way too complex, for the fact that everytime I need to restablish the password protection, the stack must be removed from memory and reopened.
Using the passkey, there will be time when the stack is saved to disk and unprotected. Can you imagine the damages that can be done if someone insert some malicious LC script in a stack that gets shared?
I don't understand why bug 546(enhancement) have not been taken care yet.

So, as of now I am trying to use encryption of the documents (stacks). I'have put together a saveEncrypt script and opeDecrypt script that handle just this.
I tried to do it in memory only, but as of now I am stuck (bug 19418)
I tried to do the saving using the temporary folder, but I am stuck (bug 19313)

Nobody is saying that protection is easy, but somehow I assumed that LC had the minimum under control.
Let me saying the most of my last year has been spent not on conceiving my App, but on understanding and often finding a different way to resolve problems that should be common to most development: the splash, localization, iOS and desktop differences, online help, drag and drop, datagrid idiosyncrasy and, now, close source my APP.

Again: sorry if I did not explain me well enough .
Trevix

[jacque]

Using the passkey, there will be time when the stack is saved to disk and unprotected. Can you imagine the damages that can be done if someone insert some malicious LC script in a stack that gets shared?

Setting the passkey only unlocks the scripts for the current session. Anyone who tries to open the stack later in LC won't be able to do anything with it, it will still be protected. That is the function of the passkey, it never changes the status of the stack on disk. To completely unprotect the stack you have to set the password to empty.

It is safe to set the passkey in your own app. That's all you need to do.

[FourthWorld]

The need for preventing injection in documents this way is unusual but seems appropriate for your app, and potentially others.

Since you already have everything in the document stacks driven by behavior scripts, any script within a document stack could only have gotten there through injection. A loop through the objects to verify that all scripts are empty could scan thousands of objects in under a second.

If done before running with "open", you could confidently catch injections before they become executable.

[rumplestiltskin]

Anyone know how to protect a stack that is included in the bundle but not part of the main stack?

Code: Select all

set the password of stack "stackname" to "password"

To access scripts in the IDE without changing the password:

Code: Select all

set the passkey of stack "stackname" to "password"

Richard,

I know this is an older post but I wanted to see if I understand what you have written.

If I have a stack that gets distributed with a standalone and I want the distribution to run properly for my clients (wherein the changes they make to fields are actually saved to that stack) but I just don't want anyone to -see- the scripts I have written, then it appears that your first line of code won't actually do that. When I review the Dictionary's description of the password property, I see this:

Important: password -protected stacks may cause some problems when opened in the LiveCode development environment. (For example, the Application Browser window cannot display properties of a password -protected stack.) If you want to set a password for stacks before you release them, the recommended method is to set the password on the Stacks screen of the Standalone Application Settings> window.

So I should check the "Encrypt" box and provide a password in the standalone settings?

Does this sound right?

Thanks,
Barry

Edit - I'll note I don't care if my standalone has any encryption as the only scripts there are for "quit" and "open the editable stack".