protection for paid applications


as developer, I want to upload a paid application on slideme. The user needs to pay for it, and install the full version through SAM.

For this scenario, I need to implement slidelock in my application, or it is already protected by the way in which slideme/SAM works? There is a tutorial how to do this?



To fully have the app protected from being forwarded from one device (SIM or MAC based) to another, you need to implement SlideLock. Please visit

SlideLock mediator

I had a look at SlideLock, and I don't like the fact that each application needs to enable three permissions: Internet, Read Phone State, and Access WiFi state!

If I was a user buying an application I would definitely think thrice before buying an application that required these permissions.

Isn't it possible to delegate the license fetch to a mediator app / service? The app can use Android's Intents to communicate with the mediator.

The mediator service could be SAM itself. This will be great for SlideMe as well because SAM would need to be installed by the user to use apps bought from SlideMe.

In Android, Intents could be intercepted or handled by a rouge application posing as SAM. Hence, for such a solution to work, one could have application specific public / private keys. The app public key would be stored inside the app, while the private key would be stored on the licensing server. The licensing server can sign it's response with the app's private key, so that the app can ensure the validity of the response.

This is a quick post and might be lacking details. If you are interested, I would be happy to elaborate on it.

Just read about Android

Just read about Android Market's Licensing service and they do something very similar to what I described:

Why can't SlideMe implement something similar?

Android Market's implementation is quite sophisticated, but it still requires the Read Phone State permission for the obfuscation. SlideLock could take it further by implementing Obfuscation as a service as well, so that only the SAM application would require the Read Phone State permission.

about the SlideLock tutorial

I tested the SlideLock tutorial and it seems quite harder to use for the most simple case: I want my application to be paid once on download, and after that run forever :).
Can you put some quick guidelines/template for this case? Probably most developers will use it.
I have one application on Amazon Appstore (and soon another), and in their case I didn't need to implement some protection inside my application, but only to sign it.

about the SlideLock tutorial

razvanaciu - it is not compulsory to use SlideLock to upload an application to SlideME. Even non-SlideLock'ed 'paid' apps can be transacted via SlideME.
Only if you want your application to be 'Locked' from being forwarded to another device (prevent from piracy) should you consider using SlideLock.


Securing your application is not as easy as it looks. In Android, there is no guarantee that your application is safe during the delivery and installation process, be it through SAM, Android Market, other Market Clients or any other application provisioning mechanism. I am not going to highlight the various methods to hack the system, but only to point it out.

SlideLock's main purpose is, given the scope of an insecure real world scenario (ie. rooted phone, lock method reverse engineering, etc), to help you increase the level of protection for your application (there is no method on earth that could 100% secure an application from being re-distributed). In other words, SlideLock will prevent your application from being easily distributed by the average end-user. A good hacker or a hacker organization can breach any level of security anyways, be it SlideLock, LVL, or any other more complex version - meaning that it does not worth the effort to implement really complex protection systems and mechanisms to avoid the inevitable. It may only take a longer while for any other more complex method to be breached.

SlideLock is not a mandatory module that we enforce you to integrate with - SlideLock is an optional module that prevents your application from being forwarded (ie. pulled from the device and installed on another device; because the slidelock module will securely connect to SlideME licensing servers and authorize the usage for your application on the end-user's device, as long as there is a legit purchase mapped to the end-user for your application on the SlideME system).

More enhancements to SlideLock, in terms of increased security, is unlikely to happen in the near future.

However, we do hear you out there asking for a better interface, and we will come up with alternative integration models to ease your integration efforts.

Yeah, I completely agree. I

Yeah, I completely agree.

I wasn't really complaining about the security in SlideLock. I am mostly concerned with the need for extra permissions in each app. The public / private key pair came into picture because they are needed whenever a middle-man is used for communication. The security of the end protocol itself isn't affected.

The obfuscation part too is only required if you implement a licensing cache. And as far as I am concerned, the cache is not a must have.

So, I look forward to a better API. Can we haz an ETA for it?




Are there any updates to SlideLock API along the lines I requested? Can we expect them sometime in the near future?

To recap: The permissions required for each app (internet access, phone identity, etc) when verifying with SlideLock can dissuade users from installing apps. My suggestion was: let the application request verification from SAM via an Intent (for which no permission is required) and let SAM handle the communication with the server (SAM already has the necessary permissions). The response from the server can then be routed by SAM to the application that requested it. To ensure the origin of the response, the server can sign it with an application specific private key.

I think this can be implemented very simply and it has great advantages for the app, the user and SAM as well (since SAM needs to be present for applications to be used, users won't uninstall it).