Symbian Platform Security - hacked?

Well, 3:00am has already passed and I'm tired and sleepy. One thing doesn't let me sleep, though. I've just stumbled upon these articles (Exploring S60 with AllFiles and Goodbye S60 Platform Security, Hello CAPABILITIES!) and I can't believe my eyes: Platform Security hacked?!

Briefly, the solution is as follows:

• Take a firmware update package (currently supported only by Nokia for their S60 phones).
• Edit a well-isolated part of it, where all those capabilities (i.e. rights) are listed that a user can grant to a 3^rd party application upon installation. Remove existing capabilities, add new ones, whatever.
  
• Flash it.

Now you have such a phone (software) that allows you to give so powerful rights to any 3^rd party application that they can do basically anything on the device. For example, your program can access DRM-protected content (you've downloaded it once and share it with others), browse other applications' secret folders, etc. You just need to

• Extract a signed SIS (Symbian Installation) file
• Add rights to it (whatever gives them more power)
  
• Re-pack & sign it again
• And install it
• Although the Software Installer will notice that the application was not properly signed (== acquires for more capabilities than it can normally have), the user will be in such a position that he can grant those extra rights.
  

Actually, this is the approach that the author of the aforementioned articles followed with regards to a very popular file browser application: he added AllFiles capability to the program so that he could explore the entire file system, which he hadn't been able to do until then.

Unfortunately, I can't prove or disprove whether this solution really works, since I haven't even updated my N95's firmware yet (shame on me!). However, this guy seems to know what he was talking about and I sort of a believe him.

In any case, if what he wrote happens to be true, then I have a few questions:

• Why on earth did Symbian publish such a confidential information that is useful solely for phone manufacturers? You know, the documentation of Software Installation Policy is a very internal thing, not anyone's business. You can see that it's enough if one talented person stumbles upon that documentation and uses it.
• Why is a firmware package in such a format that anyone can edit it? I mean, locally on their machine. Okay, with such a low-level tool that very few people are familiar with, but it's still possible. Wouldn't it have made more sense to encrypt and sign the package so that
• it cannot be decrypted by 3^rd parties (well, easily at least)
• it gets decrypted only on the target device right before flashing?

You know, I'm not a security expert, so I might easily be suggesting a stupid thing, but if there's any chance to do it that way, I think it's definitely worth the effort.

• But even if it's not viable, then why does the firmware package update the whole system including the most critical parts? You could see that one can change the software installation policy this way. Why not make a process consisting of two steps:
• User can download and flash a firmware package that updates the (vast) majority of the system, but it doesn't allow him to touch the critical parts
• Those critical parts can either NOT be updated at all or only at service points.
  

I just really don't know what I've expected from Platform Security, but I have a feeling that in my secret dreams I thought it was unbreakable (I know, I'm naive). Again, I'm still looking for confirmation as to whether this solution really works, but I'm afraid that I already feel the bitter taste in my mouth. You know, a system that Symbian is proud of, operators love (some developers hate:) and even competitors acknowledge shall not be attackable and even if a security hole is discovered it shall be closed quickly without any major impacts. Nevertheless, I think this problem can be solved - hopefully very easily. But as to injecting the fixed version on to old phones, it will just take another firmware update. :)

Tote

Update: another fellow Forum Nokia Champion of mine, Antony Pranata, wrote an article about the very same topic. I think it completes my post in addition to confirming that the solution works. Worth reading.

Symbian development - An alternative to embedding applications

I usually don't write articles about actual Symbian development issues, but this time I think I make an exception, if you don't mind. If you don't speak "Symbianish" or simply are not interested, then please skip the rest of my post. Nevertheless, I hope that the majority of you will just keep on.

I was in London on last Sunday for Nokia Developer Day. I was invited, because I'm a Forum Nokia Champion. There was an interesting presentation about Location Based Services and some technical details were revealed as to what Nokia would come out with as part of their upcoming SDK, namely S60 3rd Edition Feature Pack 2. It's not secret that they're going publish Map and Navigation API and an important feature of that API is the ability of launching Maps application stand-alone or embedded.

If you speak Symbianish, then you should know what launching an application in embedded mode means: your application loses focus and hands it over to the embedded application so that you have no control over it as long as that application owns the focus. It's worth noting, though, that albeit your application has lost focus it's still the main (hosting in other words) application that just makes use of services provided by another application. This can be seen by having a look at the list of currently running applications, where it's the name of your application that is in the list and not the one you have embedded.

The advantage of launching an application embedded in your application is that you don't have to bother with how it works internally, you just start it up and basically rely on that it works properly. On the other hand, this way of using other applications' services has disadvantages, too: one is that you have no influence on the menu structure of the embedded application.

Why is that important? Well, a real use case that we had to implement recently is that an application 1: shall be able to show some points-of-interest (POIs) on a map and 2:
shall have its own menu structure. We were happy to hear that Map and Navigation API would be available for public use, however, launching Maps application to satisfy our first requirement would mean that we would not be able to satisfy the second.

Then I started wondering how it could be done. Since I was deeply involved in the development of S60 Browser application some time ago, I know quite a lot about the application and the ecosystem around it. For example, I knew that a new approach had been introduced as part of the "Browser-offering" ~2 years ago that allows an application developer to use a (CCoeControl-based) control in her application. That control is called Browser Control (its API is BrowserControl API) and basically it is capable of showing & handling a web page just as the built-in Browser application does. So essentially your application can have its own menu structure, whilst also being able to show a web page. It gives you more flexibility and freedom if you use this API in favor of launching Browser in embedded mode, however, it's also more complex - sometimes unnecessarily.

Finally, we reached the point of my article: wouldn't it make more sense for applications that can be embedded (since not each application can be embedded) to offer such a (CCoe)control-based solution as well? For example, if the newly announced Maps and Navigation framework published such a service, then I shouldn't be worried about how to solve my problem. But this question is more general than to narrow it down to this special use case. I think, if some architects and/or lead designers from Nokia read my article, then I suggest them to think about it.

As a last thought, you might be wondering how I'm gonna work out this problem eventually. Well, there happened to be another presentation on that very day (i.e. Sunday) about Web Widget development on S60. I'm just thinking about writing an S60 widget that makes use of Google Maps API so that everyone is happy. :)

Any comments are welcome!

Tote

Treading on shaky ground

If I were Dumbledore, then I could put my thoughts, memories in my pensive to keep my mind clear and fresh. But I'm not him at all and my mind now feels overburdened with news that I can't keep in - so I let them out.

You know, it's a great thing to tag blog articles. It keeps them categorized, easy to look for, easy to oversee, etc. What I'm now about to write, though, fits in a new category (well, at least to me): treading on shaky ground. What is it? You'll see, just read on!

Everybody paid immediate attention to one of Nokia's recent acquisitions, the agreement for Nokia to acquire NAVTEQ. You know, two things couldn't escape most people's attention: first, the huge amount of money Nokia is willing to pay ($8.1 billion!), second, that it is such an area (GPS and location-based services) that hasn't been fully explored yet. They must foresee something (and of course play an active role in it) that others haven't been thinking of yet!

And it's not the only acquisition Nokia was recently involved in: for example, they also merged with Enpocket. This deal is to give a boost to advertisement after the public announcement that Nokia is opening to the Internet. Not as if we didn't know that NSeries is open to anything, we now know that to the Internet, too. In addition, and I'm sure most of you already know, Nokia has launched new services for content download & consumption lately, check out Ovi and MOSH to see what I mean.

So good, so nice. But you know what? There are some parties who are not happy with Nokia opening to Internet and offering content online. It's said to be the operators (carriers in US) who will lose the most money if Nokia happens to be successful in this area. Although their online offering (mostly ringtones and themes) can usually be described with one word, pathetic, they're still the biggest revenue generator for Nokia. What happens, for example, if some UK operators refuse to sell new Nokia models? What happens if others follow them? Although, as I've already pointed out, Nokia might not be really affected by such a sudden(?) move in the US, it'd still be an unpleasant thing to happen to Nokia. I sort of have a feeling that what we see happening around is a total war between Nokia and others (operators, mobile manufacturers, OS vendors, etc.). That's the way how it goes.

As to mobile operating systems, the competition is also getting more and more tough. Although it's nicely put by Atmasphere that iPhone is a feature phone, in contrast with N95, the über-smartphone, Apple definitely has influence on newer phones not only from Nokia, but other handset makers, too. It's also worth noting what he found about the afore-mentioned two phones:

The iPhone is for consuming content, while the N95 is for creating it.

So from that point of view, Apple might not pose a considerable risk to Nokia's position yet. But how about Google? Even though it's a bit of an old news that Google is working on a mobile OS, I'm wondering how it will threaten Symbian's future. It's said to be a Linux variant (a new distribution to make the market even more fragmented?) and of course will be ad-supported (== cheap). Looking forward to it!

Thanks for being my pensive so far, I feel really relaxed now. And also eager to know what you think about all these things I've mentioned!

Cheers,

Tote