Hello FreeCalypso community, We have another "new" phone discovery: Sony Ericsson J120 family. Like other SE phones of that era, the lowercase suffix after the number indicates GSM frequency bands: J120i is the version with 900+1800 MHz bands, and presumably there was also J120a with 850+1900 MHz bands - but just like with other SE phone models, the North American version is mostly unobtainium.
Vadim aka fixeria recently acquired a J120i phone and started examining it. The phone is Calypso-based and does have one UART (Calypso Modem UART) brought out on the FastPort connector, same as J100 and K200/220 phones. Similarly to K2x0 but unlike J100, the newly discovered J120 has Calypso boot ROM enabled, allowing entry with fc-loadtool. The flash chip appears (by ID code and CFI) to be Intel 28F320W18T (4 MiB), although the actual flash chip is most likely an MCP, not a discrete Intel 28F320W18T in a phone this late (2007 according to gsmarena). Intel 29F320W18T (along with most other members of Intel W18 family) was not previously supported by fc-loadtool, but there is now a series of new commits in freecalypso-tools Hg repository adding full support for this flash family. I will also be making a new point release of FC host tools soon, once I decide what else can be thrown in at the same time. Various notes and dumps from this phone can be found here, as curated by Vadim: https://people.osmocom.org/fixeria/dump/se_j120i/ Cursory examination of flash dumps tells me the following tidbits: * The designers of this phone chose the same path as most other TI-based phone manufs: they weren't content with keeping TI's firmware architecture as-is, instead they felt an irresistible urge to revamp it beyond recognition, and somehow convinced their managers to give them the necessary time allocation. * Flash address 0x3B000 appears to be the boundary where the static firmware image ends and writable flash sectors begin, exhibiting changes as user data writes happen in normal phone operation. * There is no TIFFS structure anywhere - hence whatever storage format is used, it is something different. * I did not spot any obvious flash location where write-once factory data like RF calibration records are stored. Perhaps they are mixed in with "dynamic" user data in the flash region beginning at 0x3B000, or perhaps they are stored somewhere else in a format that does not lend itself to easy visual recognition in a hex dump. And now it is time for a hair-raising "Easter egg" which I spotted in this Sony Ericsson J120 firmware. Starting at flash address 0x3372F4, we see the following gem: 003372F0: 5A 00 39 00 02 68 6F 03 61 73 73 03 63 75 6D 03 Z.9..ho.ass.cum. 00337300: 6E 6F 62 03 74 69 74 03 79 69 64 04 61 72 73 65 nob.tit.yid.arse 00337310: 04 63 6C 69 74 04 63 6F 63 6B 04 66 61 72 74 04 .clit.cock.fart. 00337320: 6D 6F 6E 67 04 6D 75 66 66 04 70 61 6B 69 04 70 mong.muff.paki.p 00337330: 72 61 74 04 70 75 66 66 04 73 68 61 74 04 74 61 rat.puff.shat.ta 00337340: 72 74 04 74 6F 73 73 05 66 72 65 61 6B 05 70 75 rt.toss.freak.pu 00337350: 73 73 79 07 70 65 72 76 65 72 74 00 6F 30 35 36 ssy.pervert.o056 00337360: 62 30 30 31 32 30 30 36 31 32 32 32 66 47 52 47 b00120061222fGRG 00337370: 64 32 35 38 30 00 00 00 00 00 00 C0 45 00 6E 00 d2580.......E.n. Needless to say, a collection of choice English words of this sort is NOT something we expect to see in a phone firmware image. From the location of this artifact, we know that it is part of the fw build image, not something from a phone user's personal data - it is located well before the 0x3B000 mark, and other nearby strings clearly relate to phone firmware functionality. More precisely, the swear block is immediately preceded by tables related to text entry via the numeric keypad, and immediately followed by the collection of text strings for phone UI. The first noteworthy point is that the swear block does not seem to be a random blob which some programmer simply stuck into a compilation unit as a protest against working conditions in a software sweatshop - the swear block has structure to it, indicating that at one point in time these naughty strings were once associated with some code that did something functional with them. Notice the following details: * Each swear string is preceded by a byte giving the number of characters in the string; * The overall sort order is by string length, from shortest of 2 chars to longest of 7 chars, and within each length group, same-length swear strings are sorted alphabetically. In my previous communications with Vadim, I made the conjecture that perhaps we are looking at a "functional Easter egg" whereby a SIM-locked phone can be unlocked with swearwords. I made this guess because the swear block is immediately followed by the collection of UI strings, and the first strings in that collection happen to be those dealing with SIM lock functionality. (In the boot order of a standard phone, those strings will be the first to appear in the UI in the case of a locked phone - some plausible explanation for those strings being first in the collection.) However, I now have to revise that hypothesis - my current working hypothesis is that the swear block is, after all, fully defunct code, totally dead. My rationale: the portion of the firmware we are looking at here is clearly the .const section, equivalent of .rodata in more standard toolchains. In order for a datum in the .const section to be active in any way, used for anything, its absolute address has to appear as an aligned 32-bit word somewhere in the fw image, be it in a literal pool in a code section or a part of some other const or initialized data item. However, searching the hex dump for "F4 72 33 00" (that's how 32-bit word 0x3372F4 will appear in LE byte order in a hex dump) yields no hits - hence the datum appears to be dead indeed, included in an object that went into the link, but not referenced from anywhere. Given that the swear block appears directly after some tables dealing with text entry via the numeric keypad, I wonder if the perhaps the table of swearwords was once written as some kind of prototype test code for a dictionary-based "predictive" text entry method - then later a "real" (more official) dictionary was implemented, but the naughty test table was never removed from the code, turning into a foul-taste Easter egg for reverse engineers looking at hex dump images decades later... Anyways, this is all from me for now - I assume Vadim will probably post more info about this newly discovered phone later. Hasta la Victoria, Siempre, Mychaela aka The Mother _______________________________________________ Community mailing list Community@freecalypso.org https://www.freecalypso.org/mailman/listinfo/community