From das.signal at freecalypso.org Thu Nov 2 10:13:21 2023 From: das.signal at freecalypso.org (Das Signal) Date: Thu, 2 Nov 2023 10:13:21 +0000 Subject: Powering GSM MS from USB In-Reply-To: <20231022234100.3AF2C374037B@freecalypso.org> References: <20231022234100.3AF2C374037B@freecalypso.org> Message-ID: <20231102101321.GB28182@freecalypso.org> Hi Mychaela, Although not an EE expert, I remember GSM phones from the late 90s had a big capacitor inside, probably because the batteries at the time were not capable of such high sure current. Then modern Li-ion started becoming popular and the need for such capacitor lessened afaik. In theory you could add such a capacitor between 5v and GND although it would technically not be authorized by the USB spec. But there should be no issue as long as there is protection to the USB port itself. But then again, I'm no expert on the suject ;-) --DS From falcon at freecalypso.org Wed Nov 22 00:20:10 2023 From: falcon at freecalypso.org (Mychaela Falconia) Date: Tue, 21 Nov 2023 16:20:10 -0800 Subject: New FC USB-serial tools Message-ID: <20231122002014.CE84B37402C7@freecalypso.org> Hello FreeCalypso community, I am pleased to announce a new addition to our software family: a suite of tools for working with USB-serial chips, currently FT2232x from FTDI and CP2102 from Silabs. The first official release is here: https://www.freecalypso.org/pub/GSM/FreeCalypso/fc-usbser-tools-r1.tar.bz2 https://www.freecalypso.org/pub/GSM/FreeCalypso/fc-usbser-tools-latest.tar.bz2 (symlink) I've been working with FT2232x chips (both FT2232C/D, recently discontinued, and FT2232H, still active) since 2017, and I've been programming their EEPROMs with my own tools since 2018. My FTDI EEPROM tools began life as not-fully-documented, my-own-use-only hack living in freecalypso-hwlab Hg repository, but eventually the tools grew to deserve their own source repository (fc-usbser-tools), thorough documentation up to FC quality standards, and formal releases. All FreeCalypso hw products with FT2232x chips include EEPROMs, and these EEPROMs are always programmed at FreeCalypso HQ (with these same tools) prior to shipment to customers - but of course hacker-users should always be empowered to modify their EEPROMs as needed, hence the tools need to be released and documented. Furthermore, there exist some FT2232x-containing hw products that are not made by FC, but which can benefit from EEPROM programming - the current case of most relevance is Lattice iCEstick FPGA board. Lattice factory ships these boards with blank EEPROMs, resulting in FT2232H chip taking its default VID:PID - but this ID is a poor choice for an FT2232x device that is wired for MPSSE+UART configuration. An alternative USB ID which Linux kernel recognizes as a JTAG quirk is much more convenient, and can be set with EEPROM programming; fc-usbser-tools package provides all needed tools and instructions. Besides FTDI chips, the new toolkit can also program the internal EEPROM of classic CP2102 chips, the ones which require EEPROM programming in order to switch between 230400/460800/921600 and 203125/406250/812500 baud rates. This chip is NRND, but Sysmocom still supply 2.5 mm headset jack serial cables with classic CP2102 inside, keeping this chip relevant - and these Sysmocom-made cables are very convenient, no complaints from me! The original instructions (from OsmocomBB wiki, using Python tools) for programming CP2102 baud rates are a royal pita: Python tools come with dependency hell (I once got them working under Slackware 13.37, but the move to Slackware 14.2 broke them), and the actual instructions are anything but user-friendly. However, with my new tools this baud rate programming is as simple as: cp2102-update-eeprom -b gsm or the other way: cp2102-update-eeprom -b std using only an FC-native, minimal dependency (libusb only) C language tool, with no Python and thus no dependency hell. :) Hasta la Victoria, Siempre, Mychaela aka The Mother From falcon at freecalypso.org Wed Nov 29 21:58:41 2023 From: falcon at freecalypso.org (Mychaela Falconia) Date: Wed, 29 Nov 2023 13:58:41 -0800 Subject: New phone discovery: Sony Ericsson J120 Message-ID: <20231129215849.AC86D374047E@freecalypso.org> 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 From axilirator at gmail.com Thu Nov 30 17:50:05 2023 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Fri, 1 Dec 2023 00:50:05 +0700 Subject: Sony Ericsson K200i with SAMSUNG flash Message-ID: <8415ae0e-92f1-4566-9668-5de88f538bb5@gmail.com> Hi Mychaela and community, I acquired another SE K200i and picked it up from the local post department today. It's the third K200i in my collection, and this new phone is a bit different from the two that I already have. Sharing the details here, just in case somebody else than me and Mychaela would find this interesting. Below is what makes this K200i special: * R1AA003 firmware, an older version than R1AA008, which we saw on these two K200 specimens I have. [*] * SAMSUNG K5L29xx_A flash (according to fc-loadtool), not SPANSION S71PL129, which we already saw. * The IMEI reported by the phone starts with the '35617701' prefix we saw, but the label behind the battery has a completely different IMEI with a different prefix '35871701'. [*] I also found R1AD001 on the internet, which appears to be even more recent version, but it's encrypted (binwalk shows entropy close to 0.9 across the whole file). SETool (paid version) should be able to decrypt and flash it, but I don't have a license for it. The only difference between R1AA003 and R1AA008 I could find so far is AMR codec support: the former does not list it in the hidden "Service" menu. We can compare further by looking at the MS Classmark bits. Here is some related output of fc-loadtool (-h fcfam): loadtool> flash info Configured for two flash banks of up to 8 MiB each Bank 0 base address: 03000000 Bank 1 base address: 01800000 loadtool> flash id Autodetecting flash chip type Basic device ID: 00EC 257E Samsung extended ID device, reading extended ID Extended ID: 2508 2501 Appears to be Samsung K5L29xx_A or compatible, checking CFI Confirmed Samsung K5L29xx_A or compatible loadtool> flash geom Detected flash device: Samsung K5L29xx_A Device has two banks, looking at bank 0 Bank 0 total size: 0x800000 Sectors in bank 0: 135 (2 regions) Region 0: 8 sectors of 0x2000 bytes Region 1: 127 sectors of 0x10000 bytes Command set style: AMD loadtool> flash2 geom Detected flash device: Samsung K5L29xx_A Device has two banks, looking at bank 1 Bank 1 total size: 0x800000 Sectors in bank 1: 135 (2 regions) Region 0: 127 sectors of 0x10000 bytes Region 1: 8 sectors of 0x2000 bytes Command set style: AMD Similarly to the ones with SPANSION flash, erasing the first flash bank fails (the bootloader/IMEI protection?): loadtool> flash erase 0x00 0x800000 Erasing 135 sector(s) erase timeout, aborting The flash dumps can be downloaded from here: https://people.osmocom.org/fixeria/dump/se_k200i/fw/K200i-R1AA003-CXC1250829-356177013769720-flash1.bin https://people.osmocom.org/fixeria/dump/se_k200i/fw/K200i-R1AA003-CXC1250829-356177013769720-flash2-clean.bin -- Best regards, Vadim.