Looking back at Nokia World 2009

LONDON, England – As we count down to Nokia World 2010, we thought it’d be a good time to take a look back at 2009’s event. Stuttgart was the location and things kicked off in a rather glamourous location for this intrepid reporter – the Porsche museum. There the winners of the Calling All Innovators contest were announced and those shortlisted had an opportunity to show off their wares. But that was just a preamble for the following morning we pitched up at Messe Stuttgart for OPK’s keynote speech. Read on after the jump to find out what happened next.

Uncharacteristically, OPK arrived on stage in a slightly wrinkled shirt. The simple explanation came later: five minutes before he was to go on stage, OPK’s suit jacket had an unfortunate collision with someone else’s cup of coffee. So the big man had to toss the jacket and go with a more casual look than he had planned. Some observers commented that the “new, rumpled look” was a brilliant move that made the CEO look “more approachable.”

The incident didn’t stop him from revealing a treasure trove of new devices, however.

Prior to Nokia World, the N900 was revealed to pretty wide acclaim – in our follow up vote the N900 bagged 68 per cent of the votes for “favourite product from Nokia World”). The event itself offered many their first opportunity to get hands-on with the then new device and folk were suitably excited. But bigger changes were afoot, as OPK revealed. The arrival of both the Nokia X6 and Nokia X3 marked a shift in naming for Nokia devices. This shift has evolved steadily over the course of this year with new Cseries devices being announced (step forward you touch and type wizard, Nokia C3), new Eseries devices such as the E5 and the recently announced Nokia N8.

But Nokia World wasn’t just about devices. Rolling out from under the covers came the Ovi SDK and the navigation API. Since then both have evolved and are rapidly becoming staples for developers to create new and exciting applications.

Nokia World 2009 also saw Nokia Money revealed for the first time. That too has since evolved and is now up and running as a real service, as we reported recently.

We’ve not been short on new device announcements already this year, but that doesn’t stop a whistle of anticipation around this year’s Nokia World. As ever, we’re counting down to the big event and looking forward to seeing what goodies and treats are in store for us. Of course, the full Conversations ensemble will be present and correct, so if you’re there, be sure to look us up. You can find our pics on the about us page, so if you spot us, do say hello. We’ll be pleased to see you!

Nokia completes acquisition of Motally, Inc.

Espoo, Finland - Nokia announced that it has completed the acquisition of Motally, Inc., initially announced on August 20, 2010.

Motally's mobile analytics service enables developers and publishers to optimize the development of their mobile applications through increased understanding of how users engage. The service offering is planned to be adapted for Qt, Symbian, MeeGo and Java developers.

About Nokia
At Nokia, we are committed to connecting people. We combine advanced technology with personalized services that enable people to stay close to what matters to them. Every day, more than 1.2 billion people connect to one another with a Nokia device - from mobile phones to advanced smartphones and high-performance mobile computers. Today, Nokia is integrating its devices with innovative services through Ovi (www.ovi.com), including music, maps, apps, email and more. Nokia's NAVTEQ is a leader in comprehensive digital mapping and navigation services, while Nokia Siemens Networks provides equipment, services and solutions for communications networks globally.

Consumers rate Nokia as India's Most Trusted Brand for third year in row

Espoo, Finland - Nokia has been ranked No.1 in The Economic Times-Brand Equity's annual 'Most Trusted Brands' survey for 2010 in India, marking Nokia's recognition as India's most trusted brand for three consecutive years. Nokia has appeared in the survey since 2005, and has held the first position in 2008, 2009 and now, 2010.

Nokia's leadership rating over the years in this survey is also an indicator of the dramatic impact mobility has on India's consumers over the years. India has been among the fastest growing telecom markets in the world with an estimated current mobile subscriber base in excess of 670 million subscribers.

