Windows 8 apps hackable and crackable, just like iOS and Android

Windows 8 apps can be hacked for piracy or ad removal. Should Microsoft do more?

Earlier in the week a blog post by Nokia engineer (and former Microsoft employee) Justin Angel highlighted a number of issues with applications from the Windows Store that enabled, among other things, the unauthorized conversion of trial apps into full versions, the modification of the prices of in-app purchases, and removal of embedded advertisements. Soon after publishing his post, Angel's blog was knocked offline in a flood of traffic; at the time of writing it remains unavailable, returning 503 error messages instead of content.

The integrity of Windows Store applications is an important issue. It forms part of the value proposition to developers, of the store itself; not only does the store provide easy, reliable billing, distribution, and updating, it also provides at least some degree of protection against piracy and other kinds of exploitation. If Windows 8 can't provide this then competing platforms (such as iOS) and competing delivery mechanisms (such as the Web) become more appealing.

Angel's examination of the store focused on games. Games are arguably the most popular category in app stores, and they provide some of the best demonstrations of the different business models that developers are using: ad-supported, free trials, and extensive use of in-app purchasing.

A new take on old problems

Some of the problems Angel highlighted were time-honored techniques used to subvert developers' design decisions. For example, the game Ultraviolet Dawn has an in-game currency. Players use this currency to buy various upgrades for their spaceships. The prices of the various upgrades are all stored in data files that form part of the game. These data files can be edited, making the upgrades cheaper, and hence making the in-game currency go a lot further than it normally would.

Modifying game data to make items cheaper isn't a new attack, and is far from unique to Windows 8. The widespread use of XML to store this kind of data might make Windows 8 apps a little easier to modify than software of old—no need to patch binaries in a hex editor when you can just use Notepad—but that's a minor detail.

A similar attack was used to remove the in-game ads from Microsoft's own Minesweeper. Most Windows Store apps have their interfaces written in XAML, Microsoft's XML language for user interfaces. These XAML files are stored as plain text as part of the application package and, like Ultraviolet Dawn's data files, they can be freely modified in Notepad. Editing Minesweeper's XAML allows the ad panel to be hidden from view. Removing it entirely might break the application, but hiding it is harmless and serves the purpose for the most part.

Again, the use of Windows 8 and the Windows Store is largely incidental. Patches to programs like Windows Messenger and ICQ that modify their user interfaces to hide or remove ads have been around for many years. As with the Ultraviolet Dawn modification, the use of XML may make this a little easier than it once was, but it's not fundamentally anything new or different.

It is, however, a little surprising that this can be done to Windows Store apps. To prevent side-loading, all applications in the Windows Store must be signed by Microsoft (or by an enterprise certificate for corporate applications that are distributed privately). Application binaries, the compiled executables and libraries that make up each program, can't be modified in this way, because any such modification would mean that their digital signatures were no longer valid.

What's surprising is that the same isn't true of these XML data files. Storing digital signatures for data files and verifying those signatures before each file is loaded would not be tremendously difficult. After all, Microsoft already does something comparable for HTML and JavaScript applications, after Angel highlighted similar flaws during Windows 8's beta period. For plain data, as used by Ultraviolet Dawn, the developer could in principle implement their own scheme to perform this integrity checking. But that's harder to do for XAML, as XAML is predominantly used by system libraries. A Microsoft-provided solution could cover both situations equally.

A slightly more complex example is found in Angel's examination of Soulcraft. Like Ultraviolet Dawn, Soulcraft has an in-game currency. In Soulcraft's case, that currency is purchased using real money. Soulcraft stores players' user profiles, which include the amount of currency they own, locally. The profiles are encrypted, which prevents casual modification, but the Soulcraft app itself contains everything it needs to decrypt, modify, and then re-encrypt the profiles—as indeed it must, to be able to modify the profiles.

