Self signed JARs on Nokia S40
DISCLAIMER: It seems to be possible to brick the phone when messing with the system certificate store. When only dealing with the user certificate store, as described here, this should not cause any problems. I AM IN NO WAY RESPONSIBLE FOR DAMAGES OF ANY KIND!Important Update
The information on this page is rather outdated. Now, various other sources provide more information than it is provided here:
Introduction
Unfortunately, Nokia's security model on S40 phones is extremely annoying. It is not possible to disable the nag screen for file access or to use certain multimedia features if a JAR file is unsigned. It is rather unlikely that this behavior has anything to do with "security" at all, rather than the possibility to earn money by selling expensive certificates.
Thanks to some Russian guy who calls himself "exp" it is now possible to install self signed JAR files on Nokia S40 3rd edition phones. Since the original publication includes pirated software, I'm not going to link to it (it should be easy to find with Google, however). Instead I'm going to present a 100% legal solution here, but all credits go to him!
What I write here has a rather big drawback: It only works with the so called "darkman" certificate, because I could not gain enough knowledge about the ext_info.sys file format which controls the capability of certificates on Nokia S40 phones. Since the private key of the "darkman" certificate is publicly known, it might not very "secure" to install this on your phone (however, I don't think it is extremely dangerous). More elaborations on ways to improve the situation are in the last paragraph.
What you need
You need to download the following things:- user.zip certificate to upload to phone
- key.ks private key for signing
- Sun Wireless Toolkit includes signing tool
- Gammu to access the phone's file system
Installing the certificate
- Install and configure Gammu. Check installation with
This should return the file ext_info.sys. Drive letters may vary. If above doesn't work, check the drive withgammu getfolderlisting d:/predefhiddenfolder/certificates/user
gammu getrootfolders
- Unzip user.zip
- Delete old certificate permissions database
gammu deletefiles d:/predefhiddenfolder/certificates/user/ext_info.sys
- Upload new certificate and permissions database from user.zip
gammu addfile d:/predefhiddenfolder/certificates/user exp.cer gammu addfile d:/predefhiddenfolder/certificates/user ext_info.sys
Signing a midlet
The signature is actually being stored in the JAD file. The exact permissions also have to be specified there. The most interesting ones are file access and audio/camera access. For these the following line has to be added to the JAD file (one line):
MIDlet-Permissions: javax.microedition.io.Connector.file.write, javax.microedition.io.Connector.file.read, javax.microedition.io.Connector.bluetooth.client, javax.microedition.media.control.RecordControl, javax.microedition.media.control.VideoControl.getSnapshot
First add the certificate to the JAD file (this assumes that the JadTool.jar from the Wireless Toolkit and the keys.ks file are both in the current directory. If not, please adjust the paths appropriately):
java -jar JadTool.jar -addcert -alias exp -storepass 14111989 -keystore key.ks -inputjad midlet.jad -outputjad midlet.jad
Then add the signature to the JAD file:
java -jar JadTool.jar -addjarsig -alias exp -storepass 14111989 -keystore key.ks -inputjad midlet.jad -outputjad midlet.jad -jarfile midlet.jar -keypass 14111989
It might be a good idea to choose a different name for the -outputjad parameter while testing, because any error occurring will output an empty file (and this deletes the original file if it is the same).
Note that you will still have to actually enable file access in the program permission on your phone. Doing all of the above only means that the corresponding menu entry will not be grayed out anymore.
Pitfalls
Debugging problems is extremely difficult, since the only error message you are ever going to get from the phone, no matter what actually happens, is: "Invalid program. Delete?". So be prepared that this will cost you a lot of nerves!
If you have followed all the above steps correctly, a typical problem is conflicting permissions in the MANIFEST.MF inside the JAR file. The easiest way to resolve this is:
- Unzip the JAR file (it is a regular ZIP file after all).
- Edit META-INF/MANIFEST.MF and delete all entries concerning permissions.
- Re-ZIP the JAR file and do not forget to adjust the MIDlet-Jar-Size parameter in the JAD file to reflect the new size(!).
Improvements
It would be nice to be able to use a self signed certificate of your choice. For this one needs to know the file format of the ext_info.sys file which controls for which purposes a certificate can be used (of course, we want code signing!).
For comparison you can see the working ext_info.sys (top) and the version which is automatically created by the phone (bottom), which does not allow for code signing. I found out the following things (there is one record per certificate):
- The first byte is the length of the record.
- The following 11 bytes seem to be identical for all pre installed certificates.
- The first 20 bytes in blue are the MD5 fingerprint of the key.
- The bytes in green are the null terminated file name with the length stored in the first byte.
- The bytes in yellow are the permissions with the first byte being the length.
- The record length is always divisible by four.
Unfortunately, this knowledge is not enough to create a working ext_info.sys file for an arbitrary certificate. If someone knows more than this, I would be glad about any hints ...