"Nokia has always been a consumer-centric company and a consumer award for 'trust' is the pinnacle of all awards. This award is a testament to our team's deep focus and determined efforts to better understand the needs of the evolving Indian consumer and connect with them. Our initiatives for India - ranging from 'made in India, made for India' handsets, services such as Nokia Life Tools and extensive retail and care networks - are a proof of the fact that we are continuously striving to make a positive impact on the lives of our consumers," said D. Shivakumar, Managing Director, Nokia India Pvt. Ltd.

The award marks the celebration of 15 years of mobility and Nokia in India. The first mobile phone call was made on a Nokia phone using Nokia network on July 31, 1995.

Brand Equity's 'Most Trusted Brands' survey judges 300 brands from consumer products and services. Consumers across 13 Indian cities evaluate the brand on seven key attributes.*

About Nokia
At Nokia, we are committed to connecting people. We combine advanced technology with personalized services that enable people to stay close to what matters to them. Every day, more than 1.2 billion people connect to one another with a Nokia device - from mobile phones to advanced smartphones and high-performance mobile computers. Today, Nokia is integrating its devices with innovative services through Ovi (www.ovi.com), including music, maps, apps, email and more. Nokia's NAVTEQ is a leader in comprehensive digital mapping and navigation services, while Nokia Siemens Networks provides equipment, services and solutions for communications networks globally

Brace for the Future

[This post is by Dan Morrill, Open Source & Compatibility Program Manager. — Tim Bray]

Way back in November 2007 when Google announced Android, Andy Rubin said “We hope thousands of different phones will be powered by Android.” But now, Android’s growing beyond phones to new kinds of devices. (For instance, you might have read about the new 7” Galaxy Tab that our partners at Samsung just announced.) So, I wanted to point out a few interesting new gadgets that are coming soon running the latest versions of Android, 2.1 and 2.2.

For starters, the first Android-based non-phone handheld devices will be shipping over the next few months. Some people call these Mobile Internet Devices or Personal Media Players — MIDs or PMPs. Except for the phone part, PMP/MID devices look and work just like smartphones, but if your app really does require phone hardware to work correctly, you can follow some simple steps to make sure your app only appears on phones.

Next up are tablets. Besides the Samsung Galaxy Tab I mentioned, the Dell Streak is now on sale, which has a 5” screen and blurs the line between a phone and a tablet. Of course, Android has supported screens of any size since version 1.6, but these are the first large-screen devices to actually ship with Android Market. A tablet’s biggest quirk, of course, is its larger screen.

It’s pretty rare that we see problems with existing apps running on large-screen devices, but at the same time many apps would benefit from making better use of the additional screen space. For instance, an email app might be improved by changing its UI from a list-oriented layout to a two-pane view. Fortunately, Android and the SDK make it easy to support multiple screen sizes in your app, so you can read up on our documentation and make sure your app makes the best use of the extra space on large screens.

Speaking of screen quirks, we’re also seeing the first devices whose natural screen orientation is landscape. For instance, Motorola’s CHARM and FLIPOUT phones have screens which are wider than they are tall, when used in the natural orientation. The majority of apps won’t even notice the difference, but if your app uses sensors like accelerometer or compass, you might need to double-check your code.

Now, the devices I’ve mentioned so far still have the same hardware that Android phones have, like compass and accelerometer sensors, cameras, and so on. However, there are also devices coming that will omit some of this hardware. For instance, you’ve probably heard of Google TV, which will get Android Market in 2011. Since Google TV is, you know, a stationary object, it won’t have a compass and accelerometer. It also won’t have a standard camera, since we decided there wasn’t a big audience for pictures of the dust bunnies behind your TV.

Fortunately, you can use our built-in tools to handle these cases and control which devices your app appears to in Android Market. Android lets you provide versions of your UI optimized for various screen configurations, and each device will pick the one that runs best. Meanwhile, Android Market will make sure your apps only appear to devices that can run them, by matching those features you list as required (via tags) only with devices that have those features.