Angel demonstrated that it was very easy to use Soulcraft's own application libraries to load and decrypt a profile, update the amount of currency, and then re-encrypt the profile. In this way, players can completely bypass the in-app purchasing system, giving themselves lots of gold but never having to shell out any real money for it.

As with the previous attacks, this is a new version of an old problem. Any user profile stored locally is at risk of modification. Encryption doesn't really help much as long as the game itself has the encryption keys and other information necessary to read the files, as indeed it must. Borderlands 2, for example, encrypted its savegames, in an attempt to prevent the kind of widespread modification that occurred in the original Borderlands. It didn't really help, and a fairly robust editor has been developed.

The wrinkle for Soulcraft is that these profiles modifications are depriving the developer of income. This is a problem that has been faced by developers before. The only robust solution is to not store profiles on end user machines. Profiles stored client-side are vulnerable to modification. Profiles stored server-side are not. If the profile contains something that's valuable, such as purchased currency, it should be stored server-side.

The difficulty with DRM

This is the standard DRM problem: DRM is designed to protect content that is stored and decrypted on client machines from the users of those machines. Necessarily the machines must contain all the information they need—encryption keys, algorithms—to perform that decryption. You can obfuscate this to make it harder—for example, Windows could offer its own encrypted storage with the encryption keys stored not by each application but by the operating itself—but such hurdles only give attackers a one-time cost. Once a way for extracting the keys has been devised (as it almost inevitably will be) then the DRM system can be attacked.

Server-side profiles solve the DRM conundrum by never putting the protected information on the client machine. The downside is that they create considerable complexity for developers—an entire server-side profile system must be implemented.

Angel demonstrated a similar undermining of in-app purchases with Cut The Rope. Cut The Rope in the Windows Store is a game built using HTML and JavaScript. It uses a fairly typical freemium model: the first few levels are free, the rest cost money. Angel showed that by attaching the Internet Explorer script debugger he could circumvent the purchase process and unlock the levels without having to pay. Cut The Rope made this particularly simple, as the code within it included a test/debug mode that allowed its developers to test the level unlocking logic without having to make a payment. Angel could use the debugger to enable this test mode and the game itself did the rest of the work for him.

Even without the debug mode, the fundamental problem Cut The Rope has is that the base game includes all the levels. The attacker's job is simply to trick the game into giving access to those levels. A more robust implementation would download the levels only on receipt of payment—with the payment validation performed server-side, of course. Another route would be to abandon in-app purchases entirely, and simply have two versions of the game; a no-cost Cut The Rope Free with a limited selection of levels, and a paid Cut The Rope with all the levels.

The final attack Angel demonstrated was in some ways the most serious, since it's the only attack that attacked not individual applications but the operating system itself. Windows 8 includes a license file that contains information about all the programs that you're entitled to use, and whether they're trial versions or full apps. The operating system maintains and strives to protect this file. However, a crack has been devised that allows trial versions to be converted into full versions. It also allows paid-only apps to be redistributed and used for free, as long as at least one person pays for the app in the first place.

The crack works by compromising the integrity of the Windows system services that maintain this license file. The guidelines for using the crack recommend that you leave it running all the time, to prevent Windows' own periodic re-validation of the license, so it's not a simple fire-and-forget thing. It also prevents the download and installation of app updates, as the Windows Store only provides updates to owners of legitimate licenses. Nor does it side-step server-enforced restrictions, such as the inability to re-download apps once their trials have expired (though there are ways around this).

What's Microsoft to do?

Pirating software is an age old problem. So too is patching programs and data to subvert the intentions of the developer. Even the crack for the Windows store licensing system is unexceptional in the world of software piracy. These things happen; they're practically an inevitability.

There are some small things that Microsoft could, and probably should, be doing. Blocking modification of XAML and application data files would be easy to do, and would help preserve the integrity of in-app advertising (which, like it or not, is a necessary feature for many zero-cost programs and services). There might also be value in giving developers easy-to-use, system-managed encrypted storage to keep user data in a manner that precludes trivial tampering.

