symbaali

Symbian installer hell

2009-10-15T02:51:00.000-07:00

New Y-Browser pkg file

2008-03-29T06:45:00.000-07:00

I just made minor updates to pkg file provided, as I noticed that the Y-Browser has been updated to use .mif instead of .mbm

The Y-Browser is available here: Y_Browser_088_0_3rdEd.SIS

And the updated pkg is here: ybrowser088.pkg

Remember that the .pkg file is not compatible with standard distribution of Y-Browser, so you need to uninstall it first.

Even if you are not a proud owner of a firmware modifiable device, you still might want to use Y-Browser for development aid.

If you have a legitimate AllFiles (and the less sensitive ones) capable developer certificate, you can modify Y-Browser (as explained before) and sign it with your own developer certificate. The result is a tremendous help in debugging installation etc. problems and modifying configuration files.

Joke of the week

2008-03-13T07:08:00.000-07:00

Here's a "nice" story about Symbian Signed from a fellow developer:

Our application has a disclaimer statement on first startup - required by the Symbian Signed, because we are sending SMS messages. First few rounds of Symbian Signed passed well, but now we FAILED:

The disclaimer statement is not shown again if the user kills application using taskmanager while the disclaimer statement is on screen.

We have implemented the disclaimer as a note which is shown when our configuration settings are not found. But, as we start application, the engine writes the missing settings file - so next time it won't get shown.

Now we have to create another file just to get this "problem" fixed! Total B.S! [Note to self - remember to add into backup]

And congrats for FCA00000 for his great platform security discoveries on TRK! TRK is one application that would never get signed by Symbian Signed, just try starting debug and (accidentally) disconnect the USB cable ;)

List of models

2007-11-04T04:58:00.000-08:00

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

2007-10-31T21:19:00.000-07:00

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...

yada yada in finnish

2007-10-31T11:59:00.000-07:00

Finnish computer magazine published a heavily Nokia biased article, so here's some comments in Finnish.

Lue artikkeli

Kun kännykkään on asennettu muunnettu firmware-ohjelmisto, sovellukset pääsevät kaikkiin puhelimen toimintoihin käsiksi, piraattiohjelmien asentaminen helpottuu ja haittaohjelmien riski kasvaa.

Tämähän on täyttä tuubaa, piratismin kanssa ei tällä ole mitään tekemistä ja haittaohjelmia tuskin tehdään siinä toiveessa että joku developer sen asentaisi. Ja edelleen, kaikki sovellukset eivät saa kaikkia oikeuksia, vain itse allekirjoitetut saavat mahdollisuuden lisäoikeuksiin. Kannattaa tosin ehkä hieman tutkia, mitä softia asentaa, mutta tämä ei nykytilannetta muuta.

Kun puhelimeen on asennettu hakkereiden murtama firmware-ohjelmisto, siihen voidaan asentaa tekijän allekirjoittamia (self-signed) sovelluksia ilman, että puhelin rajoittaa käyttöoikeuksia. Sovellukset pääsevät esimerkiksi soittamaan, lähettämään viestejä ja avaamaan nettiyhteyksiä vapaasti.

Tämähän ei muutu UserGrantableCapabilities-kenttää muuttamalla mihinkään, sovellukset ovat aiemminkin saaneet lähetellä viestejä, soitella ja availla yhteyksiä NetworkServices-capabilityllä. Ja tämän saa ilman mitään turboheksan modifiointia.

Ainiin, piti kertoa vielä miten vaikeata se modifiointi oli. ROM-imagesta löytyi strings-komennolla mielenkiintoisia tekstejä. Muistin, että noin 11-vuotiaana editoin PC-Toolsilla (sen aikainen heksaeditori) MS-DOS:sta suomenkielisen version. Samoilla taidoilla syntyi myös modifioinnit S60 firmwareen.

Nokia Software Updater fixes the security problems(?)

2007-10-29T06:08:00.000-07:00

Looks like Nokia is getting active: I got a new Nokia Software Updater which doesnt use the same folder anymore, now the image is in:


C:\Documents and Settings\All Users\Application Data\Nokia\Nokia Service Layer\A\nsl_service_module_00001\vpls\www.dsut.online.nokia.com.oti.caresuite\Products\ra-6\RA6p_072403.C01

And it downloads the updates everytime from their server. (More secure, they think?)

But guess what: you can still simply run the dd command after the C01 has downloaded, while it's downloading the other files. This is almost too easy!

And for the AlternativeCodeSigningOID, I recently noticed that it's for Nokia Content Signing, so you might want to keep that option there to be able to install TRK etc. Here's what I use currently as swipolicy.ini:


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
AllowOrphanedOverwrite = true
UserCapabilities = AllFiles DiskAdmin NetworkServices LocalServices ReadUserData WriteUserData ReadDeviceData WriteDeviceData UserEnvironment PowerMgmt MultimediaDD TrustedUI ProtServ NetworkControl SwEvent Location SurroundingsDD CommDD
AllowPackagePropagate = 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

And for dd command, I'm using dd (GNU fileutils) 3.16

Exact firmware version for hacked E90

2007-10-27T12:06:00.000-07:00

Here's the exact firmware details for the hack described earlier:

RA6_0545986_07.24.0.3_048

Type: RA-6
Model: E90-1
Product code: 545986

MD5 sums for the files:

da95e507b1785a33b8f6bb2597a6ffcc *RA6p_072403.C01.orig
899e730ce4a319f1b85de482b7c3c5c1 *RA6p_072403.C01.hack
c51394c667b5a75bb121cea25d2e0205 *RA6swipolicy.txt

Exploring S60 with AllFiles

2007-10-11T09:54:00.001-07:00

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!

2007-10-10T12:04:00.000-07:00

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

2007-10-03T01:26:00.000-07:00

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.

No more shouting Symbian emulator

2006-10-03T00:13:00.000-07:00

THE most annoying "feature" in Symbian emulator tools is their habit of setting Windows wave volume to the maximum. Typically this means that you are listening to MP3 with headphones as usual with decent volume, but when you launch the emulator, your head will blow apart and your ears start to bleed...

To prevent tinnitus being the leading work-related injury of the Symbian programmers, I created a simple Microsoft detours workaround. By disabling waveOutSetVolume API call, the stupid emulator has no means to mess with your volume settings. The actual magical DLL is here!

To use it, download Detours and compile library (using nmake in top directory)..

Now you can start the emulator using withdll (from samples):

c:\sdk\detours\bin\withdll.exe /d:ei_heliseva_symbaali.dll \Epoc32\release\winscw\udeb\epoc.exe

Or, for long time fix - after this the volume is gone forever:

c:\sdk\detours\bin\setdll.exe /d:ei_heliseva_symbaali.dll \Epoc32\release\winscw\udeb\epoc.exe

You could also add this to your own EXE application build cycle...

Enjoy the new, ear pleasuring Symbian!