01-30-2012 11:23 PM
By the way, contrary to what some have written, it is possible (currently) to detect whether your app has been sideloaded or installed from App World...
It's undocumented, of course, and may change in 2.0. I think I checked it on the beta and it's still the same, but I've been waiting for 2.0 final so I'd know for sure. Also was giving RIM a chance to act on this.
If you coupled this with a check for whether your app is actually signed, you could make it transparently allow debug-token (development mode) apps to run (sideloaded, of course) but not signed versions of the app unless they were installed from App World.
I've been thinking about techniques involving this, but haven't really wanted to discuss things publicly too much. Not that the basic idea is hard to figure out, but some of the ways I'm thinking of using it might be worked around if too much was publicly known in advance of using it.
01-30-2012 11:27 PM
One other point, in a separate post so you can reply separately...
Note that "fixing" the backups (encrypting, or any other change) doesn't really solve the problem.
Our code is "in the clear" in the backups, but that's only one of (counting Dingleberry) the at least four different ways that exist to get copies of our code.
This might be why RIM hasn't fixed the one issue yet... they may be trying to fix everything at once. I suspect I'm overly optimistic though, and they're not actually trying to fix any of those exploits other than the Dingleberry one.
01-31-2012 09:48 AM
you right: it's ambiguous to discuss about "piracy" counter-measure in an open space forum.
And I also think we're optimistics thinking RIM has this issue in its priority todo list.
It may be part of the success finally: Cydia, DingleBerry.... this is a proof of succes!
01-31-2012 09:53 AM - edited 01-31-2012 09:55 AM
Possible solution is to password protect the BAR file since it is a zip file. The password would be the key associated with the developer. The device would then be able to unpackage it at installation. Application backups would ignore those files in "app" and only backup "app-storage".
John Web: http://playbook.o2interactive.com Blog:http://blog.o2interactive.com Playbook Applications: Magellan Compass | Talk Clock | Papillon Converter | Personal Assistant | Panda p2p Community Library : http://code.google.com/p/playbook-as3-lib/
I thought this solution was already in use, with the "license" key. Isn't it working as you describe already? The key is public but it's input by AppWorld, no?
I never tried it (and likely never will) but if you install a sideloaded app that needs a key, does AppWorld install the key also for "external" apps (ie. not from AppWorld)?
01-31-2012 10:12 AM
The license key doesn't protect your code in any way.
It also is barely usable on the PlayBook, since the key is available only to users by copy/pasting it out of the App World listing, though they are given no instruction on how to do that. Our apps have no programmatic access to the key.
That said, no, App World would certainly not install a key for side-loaded apps. In fact, App World isn't involved in side-loading at all...
01-31-2012 10:36 AM
01-31-2012 10:55 AM
01-31-2012 11:27 AM
Ah ok, so I don't understand *at all* how works the license key system...
I though app. needed to be activated (when with license model), and that AppWorld did it (using the provided key, or retrieving it from dynamic server).
And how works this activation is the first place, since it seems that side-loaded app. don't need it....
I'm lost in translation...
01-31-2012 12:11 PM
When you say 'license key', do you mean the signing key? From what I understood and saw from my own apps or apps of fellow developers, all a pirate needs is the signed bar-file and the blackberry-deploy.bat. All the signing key does is to sign the app, which is like adding a parity bit to a byte. With this, App World can see that the bar-files are correct and not modified when they were uploaded
Which means, as a pirate, if you get direct access to AppWorld, you can get all the bar-files you want, and don't even need to care that the files have been signed. So (from my point of view) even if the bar-file is protected by a password, the app can still be pirated BUT at least the pirates wouldn't get our code :/
02-01-2012 10:39 AM
Acenet, App World (the server) is involved in delivering a license key to the device (through the App World client), but it doesn't "activate" them or do anything special with them. As far as it's concerned, they're basically an "opaque" string of characters.
It can either contact your own license server (or a third-party one that you hired) and request a key (the dynamic model), or take one out of a pool that you've uploaded (up to 1000 at a time) to the vendor portal (the pooled model), or just assign a single one repeatedly (static model).
On the phones, the app can retrieve said key programmatically, allowing the programmer to make the whole process transparent for legitimate users. On the PlayBook, that's not yet possible.
When App World requests a key from the license key server (in the dynamic model) your server will receive some data about the user, allowing you to create a record for them that includes, I believe, their BBID email. For the pooled model you wouldn't get that. In neither case would the key typically be "activated" yet.
One the app runs for the first time, it would retrieve the key and then, typically, contact your server for the actual "activation" step. Presumably your server would check that the key matched with one that was purchased (i.e. given earlier to App World) and that there are no discrepancies, and then it would tell the app the key is valid and the user's good to go. If it was a re-install, you'd want to handle that situation properly, and if the user had switched to a new device you'd have to decide how to deal with it as well. Non-trivial issues in some cases.
Anyway, whatever the approach, side-loaded apps would not have the key since App World isn't involved in installing them, so one way or the other, without involving "activation" or all those other things, the app could easily determine that it's not a legitimate purchase and could guide the user on corrective action.