Tag-Archive for » AndroidOS «

Monday, October 05th, 2009 | Author: Tim
Changing the properties..

Changing the properties..


Note: This might be well, a little low level for some people to understand -
though I’m sure this will end up finding the right people. If you understand this post -
then you’ll understand the significance of what the purposes of doing this would be
for
:)

Just randomly looking to do specific things with the Market, I finally figured out a way
to force the Market into accepting any certificate. It turns out there is actually a little bit
of code (leftover from testing?) that if special parameters are set, will allow you to
disable ssl certificate checking. This essentially allows us to well, do lots of things we
otherwise wouldn’t be able to do!

Obviously your going to need root to enable this - and I’m going to provide you the
way I’ve enabled it; using adb. Again like I’ve stated countless times, anything you do
via ADB you should be able to do via a console on the device, I’m not sure why people
always repaste everything and say just do it via a console thinking it’s some big news…
The two variables we’re going to have to set are ro.secure and
vending.disable_ssl_cert_check. Personally, my devices both have ro.secure
already set (properly) to 0. Vending.disable_ssl_cert_check is a new variable that we
will be creating, setting it to “TRUE”. Simply fire up adb and run the following
commands (as root);

setprop ro.secure 0
setprop vending.disable_ssl_cert_check TRUE

You can quickly run a “getprop” to verify you typed everything correctly; ro.secure
should be located as the first variable and the vending one is the last (since it is new).
You can verify that these settings are correct and working by watching your console
log for the Vending.apk via DDMS. The following string should appear while loading
the Market: “Turning off SSL certification check.” This can be seen below:

"Turning off SSL Check"

Also as a final reminder, every reboot these variables must be reset, since there is no program actually setting them already. You must reinitialize these variables (in my case, I only have to initialize vending.disable_ssl_cert_check) if you would like to use this mode.

Hopefully this will be of use to someone other than myself!

Tuesday, February 03rd, 2009 | Author: Tim

Your Ad Here

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.:
http://slideme.org/slidelock

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:

*Billing*
* 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%:
http://SlideME.org/rate-schedule
* Sales tax is legitimately applied to sales, including all of the European
Union
* 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
http://www.redplc.com
* 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.

*Client*
* 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.

*DRM*
* SlideLOCK has been released to protect your applications and prevent
forwarding
*
Infrastructure*
* 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;

sb.append("https://slideme.org/mobileapp/install-check?device_id=").append(mng.getDeviceId()).append("&key=").append(key).append("&version=").append(version).append("&versionCode=").append(versionCode).append("&network_op=").append(mng.getNetworkOperator()).append("&network_op_name=").append(mng.getNetworkOperatorName()).append("&network_iso=").append(mng.getNetworkCountryIso()).append("&software_version=").append(mng.getDeviceSoftwareVersion()).append("&phone_type=").append(mng.getPhoneType()).append("&network_type=").append(mng.getNetworkType()).append("&sim_iso=").append(mng.getSimCountryIso()).append("&sim_op=").append(mng.getSimOperator()).append("&sim_serial=").append(mng.getSimSerialNumber()).append("&subscriber_id=").append(mng.getSubscriberId()).append("&roaming=").append(mng.isNetworkRoaming()).append("&lock_version=1.1");

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.