4 ms·
The debug protocols for XC2xxx are documented and you can interface with the device using an Infineon MiniWiggler. Unless the core or flash protection has been
by bri3d 4y ago
The debug protocols for XC2xxx are documented and you can interface with the device using an Infineon MiniWiggler. Unless the core or flash protection has been enabled, which is not likely on an "auxiliary" control unit like this, you can read/write flash and possibly also step-debug. You should be able to use the bootstrap loader startup mode and Infineon MemTool to read and write the device.
The core IP is called C166S V2 and IDA does an OK job disassembling it. Unfortunately the instruction set is quite nasty anyway so it's not pleasant to reverse engineer even when the tooling works. I agree that coming from the "outside in" might be easier than coming from the "inside out," especially if you are able to acquire the internal BMW powertrain-CAN documentation which will make this project very easy.
Infineon do the best job of producing documentation of any major automotive CPU vendor, IMO. Their toolchains and user manuals are both available and much easier to understand than for example Renesas or Freescale.
- nneonneo 4y agoSince you have at least one working message, 0x202, and the ability to disassemble the code, one thing to try would be to search for spots in the code where that gets used as an operand or gets loaded from memory. Unless they use a switch statement (unlikely if the codes are so far apart), there’s likely to be an “if code == 0x202” somewhere that would help narrow down the input handling code. If you’re really lucky, all the other valid codes will be sitting in the same function, which (if nothing else) will make your fuzzing efforts a lot more targeted.