ever wanted to find out which microcontroller are you reverse-engineering the firmware for when you don't have the actual device in your hand?
thinking about cleaning this up and publishing as a Binary Ninja plugin
@whitequark I don't use Binary Ninja but I'd happily run this as a script. I've been tempted to do something like this for years (I tend to recognize ARM micros by the flash address implied by their vector table contents, say) but haven't... like a lot of things you've made, actually.
@cliffle oh yeah us too, but this particular set of micros (from Shimano e-bike drivetrain and peripherals, if you're curious) were particularly inscrutable, and we found no match. we still found no match after going through the biggest SVD databases, so it didn't help, even if it worked well when testing on the STM32F103 firmware from a TS101
@whitequark Interesting. The closed nature of ebike equipment bugs me, so I'll be curious to see if you learn anything more about the mystery micro.
@cliffle I've all but given up reversing them, the whole system seems like a Renesas fever dream, the most recent version of the PC app comes with multiple layers of custom obfuscation (in dotnet!) so just to dump the assemblies I'd probably need something like memprocfs, the bus is custom, the programming dongle has an MCU inside too and costs $200 with no cheaper alternatives, it is basically built like automotive software/firmware (derogatory)
@whitequark My understanding is that the Bosch stuff is similar. Renesas seems like a likely culprit based on their product lines.
Looking forward to somebody doing an open one.
@cliffle I'm faaaairly sure the second drivetrain MCU (I assume whatever generates BLDC driver pulse trains) is Renesas RX, while the display MCU and first drivetrain MCU look like some sort of Cortex-M-like (not sure which, there are accesses to NVIC at +d00 something, so not -M3), and I guess it could also be Renesas; not RA though
@whitequark Do you have the specific d00 addresses in your notes anywhere? I've got a lot of memory maps here I could cross reference if you're curious.
@cliffle lemme just upload all of the firmware somewhere, it's freely available but you need to install a windows thing which i assume you don't enjoy too much
@whitequark I don't have access to a Windows system, yeah, though I've managed to club some applications into struggling to life under Wine.
@cliffle DUE5000{-D,-M} is the drivetrain fw, SCE5000 is the display, PCE1 is the dongle. PCE1 is the most interesting, DUE5000 is pretty curious too, SCE5000 is mainly interesting because it should be quite simple
@cliffle so in DUE5000-D.4.4.3.dat at 0x180b8 you can see a store to 0xe000ed04 (NVIC.__offset(0xd04) in binja with an SVD loaded) and I'm not sure what that is
@cliffle actually this is just ICSR that for some reason the SVD plugin I'm using didn't pick up (what >.>) and I have subsequently failed at googling <.< sorry
@whitequark No worries, I can confirm your analysis, I think it's an ICSR access.
@cliffle any idea which MCU it could be? if I run my extractor plugin it gives me this list:
@whitequark Not off the top of my head -- those addresses look pretty typical for an ARMv6-M/v7-M/v8-M peripheral layout. The start of the file's also weird, there's a fairly large almost-certainly-a-header followed by something that looks like a remix of an M-profile vector table. It's very regular, possibly instructions to the bootloader, probably not specified by an architecture.
@cliffle oh yeah I specifically extracted all accesses to the peripheral range (in hopes that you may have a more comprehensive peripheral database than I do). there is a header that I know parts of the format of, and the vector table is what really weirds me out because I've never seen one like this.
I do know there is a bootloader.
@cliffle I think the bootloader *might* be upgradeable so I guess that would be an avenue of further study. all this stuff is stupid expensive and fccid shows nothing so it's really annoying :s
@whitequark it feels to me like some sort of loader instructions, maybe for handling a sparse image or doing RLE or something. It seems like the bootloader occupies the first 64 kiB of the address space, which you could potentially use to narrow down MCUs by flash geometry -- bet whatever part this is has a 64 kiB initial erase sector, which rules out a lot of ST parts, for instance.
@cliffle that's interesting--why 64K?
@whitequark That's an assumption based on the fact that the vector addresses in this file suggest that it's mapped starting at address 0x10000. Suggests that flash starts at 0 (because otherwise it's normally mapped much higher), so I assumed that something was occupying the 0-FFFF range; since the image starts with an elaborate header I assumed it was a bootloader.
@cliffle ah, are you looking at the table at 0x1708?
@whitequark Whoops, apologies, I'm analyzing the SCE images. Will poke at the DUE image in a bit.
@whitequark The DUE5000-D image definitely contains ARM Thumb code -- I looked through the dump manually and spotted a function epilogue next to a constant pool at offset 0x205de. From the constant pool values, the part has at least 10 kiB of RAM at 0x20000000. That memory layout suggests M-profile.
I don't find any of the common V7M-and-later instructions like LDM or TBB at first glance -- this might be v6M code?
@whitequark Also in case it's useful, here's a table I made that I wish ARM had made.
@cliffle @whitequark oh my word. Implementing my cortex-m simulator from the arm arm arm was horrible. I wish I’d had this!
@thejpster @whitequark Yeah, this is the "ISA reference card" I always wanted, which I wrote for my Forth assembler.
Looking forward to a RISC-V future, theirs is much simpler (and less likely to sue me).
@whitequark @cliffle I've been thinking about making something like that for arm64 but I wouldn't know how to arrange it since the top bits are used for data sometimes and not always for distinguishing instructions. :|