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~ _______________________________________________ Community mailing list [email protected] https://www.freecalypso.org/mailman/listinfo/community