Application developers, too, can take more care. The developers of Cut The Rope made subverting the payment system particularly simple by virtue of shipping testing code to end-users. Soulcraft should store user profiles and their purchases on a server somewhere, away from prying eyes.

Nonetheless, there is an underlying challenge for developers and Microsoft alike. The attacks Angel described are traditional attacks on the PC because the PC lets you run whatever software you like. PC software has always had to tolerate running in a hostile environment; an environment rife with debuggers, hex editors, disassemblers, and virtualization, the tools that allow the reverse engineering, modification, and cracking of that software.

Such attacks are much less typical of mobile platforms, particularly iOS, because those applications and tools can't easily run on iOS devices. By default, all iOS programs are sandboxed and isolated from one another, preventing the kind of inspection and analysis that Angel demonstrated for the Windows 8 programs.

But that's not always the case: on jailbroken iOS devices, those of a suitable bent can indeed run debuggers and other software—and this is exactly what they do in order to enable piracy of iOS apps. iOS applications are encrypted and have to have a legitimate digital signature, but jailbreaks remove the digital signature checking almost entirely, and decrypted applications can be generated by letting the operating system decrypt a legitimately purchased application, and then using a debugger to copy the decrypted app from memory.

Rooted Android devices are susceptible to similar attacks.

Microsoft, Apple, and Google all have systems whereby applications can verify their own licensing status, which defeats basic attempts to pirate, but once a cracker has a copy of the app to examine, they can easily remove these checks, so the value of such protection is limited.

Windows 8's PC nature may increase applications' exposure to these attacks to some extent. That's something that application developers should be aware of. Some might not like the exposure and could decide to abandon Windows, but ultimately application security and integrity are the responsibility of app developers, not operating system developers, and that's the case on every mobile platform around.

101 Reader Comments

I'm not sure they can do more. People are going to find ways to pirate regardless of what they do. Does that mean they shouldn't take it more seriously? Of course not, I'm just saying it ultimately becomes a lesson in futility. You spend more and get less in return for being "more secure". It's not going to stop.

The iOS model of the marketplace has never been particularly resilient on computers that still let you sideload, and never will be. In-particular, being able to sideload and run as the root user... Sideloading is also malwareloading.

But I *like* sideloading. In fact it's pretty much my favorite thing. Curses. Security is hard

apple knows what's up: cultivate a culture where people don't pirate stuff. either that or go full-bore RMS....

If this was sarcasm then very well done my friend! I fear that perhaps it wasn't sarcasm, though, after watching apologists stick up for their technology constantly (even here!) without rational cause. The next short bits are dedicated to the chance that you were less than sarcastic.

I will let you in on a secret:

Apple has an incredibly large pirated app ecosystem; for example Installous which fails to even market itself as anything more than a pirating app. More than that, I've seen memory adjusting programs for fixing pay-in-app games in just the same manner this article is talking about. Shocking right? The culture so adored might itself have a dark underbelly. Shock. Awe.

Let us get beyond our blind fanaticism that adds nothing of content to the countless articles people such as you feel the deep call to post on. Let's not waste the precious real estate that millions of these comments (cumulative) take up. Let us move on into areas of intellectual discourse once thought unreachable, pushing the boundaries of our imagination instead of stagnating on the rocks upon the beach of Cliche.

It sounds like a lot of this is laziness on the developers' part. If you store data in ASCII readable files (like XML), of course it can be modified. If you don't want it modified, maybe XML is not the answer. Some encryption or even obfuscation might be helpful.

I understand the need for developers to be able to make a profit, but on the other hand I also know that I've been able to fix a lot of things on my computer by editing data files or the registry. And on my WebOS phone, I've been able to improve some apps and the homebrew community has been able to improve a lot more. (And by improve I mean things like making the app work properly on an unsupported device, etc. Not removing ads or piracy. I block ads at the global level with a hosts file....) So, I don't want a device that is locked down too tightly. I hope they keep any restrictions tightly limited to only the places they are actually needed.

