ann83
Newbie
Karma: +0/-0
 Offline
Posts: 2
|
 |
« 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 0000:800BA598 99 0F E0 48 ld32.a a15, [a0]-0x72E0
0000:800BA59C 59 FF 54 55 st32.w [a15]0x5554, d15
0000:800BA5A0 DA 55 mov16 d15, #0x55
0000:800BA5A2 99 0F E0 48 ld32.a a15, [a0]-0x72E0
0000:800BA5A6 11 1F 00 F0 addih.a a15, a15, #1
0000:800BA5AA 59 FF A8 AA st32.w [a15]-0x5558, d15
0000:800BA5AE 82 0F mov16 d15, #0
0000:800BA5B0 99 0F E0 48 ld32.a a15, [a0]-0x72E0
0000:800BA5B4 59 FF 7C 45 st32.w [a15]0x553C, d15
0000:800BA5B8 99 0F E0 48 ld32.a a15, [a0]-0x72E0
0000:800BA5BC 19 0F E4 48 ld32.w d15, [a0]-0x72DC ; password1 A0=D0009AA0
0000:800BA5C0 11 1F 00 F0 addih.a a15, a15, #1
0000:800BA5C4 59 FF A8 AA st32.w [a15]-0x5558, d15 ; d15 password1
0000:800BA5C8 99 0F E0 48 ld32.a a15, [a0]-0x72E0
0000:800BA5CC 19 0F E8 48 ld32.w d15, [a0]-0x72D8 ; password2
0000:800BA5D0 11 1F 00 F0 addih.a a15, a15, #1
0000:800BA5D4 59 FF A8 AA st32.w [a15]-0x5558, d15 ; d15 password2
0000:800BA5D8 DA 08 mov16 d15, #8
0000:800BA5DA 99 0F E0 48 ld32.a a15, [a0]-0x72E0
0000:800BA5DE 59 FF 58 55 st32.w [a15]0x5558, d15
|
|
|
|
|
Logged
|
|
|
|
ann83
Newbie
Karma: +0/-0
Offline
Posts: 2
|
|
« Reply #1 on: May 27, 2019, 12:47:23 PM »
|
|
|
0000:800BA30C 91 10 00 0D movh.a a0, #0xD001
0000:800BA310 D9 00 A0 A9 lea a0, [a0]-0x6560 ; a0=D0009AA0
0000:800BA314 91 90 00 18 movh.a a1, #0x8009
0000:800BA318 D9 11 D0 9C lea a1, [a1]-0x31B0 ; a1=8008CE50
0000:800BA31C 91 90 FE 8A movh.a a8, #0xAFE9
0000:800BA320 D9 88 00 08 lea a8, [a8]-0x8000
0000:800BA324 A0 09 mov16.a a9, #0
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 . |
|
|
|
|
Logged
|
|
|
|
|
H2Deetoo
|
|
« Reply #2 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.
|
|
|
|
|
Logged
|
|
|
|
|
woj
|
|
« Reply #3 on: November 16, 2021, 03:29:22 PM »
|
|
|
0000:800BA30C 91 10 00 0D movh.a a0, #0xD001
0000:800BA310 D9 00 A0 A9 lea a0, [a0]-0x6560 ; a0=D0009AA0
0000:800BA314 91 90 00 18 movh.a a1, #0x8009
0000:800BA318 D9 11 D0 9C lea a1, [a1]-0x31B0 ; a1=8008CE50
0000:800BA31C 91 90 FE 8A movh.a a8, #0xAFE9
0000:800BA320 D9 88 00 08 lea a8, [a8]-0x8000
0000:800BA324 A0 09 mov16.a a9, #0
... 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). |
|
|
|
|
Logged
|
|
|
|
d3irb
Full Member
Karma: +134/-1
 Online
Posts: 195
|
|
« Reply #4 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. |
|
|
|
|
Logged
|
|
|
|
|
woj
|
|
« Reply #5 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... |
|
|
|
|
Logged
|
|
|
|
|
prj
|
|
« Reply #6 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?
|
|
|
|
|
Logged
|
|
|
|
|
woj
|
|
« Reply #7 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: **************************************************************
* *
* FUNCTION *
**************************************************************
undefined FUN_80139052()
undefined d2:1 <RETURN>
FUN_80139052 XREF[3]: FUN_80138eb4:80138ed2(c),
801396a2(c),
FUN_8015c7e8:8015c8b4(c)
80139052 7b 00 00 02 movh d0,#0x2000
80139056 91 10 00 fd movh.a a15,#0xd001
8013905a 99 ff 6c 0c ld.a a15,[a15]-0x3bd4=>DAT_d000c42c = ??
8013905e d9 f2 1c 00 lea a2,[a15]0x1c
80139062 01 24 02 26 addsc.a a2,a2,d4,#0x2
80139066 4c 20 ld.w d15,[a2]#0x0
80139068 8f 3f 1e 10 sh d1,d15,#-0x1d
8013906c 40 2f mov.aa a15,a2
8013906e 8b 41 00 12 eq d1,d1,#0x4
80139072 2b 0f 00 11 cadd d1,d1,d15,d0
80139076 4d 40 e0 0f mfcr d0,#0xfe04
8013907a 8f 00 50 f1 or d15,d0,#0x100
8013907e cd 4f e0 0f mtcr #0xfe04,d15
80139082 0d 00 c0 04 isync
80139086 60 19 mov.a a9,d1
80139088 cd 40 e0 0f mtcr #0xfe04,d0
8013908c 0d 00 c0 04 isync
80139090 00 90 ret
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. |
|
|
|
|
Logged
|
|
|
|
|
terminator
|
|
« Reply #8 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.
|
|
|
|
|
Logged
|
|
|
|
|
terminator
|
|
« Reply #9 on: November 20, 2021, 04:23:21 AM »
|
|
|
then look in the C code.
Would you share the link then? |
|
|
|
|
Logged
|
|
|
|
|
prj
|
|
« Reply #10 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. |
|
|
|
|
Logged
|
|
|
|
|
woj
|
|
« Reply #11 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  ). |
|
|
|
|
Logged
|
|
|
|
|
prj
|
|
« Reply #12 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. |
|
|
|
|
Logged
|
|
|
|
|
woj
|
|
« Reply #13 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. |
|
|
|
|
Logged
|
|
|
|
|
prj
|
|
« Reply #14 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. |
|
|
|
|
Logged
|
|
|
|
|
