Sunday, February 25, 2007

Creating Self-signed Symbian OS Certificates


This short note describes the steps required to create a self-signed certificate for signing Symbian OS packages.

Shortly, the steps are the following:

1. Creating the certificate
2. Converting the certificate
3. Installing the certificate
4. Signing the installation package

The rest of this note describes each of the steps in more detail. The discussion assumes that the 9210 SDK has been installed, and paths set up properly.
Creating the Certificate

The certificate and its corresponding private key can be created with the following command:

makekeys -cert -dname "CN=Your Name EM=email@address CO=XX" filename.key filename.cer

The items with emphasis should be replaced with your own values. The dname (distinguished name) parameter string can also contain other values, see the makekeys help for more information. makekeys will prompt you to enter a passphrase for the key, using one is highly recommended.

Important note: QuickEdit mode must be disabled from the shell window, otherwise random data gathering won't work.
Converting the Certificate

For some reason, makekeys creates certificate files that the 9210 certificate manager software cannot read. To work around this, the certificate must be converted to a suitable file format. This is possible using the built-in certificate management tools in Windows 2000 or XP. The following steps are needed:

1. Open the newly generated certificate file by double-clicking it in Explorer
2. Click "Install Certificate" and follow the instructions, using default settings
3. Open "Internet Options" from Control Panel, select the "Content" tab, and click on "Certificates...".
4. Locate the new certificate in the "Trusted Root Certification Authorities" tab. If you used non-default options when installing the certificate, it may be visible in one of the other tabs.
5. Select the new certificate and click "Export...". Follow the Certificate Export Wizard's instructions, and select "DER encoded binary X.509 (CER)" as the export format. Enter a new file name.

The resulting certificate from these steps can be installed on a 9210 communicator. Note that you should retain the original file too, since it can be useful with other SDK tools.
Installing the Certificate

Because the certificate is self-signed, the device will not trust it by default. To install the certificate on the device and set it trusted for software installation, follow these steps:

1. Transfer the file to the device normally, and save it to a known location.
2. Open the Certificate manager from the communicator's Control panel.
3. Select "Add" and choose the file. This installs the certificate.
4. Select the newly installed certificate from the list, select "View details", select "Trust settings" and enable "Software installation".

After this process the Communicator will accept installation packages signed using the new certificate.
Signing the Installation Packages

Finally, to make use of the new certificate, installation packages must be signed using the corresponding private key. This process is documented in the SDK, but, briefly, the steps are the following:

1. Copy the original key and certificate files created by makekeys to a known location. In this example, the files are assumed to be at c:\home\user\keys\filename.key and c:\home\user\keys\filename.cer.
2. Add the following line to the installation package file (project.pkg):


3. Create the installation package normally. If you set a passphrase for the key, makesis will prompt you for it.

Friday, February 23, 2007

DLL capability model in a Secure Platform.

With platform security, every DLL must have at least the same set of capabilities as the loading process, or otherwise the process is not allowed to load the DLL. For this reason most general-purpose DLLs would need (or close to) ALL -TCB as they cannot know in beforehand all the processes that can/will load them at some point in the future. Even if your DLL is set to have ALL -TCB capabilities, it does not mean that it is using all of them. A DLL (that has a higher capability set than the loading process) cannot leak capabilities to the process.

A DLL capability does not grant the DLL access to any capability-restricted resources (not even if the DLL has ALL -TCB). For that access you will need a process with ALL -TCB capablities. DLL capabilities only reflect a level of trust, so that the loading process can be sure that the DLL it is capable of loading has been tested to be trusted with the set of capabilities that the process has.

To get your DLL signed with these heavy capabilities:

For example, all MTM, FEP, and browser plug-ins require ALL -TCB. If you are developing such a component and require ALL -TCB capabilities, you need to fill in the Capability request form on the Symbian Signed Web site and send the form to
In the form you have to explain why each capability is requested and also give some company background information, for example, if you already have some co-operation with Nokia. This should be done before requesting the developer certificate.
When Nokia gets the capability request form, the case is evaluated with S60 platform. Manufacturer-approved capabilities are granted so that those DLLs that require sensitive capabilities are packaged to an embedded SIS file which is certified first, and the developer should use it in the delivery.

For more information about the process, see the "Testing and Signing with Symbian Platform Security" document at

Thursday, February 22, 2007

RSend Method to send SMS.
#include "rsendas.h"
#include "rsendasmessage.h"
LIBRARY sendas2.lib

Pros: No need to get Much more capability.
Cons: You can't manipulate msg entry in sms Msging entry. Only possible in MTM method.

void CSmsSendHandler::SendSmsInThirdEditionL(const TDesC& aAddr, const TDesC& aMsg)

RSendAs sendAs;

RSendAsMessage sendAsMessage;
sendAsMessage.CreateL(sendAs, KUidMsgTypeSMS);

// prepare the message
sendAsMessage.AddRecipientL(aAddr, RSendAsMessage::ESendAsRecipientTo);

// send the message

// sendAsMessage (already closed)

// sendAs


Wednesday, February 21, 2007

RSendAs : Send a file bluetooth

A number of people seem to have a problem using RSendAs to send a file via Bluetooth but its more or less the same as sending any other message.

To start, you need to get hold of the bluetooth MTM UID, its in "SendUiConsts.h"

Then its simply a case of:

1. Opening the SendAs session
2. Creating a message using the session
3. Adding the file as an attachment
4. Sending the message

void SendFileL(const TDesC& aFilename)
// 1. Open session
RSendAs session;

// 2. Create message
RSendAsMessage message;
message.CreateL(session, KSenduiMtmBtUid);

// 3. Add attachment
TRequestStatus status;
message.AddAttachment(aFilename.FullName(), status);

// 4. Send message
if (status.Int() == KErrNone)


Monday, February 19, 2007

Some Known Symbian Target Types.

The following target types are supported: [That are more or less know Known to me]

A window server animation DLL.

A GUI application. This is deprecated at v9.0. Applications must be converted to EXEs.

A system control. This is deprecated at v9.0. They must be converted to applications.

A DLL: either a shared library, or a polymorphic interface.

An ECOM implementation collection. This is deprecated at v9.0. The plugin target type should be used instead.

An Symbian OS executable that can be launched from the shell. This is an executable program which exports no functions undera multi-process platform and a DLL which is linked with the TIntWinsMain() function exported as ordinal 1 under a single-process platform.

An executable program.

An executable program for a multi-process platform, a DLL for a single-process platform.

An executable program with exports.

A plug-in file system.

Results solely in the generation of a .lib file. It is an error for a component of the IMPLIB type to contain SOURCE statements and the build tools enforce this.

[If you know any thing about this target please let me know]

[If you know any thing about this target please let me know]

[If you know any thing about this target please let me know]

A logical device driver.

A static library.

A media-server plug-in DLL (deprecated).

A MIME recognizer. This is deprecated at v9.0, and should be converted to PLUGIN (ECOM).

An extended notifier DLL. This is deprecated at v9.0, and should be converted to PLUGIN (ECOM).

An OPL extension.

A physical device driver.

A printer driver.

A recognizer. This is deprecated at v9.0, and should be converted to PLUGIN (ECOM).

[If you know any other target please let me know on my mail]

Thank you
stats counter