Adobe AIR Development

[rhgills]

@webbsites

Solid solution. 

[tensioncore]

@shawnblais:

You've got a point. But this information is now rather easily attained after all of our discussion.

[peter9477]

---

webbsites wrote:

The app should be encrypted by AppWorld using a key tied to the account. It should be stored encrypted on the device, and decrypted on-demand and in-memory by the AIR runtime using the account key.

---

In at least several different ways, this is an infeasible idea.  For one thing, it could not possibly be done in memory for larger apps.  For another, the performance hit on startup (or at various times during runtime, assuming you didn't do the whole thing all at once) would be unacceptable.

[MauriceRice]

---

shawnblais wrote:

To prevent your apps from running from outside the browser, this should suffice:

if(Capabilities.os.indexOf("PlayBook") == -1){

NativeApplication.nativeApplication.exit();

}

---

Thanks for this - I'll use it.

But this still doesn't prevent anybody from obtaining my app from a DM backup and sideloading it to a PlayBook .

[rhgills]

@peter

Good point. Ideal from a security standpoint, but not good at all for the user.

@MauriceRice

The problem is that anyone with the technical knowledge to acquire a copy of your SWF (at present) can open your SWF and remove that code. A certain measure of technical aptitude can be assumed by a user acquiring a copy of your application either through the unencrypted backup or through sniffing the packets out of the air. This may very well change if (when) sites popup to enable the piracy of playbook AIR apps. In that case, the individual pirate might not have the technical knowhow to do this, but the person actually making your hard work available will and will remove your protections. The code your quoted cannot be effectively obfuscated. (identifier renaming will do absolutely nothing, available methods of control flow obfuscation can be easily unraveled and string encryption would not prevent deleting this code).

Likely progression:

1. Alice acquires a copy of your application through one of the means available.

2. Alice tries to run your application on her computer.

3. The application exits and Alice, expecting DRM of some sort, opens your SWF using a decompiler (which produces identical actionscript to what you wrote).

4. Alice searches for the words exit, crash, playbook, etc... and finds the offending code block.

5. Alice deletes that block, recompiles and is off and running.

Your only hope in this case is that Alice gives up when your application crashes, believing your application is simply buggy.

[Innovatology]

@peter9477:

> In at least several different ways, this is an infeasible idea.  For one thing, it could not possibly be done in

> memory for larger apps.  For another, the performance hit on startup (or at various times during runtime,

> assuming you didn't do the whole thing all at once) would be unacceptable.

Peter, I respectfully disagree.

For most apps, only the code segments (actionscript bytecode) need to be encrypted. This is usually just a small part of a .swf, and thus would  take up only a few KB.  One could even exclude the Flash/Flex/Air frameworks from encryption. Even for a major app it's rarely more than 200Kb or so.

When done natively this decryption would be negligible in comparison to the loading (from Flash memory!), decoding, memory-mapping and JITting of the bytecode. A well-optimized decryption algorithm would take milliseconds.

If you want to encrypt resources (images, sounds, fonts, data) there are sufficient ways of doing that in actionscript as long as that code is protected. Could easily be optimized with some native support too, just as image decoding is.

The weakest link in this mechanism is the vault where the decryption keys are stored. 

Cheers,  - Jon -

[TheMarco]

My biggest concern is not piracy but other folks having access to our code this easily. If the on-device app content would be encrypted that would be a lot harder. I personally don't care so much about people getting the app pirated because I know fighting piracy is futile. I am however quite upset about my code being out in the open for anyone to view or steal.

Unacceptable.

[GoldenJoe]

---

shawnblais wrote:

To prevent your apps from running from outside the browser, this should suffice:

if(Capabilities.os.indexOf("PlayBook") == -1){

NativeApplication.nativeApplication.exit();

}

This is pretty crappy, but I don't think it's as a big a deal as you guys are saying. In order for this to have any real impact, ie reach the casual consumer, there will need to be a website or something hosting all these apps, and I doubt that will happen anytime soon...

As a Flash dev I'm pretty used to this, you release your stuff, you know if can be stolen, but you just have to accept that as a fact of life, and hope that the percentage of users who do it is relatively low...

---

Pretty crappy security beats RIM's security right now. Kudos.

Seriously. I hate to post so much negative stuff, but COME ON. Is this real? It's like RIM is deliberately trying to discourage us from developing on the PlayBook. I almost feel like there's a new crisis every other day. We can't obfuscate our code. We have to spend $250-$700 on Flash Builder to continue development. The playbooks are shipping late. Our sales are abysmal. Now our apps can apparently be pirated quite easily. What could possibly be next? Is this thing going to sprout legs and try to stab me in my sleep?!

[shawnblais]

---

rhgills wrote:

Likely progression:

1. Alice acquires a copy of your application through one of the means available.

2. Alice tries to run your application on her computer.

3. The application exits and Alice, expecting DRM of some sort, opens your SWF using a decompiler (which produces identical actionscript to what you wrote).

4. Alice searches for the words exit, crash, playbook, etc... and finds the offending code block.

5. Alice deletes that block, recompiles and is off and running.

Your only hope in this case is that Alice gives up when your application crashes, believing your application is simply buggy.

---

So Alice has just spent 1-3 hrs of her life, to steal a $3 app... For all that hard work, she can run my app in her browser!

Just don't make it publically available or I will call RIM and have them stick their lawyers on her.

[TheMarco]

The problem is not Alice.

The problem is Bill who is a developer and gets the code, changes some graphics, repackages it and puts it up for sale. Either on the PlayBook or even on a different platform, for example the HP TouchPad which also has Flash and a WebWorks-ish SDK.

Bad, bad, bad.