It seems fair that once you've downloaded a program, you should be able to do anything you like with it, including modifying the data files in ways the developers didn't intend. I realize that the DMCA and various EULAs don't make such activity legal in the strictest sense, but I don't see anything immoral or wrong about modifying something that obtained through legitimate means however you see fit.

On the other hand, if this makes developers less likely to offer trial, in game purchase, or ad supported versions of software, if such activity ever becomes widespread enough it could hurt everyone.

Of course, as was mentioned above, there's always the option of just supporting developers who make apps for the love of doing it - I'll always use an open source or unrestricted freeware application if one exists that does what I want vs using a for-profit app.

At the end of the day, there will always be a way around DRM. Nothing is unhackable, and once someone has found a way to do it tools will pop up that make it easy for anyone so inclined to repeat the process. Therefore I'm against any measures that reduce usability for non-hacking users. Server-side data files may make it easier to keep things on lock-down, but it also restricts legitimate use of the application to times when the user has an available data connection, so it's an inherently user-unfriendly solution.

Most people will never hack their phones or apps, so it might not be worth worrying about those that will. Accept that some people will find a way to get free access to any software, or usually pay-restricted features of such software, that anyone ever writes, and realize that it isn't the end of the world. As long as the app is appealing enough it can still make money as the vast majority of users will never try to hack in the first place. Basically, don't worry about who isn't paying for it, worry about making it appealing to those that will.

Peter, you've been doing Windows development for a long time. I've only recently started working with Windows specific development, though from what I understand, aren't XAML files considered resources? And I was under the impression that resources are baked into the binary and you access them through either Windows.Resource or appName.Properties.Resources.ResourceName? If so then having XAML outside of what's expected goes against what Microsoft recommends, and this is akin to people being able to hack IAP on IOS because the developers didn't follow proper procedures. In the IOS case, developers didn't confirm if a receipt came back properly from Apple before unlocking IAP, they just trusted the device IAP API to say 'okay, this is purchased!'

So, what is an app developer to do? If one can't protect one's app from infestation, what kind of countermeasures should one adopt ?

Feel free to code apps in any way that discourages hacking as long as the measures taken don't make using the app more difficult for those who purchase it legitimately - once that line has been crossed, however so slightly, the developer is wrong.

Realize that everything will be hacked, everything will be pirated, everything will be exploited, and don't worry about it.

Make the app worth paying for for those who will buy it and use it legitimately and don't waste time thinking about everyone else.

I think this could be the weakest piece I've read from PeterB. Let's point out some problems.

Quote:

If Windows 8 can't provide this then competing platforms (such as iOS) and competing delivery mechanisms (such as the Web) become more appealing.

It's pretty trivial to jailbreak an ios device, and installous is almost as easy to use as the app store. It can even tell you if updates are available. There have been plenty of articles on Ars about how piracy on ios is hurting developers. The main appeal of ios is the huge userbase, and not much compatibility/fragmentation problems.

Quote:

The widespread use of XML to store this kind of data might make Windows 8 apps a little easier to modify than software of old—no need to patch binaries in a hex editor when you can just use Notepad—but that's a minor detail.

Software have been using ini and cfg files for years on windows. You've been able to give yourself a huge pile of cash in Solitaire since Win95 (and I think even PocketPC) by editing one file. Ars even showed how to change the encrypted ini files for Bulletstorm to change settings hidden by the developers. I can't remember the last time a hex editor was needed to change any settings.

Quote:

Server-side profiles solve the DRM conundrum by never putting the protected information on the client machine. The downside is that they create considerable complexity for developers—an entire server-side profile system must be implemented.

Server-side profiles are also pretty much universally despised by 'the community' - it stinks of always-on DRM and even ubisoft are backing away from that model.

