SlideMe / SlideLock released – does it really protect?
SlideLOCK - protecting the apps?

SlideLOCK - protecting the apps?

SlideME is pleased to announce support for paid applications with our
release of SAM 2.3, the first billing solution for Android that includes a
mobile client. You can download SAM 2.3 at http://slideme.org/sam2.apk

Several weeks back, we ran into the issue of the G1 not protecting against
applications being removed from the device, so we are introducing SlideLock,
which you can embed into your application to prevent forwarding to another
device. This is independent from support for paid applications, and will
provide additional protection, if the developer chooses to use it.:

Developers of paid applications will also need to sign in and approve the
new developer agreement and assign tokens, which authorize downloads.

This is a major release:

* No country restrictions on purchasing applications. Anyone can buy & sell.
* Support for global payments via SlideCollect including users paying via
their Amazon Payments account.
* High payout rates to content providers/developers ~98%:
* Sales tax is legitimately applied to sales, including all of the European
* SlideME Prepaid MasterCard: developers from anywhere in the world can
receive a debit card and get paid without a need of a bank account.

* Multiple payout methods
* Fraud detection: SlideME has partnered with Retail Decisions, a world
leader in credit card fraud prevention, in order to combat fraud and further
reduce chargebacks. More information about ReD is available at
* The Shopper Guarantee – All customers receive the Shopper Guarantee. This
guarantees shoppers that they will either receive their digital downloads
via SAM, or they will receive their money back. This guarantee can increase
customer confidence in purchasing from SlideME website.

* SAM 2.3 with a new user interface
* SAM 2.3 billing support
* SAM 2.3 supports secure method so shoppers never need to enter their
credit card or sensitive information from within their handset.

* SlideLOCK has been released to protect your applications and prevent
* 24/7 support has been implemented to support you and users in the best
possible way.
* High Availability secured environment
* Distributed feeds of content on SlideME’s Marketplace to further promote
your applications

Alright everything seems all great and what not, but the whole SlideLOCK idea seems like it’s trying a little too hard. Two big permissions must be added for the SlideLOCK to work correctly, both READ_PHONE_STATE and INTERNET_ACCESS.

Keep your code secure!

Keep your code secure!

Why does slideLock need READ_PHONE_STATE? Well because it’s grabbing your NetworkOperator, NetworkCountryIso, DeviceSoftwareVersion, PhoneType, NetworkType, SimCountryIso, SimOperator, SimSerialNumber, SubscriberId and isNetworkRoaming variables. It uses INTERNET_ACCESS to send these in an https request to the slideme website as follows;

So, in theory, what SlideLOCK does is ping it’s site with all your information (which, by the way, does it really need all that information to make a unique id?!) and the application version and key. It checks this against a database which I’m guessing will show who has purchased this, then it sends back either a yes or a no. Pretty bloated up program for simple checking if a user bought a program, seems like that should be fairly easy for someone to throw together without using their own SDK. The whole “lock” idea seems to be a way of trying to shelter developers into thinking they are fully protected… My main concern is, while this idea may have worked on WindowCE/Mobile – what is going to stop a user from editing their hosts file? By default a application is set to run if the network connection appears down, so a simple edit to the hosts file should kill this… Though I’m not condoning this in anyway. Also a user would have to find someone to give them the files that are “locked” to their phone. I originally though they where modifying each .apk for users and having them hardcoded to a device id – guess not!

On a somewhat tangent… Isn’t it strange that they never even ask for an ANDROID_ID? Honestly, it makes you think if they are just harvesting data from users while making a “match”. I mean – the SimSerialNumber should provide something completely unique anyway…

I’d put my money on this be “circumvented” pretty fast and easily.

  1. SlideLock is meant to protect from the 95% of users out there.

    We’ve been upfront with the Android community about this and addressed it on the android lists when the issue of the G1 not protecting applications came up:

    Without a DRM engine that encrypts/decrypts the apks, any protection solution for Android applications will be insecure at various levels. Either Google, or the device manufacturers, will have to deliver a proper DRM engine on the Android platform to protect apps. Until that time, these are just deterrents.

    We collect the information for three reasons: 1) to id the user and allow someone with the same device (or sim) to access the application; 2) to have information in diagnosing install and purchase errors (problems on specific networks, roaming, etc); 3) to understand which countries and operators traffic is coming from, which in aggregate we plan on sharing with the respective developers. You will notice, we do not send the phone number or MSISDN of the user.

  2. all slide lock does is add another activity wrapped around your main activity. the slide lock activity runs checks if the phone is allowed to run the app and then if it does it kicks off your original main activity.

    There is a few ways to circumvent this. This article mentions hacking with the network call, but it is really much simpler than that. you can just start up the original main activity directly instead of the slidelock wrapper activity, the only problem is that there is no icon for it, because it is not the main activity anymore, the slidelock wrapper is. But you can start any activity from the shell with a simple command. You can even put together a simple app that kicks off the original main activity.

  3. I am HAPPY that there is no “ANDROID_ID”. If anything, they can have my Google account name, and personalise my paid apps against that name. But a device-centric ID —which, by the way, SlideLOCK effectively is— is a BAD IDEA because paying customers are left stranded when they change to a different device. I know I have had a lot of benefit from having a “spare” pda in days gone past, it would have been very bad if I would not have been able to swap all my apps over.

Your Name Email Website