Gatecrasher wrote:I disassembled the consolidated ROM that kur4o posted and found some subroutines that reference the checksum locations, but nothing that called that code to begin with. That's why I asked for the utility file. I pulled out the reflash kernel and I've got a clean disassembly of that. I'm looking for a standalone checksum routine. But I'm running into the same problem I did with the main operational code. Both of them make a bunch of references to memory locations in the bootloader area. 0x0-0x3FFF. I'm worried the checksum routine is in the bootloader because the reflash kernel has the same type of 4 byte checksum in the same location as the OS and cal files. I'm hoping there's maybe a redundant copy of it in the reflash kernel though.
I'm trying to make some educated guesses on some of the memory references. It's tedious, but I've got the buzz now.
I'm not sure the relationship the TI chip has or if any of these files actually get flashed to it. It was my understanding the infineon chip gets the reflash, and the TI chip isn't writeable thru canbus. Maybe thru the secondary bus that the pitch/yaw sensor communicates through? not sure. I guess the TI chip and infineon communicate over SPI? but I'm not sure.
Any tips or ideas are welcomed though. Any way to possibly narrow down what this CS is would be great and help the brute force campaign. I should have that up and running by this time next week. Mostly just waiting on a spare EBCM to come in while I write some code. But with the 4 byte CS, I'm not very optimistic a solution will be found unless some massive reductions can be made.
Can you tell if the CS is 32bit or two 16 bits? It's sort of funny(not) since I have so much time in this already, that I can't even answer the most basic questions.
I'm pretty sure the Infineon chip is just some kind of ASIC. I wouldn't worry about it.
The code definitely gets flashed to the TI chip. It disassembles correctly, and the memory locations and registers line up perfectly. It's from the same family as the one in the BCM in my truck. Different suppliers though, so the code unfortunately doesn't have any similarities once you get past the hardware level.
I think it's a 32 bit checksum, but I won't know for sure until I can find the code that actually operates on them. Right now I can only find code that looks up their locations, and then passes those locations back to the parent subroutine. It's that parent subroutine I can't find. I'm worried it's in the boot block. This code is a gordian knot of indirect references to RAM locations, so it's possible I'm just missing something.
Gatecrasher wrote:I'm pretty sure the Infineon chip is just some kind of ASIC. I wouldn't worry about it.
The code definitely gets flashed to the TI chip. It disassembles correctly, and the memory locations and registers line up perfectly. It's from the same family as the one in the BCM in my truck. Different suppliers though, so the code unfortunately doesn't have any similarities once you get past the hardware level.
I think it's a 32 bit checksum, but I won't know for sure until I can find the code that actually operates on them. Right now I can only find code that looks up their locations, and then passes those locations back to the parent subroutine. It's that parent subroutine I can't find. I'm worried it's in the boot block. This code is a gordian knot of indirect references to RAM locations, so it's possible I'm just missing something.
Colorado and at least some GMT800 trucks use TMS470s in their BCMs.
That flash bootloader is the kernel I was talking about extracting from the utility file. It's not actually a bootloader since the chip doesn't get reset once it's uploaded. The chip boots off its internal bootloader, sets up all its hardware, and then jumps to execute the flash kernel out of RAM when SPS sets up a programming session.
The bootloader or boot block is code that lives permanently in flash at 0x0-0x3FFF. The only way to get it is to upload a custom kernel to read it out, or pull it via some other means like JTAG. I dumped the entire flash memory from my BCM via JTAG.
This is basically how the chip works:
Power on.
Bootloader at 0x0 executes.
If operating system and calibration is found, go into normal operation mode.
If SPS requests a programming session, stop normal operation, wait for SPS to transfer flash programming code to RAM, then jump to RAM and execute flash code.
If no OS and cal are found, go into a loop and wait for an SPS session to connect.
Brute force method to it to give an indication of what kind of checksum it uses. Try increase a byte in the cals by 1, and then update the checksum by 1 or decrease by 1.
I have come across weird checksums which have a special 'number' applied which throws out standard 2's compliments.
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Tazzi wrote:Brute force method to it to give an indication of what kind of checksum it uses. Try increase a byte in the cals by 1, and then update the checksum by 1 or decrease by 1.
I have come across weird checksums which have a special 'number' applied which throws out standard 2's compliments.
Tazzi wrote:Brute force method to it to give an indication of what kind of checksum it uses. Try increase a byte in the cals by 1, and then update the checksum by 1 or decrease by 1.
I have come across weird checksums which have a special 'number' applied which throws out standard 2's compliments.
It's funny you mention that. There's two places where the flash kernel loads 0x12345678 into one of the registers, but I haven't figured out what it's doing with it yet.
I made some progress with it last night. I figured out what it's using as the base address into the peripheral control register memory space. But only some of the resulting addresses make sense. Still, it's progress. I can at least rule out those chunks of the code as having anything to do with the checksum process.
Well, I found out why some of the registers don't make sense. TI didn't include them in any of the data sheets. You have to hunt around for code samples and some flash API data sheets to find them.
I'm down to two subroutines left to decode. If the checksum routine isn't in there, then it's got to be part of the bootloader.
Gatecrasher wrote:Well, I found out why some of the registers don't make sense. TI didn't include them in any of the data sheets. You have to hunt around for code samples and some flash API data sheets to find them.
I'm down to two subroutines left to decode. If the checksum routine isn't in there, then it's got to be part of the bootloader.
and if bootloader than full chip dump thru JTAG required?
I really appreciate your efforts, hopefully it's in one of these two subroutines- but if it isn't I'm committed to getting the bootloader. We're going to figure this CS algo out come hell or high water.