Quote:

It uses a fairly typical freemium model: the first few levels are free, the rest cost money

I think the phrase you're looking for there is shareware, and it's been around since the 90s. I believe there was one little developer in particular who figured out how to make it work, maybe you've heard of iD games.

Quote:

Update: Our research suggests that Microsoft is indeed blocking these modifications; it's likely that Angel's findings here were influenced by his use of the license crack.

Oh, so once you're running a system crack (like a jailbreak) then all bets are off, just like every other platform.

One thing not mentioned in the article - can these cracks be used in WindowsRT, or are they Win8 only for now? I think MS would be a lot more worried if RT is vulnerable as that's their anser to ios and the ipad.

It uses a fairly typical freemium model: the first few levels are free, the rest cost money

I think the phrase you're looking for there is shareware, and it's been around since the 90s. I believe there was one little developer in particular who figured out how to make it work, maybe you've heard of iD games.

Quote:

Update: Our research suggests that Microsoft is indeed blocking these modifications; it's likely that Angel's findings here were influenced by his use of the license crack.

Oh, so once you're running a system crack (like a jailbreak) then all bets are off, just like every other platform.

Your first quoted point just agrees with what he's said which goes against the main point of your post - that he's not making any good points.

The second point I believe is the difference between having a system you goof off on, and don't trust, vs a system you literally bank on. Of course many don't get this and bank on systems they've willfully cracked yet continue to trust.

I think this could be the weakest piece I've read from PeterB. Let's point out some problems.

Quote:

If Windows 8 can't provide this then competing platforms (such as iOS) and competing delivery mechanisms (such as the Web) become more appealing.

It's pretty trivial to jailbreak an ios device, and installous is almost as easy to use as the app store. It can even tell you if updates are available. There have been plenty of articles on Ars about how piracy on ios is hurting developers. The main appeal of ios is the huge userbase, and not much compatibility/fragmentation problems.

There are many people with iPhone 5s who'd love an untethered jailbreak. It's not that trivial. Not at all.

Quote:

Software have been using ini and cfg files for years on windows. You've been able to give yourself a huge pile of cash in Solitaire since Win95 (and I think even PocketPC) by editing one file. Ars even showed how to change the encrypted ini files for Bulletstorm to change settings hidden by the developers. I can't remember the last time a hex editor was needed to change any settings.

Try editing Borderlands' saves, for example.

Quote:

Server-side profiles are also pretty much universally despised by 'the community' - it stinks of always-on DRM and even ubisoft are backing away from that model.

Despised? Does the community despise Call of Duty? World of Warcraft? Most games that have competitive multiplayer with character progression have switched to server-side profiles.

Quote:

I think the phrase you're looking for there is shareware, and it's been around since the 90s. I believe there was one little developer in particular who figured out how to make it work, maybe you've heard of iD games.

You'll notice that shareware DooM only included the .pak files for the first episode. You couldn't crack it to play the other episodes.

Quote:

One thing not mentioned in the article - can these cracks be used in WindowsRT, or are they Win8 only for now? I think MS would be a lot more worried if RT is vulnerable as that's their anser to ios and the ipad.

Can't run the crack executable on Windows RT, as I believe it still lacks a jailbreak. It seems inevitable, however, given that code execution and privilege escalation vulnerabilities are found in Windows from time to time.

So, what is an app developer to do? If one can't protect one's app from infestation, what kind of countermeasures should one adopt ?

