Google Marketplace DRM broken Android applications secured by Google's Library aren't as secure as they should be, with only a byte or two preventing applications being copied freely. The bytes in question are contained within the selected application but clearly identifiable once the app has been disassembled, as demonstrated by Justin Case, whose write …
Its a fairly trivial fix.
And no, I won't provide a free example... ;-)
Lets just say it involves changing the handshake. The only issue is that if you upgrade or move your handset, you'll need to register that handset move w Google.
Fail because its such an obvious fix that it shouldn't have been an issue in the first place.
"DRM" of this sort is impossible to accomplish.
Any app which must decode/verify itself before running is intrinsically vulnerable regardless of how much verification is done within the app.
Like the skype client (notorious for obfuscation), reverse engineers will always be able to break that "DRM" since it's not truly cryptographically secure (the keys are obviously present in the app).
This is different from say the PS3 or XBOX (and I suspect the iphone), where the operating system checks the cryptographic signature on an application before running it. No amount of reverse engineering on the application will defeat OS based DRM.
Furthermore, if the OS is rooted (as I suspect is common with android users), then the user could simply disable the OS based DRM.
All this was well known to microsoft when they had their paladium hardware initiative a few years back. It was unpopular because PC users hate handing ms the keys to their own hardware (more than they already do).
So I disagree about there being any fix, much less an obvious one that isn't a cat & mouse game. As long as android is an open os on open hardware, there is no DRM google can add which users cannot remove.
Lou...
Want to bet?
You seem to be on track when you mention PS3 or XBox. ;-)
Like I said there exists schemes that would work and why they were not implemented is beyond me.
Can they be broken? Maybe over time, but the point is that your security only has to be strong enough that its not worth the effort to break.
"Want to bet? You seem to be on track when you mention PS3 or XBox. ;-)"
Doesn't seem like you read my whole post: "As long as android is an open os on open hardware, there is no DRM google can add which users cannot remove."
Sure they could lock down the handsets and only permit apps cryptographically signed by google, but that totally overlooks the value of android as an open platform. Having an open platform is more important to google and it's users than DRM is. Until that changes, there is absolutely nothing an app developer can ultimately do to stop a determined hacker willing to reverse engineer some code.
"the point is that your security only has to be strong enough that its not worth the effort to break."
Security by obscurity may work for unpopular apps that are unlikely to receive the attention of a skilled hacker, but it's unwise to bet on it, especially when hundreds or thousands of apps will be sharing the same obscurity techniques.
Also the Android user willing to install pirated software will face the same obstacles as users of, for example, PCs:
the program could contain malicious code,
updates, upgrades and add-ons might not work,
to install the dodgy code you'd need to go somewhere other than the Android Market - this ability is off by default.
If its Apple the commentards are ripping their eyes out and foaming at the mouth at the prospect of having Apple control their applications/appliances.
If someone offers a crack for android then two of the first free commentards are offering Google solutions.
Show some consistency you lot!
Youre normally a fairly irreligious bunch but not when it comes to phone OS's.
"But it's a fundamental problem with Java, you can easily reverse engineer it."
Same with .net CLR or android's register based alternative to java bytecode.
The intentions of the "byte code" are clear and therefor it's trivial to reverse engineer each function call. It's generally a good thing since it makes the code portable. A JIT compiler can always optimize for the processor it's currently running on, even with old programs.
Regardless of the merits of byte code versus machine code, I doubt an x86 (or ARM or PPC) implementation would have changed the end result for this "DRM".
The answer for android devs is to use obfuscation tools. Google already say to do this so apps that don't only have themselves to blame.
http://developer.android.com/guide/publishing/licensing.html#app-obfuscation
I expect it is also possible to supplement the legit checks with some of your own choosing. For example, the LVL lets you process the raw server response, so do so. If it looks iffy then don't proceed. Make several independent calls to the LVL from different bits of code. Store the response somewhere global so any piece of code can do a quick test. If anything looks iffy then log the phone's serial # and other pertinent info on your own server and report it back to google.
Meanwhile reward legit users by releasing frequent updates and new features which freeloaders will miss out on.
To most people, the best version is the cheapest version (which of course includes "free").
Also, the best app are always not available in your country's app store. Hence the need to pirate.
Skull and Crossbones. This is exactly what will happen if Apple doesn't let me buy the Martha Speaks Dog Party and Clifford's Be Big With Words apps soon. I've put up a request last week and the app still isn't showing up.
"Meanwhile reward legit users by releasing frequent updates and new features which freeloaders will miss out on."
Yeah, but the problem with that is simply that not everything can be updated and improved constantly beyond the core product or idea. Meaning, the only way developers can acheive what you say is to restrict features or cripple their software. This provides poor value for money and products that do not satisfy.
Don't make a shit product in the hope that people will buy it anyway and wait for updates to make it better, because they won't. The mechanic of users rating purchases with little stars will ensure your products stay well away from the "highest rated" list.
If your product is good, people will buy it. If it's great, more people will buy it. Regardless of the tiny % of people that might pirate, that probably wouldn't have bought your product in the first place.
Adding features and bugfixes to apps serves many purposes:
1. It incentivizes people to buy your product because they get free updates. Updates could be anything - bug fixes, new content, minor or major functionality, Android 2.2 / 3.0 support. Depends on the app really, but the idea is to keep it relevant whatever that means.
2. It keeps pirates on their toes because they're fighting a moving target. If your app stays at version 1.0 forever, the pirates just have to crack it once. If it keeps changing then you cause pirates more effort and realistically they've probably moved onto cracking somebody else's app by then.
3. It frustrates freeloaders who use the pirated version. They don't get the bug fixes or new functionality. You could even break their apps easily enough, for example by changing the urls or protocols your app uses so people on old apps don't work properly any more. Legit users would get updates so it wouldn't affect them.
4. It keeps existing customers happy and spreads good word of mouth that leads back to 1.
I assume anyone motivated enough to use a licence to protect their app should be motivated enough to keep their app from being pirated.
"Yeah, but the problem with that is simply that not everything can be updated and improved constantly beyond the core product or idea. "
Just look at Acrobat. Adobe keep upgrading it so they can sell upgrades, but they are way beyond what a PDF should be... Video in a PDF? DO NOT WANT. Keep updating a program because YOU need to update it, and not because the program needs to be updated and you end up with a bloated pile of crap.
"The Marketplace application returns a "1" if the application isn't allowed to run, so on receiving a "1" the application displays some information to that effect and quits. But that decision tree can be changed so an application receiving a "1" decides instead to go ahead and run"
Why is it the app's decision as to whether or not it is allowed to run? Surely, that decision should be taken by the OS? For example, the OS calculates a hash of the compiled app (i.e., the bytecode), then checks with the Marketplace as to whether or not the app can run. As long as the hash doesn't change, there is no need to consult the Marketplace for subsequent launches.
Fail because, well, they're doing it wrong...
"Android applications exist in byte-code, as do Java apps, and can thus be disassembled back to something very close to the original source with surprising ease. All the pirate has to do is disassemble the application, change it"... in any way...", then recompile it and Bob's your pirate."
Surely the problem that exists here is that applications can be disassembled at all. Once you have the source, anything is possible.
You can do the same thing in assembly language, it just takes a little longer to find the right instruction to change to change. I've done it myself with windows programs.
As far as letting the OS decide, that requires that all application's be submitted to a central authority to be approved and digitally signed just like Apple's app store.
Permitting anyone to have any app signed at will would be pointless as then the cracked versions would simply get signed.
Also someone would quickly "jailbreak" android to allow unsigned applications.
There is no simple way to prevent piracy and the more extreme measures tend to harm legitimate users more than the pirates, so its best just to take basic precautions against casual copying.
Old Excuses:
1) I'm socking it to 'The Man'
- Most apps are from small/independent developers to whom this is their livelihood; no big corporations/publishers involved.
2) The prices are far too high...
- What? A dollar/quid or two?
3) It's not a lost sale, I wouldn't have bought it anyway
- Don't install it then.
"3) It's not a lost sale, I wouldn't have bought it anyway
- Don't install it then."
Bad excuse. How do you know it's crap before you've installed it? Or actually, is it crap or not?
If I buy a car, I can have a test drive, for free, before buying, no strings attached.
But that's a opportunity software, music or film makers _don't want you to have_. Tell us why?
To me it's obvious that they knowingly sell crap and "try before buy" would kill the sales. That also explains a major whining about "piracy": "Pirated" products are not lost sales as such, but they show what the company is _really selling_ and that reality kills the sale.
Actually, many sales as the friends, who also saw what was on sale, won't buy either.
Most PC purchases (physical or digital) have keys, and the keys, once used, are hard to declare returned, abandoned, sold, whatever. I don't even think Steam (one of the biggest online digital distributors of games) has any form of return policy beyond canceling a pre-order.
What if the DRM itself is crap? Surly that's a legitimate excuse.
Believe it or not, in the US, copyright is a two way street.
Consumers have the right to make backup copies. We have the right to play our media in private on any machine we want without limit. We're even explicitly allowed to legally copy arbitrary pieces for public discussion (though not entire works).
Make no mistake, DRM is becoming more and more about controlling what consumers can do with their own property rather than protecting copyrighted works from illegal copying. As usual, DRM hurts legitimate users but does very little to stop the serious infringer.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
