Thanks for Support

[Mychaela Falconia]

Hi Ajay,

> I am also attaching one more firmware for Moto C123, this is also a 900 +
> 1800 MHz phone. The problem with this phone is that the osmocon application
> works fine when I try and load layer1.highram.bin with chainload, but when
> I try to load layer one or any other app using compalram.bin I am not able
> to load it.
>
> I do not have a flashdump with which the osmocon application works fine
> with compalram and so I cannot try and find out what the problem is. But I
> suspect that the bootloader/firmware version of this phone might also
> differ from what you have seen in the wild till now.
>
> The firmware of this Moto c123 can be found here : https://we.tl/rVLoGA9jQI

Wow, yet another example of an ultra-malicious C1xx boot code version
out in the wild!  The boot code version embedded in this fw version
(yes, different from anything we've seen before) has the following two
points of nastiness:

1. Mot/Compal have added a check to their serial code download mechanism
   intended to prevent the loading of any code other than theirs.  You
   know how in the "classic" Compal code download protocol there is a
   running XOR checksum of all bytes being computed as the bytes trickle
   down the wire, and the host needs to send the correct checksum at
   the end?  Here they've added an additional check: after each 1000
   (decimal) bytes have been received, the running XOR checksum at that
   point must equal a certain hard-coded value: EE after 1000 bytes,
   A2 after 2000 bytes, 3D after 3000 bytes, 5E after 4000 bytes and
   D6 after 5000 bytes.  But this check does not kick in if the
   downloaded code image is shorter than 1000 bytes; in common with
   the previous C11x/12x boot code versions, this one does NOT require
   a 1003 or 1004 signature, hence the "Compal stage" that needs to be
   loaded (both with our tools and with OsmocomBB's chain loading) is
   only 32 bytes - hence we successfully evade Mot/Compal's idiotic
   security check. :)

2. In order to have their idiotic security check kick in every 1000
   (decimal) bytes, they have to do an if ((count % 1000) == 0) check,
   i.e., they have to invoke the modulo operation.  Just like on many
   other processor architectures, modulo is not an elementary
   operation on the ARM7TDMI, hence C compilers typically implement
   the % operator by calling an internal library function.  In the
   case of TI's compiler, this function is called U$MOD.  And guess
   what: the malicious boot code in this C123 specimen calls U$MOD
   which resides in the main body of the firmware, well outside of the
   boot code sector!  What it means is that if you were to flash this
   boot code version into a phone, you are NOT "out of the woods" when
   the erase-program-boot operation finishes, and instead the bricking
   window extends until you program the corresponding full fw image as
   well - any interruption before then, and the phone would be
   unrecoverably bricked.

For DS and anyone else who knows ARM assembly and would like to see
all this code with their own eyes, look in this Hg repository:

https://bitbucket.org/falconian/freecalypso-reveng

In the compal subdirectory you will find several annotated disassembly
listings for different versions of C1xx boot code.  The function that
handles the serial download happens to be at 0xbac in all of the
versions seen so far, and here are the different versions:

c123-boot.disasm	Classic C11x/12x boot code, no maliciousness
			of any kind, no 1003/1004 signature check, no
			locking provisions.

c139-boot.disasm	Classic C139/140 version: checks for "1003",
			but no other maliciousness.

c118-newboot.disasm	Newer C11x/12x version, includes the 0x2060
			bra lock mechanism, but no 1003/1004 check.

c139-tfboot.disasm	Newer C139/140 version with both the 0x2060
			bra lock mechanism and the 1003/1004 check,
			originally found in Tracfones, then later in
			other specimen.

c123-newboot.disasm	The latest piece of fruit from Ajay's C123
			specimen.

For Ajay: I recommend that you leave your C123 intact for the time
being, i.e., don't reflash it with anything else yet.  When and if one
of the community projects produces a flash-worthy free functional
firmware offering for the C11x/12x subfamily, you'll be able to flash
it then with a completely safe procedure, but until then, you can use
your run-from-RAM (no flashing) OsmocomBB tools for air sniffing or
whatever you are playing with in the chain loading configuration, so I
recommend you stick with that.

Das Signal wrote:

> Although I have limited experience with osmocom-bb, I think you do have to
> use the chainload option to load the layer1. This is really due to a
> limitation in the bootloader, expecting 1003 or 1004 which imposes a
> limitation of the size of the code you can execute this way (below 16K).

What you are saying is only true for the C139/140 family, but not for
C11x/12x or C155/156.  Although I have played with OsmocomBB even less
than you have, I assume their non-chainloading ("straight Compal")
mode probably does work on the latter targets - unless the phone
happens to have an ultra-malicious bootloader like the one Ajay just
encountered.

> Regarding flashing, I have unfortunately myself bricked a C139 while using
> the osmocom-bb flashing tool (to the letter, I should add) as described in
> http://bb.osmocom.org/trac/wiki/flashing , and I known someone recently also
> bricked his, see
>
> http://lists.osmocom.org/pipermail/baseband-devel/2016-February/004953.html
>
> Which is the very same issue I got too. So be very careful when flashing the
> bootloader, so far in my experience Mychaela's erase-program-boot command
> has been very reliable, as it both uploads and verifies the bootloader before
> comitting any changes to flash in an single step.

Not so fast.  Just because the flashing mechanism I've implemented in
the form of the erase-program-boot command (and the associated code in
the loadagent back end) protects you against bricking caused by
flashing process interruption (serial cable losing connection, PC host
crashing, operator distraction etc) does NOT mean that it will protect
you from bricking by way of programming a bad version of the boot code
- it WON'T protect you against the latter.

In order to guard against bricking your phone when reflashing the boot
sector, you need to be careful not only with HOW you flash it (the
flash erase-program-boot command in loadtool is the only safe way),
but even more careful with WHAT you flash into that boot sector.

OsmocomBB's flashing instructions are causing damage to the community
by causing users to brick their phones not only because they are not
using a safe tool like our erase-program-boot, but also because of
their silly copyright worship.  Because of the latter, instead of
posting images of known-good Compal boot code versions and telling
users "please use this image" (like we do), they are telling users to
read out whatever boot code their phone came with, and then flash it
back in.  This is extremely bad advice, and it is a recipe for making
bricks out of phones.

To Osmocom and other non-FreeCalypso-loyalist people reading this:
just because your phone originally came with a certain version of the
boot code does NOT mean that it is safe to flash that unknown version
back into your phone alongside with your own code - it may not be!
Suppose your phone came with one of the newer boot code versions that
includes the 0x2060 bra check - if you were to flash this boot code
back into your phone without the corresponding main fw image at 0x2000
with 0xDDDDDDDD in the 0x2060 word - e.g., if you flash OsmocomBB's
code at 0x2000 instead, which doesn't have that 0xDDDDDDDD word - you
will make a brick out of your phone with 100% certainty, and it will
be absolutely unrecoverable.

Instead, if your objective is to flash your potentially-brickable C1xx
phone with something other than an official Mot/Compal complete fw
image, then you should NEVER use whatever random unknown boot code
version your phone came with, instead you should download some KNOWN
good boot code version from an FTP site.  But it would require
apostatizing yourself from the church of copyright worship...

Even if what you seek to flash *is* one of the complete official fw
images for your hw model, even then bricking-safe flashing can be very
tricky.  For example, if the official fw version you'd like to flash
includes the bootloader lock provision, you need to ensure that the
word at 0x2060 contains 0xDDDDDDDD (i.e., that the lock is not
activated), and patch it in with a hex editor if it doesn't - and then
do the full 0x10000 byte sector with erase-program-boot, rather than
just 0x2000 bytes.  If you try to flash a locked fw version into your
phone, or just a bootloader-by-itself if that bootloader version
includes the "bra lock" provison, you will make a brick if the
flashing process gets interrupted at any point before full completion,
as recovery with tfc139 works only when the phone has a complete and
fully working fw image in it, not a partially flashed one.

As another nasty example, consider the most recent C123 firmware
specimen Ajay just contributed.  Suppose Ajay were to reflash his
phone away from this nasty fw version, and put one of the earlier
(nicer) fw versions in his flash.  Then suppose he desired to flash it
back to this particular nasty version - or suppose someone else wanted
to try it out.  Well, there is NO bricking-safe way to program this
particular nasty fw version into a phone, because the boot code in
this version calls the U$MOD function that lives somewhere far in the
main fw portion of the image.  Thus erase-program-boot would succeed,
but if your flashing process then gets interrupted at some point prior
to getting the *complete* fw image flashed, the result would be a
brick: there would be no way to get back in to finish the flashing
process, as the boot code would call a function that isn't there and
crash instead of allowing your download code to run.

OK, enough rant for today...

M~