List of models

Hello again,

It looks like there's a quick-fix from Nokia to prevent installer modification of E90 07.40.1.2 firmware. I guess it's no longer reading swipolicy.ini even though the file is there, but instead has hardcoded the capabilities somewhere - inside the exe perhaps? The image though is still modifiable, no real protection there.

And since Nokia says "most recent phones are not affected", I though I'd list a few models where I have somewhat reliable confirmation of successful modifications. If you have more results, please post comments with version numbers.

E50
E60
E61
E65
E90 (07.24.0.3, on 07.40.1.2 swipolicy not used?)
N71
N73
N76
N80

My own feeling about "devices affected" is that all the devices can be modified, but it's a bit difficult to prove it without the devices. Bricking the device is also easy, if you don't check the results of your modifications. And using pop-port, it's easy to brick even with standard updates =)

Statements, Motives & Impacts

Looks like we have official Nokia's statement about the firmware hacks - I suppose it doesn't get more official than this!

Nokia takes all security issues seriously. We are determined to be active in the development of security controls and preventive measures.

Nokia is aware that it may be possible to modify the software update package of a limited amount of device models. This type of intentional modification may make the mobile device inoperational. This issue has no impact to the user unless there's intention to do these modifications.

We have taken necessary steps to correct this issue, and it will be fixed in future releases. It's important to note that our latest device models are not impacted with this case.

(from gabor-toroks-forum-nokia-blog)

I don't know what are the latest models, and I guess it's limited - though so far it looks like almost all devices are modifiable in one way or the other.

As many of you have guessed, my focus is on other activities than "hacking" and I have no intentions to play game of cat and mouse with Nokia. My sole intention is to free myself (and the developers) from Nokia's control, as the capability restrictions are clearly placed for limiting the competition and to protect Nokia's own business.

And what ever your twisted press or Nokia tells you, the hacked firmware is not really a security exploit. It's not remotely exploitable and even locally, it practically requires you to code the program yourself. This is a new useful tool for Symbian developer's toolbox, opening new possibilities for the home based developers, working as subcontractors or looking for publisher.

Nokia's PR claims this hack opens door to piracy, viruses and malware. Not really. The "sensitive" capabilities give access mostly to phone's local features, like task management and multimedia features. The most dangerous capability (from phone bill point of view), NetworkServices, was already user grantable. In fact, using the described hack you could also remove that, making your phone more secure. Even if you intentionally make the hack, the software is still installed through same mechanism and user is notified of the possibly dangerous self-signed content.

Let me take an example about Nokia's protectionism: If you want to implement a new "Skype" type application, which uses Wi-Fi for audio transportation, you need to obtain MultimediaDD capability from Nokia. Without MultimediaDD capability, you cannot do full duplex audio, required for any sensible human conversation.

It's nice to present "open platform" to the press, but the reality is that Nokia is interested in any competition threats for it's current business, and by controlling the access to phone's APIs using capabilities, it can control who can develop and what kind of software.

In future, I'm concentrating on posting of developer related material enabled by this firmware hack - showing what you can do with those extra capabilities. I know there's other people working on the firmware front, but for me the only real issue is if *I* can take the control of the S60 device on my desk.

Stay tuned!

PS. Kids, remember to store your phone's ROM images after flashing, they might come handy someday...

Exploring S60 with AllFiles

Symbian Signed says they won't accept any file explorer tools with AllFiles capabilities. As a result of firmware modification, they really don't need to do that, we can self-sign those!

Here's couple of screenshots of Y-Browser running with AllFiles capability:





By default, Y-Browser comes with standard set of capabilities, so we need to add AllFiles capability to the set.

You'll need the fabulous sisinfo tool to unpack the sisx, elftran (from sdk) to modify executable headers and of course makesis and signsis to create new sisx.

Extract .sisx contents:

sisinfo.py -f Y_Browser_082_16_3rdEd.SISx -e .

Adjust capabilities:

elftran -capabilities NetworkServices+LocalServices+ReadUserData+WriteUserData+UserEnvironment+AllFiles sys\bin\YuccaBrowser.exe

Finally, run makesis, signsis - you know the drill for selfsigning. For makesis you need .pkg file, you I made a simplified version for you - ybrowser.pkg


makekeys -cert -password password -len 512 -dname "CN=symbaali OR=symbaali" key.key cer.cer 
makesis ybrowser.pkg ybrowser.sis
signsis ybrowser.sis ybrowser.sisx cer.cer key.key password


Goodbye S60 Platform Security, Hello CAPABILITIES!

Somebody asked about the .sisx file installation restrictions (aka Platform Security), so here's a similar solution for that. It's similar hack to midlet permissions, please see previous entry how to run updater first and where the image files stay.

