RADustin wrote: Got lucky here, but all I know so far is the algo for device control seed/key isn't one of the ones used for the normal security that was hacked from the tech2.
Was this 2byte or 5byte?
2 byte
I have JTAG running. Definitely money well spent on the Jlink. I was up and running in maybe 20 minutes using JLink commander. I have yet to map the ram so J-Flash is not running yet, but I'm working on it.
I think my bootload above is incorrect. I'm going to remove it. See full 512k dump attached from JTAG. Can someone lend some more time with assembly to see what can be figured on the checksums?
I was just about to ask you to double check that first 16k. It started to disassemble correctly, and then the alignment got jacked up and things stopped making sense.
I already found what I believe to be the pointer to the mode 36 (transfer data) routine. Now that you've posted the updated file, that pointer connects to what looks like valid code. I'm hopeful the checksum routine isn't far behind.
Gatecrasher wrote:I was just about to ask you to double check that first 16k. It started to disassemble correctly, and then the alignment got jacked up and things stopped making sense.
I already found what I believe to be the pointer to the mode 36 (transfer data) routine. Now that you've posted the updated file, that pointer connects to what looks like valid code. I'm hopeful the checksum routine isn't far behind.
I'm getting excited. I appreciate you taking a look.
Glad I pushed to get this connected via JTAG. The dump was fairly trivial, but a write from file is more complicated.
J-link keeps giving me ramcode failed messages because I'm pretty sure I don't have the correct starting address for the working RAM. and I have no clue at present on how to find this address.
I can't be sure yet, but the chip seemed to get pissed off with an incorrect checksum vs the data it had in it. I can inject data 1 byte at a time in it thru JTAG and I was messing around and all of sudden lost all canbus. As soon as I flashed the byte back to 'stock' canbus coms returned. Had me nervous for a minute I made a brick.
As best I can tell, RAM starts at 0x200000 and ends at 0x208000.
There's a bunch of memory base address selection registers. If you have to set those up manually, this is going to be a pain. If you can use the values the processor has set up for itself with the bootloader, then it should be a lot easier.
Do you have a link to the J-link you bought? I think I might need to pick one up.
This is the bench setup. Just soldered on some wires and put some dupont pins on the ends to stab into the ribbon cable. Super easy and works fine. For dumping this J-Link has worked perfect, but I still can't move bulk data until I get the RAM issue figured out.
That might have to do with those base memory registers. There's all sorts of stuff in there about protection regions too. I only glanced at it in the manual. It looks like a really messy, poorly explained topic that's not really relevant to the checksum question right now.
I can program memory thru JTAG while watching my scantool on canbus to see when/if I hit the right spot. That way when the checksum is done and we can go in through canbus, I know the exact address of the byte I need to change to update the cal file to have the data I need it to have.
Just trying to work in parallel. But I've pretty much given up on making the RAM stuff work right now, I'm just trying byte by byte, one at a time through JTAG. Obviously my first guess was incorrect.