Android started on phones, but we’re growing to fit new kinds of devices. Now your Android app can run on almost anything, and the potential size of your audience is growing fast. But to fully unlock this additional reach, you should double-check your app and tweak it if you need to, so that it puts its best foot forward. Watch this blog over the next few weeks, as we post a series of detailed “tips and tricks” articles on how to get the most out of the new gadgets.

It’s official folks: we’re living in the future! Happy coding.

Securing Android LVL Applications

[This post is by Trevor Johns, who's a Developer Programs Engineer working on Android. — Tim Bray]

The Android Market licensing service is a powerful tool for protecting your applications against unauthorized use. The License Verification Library (LVL) is a key component. A determined attacker who’s willing to disassemble and reassemble code can eventually hack around the service; but application developers can make the hackers’ task immensely more difficult, to the point where it may simply not be worth their time.

Out of the box, the LVL protects against casual piracy; users who try to copy APKs directly from one device to another without purchasing the application. Here are some techniques to make things hard, even for technically skilled attackers who attempt to decompile your application and remove or disable LVL-related code.

• You can obfuscate your application to make it difficult to reverse-engineer.

• You can modify the licensing library itself to make it difficult to apply common cracking techniques.

• You can make your application tamper-resistant.

• You can offload license validation to a trusted server.

This can and should be done differently by each app developer. A guiding principle in the design of the licensing service is that attackers must be forced to crack each application individually, and unfortunately no client-side code can be made 100% secure. As a result, we depend on developers introducing additional complexity and heterogeneity into the license check code — something which requires human ingenuity and and a detailed knowledge of the application the license library is being integrated into.

Technique: Code Obfuscation

The first line of defense in your application should be code obfuscation. Code obfuscation will not protect against automated attacks, and it doesn’t alter the flow of your program. However, it does make it more difficult for attackers to write the initial attack for an application, by removing symbols that would quickly reveal the original structure of a compiled application. As such, we strongly recommend using code obfuscation in all LVL installations.

To understand what an obfuscator does, consider the build process for your application: Your application is compiled and converted into .dex files and packaged in an APK for distribution on devices. The bytecode contains references to the original code — packages, classes, methods, and fields all retain their original (human readable) names in the compiled code. Attackers use this information to help reverse-engineer your program, and ultimately disable the license check.

Obfuscators replace these names with short, machine generated alternatives. Rather than seeing a call to dontAllow(), an attacker would see a call to a(). This makes it more difficult to intuit the purpose of these functions without access to the original source code.

There are a number of commercial and open-source obfuscators available for Java that will work with Android. We have had good experience with ProGuard, but we encourage you to explore a range of obfuscators to find the solution that works best for you.

We will be publishing a separate article soon that provides detailed advice on working with ProGuard. Until then, please refer to the ProGuard documentation.

Technique: Modifying the license library

The second line of defense against attack from crackers is to modify the license verification library in such a way that it’s difficult for an attacker to modify the disassembled code and get a positive license check as result.

This actually provides protection against two different types of attack: it protects against attackers trying to crack your application, but it also prevents attacks designed to target other applications (or even the stock LVL distribution itself) from being easily ported over to your application. The goal should be to both increase the complexity of your application’s bytecode and make your application’s LVL implementation unique.

When modifying the license library, there are three areas that you will want to focus on:

• The core licensing library logic.

• The entry/exit points of the licensing library.

• How your application invokes the licensing library and handles the license response.

In the case of the core licensing library, you’ll primarily want to focus on two classes which comprise the core of the LVL logic: LicenseChecker and LicenseValidator.

Quite simply, your goal is to modify these two classes as much as possible, in any way possible, while still retaining the original function of the application. Here are some ideas to get you started, but you’re encouraged to be creative:

• Replace switch statements with if statements.

• Use XOR or hash functions to derive new values for any constants used and check for those instead.

• Remove unused code. For instance, if you’re sure you won’t need swappable policies, remove the Policy interface and implement the policy verification inline with the rest of LicenseValidator.

• Move the entirety of the LVL into your own application’s package.

• Spawn additional threads to handle different parts of license validation.

• Replace functions with inline code where possible.

For example, consider the following function from LicenseValidator:

public void verify(PublicKey publicKey, int responseCode, String signedData, String signature) {
    // ... Response validation code omitted for brevity ...
    switch (responseCode) {
        // In Java bytecode, LICENSED will be converted to the constant 0x0
        case LICENSED:
        case LICENSED_OLD_KEY:
            LicenseResponse limiterResponse = mDeviceLimiter.isDeviceAllowed(userId);
            handleResponse(limiterResponse, data);
            break;
        // NOT_LICENSED will be converted to the constant 0x1
        case NOT_LICENSED:
            handleResponse(LicenseResponse.NOT_LICENSED, data);
            break;
        // ... Extra response codes also removed for brevity ...
    }

In this example, an attacker might try to swap the code belonging to the LICENSED and NOT_LICENSED cases, so that an unlicensed user will be treated as licensed. The integer values for LICENSED (0x0) and NOT_LICENSED (0x1) will be known to an attacker by studying the LVL source, so even obfuscation makes it very easy to locate where this check is performed in your application’s bytecode.

To make this more difficult, consider the following modification:

public void verify(PublicKey publicKey, int responseCode, String signedData, String signature) {
       // ... Response validation code omitted for brevity …
        
        // Compute a derivative version of the response code
        // Ideally, this should be placed as far from the responseCode switch as possible,
        // to prevent attackers from noticing the call to the CRC32 library, which would be
        // a strong hint as to what we're done here. If you can add additional transformations
        // elsewhere in before this value is used, that's even better.
        java.util.zip.CRC32 crc32 = new java.util.zip.CRC32();
        crc32.update(responseCode);
        int transformedResponseCode = crc32.getValue();

        // ... put unrelated application code here ...
        // crc32(LICENSED) == 3523407757
        if (transformedResponse == 3523407757) {
            LicenseResponse limiterResponse = mDeviceLimiter.isDeviceAllowed(userId);
            handleResponse(limiterResponse, data);
        }
        // ... put unrelated application code here ...
        // crc32(LICENSED_OLD_KEY) == 1007455905
        if (transformedResponseCode == 1007455905) {
            LicenseResponse limiterResponse = mDeviceLimiter.isDeviceAllowed(userId);
            handleResponse(limiterResponse, data);
        }
        // ... put unrelated application code here ...
        // crc32(NOT_LICENSED) == 2768625435
        if (transformedResponseCode == 2768625435):
            userIsntLicensed();
        }
    }

In this example, we’ve added additional code to transform the license response code into a different value. We’ve also removed the switch block, allowing us to inject unrelated application code between the three license response checks. (Remember: The goal is to make your application’s LVL implementation unique. Do not copy the code above verbatim — come up with your own approach.)

For the entry/exit points, be aware that attackers may try to write a counterfeit version of the LVL that implements the same public interface, then try to swap out the relevant classes in your application. To prevent this, consider adding additional arguments to the LicenseChecker constructor, as well as allow() and dontAllow() in the LicenseCheckerCallback. For example, you could pass in a nonce (a unique value) to LicenseChecker that must also be present when calling allow().

Note: Renaming allow() and dontAllow() won’t make a difference, assuming that you’re using an obfuscator. The obfuscator will automatically rename these functions for you.

Be aware that attackers might try and attack the calls in your application to the LVL. For example, if you display a dialogue on license failure with an “Exit” button, consider what would happen if an attacker were to comment out the line of code that displayed that window. If the user never pushes the “Exit” button in the dialog (which is no not being displayed) will your application still terminate? To prevent this, consider invoking a different Activity to handle informing a user that their license is invalid, and immediately terminating the original Activity; add additional finish() statements to other parts of your code that get will get executed in case the original one gets disabled; or set a timer that will cause your application to be terminated after a timeout. It’s also a good idea to defer the license check until your application has been running a few minutes, since attackers will be expecting the license check to occur during your application’s launch.

Finally, be aware that certain methods cannot be obfuscated, even when using a tool such as ProGuard. As a key example, onCreate() cannot be renamed, since it needs to remain callable by the Android system. Avoid putting license check code in these methods, since attackers will be looking for the LVL there.

Technique: Make your application tamper-resistant

In order for an attacker to remove the LVL from your code, they have to modify your code. Unless done precisely, this can be detected by your code. There are a few approaches you can use here.

The most obvious mechanism is to use a lightweight hash function, such as CRC32, and build a hash of your application’s code. You can then compare this checksum with a known good value. You can find the path of your application’s files by calling context.GetApplicationInfo() — just be sure not to compute a checksum of the file that contains your checksum! (Consider storing this information on a third-party server.)

[In a late edit, we removed a suggestion that you use a check that relies on GetInstallerPackageName when our of our senior engineers pointed out that this is undocumented, unsupported, and only happens to work by accident. –Tim]

Also, you can check to see if your application is debuggable. If your application tries to keep itself from performing normally if the debug flag is set, it may be harder for an attacker to compromise:

boolean isDebuggable =  ( 0 != ( getApplcationInfo().flags &= ApplicationInfo.FLAG_DEBUGGABLE ) );

Technique: Offload license validation to a trusted server

If your application has an online component, a very powerful technique to prevent piracy is to send a copy of the license server response, contained inside the ResponseData class, along with its signature, to your online server. Your server can then verify that the user is licensed, and if not refuse to serve any online content.

Since the license response is cryptographically signed, your server can check to make sure that the license response hasn’t been tampered with by using the public RSA key stored in the Android Market publisher console.

When performing the server-side validation, you will want to check all of the following:

• That the response signature is valid.

• That the license service returned a LICENSED response.

• That the package name and version code match the correct application.

• That the license response has not expired (check the VT license response extra).

• You should also log the userId field to ensure that a cracked application isn’t replaying a license response from another licensed user. (This would be visible by an abnormally high number of license checks coming from a single userId.)

To see how to properly verify a license response, look at LicenseValidator.verify().

As long as the license check is entirely handled within server-code (and your server itself is secure), it’s worth nothing that even an expert cracker cannot circumvent this mechanism. This is because your server is a trusted computing environment.

Remember that any code running on a computer under the user’s control (including their Android device) is untrusted. If you choose to inform the user that the server-side license validation has failed, this must only be done in an advisory capacity. You must still make sure that your server refuses to serve any content to an unlicensed user.

Conclusion

In summary, remember that your goal as an application developer is to make your application’s LVL implementation unique, difficult to trace when decompiled, and resistant to any changes that might be introduced. Realize that this might involve modifying your code in ways that seem counter-intuitive from a traditional software engineering viewpoint, such as removing functions and hiding license check routines inside unrelated code.

For added protection, consider moving the license check to a trusted server, where attackers will be unable to modify the license check code. While it’s impossible to write 100% secure validation code on client devices, this is attainable on a machine under your control.

And above all else, be creative. You have the advantage in that you have access to a fully annotated copy of your source code — attackers will be working with uncommented bytecode. Use this to your advantage.

Remember that, assuming you’ve followed the guidelines here, attackers will need to crack each new version of your application. Add new features and release often, and consider modifying your LVL implementation with each release to create additional work for attackers.

And above all else, listen to your users and keep them happy. The best defense against piracy isn’t technical, it’s emotional.

Download Swype Pen Input by Nokia Beta Labs for Nokia 5800, N97 and X6

Nokia Beta Labs has released another useful application called Swype Pen Input for Symbian S60 5th edition based touch screen mobiles. Swype application provides a faster and easier way to input text on your mobile. With one continuous finger or stylus motion across the screen keyboard, the application enables users to input words faster and easier than other data input methods—at over 40 words per minute. There is a patented technology of Nokia behind this application.



Swype application is currently under development. The Beta release for Symbian includes support for English US, Spanish, Canadian French, and Brazilian Portuguese languages. The exciting features of this application are:

• Layout - Standard QWERTY keyboard layout makes Swype application very easy to learn.
• Stylus or finger Usage – Swype's amazing input path analyzer allows you to go fast and sloppy. Just make a reasonable effort to trace through the word and Swype will do the rest for you.
• Double Tap Editing – Make a mistake? Double tap on any word to bring up a list of other possible matches. sounds great?
• Auto-Spacing, Auto-Capitalization and Auto Spelling Correction.
• Automatic Help – Swype detects when you may be having trouble or might benefit from a particular feature and then prompts you with helpful tips and instructions.
• Provides instant access to Symbols, Numbers and Editing functions.
• 65,000-word Learning Dictionary – Most of the words you will type are already in the Swype dictionary. If it isn't there, just tap it out once followed by a space and Swype will remember it for future use. It means you can add the words to Swype dictionary.

The application works with Nokia 5800 XpressMusic, N97, N97 Mini, 5230, 5233, 5235 and 5530 XpressMusic. More information about this application is available from http://betalabs.nokia.com/apps/swype-for-symbian. You can also read FAQ and see the demo videos from http://betalabs.nokia.com/apps/swype-for-symbian/more_info. A direct link to download the .sisx file from Nokia Beta Labs  is - http://nds2.betalabs.nokia.com/Swype/Swype-S60-5thEd-1-0-10334-betalabs.sisx. Alternate download link is also available at the end of this post.


Related Posts:

• Download Game Miluegg Paratrooper for Nokia 5800, X6, N97, 5230 and 5530
• Download Application GreenCalc for Nokia 5800, X6, N97, 5235 and 5530
• Download Game Onion Tasty Dream for Nokia 5800, N97, X6, 5230 and 5530
• Download Game Travel Genius for Nokia 5800, N97, X6, 5233, 5230 and 5530

Download Application GreenCalc for Nokia 5800, X6, N97, 5235 and 5530

GreenCalc is a Java application for Symbian S60 5th touch screen mobile phones. The application can be used to calculate your energy, CO2 emissions. The application teaches you how to be environment friendly! With GreenCalc application, you can create several profiles for different buildings and manage different settings information.

You need to enter the followings to create a profile:

• Name of Profile: Define a name for your profile. Building:
• Define the building that you want to analyze.
• Description: You can optionally type in a short description of this profile.
• Color of Icon: You can choose the color of the bulb image that represents your profile.

After a profile is created, you need to add Bulbs and configure the settings of the current profile. To add a bulb, following information need to be input:

• Name of Bulb: Define the name of the bulb – usually the name of the room in which the bulb is used often or the brand name of the bulb.
• Amount: Define the amount of the exact same bulbs in your household/building.
• Watt: Type in the power of the bulb in Watt. This information can be found on the bulb itself.
• Uptime in Minutes: Estimate how many minutes this bulb is on per day.

Now you are ready to define energy costs and cost of materials in the configuration window. Now you can Calculate the money you can save. To calculate the savings you would make press the "Options" button and then the "Calculate" button in the profile view. After this a chart is displayed where you can see how much money you can save over many years. The X-axis display the years and the y-axis the money you save.

This application also provides a view which shows you how much CO2 emissions in Kg you are producing with your current bulbs for your defined time span and how much CO2 emissions you could avoid by using energy saving bulbs. A detailed manual with screenshots is available with this application.

The application works with Nokia 5800 XpressMusic, N97, N97 Mini, X6, 5230, 5233, 5235 and 5530 XpressMusic. The application version 1.0 is available to download.


Related Posts:

• Download Game Miluegg Paratrooper for Nokia 5800, X6, N97, 5230 and 5530
• Download Application Nuance T9 Nav for Nokia 5800, N97, X6 and 5530
• Download Game Onion Tasty Dream for Nokia 5800, N97, X6, 5230 and 5530
• Download Game Travel Genius for Nokia 5800, N97, X6, 5233, 5230 and 5530