diff compal/c139-boot.notes @ 105:49c7cda96f04

C139 boot ROM fully cracked
author Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
date Mon, 31 Mar 2014 05:51:57 +0000
parents
children
line wrap: on
line diff
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/compal/c139-boot.notes	Mon Mar 31 05:51:57 2014 +0000
@@ -0,0 +1,49 @@
+Download protocol, attempted first at 406250 baud, then 115200, only on the
+MODEM UART:
+
+The boot code begins by transmitting 1B F6 02 00 41 01 40, then calls the
+Rx-with-timeout function 7 times, expecting this seq: 1B F6 02 00 52 01 53.
+Getting anything else or timeout causes the 0xbac function to return,
+ending that download attempt.  If this seq was received, the boot code then
+sends 1B F6 02 00 41 02 43 and expects to receive 3 bytes as follows:
+
+* one dummy byte (stored into an automatic var, but then not used)
+* payload length MSB
+* payload length LSB
+
+The boot code then expects to receive the specified # of bytes [0,65535]
+and stores them beginning at 0x800100.  Then the Rx-with-timeout function
+is called again to receive the XOR checksum byte, not counted in the length.
+If the checksum fails to match, 0xbac function sends 1B F6 02 00 45 53 16
+and returns.  If this check passes, the "1003" check is performed next:
+the 4 bytes starting at 0x803ce0 must match.  If the downloaded image was
+shorter, the comparison will be made against pre-powerup IRAM content,
+i.e., law of chance.  Furthermore, the comparison is actually an inequality:
+each "signature" byte in the downloaded image needs to be >= (in the signed
+sense) than the "1003" reference.  (0x7F7F7F7F thus ought to be a passing
+value.)
+
+If this last check passes, the 0xbac function jumps to the downloaded image
+instead of returning.  Control is transferred to 0x800100 in the ARM state.
+If the "1003" check fails, 0xbac function sends 1B F6 02 00 41 03 57
+and returns.
+
+If the boot process is not diverted to a successful serial download as above,
+the boot code does one strange thing before it jumps to 0x20f8 (main app entry
+point).  The boot code unconditionally transmits "ftmtool" on the MODEM UART
+and waits a certain time for a "yes" response.  If it receives that "yes",
+it responds with "modemerror", otherwise just "error".  Either way, it then
+proceed to jump to the main app entry point at 0x20f8!  There is also a bunch
+of "dead" code in the 8 KiB "boot block", code which does not seem to be
+reachable from any path.  There is no check for whether or not the "main app"
+is present; if the flash contains the 8 KiB "boot block" followed by blank
+space, the boot code will happily jumps to those FFs - but it will still
+provide an opportunity for serial download as usual, so no real problem.
+
+IRAM variables used by the boot code:
+
+83FF00	holds UART base addr, set to FFFF5800 (MODEM)
+83FF08	32-bit var init to 0
+83FF10	32-bit var init to 0
+83FF80	byte var init to 0 at the beginning of ftmtool function (0xdbe),
+	set to 1 if "yes" received in response to "ftmtool"