|
Title: EDC17 flash password Post by: ann83 on May 27, 2019, 07:50:50 AM Hi,
I wonder if anyone played with flash password algo for EDC17 ? There are tools for it but I'm looking for technical details. Thanks Code: 0000:800BA598 99 0F E0 48 ld32.a a15, [a0]-0x72E0 Title: Re: EDC17 flash password Post by: ann83 on May 27, 2019, 12:47:23 PM Code: 0000:800BA30C 91 10 00 0D movh.a a0, #0xD001 The initialization of the a0 register sets it to D0009AA0, so the password1 comes from [a0]-0x72DC = D00027C4. I'm looking for relation between FLASH and LDRAM address . Title: Re: EDC17 flash password Post by: H2Deetoo on April 08, 2020, 12:49:56 PM There is no relationship.
Some code somewhere else (before this is called) creates the right passwords based on some algo and stores them on those addresses. Title: Re: EDC17 flash password Post by: woj on November 16, 2021, 03:29:22 PM Code: 0000:800BA30C 91 10 00 0D movh.a a0, #0xD001 Bump! This right here is what I am looking at at the moment, the initialization of a8 and a9 bothers me, I have this identical in my bin. The arithmetic for addresses I know so far (I so far suck at TC I admit) is that a8 ends up to be AFE88000 and a9 ends up being just 00000000 of effective 32bit addresses. None of the two makes sense, AFEXXXXX is outside of physical address range, and there are no accesses in the code to [a8]+/-offset. But there are accesses to [a9]+offset, which I am quite certain are those doubly linked addresses to the calibration data, so that can't be 00000000 either. Had any of those been A0088000 (so no middle FE), that would make almost perfect sense, cached access to pointer data. What I am missing? (For the record, I am just at the beginning of my trip with TC, so it will probably come to me, as usual, but I am now stuck at this, I have not disassembled all the code yet, and not checked all mtcr-s either). Title: Re: EDC17 flash password Post by: d3irb on November 16, 2021, 03:43:54 PM AFEXXXXX is outside of physical address range What I am missing? Read the chip manual - these are TC1766, right? In TC1766 0xAFE00000 / 0x8FE00000 is where DFlash sector 0 lives. Title: Re: EDC17 flash password Post by: woj on November 17, 2021, 02:38:55 PM Read the chip manual - these are TC1766, right? In TC1766 0xAFE00000 / 0x8FE00000 is where DFlash sector 0 lives. Most likely TC1767, at least that's what all the fractional information I found would indicate, the ECU is ME17.3.0, Fiat/Abarth stuff, I do not have the ECU to look inside, only the dumps. In any case, thanks, at least now I have found the right document, though for 1766, the equivalent for 1767 does not seem to be publicly available (but I did not search too hard, correct me if I am wrong). But then, for my purposes the a8 / DFLASH is currently irrelevant, the magic with a9 is more important. My understanding up till now is that it is indeed 0x00000000, so a virtual address that is mapped by MMU somewhere else. That would at least explain why others here reported the inability to find a9 value directly, but by reverse calculation based on known maps. I am actually doing this in Ghidra, so far the tool looks very very promising, once I get the hang of it, perhaps I will post something in a fresh thread, TBC... Title: Re: EDC17 flash password Post by: prj on November 17, 2021, 02:46:55 PM a9 is not 0. No clue why you would assume that.
There's literally leaked C source code for the ECU. If you really can't figure out something this simple from reversing the binary (literally look where it's assigned, no not in just one location...), then look in the C code. Also what does this have to do with flash passwords? Title: Re: EDC17 flash password Post by: woj on November 17, 2021, 03:06:50 PM a9 is not 0. No clue why you would assume that. There's literally leaked C source code for the ECU. If you really can't figure out something this simple from reversing the binary (literally look where it's assigned, no not in just one location...), then look in the C code. Also what does this have to do with flash passwords? Well, at first I was sure it couldn't be 0, but then all assignments I found were resetting it to 0 next to proper initialization of a0/a1/a8, so I folded under the assumption that this could be it. But now I found it: Code: ************************************************************** This obviously does not yet give me the value because of the indirect reference through DAT_d000c42c, but it's a start. And yes, I am still struggling with TC, will get there. Nothing to do with the passwords, but I found the relevant code here, didn't want to create pointless new topic. Title: Re: EDC17 flash password Post by: terminator on November 20, 2021, 04:21:37 AM a9 is just a reference to the offsets table.
Attach the file and I will save your time. Title: Re: EDC17 flash password Post by: terminator on November 20, 2021, 04:23:21 AM then look in the C code. Would you share the link then? Title: Re: EDC17 flash password Post by: prj on November 20, 2021, 04:38:52 AM Would you share the link then? It's been posted all over the forum and in many damos packs.I'm not going to upload and share Bosch IP. Title: Re: EDC17 flash password Post by: woj on November 20, 2021, 01:44:55 PM a9 is just a reference to the offsets table. Attach the file and I will save your time. I already found the table, just don't know yet if a9 points to the beginning of it, or somewhere in the middle. I find this negative offset addressing totally idiotic on TC-s, but I guess there must have been some really good design reason for this, I am not a chip designer or hardware person otherwise, so I wouldn't know. In any case, I now got far enough to figure it out on my own, and I want to do it because it's part of my practice with TC. Re. the source, I could not find the references here, I think I said this once before, but the search engine is not the best here if you want to look for more than one word. Otherwise, as prj said, you will find references on MHHAuto to the damos pack that has it, but it's huge and I won't waste my time on trying to get my hands on it. Patching in code changes requires working on the assembly level anyhow, so the source will not help me that much (but very curious anyhow ;)). Title: Re: EDC17 flash password Post by: prj on November 21, 2021, 04:23:57 AM Patching in code changes requires working on the assembly level anyhow, so the source will not help me that much (but very curious anyhow ;)). Oh how wrong you area. When you have actual headers then adding in new code in C becomes trivial.Title: Re: EDC17 flash password Post by: woj on November 21, 2021, 11:23:06 AM Oh how wrong you area. When you have actual headers then adding in new code in C becomes trivial. Sure, provided that this "when" is satisfied, I have not yet seen the code, so I am not even sure how complex the ECU configuration is in practice. When you pointed it out I was also thinking that perhaps I wouldn't like the fact that any C code line added would shift all other code and the binary would no longer resemble the original, but on the second thought that could actually be an advantage. Title: Re: EDC17 flash password Post by: prj on November 22, 2021, 03:48:51 AM Sure, provided that this "when" is satisfied, I have not yet seen the code, so I am not even sure how complex the ECU configuration is in practice. When you pointed it out I was also thinking that perhaps I wouldn't like the fact that any C code line added would shift all other code and the binary would no longer resemble the original, but on the second thought that could actually be an advantage. Nobody spoke about re-compiling it, which is impossible since the toolchain has not leaked.Actually this response tells me you don't know anything about C, linking and EABI. Better start learning and stop posting wild theories for a bit. |