The S60 image contains policy file, which enforces the capabilities and signatures when installing applications. Luckily, it allows defining the user granted permissions easily (it's all documented!). The actual offset of this SWIPOLICY.INI file varies, so this is not a complete solution (not taking account flash sector data, but you probably know better what you are doing)

At offset 28251550 of image, my phone's contents of the "SWIPOLICY.INI":

AllowUnsigned = false
MandatePolicies = false
MandateCodeSigningExtension = false
Oid = 1.2.3.4.5.6
Oid = 2.3.4.5.6.7
DRMEnabled = true
DRMIntent = 3
OcspMandatory = false
OcspEnabled = true
AllowGrantUserCapabilities = true
AllowOrphanedOverwrite = true
UserCapabilities = NetworkServices LocalServices ReadUserData WriteUserData UserEnvironment
AllowPackagePropagate = true
SISCompatibleIfNoTargetDevices = false
RunWaitTimeoutSeconds = 600
AllowRunOnInstallUninstall = false
DeletePreinstalledFilesOnUninstall = true
AlternativeCodeSigningOID = 1.3.6.1.4.1.94.1.49.1.2.2.1 1.3.6.1.4.1.94.1.49.1.2.2.5
PhoneTsyName = phonetsy


Note the UserCapabilities field. Now, in my phone this fragment is exactly 648 bytes in size, so we have exactly that much bytes to fit our new policy.

First, extract the original text using dd (the famous unix tool). Replace skip offset and count bytes with suitable values:

dd if=phonemodel.C01 of=some.txt skip=28251550 bs=1 count=648


Next, edit the capabilities you want into the file. If you run out of space, see for Symbian's documentation for defaults, you might want to remove some. For reference, here are my own modest capabilities for self-signed executables - I chose to remove AlternativeBullshitOID (I have no idea what it does):

AllowUnsigned = false
MandatePolicies = false
MandateCodeSigningExtension = false
Oid = 1.2.3.4.5.6
Oid = 2.3.4.5.6.7
OcspMandatory = false
OcspEnabled = true
AllowGrantUserCapabilities = true
UserCapabilities = AllFiles DiskAdmin NetworkServices LocalServices ReadUserData WriteUserData ReadDeviceData WriteDeviceData UserEnvironment PowerMgmt MultimediaDD TrustedUI ProtServ NetworkControl SwEvent Location SurroundingsDD CommDD
AllowPackagePropagate = true
SISCompatibleIfNoTargetDevices = false
RunWaitTimeoutSeconds = 600
DeletePreinstalledFilesOnUninstall = true
PhoneTsyName = phonetsy

(padded to 648 bytes using empty lines)

Verify that the result fits into 648 bytes (or whatever) and then insert it into the same spot in ROM image:

dd if=some.txt of=phonemodel.C01 seek=28251550 bs=1 count=648


Finally, update the phone. After that, you should be getting much more capabilities with self-signing, actually more than you get with "standard" developer certificates. This even saves some $$$, because you don't have to buy ACS Bullshit ID to get these more "sensitive" capabilities.

I have verified this hack by compiling an EXE with all above capabilities, installing it in a self-signed sisx and checking RThread::HasCapability() for those capabilities. And don't worry, WE ARE CERTIFIED!

Hacking S60 3rd edition firmware - Unlimited permissions for untrusted midlets

By default, Nokia S60 3rd Edition phones install midlets mostly with "oneshot" or "session" permissions, which force user to accept permission everytime a network connection is made or file is opened. If you don't have signing key (which costs $$$), you cannot even modify these permissions, because the phone only allows "ask everytime" option for e.g. file write.

So, here's the hacking alternative - proceed at your own risk. By replacing some strings, we can give equals permissions to untrusted applications with the manufacturer signed applications.

First, update your S60 phone normally using Software Update tool from Nokia. It downloads updates to your harddrive, storing binary images to

C:\Documents and Settings\All Users\Application Data\Nokia\Nokia Service Layer\A\nsl_service_module_00001\www.dsut.online.nokia.com.oti.caresuite\Products\<phonemodel>

Directory contents look interesting and for my phone there is about 50 MB rom image there. Simple strings scan on rom image shows contents some fragments of text based java permission file, which by closer look very interesting (at around 0x2310000 in my case):

# midp2_rp.xpf
# Copyright (c) 2004-2005 By Symbian Software Ltd. All rights reserved.
# This file defines one possible interpretation of the MIDP2 Security RP security policy,
# but with a JTWIr1 compliant policy for untrusted MIDlet suites

FormatVersion: 1.0

[...]

# MIDlets in untrusted MIDlet suites need user permission before doing anything
        DomainBindings: [UNTRUSTED]
                FunctionGroupBinding: "Application Auto Invocation"
                        Permission:             User
                        DefaultMode:    Session
                        MaximumMode:    Session
                EndFunctionGroupBinding
                FunctionGroupBinding: "Landmark"
                        Permission:             User
                        DefaultMode:    Session
                        MaximumMode:    Session
                EndFunctionGroupBinding
[...]

Now, all you need to do is to open up your favourite hex editor and write "MaximumMode: Blanket" to permissions you want to allow, and if you feel risky you can change the DefaultMode as well.

Now re-run the software update, force re-runing and phone will be flashed with your new permissions. After installing midlet, you should see more permission options in the application manager (select midlet, click open). If you try it, please post success with different phone models to comments.