New phone discovery: Sony Ericsson J120

Wed Nov 29 21:58:41 UTC 2023

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