Gabor Torok's Forum Nokia Blog

Smartphone statistics, 2008

2009-03-12T17:16:54+01:00

Gartner released their statistics about worldwide smartphone sales, which contains useful information not only the previous quarter (Q4 2008), but the whole past year. I'd like to share the following two figures with you:

Comments:

Nokia is still #1, but it's market position is seriously challenged by RIM, Apple and HTC.
Even Apple is suffering from decreased sales in Q4, but that didn't prevent them from being ranked as the third vendor by sales.

Comments:

Symbian had lived better days a year ago, but it's still a bit more than 50% of smartphones that runs this operating system.
RIM and Mac OS X performed exceptionally well even during the tough economical situation.
Although the share of Windows Mobile shrank a bit, it still maintains its third position. Only blinds can't see that not for long.

Finally, some words on regional sales:

Dramatic increase (69%) is experienced in sales of smartphone in North-America, which now accounts for 20% of mobile phones in this region. Carriers are agressivelypushing data plans that is beneficial for vendors, too, offering vertical mobile solutions from hardware manufacturing to providing developer SDKs to cloud services.
While overall device sales dropped, Asia/Pacific recorded a 2.3% growth in smartphone sales.
EMEA region were up by only 2%, Western-Europe sales increased by 9.6%. Samsung drove sales in 2008 with Omnia as its most successful product.

Tote

mobile-thoughts.blogspot.com

Mobile worm, Yxes.A - an analysis

2009-02-20T11:58:50+01:00

F-Secure and FortiGruard both reported that a new worm,Yxes.A, is spreading on Nokia smartphones based on S60 3rd Edition platform (and probably higher, too). According to FortiGuard:

"It gathers phone numbers from the infected device's file system, and repeatedly attempts to send SMS messages to those. The messages feature a malicious Web address (URL); upon "clicking" on the address in the received message, the recipients will download a copy of the worm (provided their phones/subscriptions allow for internet browsing)." That is, it's a Trojan.
Beyond propagating to as many users as possible via the strategy mentioned above, the worm's aim is to gather intelligence on the infected victim (such as serial number of the phone, subscription number) and post it to a remote server likely controlled by cyber criminals.
It's also noted that worm can mutate easily: "As far as our analysis goes, the worm currently does not take commands from the remote servers it contacts. However, since the copies hosted on the malicious servers are controlled by the cyber criminals, they may update them whenever they want, thereby effectively mutating the worm, adding or removing functionality." It's not that simple, though. It's not like download a new EXE from the Net and it will just work. No new EXE or DLL (a plug-in, for example) can be installed without the assistance of Application Installer, which will eventually require user's attention and approval. Some files that don't have to be installed can be downloaded, though, containing instructions for the worm to execute, however, it's becoming a science fiction if we think that any malware author will put THAT much effort in developing such a system. I'm highly sceptical on that it would be a real threat and refuse to be threatened by that.
It's also reported that "On launch, the worm executes as the process 'EConServer.exe', which is likely meant to camouflage alongside the existing legitimate system process 'EComServer.exe'". This simply doesn't mean anything: if a process name is only similar to another (system) process name then it doesn't imply anything. And anyway, EComServer.exe is never launched by hand (but by the system upon device start), consequently it's not a valid scenario that the malicious EXE gets launched instead.
It's a very agressive application, since it "will also automatically run every time the device is rebooted / power cycled. Further, it bears a destructive nature and will kill certain processes such as the application manager (AppMgr)." If that's true then the program must hold very strong capabilities that cannot be granted by a self-signed certificate.

You can see from the list above that the worm can be malicious, indeed. Following from the last point we can conclude even more:

The program couldn't be self-signed, since the program requires such strong capabilities that the Application Installer will never grant to a self-signed installable.
It couldn't be signed via Open Signed Offline*, either, since that would limit the spread only to max 1000 devices with given IMEI numbers.
It couldn't be Certified Signed*, either, since that requires a thorough test done by an official Test House. Even if they hadn't done a thorough test, such a behavior must have turned out very soon.
All that means that it was Express Signed*. You know, one characteristic of Express Signed is that they do occasional testing, which means that there might be some malicious apps that can go through this filter.

What counter-measures can be taken? First, the certificate of the malware author must be revoked. That means that whenever they will try to publish another application, whatever it will do it will not be allowed to be distributed, but will be filtered out automatically. This doesn't comfort any victims of this virus, though (hmm, are there any?).

Second, it would be just great if OCSP-checking was enabled on every phone by default. OCSP is a protocol that allows the Installer to check it in a database that a certificate is revoked or not. Although it is available on each S60 phones, it is disabled by default. But I go even further: it's not only the Installer that should use it, but other components of the system, too. In fact, the system itself should perform such a cross-check at regular intervals if any of the installed applications have become undesirable for the user (i.e. the certificate used to sign that application has got revoked) in the mean time. I'm unsure as to why this mechanism can be disabled at all, probably because it requires a network connection and data exchange with a remote server. But I think this should be something that operators shouldn't charge for - isn't it in their best interest, too, that the devices using their network wouldn't get infected?

* For more information on various signing schemes, please visit Symbian Signed.

Any thoughts are welcome,

Tote

mobile-thoughts.blogspot.com

Malware on Android: It has begun

2009-01-27T22:46:26+01:00

No, it's not going to be yet-another I told you so post. Though I did. :) You might have heard of the spreading of MemoryUp virus on Android-powered devices. There are numerous articles mentioning it (like this one ;), let me cite one of them from phoneArena:

"As strange as it may seem, a lot of users have complained of the MemorUp app..."

What is so strange in this? Android's security model is an open invitation to malware authors: anyone can write an application and distribute it freely on Android Market. The secret is that although every application must be signed, it's not mandatory that the certificate used for signing be certified by a Certificate Authority. In other words, you can self-sign your own application.Accountability is lost.

"We’re more worried about the fact that such a harmful application has found its way to Android Market and has stayed unnoticed until now."

That's exactly how Android Market works. I'm surprised that you're surprised. Anyone can write and freely distribute their own programs that may even be a malware. Signing ought to prevent from mass virus distribution - as long as signing certificates are certified by CAs (authors can be traced back and prevented from continuing malicious activity). Which is sadly not the case, see above.

"If it has managed to creep inside, wouldn’t there be a chance for others?"

It's not a question, I'm sure there will be more. Even though self-signed applications are limited as to what they're allowed to do, MemoryUp has showed us that this restriction is not enough.

The question is rather what could be done against this phenomenon? One option is that Google leaves it untouched: it will turn out very quickly if a program is malware or not (well, unless if it's a timed bomb). Another alternative is be stricter on what a self-signed app can do and allow only properly (i.e. CA) signed programs to act freely (after user's confirmation, of course). The strictest option would, of course, be if self-signing was not allowed at all. I'm sure you've noticed that the last two options mean that developers would need to pay for (CA) signing. Which is against the principles of Android development.

Looking forward to Google's reaction,

Tote

mobile-thoughts.blogspot.com