One of my articles that has gained lots of attention was written about hacking Symbian Platform Security. Although it turned out that reproducing the workaround found by Symbiaali is laborous, requires strong technical knowledge and its wide-spread use is very unlikely, it clearly showed me that people were interested in this topic.

Today I found another post at Symbian Freak that describes just another way to turn Symbian operating system's well-known permission checking feature off. Although I don't agree with the title of the article (good-bye?? S60??), I think at least it's worth a few words.

What is this crack about? How can we cheat Platform Security capability checking so that it does not care if our program really has the capability being checked or not? Well, in a very special way:

• Take a development environment for Symbian, like CodeWarrior Pro or Carbide.C++ Pro. Please note that you will need the ability of on-device debugging, that's why CodeWarrior Personal/Carbide.C++ Express is not enough. I'm unsure if Carbide.C++ Developer Edition was enough (this is between Express and Professional), but I doubt that. More on this later.
• Prepare everything for on-device debugging (connect phone to PC, install MetroTRK to phone, etc.).
• Start any program from within the development environment (aka IDE) in debug mode.
• Change some bits in the kernel stack responsible for security enforcement. This is the most critical place, where you can really turn everything upside-down. And since you can do that, I believe it's Carbide.C++ Professional Edition that you need and not Developer - latter is less expensive, but in turn it provides only on-device application debugging in contrast with Pro's system debugging.
• Voilà, we're done - we have access basically to anything.

• The crack is temporary, since everything is done in RAM.
• Required tools are expensive: CW Pro was available at ~$1.700 (the product is discontinued and cannot be bought officially), Carbide.C++ Pro can be purchased for $1.300.
• Break is limited to one device.
• Proved to work only on Nokia N80, on other "hotter" devices (like the N95) it does not work or at least nobody has been able to make it work so far.

• Explore file system, discover what is stored where and how (as if you had AllFiles and/or TCB capability) and exploit it.
• Access to DRM-protected content (as if you had DRM capability). This might be more dangerous as you can download e.g. DRMed music once and sell it multiple times later on.

To sum up this post, this new way of cheating Platform Security is the traditional way of cracking. I'm not surprised that it had been discovered and published, I just wonder why it has taken so long? And finally, I don't think that it would cause major problems in Symbian ecosystem.

What do you think?

Tote

Update: Corrected the name of Carbide.C++ edition to Express. Thanks Lucian!

I think it's a good idea to wait a bit with commenting the announement of big things. You might not be as fast as others, but at least will have a broader view to the whole picture. At least that's what I did with Steve Jobs' announcement about the iPhone SDK (official press release is here) and developer program. Having read lots of articles written about it (by writers faster than me:), my remarks are below.

App Store
This is the place, the only place, where people can download 3rd-party software from, let it be commercial or freeware.

• Making it centralized is a good idea, better than having to look for something at lots of places. Especially if Apple undertakes lots of tasks, like distribution, advertising, content filtering, software update, etc. On the other hand, it will naturally result in that the control will be kept in one hand - it'll always be up to Apple to decide what is porn, illegal, etc. Is that good for us? Also, it doesn't help too much in pushing down the prices (I mean, interest rate) if there is only a single point of sell.
• I've been already thinking about that reselling applications should be done by device vendors themselves in order to keep the price at a more bearable level than it is at now. For example, Handango's 40-50-60% is something I call unabashed. However, it's understandable that they keep interest rate at that high level: it's their main (only?) income. Whereas for device manufacturers it would not be. Okay, I understand that they've been trying to keep themselves away from this part of the business so far, but nowadays that Internet is everything and if you don't provide a service that your competitors do, then you lose. For example, Nokia now offers Mosh and Ovi, but I can't remember if they offer App Store-like service, too. If they don't, I'm sure they will soon.
• One more thing: I think Apple is now bargaining. They announced a 30% interest rate from the price that developers will be able to sell their apps at, however, that's still too high. Never mind, let's check what people say about this rate, if the opposition is too big than we can offer less. From 30% you can do that.

• However, doing that require paying $99. It's a one off cost and in fact sounds reasonable for "standard" developers ($299 for enterprise developers) - it's mostly for signing, though freeware app developers will also have to pay this fee - for traceability purposes. In this respect (i.e. traceability), it's similar to Java certification and Symbian's Platform Security.
• Only platform is Mac? Sounds like a joke, look at the figures how many people/developers use this platform compared to Windows, Linux. I read it in Paul Todd's article that the SDK offers true simulation, not only emulation, which is fantastic. I wonder how VMWare would perform in iPhone development, though: people could install a virtual Mac machine on their operating system for development. Even more, it would make sense for Apple to create freely downloadable VMWare images for developers having everything pre-installed on it.
• Let me talk about the programming language developers are supposed to use, Objective-C. To be honest, I don't "speak" this language, but I have seen code written in it. I've been in "cross-platform business" lately and having said that I can see this language being more useful to our efforts than Java, for example (since none of the popular mobile OSes are built on non-C/C++). On the other hand, I'm afraid that Obj-C is too far away from standard C and C++ and one would need to make too big efforts to keep the codebase as common as possible.
• As for opening up 90% of APIs: it's nice, but a double-edged sword. First, Apple's got only one platform and one device (I mean, mobile phone). If everything goes fine with Apple's business there will be more platforms and more devices: the burden of SDK maintenance may grow to sky-high especially if you open up such a lot of APIs, taking care of source- and binary-compatibility, documentation, etc. You know, I would love to see Symbian/S60/UIQ to go open source or at least open up lots more APIs, too, but I understand why these companies decided not to do so. If Apple has the capacity to do it, then looking forward to it.
• As to $100M VC fund for 3rd-party development: it's obvious that newcomers have to say big, like this (remember Android's Developer Challenge?), I'm just hoping that others will do the same. Even if they're not newcomers, "just" founders of this industry. :)
• No multi-tasking: phew, it's really pain in the ... well, you know where. Although lots of things can be solved by storing state information when an application is forced to quit (heard that no 3rd-party app can run in the background! See Techcrunch for more details) and then retrieve that information on re-launch, this limitation causes lots of use cases not to work, like listening to incoming SMS, downloading/uploading/streaming content in the background, generally just hopping from one application to another where the soon-to-be-background app would still have things to do. I don't know why Apple has decided to introduce this limitation, but hope they will drop it soon.