I can only speak about the iOS side of things, and unfortunately there are some real trade-offs involved when you try to lock down your app. This is especially apparent when you try to throw in server-side authentication and checks for purchases. One of the key features in most of the apps I have worked with is some form of offline functionality (thus storing app state). Apple puts some restrictions on either being able to track a device by uuid or mac address and/or requiring sign-up, so a level of anonymous (outside the itunes acct) purchase needs to be accommodated (again a locally stored app state issue).The list runs the gamut from less to more secure options for this data storage (plist, non-hashed unencrypted file, hashed unencrypted, hash encrypted), and I can say that more often than not developers are not thinking about the user that has rooted their app and is using their keys to look at data. There is always increasing overhead the more locked down things get and at some point you really worry more about the % of legit users you piss off with it as opposed to the % of folks actually ripping you off.Its not as simple as just calling out for a receipt you can verify against, and while I think due diligence is appropriate at some point you have to ask yourself "are the small percentage of people ripping the product off in a position where if the app was appropriately locked down they would instead be customers?" Security is tough to bake in late in development and its usually not a top priority (medical/banking excluded) when a client is laying out their project $'s.

Peter, you've been doing Windows development for a long time. I've only recently started working with Windows specific development, though from what I understand, aren't XAML files considered resources? And I was under the impression that resources are baked into the binary and you access them through either Windows.Resource or appName.Properties.Resources.ResourceName? If so then having XAML outside of what's expected goes against what Microsoft recommends, and this is akin to people being able to hack IAP on IOS because the developers didn't follow proper procedures. In the IOS case, developers didn't confirm if a receipt came back properly from Apple before unlocking IAP, they just trusted the device IAP API to say 'okay, this is purchased!'

For whatever reason, the compiled binary format, BAML, that's used in WPF doesn't exist in WinRT. As such, WinRT's XAML files are stored as raw XML within the application directory, rather than embedded within the binary.

It now looks as though Justin Angel made a mistake in thinking that those files were not signature protected, however.

That is a understatement of epic proportions. In Android you simply go into the settings menu and unselect "install android apps only from known sources" then copy a apk to your device and run it.. bingo, any app, pirated or not. No rooting required.

I think it's worth emphasising that there are different aims to different protections. With the focus on games: Securing a game enough that it's worth it to the average user to pay to acquire it (without increasing the hassle for legitimate users), so you can run a worthwhile enterprise, is one thing. Securing the actual gameplay is a different set of issues.

The name of the game should be (coinciding with making your money) providing an awesome experience for as many legitimate users as you can - and maintaining a cost-to-quality ratio that provides you enough legitimate users that you can justify the product. Don't worry about idiots, they'll always be out there, and they don't deserve the attention. It's a mistake to worry about them as though they're potential customers; these people are not a demographic to be spending time or money on. If your game only appeals to these idiots - rather, if it doesn't appeal to enough people who are willing to pay what you're charging - then maybe you need to adjust your strategy. If some idiot hacking the game doesn't ruin it for someone else playing legitimately, don't lose too much sleep over it.

Games where online multiplayer with/against strangers is a crucial part of the gameplay - hardcore anti-cheat protection is basically a must. Good luck to you - I think in this case players understand if you have to dress your software in a thousand tonnes of armour, and charge a little extra money and hassle.

Games that are singleplayer, or multiplayer amongst friends? Introduce enough basic bug-free/hassle-free copy protection that legitimate users don't feel like idiots for having bought a copy, but otherwise _make_ the gameplay hackable. In fact, if you've got an editor from production, consider releasing it as-is to the community. Increase your pool of legitimate, happy-to-pay users. Consider yourself the same as any other digital artist. Offer merchandise, 3rd party licensing, maybe some premium community services, and reasonably priced expansion content. If your game costs too much to make to be able to support the economics... then maybe your game cost too much to make and you need to adjust your budget...

I am kind of curious why there hasn't been more work to make secure systems, either through software or hardware, since everyone that makes software seems to strive for (and never succeeding) in securing their software. I guess maybe it's just a losing battle.

And so goes the arms race between developer and end user. They have the advantage as the OS vendor is on their side, but then you have pathetic developers like this: http://lunarfrog.com/blog/2012/06/05/me ... rotection/ who think it's a bug that the user can take ownership of the folder these applications live in, as if the platform is intended to serve developer needs and hold the owner of the system at bay.

