New Platform Security Tweaks Nokia’s Python for S60 Application Development

New Platform Security Tweaks Nokia’s Python for S60 Application Development

he new platform security features in S60 3rd Edition required several changes to the whole Python for S60 framework. Without these modifications, S60 3rd Edition can’t be supported by Python for S60. Find out how the new platform security features affect Python for S60, what your development options will be, and how to perform native extending.

This article will walk you through a stand-alone installation. In essence, this type of installation makes Python applications no different from any native Symbian applications?a user cannot tell whether the app is Python or C++, though it is visible in the device main menu. You’ll also use a script shell, visible in the device menu, that enables a user to run individual Python scripts.

Author’s Note: This article introduces Python for S60 on S60 3rd Edition. The process described is not applicable to Python for S60 running on either S60 1st or 2nd Editions and the developers using these platforms are not affected in any way.

About Python for S60 3rd Edition
The biggest change in S60 3rd Edition is that platform security is enforced in S60 3rd Edition devices. This means you must sign all your installed Symbian installation files (SISX files) in order to guarantee successful installation.

A fundamental concept in S60 3rd Edition platform security is ‘capability,’ which defines a running process’s functionality within the device. A capability is like a token?when a process sends requests across process boundaries to access a corresponding set of sensitive APIs to perform a function, the capability grants the permission. The purpose of the capability model is to ensure that only trusted applications are able to use certain APIs and system resources.

Since a standalone Python for S60 application is no different from a native application?and runs in a separate process?it needs to be signed if it uses controlled APIs or isdistributed via a SISX package.

What a Python standalone application is able to do will be limited by the capabilities assigned to the interpreter DLL (these capabilities are listed later in the section “Signing and Distribution”).

The DLL’s capability set is the maximum set for any Python application on S60 3rd Edition devices. For example, if the signed interpreter DLL does not possess a capability, say AllFiles, the Python application cannot have it either. You can, of course, sign the Python interpreter DLL for special purposes with larger capabilities sets, but that discussion is outside the scope of this article.

Because the Python application is seen from the device’s main menu, the script shell (which is also a Python application) needs to be signed. The script shell should not enable users to run scripts with large capabilities and thus, it is not signed by Nokia with the same capabilities as the interpreter DLL. This shouldn’t cause problems?lyou can sign the script shell application with a developer certificate. Click here to find out how to obtain a developer certificate. Due to separate signing needs for the interpreter DLL and the script shell application, there are two separate packages (‘X’ indicates version number):

  • PythonForS60-X_X_X_3rded.SIS: This package contains the interpreter DLL, all the Nokia-provided native Python extensions, and other needed files.
  • PythonScriptShell-X_X_X_3rded.SIS: This package contains only the script shell application and does not work without the above package.

Keep in mind that the script shell is just a normal application, similar to the one you wrap with py2sis (a tool for packaging Python scripts to SIS packages) and is subject to the all the same security preconditions listed earlier. The interpreter DLL is used by all the standalone Python applications and is the entity you need to sign with as many capabilities as you can get (for some capabilities, you’ll need to justify your business reasons to get approval from Nokia, as shown in the signing section). This assures you that your individual Python applications will be able to access the controlled resources as freely as possible. Remember: the maximum capability set of a Python application should not be beyond the capability set assigned to the interpreter DLL (this is due to platform security reasons).

Author’s Note: The script shell Python application visible in the device main menu has nothing to do with other standalone Python applications (i.e. there are no logical or conceptual dependencies).

Click here for an overview of the Symbian signed process and platform security.

Creating a Standalone App in S60 3rd Edition
Before you get started, remember that the installed SDK should compile the basic “helloworld” sample program.

  1. Install a working version of the S60 3rd Edition C++ SDK (tested with Windows only).
  2. Install a working version of Python, tested with Python 2.4.4.
  3. Download the Standard Python for S60 source distribution. It includes the py2sis (tested with pys60-1_3_15_src) tool that can be used to create standalone applications from your Python scripts. The packaged Python applications are no different from native applications to a devices user. Click here to obtain pys60-1_3_15.
  4. Unpack the Python for S60 source distribution in C:Symbian9.1S60_3rd_MR.
  5. Map the directoty to the V drive. Py2SIS also currently requires that the SDK configuration is subst’ed. The following path the maps to the drive:
    C:>subst V: C:Symbian9.1S60_3rd_MR 
  6. Invoke the following code ( is the script you are packaging):
    V:pys60-1_3_15_srcsrcpy2sis>C:Python24python --uid=0x01234567 --sdk30 --caps="NetworkServices LocalServices ReadUserData WriteUserData" –leavetemp
  7. Sign the created packages using SignSIS. Here’s an example invocation:
    V:pys60-1_3_15_srcsrcpy2sis> signsis ball.sis ball.sisx yourcert.cer yourkey.key password

    yourcert.cer and yourkey.key are the certificate and key used for signing the application. After issuing the above command, an output file ball.sisx (normally, the signed .sis file has the extension name .sisx although it does not really matter) is generated in the current directory, and it has been signed with your own certificate. ball.sisx is actually an installable file for the target devices. You can use a Bluetooth/Infra-red/Memory card to deploy it onto a real device.

