Some brief ideas and experiences with mobile themes/skins and their file formats, namely: Nokia Series 40 Theme NTH (1.0 and 2.1), Nokia Series 60 Theme SIS (2.6, 2.8 and 3.0), Sony-Ericsson Theme THM and Sony-Ericsson Theme UTZ. I enjoyed playing with those formats and implementing a parser/validator/extractor. It especially was a nice experience because these file-formats are mostly straight forward -> designed by people that know their job.
Nokia NTHThe first theme I started playing with, was Nokia's Series40 Theme format (.nth). The tool for creating them is called "S40 Theme Studio", it is available through Nokia's developer forum and it is the worst piece of Java I ever had on my desktop. It is buggy, nightmarish slow and not intuitive at all. Well, but still i managed to create a few test themes for finding more details about that format.
NTH-files are ZIP-archives. The non-binary attributes of the theme is described in "theme_descriptor.xml". That descriptor has been revised only once; Version 1.0 and Version 2.1 have been released so far. Those themes run on a number of Nokia's Series 40 handsets starting from the 2nd edition.
Sony-Ericsson THMThe Sony-Ericsson "Themes Creator" in contrast to Nokia's, does function perfectly fine, is very intuitive and stable. They have one tool to cover them all, so this baby actually produces two formats; THM and UTZ. First I looked at Sony-Ericsson's THM format. Most of the SE phones are "speaking" this format.
To my surprise, that format was pretty straight forward and really easy to parse. A THM-file actually is an uncompressed tar-file in the extended ustar-variant (http://en.wikipedia.org/wiki/Tgz). One little quirk is the way they encode the targeted device; it is shown as the "owner-user ID" of that tar-content (see TAR file-header on wickipedia). The first file within that tar-archive is always a file called "Theme.xml". That XML file, as usual, contains all non-binary theme data. Pictures are stored in common formats like PNG or JPEG.
"Theme.xml" has gone through seven public evolution steps, while remaining downward compatible (at least by that file's structure).
Version 1.0: T68i, T300, T310, T230, T290
Version 2.0: T610, T630, Z600, J210, Z300, J220, J230
Version 3.0: Z1010, K700, S700, K500, Z500, K300, J300
Version 3.1: V800, Z800
Version 3.2: V800 Organic, Z800 Organic
Version 4.0: K750, W800, W700, K600, Z520, Z525
Version 4.5: K610, K800, K790, W850, Z710, W710
Sony-Ericsson UTZThe second format I received from Sony-Ericsson's "Theme Creator" was UTZ. UTZ-files are actually ZIP-archives. The first encoded file again is called "Theme.xml" and it defines all non binary attributes as well as linking binary data like JPEG-wallpapers and ringtones. Within the main-comment section of the ZIP file, Sony-Ericsson encodes the targeted device. Once again a bit quirky for my taste.
Handsets that are listed to be compatible with the UTZ-format are: P900, P910, M600, W950, P990, M600, W950.
EPOC SISThis one turned out to be the toughest. For their Series 60 handset, Nokia uses the EPOC/Symbian installer packages (.sis). The tool for creating those themes is called "Series 60 Theme Studio" and it competes very well with the Series 40 tool mentioned above for a price called "worst software ever released". And I thought only the asians cant code...
The SIS format has never been publicly documented, but there are some official tools for creating and even unpacking them manually (makesis and unsis). Those tools, written in perl, are already a great source for information on the file structure. The most valuable source however is the "SIS File Format" page http://homepage.ntlworld.com/thouky/software/psifs/sis.html created and maintained by Alexander Thoukydides. A super nice fellow, by the way - I had a question and he responded nice and quickly.
Packed with the knowledge found within the perl-tools and on Alexander's page, it became very easy to write a complete parser/deompressor for SIS-files.
Within those SIS-files, Nokia's S60 themes contain the theme descriptor "THEMENAME.skn". This time, no plain XML is used. I decided not to attempt to parse the SKN-files as their existence was all I needed to know.
Nokia currently supports three different versions of those S60 Themes; 2.6, 2.8 and 3.0. The difference between 2.6 and 2.8 is the enhanced demands / enforced preconditions of the theme packages. Those demands or requisites are encoded using so called UID's. Unique Identifiers for products and platforms. Version 2.6 demands only UID 0x101F8582 (series 60 skinning support) whereas 2.8 also needs UID 0x10207113 (series 60 scalable skinning support).When using the format version 3.0, Nokia suddenly goes a totally different way; The SIS package has to be signed.
Signed SIS packages seem to have undergone another evolutionary step. These SIS files do not show the standard UID's in the header and don’t have any visible text-data when inspected with a hex-editor. Alexander's page does currently not cover those files. No SIS-tool that I have tried does support that format variant (unsis, unmakesis, viewsis, sistool, pdunsis). Most of those tools simply crash, some say "unsupported format".
I will call those Compressed Header SIS files or shortly chSIS.
Well, I didn’t find much but I sure want to share that with you.
chSIS Prefix Header:
| 00000000h: | 4 byte | UID | 0x10201A7A |
| 00000004h: | 4 byte | | 0x00000000 |
| 00000008h: | 4 byte | | 0xA00000EB |
| 0000000Ch: | 4 byte | | 0x2D360762 |
| 00000010h: | 4 byte | | 0x0000000C |
| 00000014h: | 2 byte | | 0x000C |
| 00000016h: | 2 byte | | ? |
| 00000018h: | 4 byte | | 0x00000022 |
| 0000001Ch: | 4 byte | | 0x00000002 |
| 00000020h: | 4 byte | | ? |
| 00000024h: | 4 byte | | 0x00000023 |
| 00000028h: | 4 byte | | 0x00000002 |
| 0000002Ch: | 4 byte | | ? |
| 00000030h: | 4 byte | | 0x00000003 |
| 00000034h: | 4 byte | | compressed header size: n |
| 00000038h: | 4 byte | | 0x00000001 |
| 0000003Ch: | 4 byte | | uncompressed header size |
| 00000040h: | 4 byte | | 0x00000000 |
| 00000044h: | n byte | | compressed main header data |
| [...] |
| more compressed data records prefixed by short uncompressed headers. |
It appears that after that first block of compressed data (44h + n) more blocks with similar structures are concatenated. The compression used is compatible with zLib http://www.zlib.net. The compressed header data is not encoded like the usual, uncompressed SIS data records. Here comes a little example of such header after decompression.
Uncompressed main header example:
00000000h: 0D 00 00 00 D0 09 00 00 0E 00 00 00 AE 00 00 00 ; ....Ð.......®...
00000010h: 09 00 00 00 04 00 00 00 EB 00 00 A0 01 00 00 00 ; ........ë.. ....
00000020h: 1C 00 00 00 55 00 6E 00 6B 00 6E 00 6F 00 77 00 ; ....U.n.k.n.o.w.
00000030h: 6E 00 20 00 56 00 65 00 6E 00 64 00 6F 00 72 00 ; n. .V.e.n.d.o.r.
00000040h: 02 00 00 00 1C 00 00 00 01 00 00 00 14 00 00 00 ; ................
00000050h: 44 00 69 00 67 00 69 00 74 00 69 00 6C 00 65 00 ; D.i.g.i.t.i.l.e.
00000060h: 73 00 32 00 02 00 00 00 1C 00 00 00 01 00 00 00 ; s.2.............
[...]
My first guesses and observations within that formerly compressed main header:
00000000h: 4 byte 0x0000000D
00000004h: 4 byte header size
00000008h: 4 byte 0x0000000E
0000000Ch: 4 byte ? (0xA6, 0xA3, ...)
00000010h: 4 byte 0x00000009
00000014h: 4 byte 0x00000004
00000018h: 4 byte 0xA00000EB
---
0000001Ch: 4 byte 0x00000001 = text data following
00000020h: 4 byte vendor name size: n
00000024h: n byte vendor name data
---
00000024h+n: 4 byte 0x00000002
00000028h+n: 4 byte record size: rm
0000002Ch+n: 4 byte 0x00000001 = text data following
00000030h+n: 4 byte component name size: m
00000034h+n: m byte component name data
rm-m byte padding 0x00
---
00000034h+n+rm: 4 byte 0x00000002
00000038h+n+rm: 4 byte record size ro
0000003Ch+n+rm: 4 byte 0x00000001 = text data following
00000040h+n+rm: 4 byte "Vendor-EN"-size: o
00000044h+n+rm: o byte "Vendor-EN"-data
ro-o byte padding 0x00
---
I stopped guessing at this point.
[...]
The way data is organized here and in some other locations make those compressed headers appear to be organized as WBXML data.
That is it, I did not drill any deeper as the demand simply isn’t there.