I expect to see app developers clamoring for more and more intrusive DRM and more restrictions on the capabilities of end users.

So Peter, I only have one question, what does "Angel's findings here were influenced by his use of the license crack." mean exactly?

There is only one tool I know of that might describe this, designed to block the in-application ads, is this the tool you mean or are we talking about an unlicensed copy of Windows being used to illustrate a possible attack vector in the Windows Store model?

If its the later one, lets be honest, that is nothing really new and unlikely the biggest problem developers will have going forward with Windows 8. Even after the price increase Windows 8 will have a very good feature to value ratio.

Some of the problems that this possible vector exposes can fix with several simple framework updates from Microsoft. One possible solution would be to is provide a method to decrypt resources on the fly after asking for an online key from the developer. This key could be set aside and would be unique to each purchase.

Soulcraft should store user profiles and their purchases on a server somewhere

What??? Just What??? I never expected to read a line like that in an Ars article and I feel strongly that my money should not be going towards an publication which advocates such a view.

Soulcraft is not an online multiplayer game. Online only DRM is not acceptable. What if I want to play it on a plane?What if I want to put it on the old phone I use as a games console for my kids (has wifi at home but no mobile sim when we're out) ?

That is a understatement of epic proportions. In Android you simply go into the settings menu and unselect "install android apps only from known sources" then copy a apk to your device and run it.. bingo, any app, pirated or not. No rooting required.

Hmm, not quite.

You can use that trick to load APK from a different source, but you can't access applications on your device. The applications are in separate folders and only the applications themselves (and root) have access right to those folders. (In Android each application has it's own user id and then standard Linux/Unix systems are used to control access to files and memory.)

So, what is an app developer to do? If one can't protect one's app from infestation, what kind of countermeasures should one adopt ?

I can only speak about the iOS side of things, and unfortunately there are some real trade-offs involved when you try to lock down your app. This is especially apparent when you try to throw in server-side authentication and checks for purchases. One of the key features in most of the apps I have worked with is some form of offline functionality (thus storing app state). Apple puts some restrictions on either being able to track a device by uuid or mac address and/or requiring sign-up, so a level of anonymous (outside the itunes acct) purchase needs to be accommodated (again a locally stored app state issue).The list runs the gamut from less to more secure options for this data storage (plist, non-hashed unencrypted file, hashed unencrypted, hash encrypted), and I can say that more often than not developers are not thinking about the user that has rooted their app and is using their keys to look at data. There is always increasing overhead the more locked down things get and at some point you really worry more about the % of legit users you piss off with it as opposed to the % of folks actually ripping you off.Its not as simple as just calling out for a receipt you can verify against, and while I think due diligence is appropriate at some point you have to ask yourself "are the small percentage of people ripping the product off in a position where if the app was appropriately locked down they would instead be customers?" Security is tough to bake in late in development and its usually not a top priority (medical/banking excluded) when a client is laying out their project $'s.

edit NulloModo you kinda beat me too it

You raise a very important point, "big media" would like us to believe that every pirated copy represents a lost sale but we all know that's not true. So you have to factor in how many people are pirating the app and how many of them are likely to actually be a customer if they couldn't pirate, how resrictive is the DRM going to be to the legit users and how much of an overhead for the developer is the implementation of the DRM going to create. Once you have looked at all those factors a lot of the time you are going to find that DRM is a waste of time and those that would pay will pay and those that wouldn't won't.

Summarising: it is still possible for people to control what code runs on their own computers and how it runs ...and this is somehow a PROBLEM???The fact that this discussion is even happening it a ready sad indication of how hostile to users the software industry has become. It things keep moving in this insane direction then pretty soon general purpose computers will have been entirely replaced by limited functionality appliances which require you to get permission from a remote server in order to do the most mundane task. Want to run your OWN code? Yeah, sorry, that ain't gonna be happening.