# HG changeset patch # User Mychaela Falconia # Date 1449945656 0 # Node ID 0654212e5c5305cb25c847b43277bdfabf254005 # Parent 7a55a3eb985ae2114a915bd3d13678601d8e8d9d doc/Compal-unlock: documented safe flashing of newer fw versions and cisversion unlocking diff -r 7a55a3eb985a -r 0654212e5c53 doc/Compal-unlock --- 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 ====================