Python Application Signing and Distribution
To execute the scripts on an S60 3rd Edition target device, you need to sign your applications before installing them on a real device. The latest platform security restrictions implemented in the target devices require this step.

Symbian recently made some big changes to the Symbian signed policy. These changes greatly affect the Symbian signed process and application deployment. Detailed information can be found here).

Figure 1. Flowchart: The relation between S60 Capabilities and Symbian signed..

As shown in Figure 1, the Symbian capability has been categorized into four groups:

  1. User capabilities: LocalServices, ReadUserData, WriteUserdata, NetworkServices, UserEnvironment.
  2. System capability set 1: SwEvent, ProtServ, TrustedUI, PowerMgmt, SurroundingDD, ReadDeviceData, WriteDeviceData
  3. System capability set 2: CommDD, DiskAdmin, MultimediaDD, NetworkControl
  4. Manufacturer capabilities: AllFiles, DRM, TCB, needs approval from manufacturer of mobile phones

Depending on the capabilities you use, there are now six ways to sign a Python application:

  1. User grantable: This means the compatibilities used in your application are granted at installation time and the application UID is in the unprotected range (0x80000000-0xFFFFFFFF). You may use the SignSis command to sign a .sis file.
  2. Open signed without publisher ID: This means users have to log into to upload your application’s .sis file. After successful uploading, you may immediately have the application signed by the web site and then download it. This is for testing purposes and you can only install your signed application onto one mobile device. When signing, you need to supply your email address together with the device IMEI (phone serial number) number.
  3. Open signed with publisher ID: This means you must purchase a publisher ID first from the TC TrustCenter. With the publisher ID, you may apply for a developer certificate from Using the certificate, you may sign a .sis file with SignSis command. This is for testing purposes and the certificate is limited by the number of IMEI contained in the certificate.
  4. Express signed: This means you must have a publisher ID first. Then, you login at and upload the necessary files there. You can then sign your application immediately and download it. The signed application is for commercial sales.
  5. Certified signed: You must have a publisher ID first. When an application has been fully tested using either the “Open signed” or self-signed method, you may send the application to one of the four named test houses in the world for detailed testing. After the application has passed the test criteria from Symbian, you can sign the application for commercial use.
  6. Symbian signed for Nokia: Any of the applications needed for pre-installation must pass Nokia test criteria. It has stricter criteria than “Certified signed.” Detailed information can be found at: This is for commercial use.

For more detailed information on Symbian signed, take a look at

The py2sis program allows you to package individual scripts to installable SISX packages. The packages generated by py2sis require you to install the PythonForS60-X_X_X_3rdEd.SIS in a real device.

The Python functions or modules affected by platform security are outlined below in Table 1:

Function or module 

Capabilities needed







contacts       appointments











Voice calls

Messaging (SMS, MMS) Internet services (access to services via HTTP)





Table 1. The Python Functions or Modules affected by New Platform Security.

Author’s Note: In Table 1:

  • * = This gives false data if the executable is not signed with the specific capabilities.
  • + = Claimed by the S60 SDK, but in practice self-signing is sufficient.

If you use the following extensions, no capabilities are needed. Self-signing is sufficient:

  • camera
  • e32db
  • inbox
  • audio
  • socket
  • graphics

If your application needs more capabilities, you needs to change the Python DLL capabilities and sign the SISX package to one that provides a certificate with enough signing meta-capabilities.

As you’ve seen, the 3rd Edition of Series S60 introduces new security features which have an impact on the way you’ll develop your applications and how it gets testes and deployed. Firstly, the script shell application has been separated from the main Python interpreter distribution and put in a new SISX file. These two SISX files can be signed each with a different set of capabilities. With Python for S60 in place on the S60 3rd Edition platform, you may now use the Python script language to quickly develop mobile applications.


About Our Editorial Process

At DevX, we’re dedicated to tech entrepreneurship. Our team closely follows industry shifts, new products, AI breakthroughs, technology trends, and funding announcements. Articles undergo thorough editing to ensure accuracy and clarity, reflecting DevX’s style and supporting entrepreneurs in the tech sphere.

See our full editorial policy.

About Our Journalist