changeset 988:0654212e5c53

doc/Compal-unlock: documented safe flashing of newer fw versions and cisversion unlocking
author Mychaela Falconia <falcon@ivan.Harhan.ORG>
date Sat, 12 Dec 2015 18:40:56 +0000
parents 7a55a3eb985a
children 0b7abc72e49e
files doc/Compal-unlock
diffstat 1 files changed, 70 insertions(+), 8 deletions(-) [+]
line wrap: on
line diff
--- a/doc/Compal-unlock	Sat Dec 12 08:24:08 2015 +0000
+++ b/doc/Compal-unlock	Sat Dec 12 18:40:56 2015 +0000
@@ -288,14 +288,76 @@
 erase and program operations appropriately for the flash configuration in your
 phone.
 
-One last word of caution: if you are going to flash some fw version other than
-the unlocked North American C139 one discussed above, please check to see what
-boot code version it includes, and whether or not that version has the
-malfeature of checking the flash word at 0x2060 for the serial access control
-flag.  If the fw version you are seeking to play with has boot code with that
-malfeature present, the bricking vulnerability window extends until you not
-only program the new boot code into flash, but also program 0xDDDDDDDD into
-that 0x2060 word.  You've been warned.
+Flashing newer firmware versions
+================================
+
+The flashing procedure given above, where the first 0x2000 bytes of the new fw
+image (the bootloader part) are written with the flash erase-program-boot
+command and the regular flash program-bin command writes everything from 0x2000
+onward, is only correct for older firmware versions whose bootloader portion is
+completely free from the access locking malfeature: not only unlocked, but with
+no provision for locking at all.  In these older fw versions the boot code is
+fully contained in the first 0x2000 bytes and nothing from 0x2000 onward affects
+the ability to perform a new serial boot, hence the bricking vulnerability
+window ends at 0x2000.  However, this flashing procedure should NOT be used for
+newer fw versions that have the provision for locking the bootloader - it's the
+provision that matters in this case, even if the lock hasn't been activated -
+if you flash one of these newer fw versions as above, you will risk bricking
+your phone!
+
+If you need to flash one of the newer fw versions that includes the bootloader
+lock provision, you need to take some additional precautionary steps:
+
+1. Examine the fw image you wish to flash with a hex dump viewer.  Look starting
+   at offset 0x2000.  You should see 3 identifying ASCII strings: one right at
+   0x2000, another at 0x2020 and one more at 0x2040.  Then look at 4 bytes at
+   offset 0x2060.  If they contain 0xFFFFFFFF (blank flash) like the surrounding
+   unused bytes, then you have an older fw version without the bootloader lock
+   provision - you can safely flash it as in the previous section.  If it's a
+   newer fw version with the bootloader lock provision, the word at 0x2060 will
+   contain either 0x00000000 or 0xDDDDDDDD, corresponding to the activated
+   (access disabled) and non-activated (access enabled) states of the lock,
+   respectively.
+
+2. If the fw image you wish to flash has 0x00000000 at 0x2060, you must patch
+   it to 0xDDDDDDDD with a hex editor before flashing.  Just because our tfc139
+   utility can recover phones with maliciously locked bootloaders does NOT mean
+   that you should *ever* deliberately flash such a bootloader-locked fw image
+   into your phone!  Recovery of locked phones via tfc139 depends on the
+   complete fw image being present and working, not just the bootloader part,
+   hence if you were to flash an image that has a lockable bootloader with the
+   lock activated, the bricking vulnerability window will extend until the
+   *entire* fw image has been programmed - far too dangerous.
+
+3. When flashing the image with fc-loadtool, use a slightly different command
+   sequence compared to the previous section:
+
+   flash erase-program-boot new-fw-image.bin 10000
+   flash erase 10000 360000
+   flash program-bin 10000 new-fw-image.bin 10000 360000
+
+The difference is that the boundary between the part handled with flash
+erase-program-boot and the part handled with flash program-bin has been moved
+from 0x2000 to 0x10000.  Because the word at 0x2060 is part of the bricking
+vulnerability window with these newer fw versions, one should rewrite the
+entire boot sector of the flash (including the beginning of the main fw image)
+with flash erase-program-boot for safety.
+
+Unlocking while keeping the same fw version
+===========================================
+
+Suppose you have a phone with a locked bootloader such that you had to break in
+with tfc139, you would like to unlock it so you can use RAM-based (non-flash)
+tools such as c139explore or OsmocomBB with it, but you have no particular need
+to change the main fw from the original version to a different one.  If you
+need to perform such a cisversion unlock, you can do it as follows:
+
+1. Break in with tfc139;
+2. Use fc-loadtool's flash dump2bin command to save the first 64 KiB sector
+   of the flash to a file;
+3. Using a hex editor, patch the word at 0x2060 from 0x00000000 to 0xDDDDDDDD;
+4. Use fc-loadtool's flash erase-program-boot command to flash the patched
+   (unlocked) boot sector back into the phone.
 
 C155/156 differences
 ====================