Firmware re

Checksums
see Checksum algorithms

EEPROM
see EEPROM access functions

security / encryption
It seems everything uses the same algorithm. Somewhere Nissan calls this algo "01", so I'll use that notation. It operates thus: They are the inverse of each other, i.e. ( rev_01( fwd_01(data, scode), scode) == data )
 * 1) uint32_t fwd_01(uint32_t data, uint32_t scode);   // encodes 'data' using 'scode'.
 * 2) uint32_t rev_01(uint32_t data, uint32_t scode);   // decodes 'data' using 'scode'.

The 01 algo is used for on most known ROMs. Algo description and equivalent C code [posted here].
 * SID 27 key exchange (use "fwd_01" to generate key from seed)
 * SID 36 RAM bootloader kernel download ("rev_01" to decode the payload; fwd_01 was used to encrypt it)
 * SID 36 firmware payload download (rev_01 to decode the payload)

Arbitrary code execution !
Note : this section applies mainly to K-line based ECUs. It's possible some of the steps will work on CAN-only ECUs ?

This is the stepping stone towards reflashing over the OBD K line or CAN interface, without opening the ECU case. Some nice things that could be done :
 * Run a "fastdump" kernel to read out the ROM much faster than the standard K line method
 * Read / write the external EEPROM
 * Reflash all, or part of the ROM

The method is as follows :
 * 1) write / compile payload, either as position-independant code, or linked to run at the ECU's "RAMjump" address.
 * 2) Pad payload to next multiple of 32 bytes
 * 3) Calculate "cks16" : unsigned 16bit sum of all 8-bit bytes of the payload
 * 4) encrypt payload using "sid36 key 1"
 * 5) Connect to ECU
 * 6) SID 27 seed/key exchange
 * 7) SID 34 80, enter programming mode
 * 8) SID 36 XX YY 0x20 B_00 B_01 B_02... B_31
 * 9) Increment XXYY at every line : "36 00 00 20 ...... 36 00 01 20 ...."
 * 10) SID 37 cks16_H cks16_L TransferExit
 * 11) SID BF 00 ramjump check
 * 12) SID BF 01 actual ramjump.

The payload must be crafted to disable all interrupts and take over the manual generation of the WDT pulse train. Or, it might be possible (if the goal isn't a reflash) to use the firmware's mechanism for the WDT ? i.e. enable a limited set of interrupts, etc)

A very simple test payload that simply freezes the ECU (causing the supervisor to reset it) could look like