DT
Full Member
Karma: +20/-1
 Offline
Posts: 184
|
 |
« Reply #210 on: January 06, 2016, 11:39:14 AM »
|
|
|
byte 8000h is added to a register in the STUTRAP_handler, how odd, it's definitely code though?
Also MEM_EXT:8F98 location calls a function, look it's ASCII lol
edit I don't think 0x8000 is a function it's a struct/table.........................
Sure it's code, everything looks legit, subroutines start with push a couple of registers to stack then pops them back at end. The "only" thing that are a problem are all calls from within 0x8000-0xb800 to 0x6000-0x7fff. CALLS either to ascii data or to middle of subroutines or even loc_xxxx+1 or +2 (corrupt) Could it be that the cpu has 32k internal rom that is used first and then later disabled. The trap code is strange. Moving a word from 8000, 8000+1 and 8000+2 would not make sense. Or is that only delay code instead of nop's since the following calls to 142b4 make no sense either and does not use r12. It really look like the code between 0x8000 and 0xb800 is does not fit seg009:415A STUTRAP_handler: ; CODE XREF: ROM:STUTRAPJ
seg009:415A mov word_F9F2, r0
seg009:415E scxt CP, #0F9F2h
seg009:4162 mov r12, sub_8000
seg009:4166 calls 1, sub_142B4
seg009:416A reti
seg009:416C ; ---------------------------------------------------------------------------
seg009:416C
seg009:416C STOTRAP_handler: ; CODE XREF: ROM:STOTRAPJ
seg009:416C mov SP, #0FC00h
seg009:4170 mov word_F9F2, r0
seg009:4174 scxt CP, #0F9F2h
seg009:4178 mov r12, sub_8000+1
seg009:417C calls 1, sub_142B4
seg009:4180 reti
seg009:4182 ; ---------------------------------------------------------------------------
seg009:4182
seg009:4182 BTRAP_handler: ; CODE XREF: ROM:BTRAPJ
seg009:4182 mov word_F9F2, r0
seg009:4186 scxt CP, #0F9F2h
seg009:418A mov r12, sub_8000+2
seg009:418E calls 1, sub_142B4
seg009:4192 reti |
|
|
|
|
Logged
|
|
|
|
|
k0mpresd
|
|
« Reply #211 on: January 06, 2016, 12:04:32 PM »
|
|
|
you guys should work on gen2 controllers. might be a bit more familiar.  ive been saving this for a looooong time. might have a few more kicking about as well.  |
|
|
|
« Last Edit: January 06, 2016, 12:08:40 PM by k0mpresd »
|
Logged
|
|
|
|
|
dream3R
|
|
« Reply #212 on: January 06, 2016, 01:30:13 PM »
|
|
|
you guys should work on gen2 controllers. might be a bit more familiar. ive been saving this for a looooong time. might have a few more kicking about as well. Nice |
|
|
|
|
Logged
|
|
|
|
|
dream3R
|
|
« Reply #213 on: January 06, 2016, 01:31:33 PM »
|
|
|
Sure it's code, everything looks legit, subroutines start with push a couple of registers to stack then pops them back at end. The "only" thing that are a problem are all calls from within 0x8000-0xb800 to 0x6000-0x7fff. CALLS either to ascii data or to middle of subroutines or even loc_xxxx+1 or +2 (corrupt) Could it be that the cpu has 32k internal rom that is used first and then later disabled. The trap code is strange. Moving a word from 8000, 8000+1 and 8000+2 would not make sense. Or is that only delay code instead of nop's since the following calls to 142b4 make no sense either and does not use r12. It really look like the code between 0x8000 and 0xb800 is does not fit seg009:415A STUTRAP_handler: ; CODE XREF: ROM:STUTRAPJ
seg009:415A mov word_F9F2, r0
seg009:415E scxt CP, #0F9F2h
seg009:4162 mov r12, sub_8000
seg009:4166 calls 1, sub_142B4
seg009:416A reti
seg009:416C ; ---------------------------------------------------------------------------
seg009:416C
seg009:416C STOTRAP_handler: ; CODE XREF: ROM:STOTRAPJ
seg009:416C mov SP, #0FC00h
seg009:4170 mov word_F9F2, r0
seg009:4174 scxt CP, #0F9F2h
seg009:4178 mov r12, sub_8000+1
seg009:417C calls 1, sub_142B4
seg009:4180 reti
seg009:4182 ; ---------------------------------------------------------------------------
seg009:4182
seg009:4182 BTRAP_handler: ; CODE XREF: ROM:BTRAPJ
seg009:4182 mov word_F9F2, r0
seg009:4186 scxt CP, #0F9F2h
seg009:418A mov r12, sub_8000+2
seg009:418E calls 1, sub_142B4
seg009:4192 reti It's odd I know but look at the hex it looks like reference table to call functions. |
|
|
|
|
Logged
|
|
|
|
john9357
Full Member
Karma: +10/-1
Offline
Posts: 54
|
|
« Reply #214 on: January 06, 2016, 03:29:07 PM »
|
|
|
There are many maps on haldex gen1 and gen2!
the processor on gen2 : c167 too
|
|
|
|
« Last Edit: January 06, 2016, 03:30:47 PM by john9357 »
|
Logged
|
|
|
|
|
k0mpresd
|
|
« Reply #215 on: January 06, 2016, 03:38:28 PM »
|
|
|
There are many maps on haldex gen1 and gen2!
the processor on gen2 : c167 too
gen2 is 200bb flash. |
|
|
|
|
Logged
|
|
|
|
DT
Full Member
Karma: +20/-1
Offline
Posts: 184
|
|
« Reply #216 on: January 06, 2016, 04:30:36 PM »
|
|
|
It's odd I know but look at the hex it looks like reference table to call functions.
No! I can't see how you would choose ref table over code. |
|
|
|
|
Logged
|
|
|
|
|
dream3R
|
|
« Reply #217 on: January 06, 2016, 04:44:47 PM »
|
|
|
No! I can't see how you would choose ref table over code.
Boot function moves a byte from there and there are a few others two. Then in hex I noticed the bottom of what I thought was a table/scruct happened to contain memory references to a function position in the flash. I don't check them all but from the bottom up it seemed to match. This and a hardware reset function loads bytes too iirc. This I thought may explain the unreferenced function. It was only ten mins I looked, I'll post some screens tomorrow. I've seen code like this before in me7 diag. The odd thing is the function is almost perfect if not perfect so may just be a coincidence. Food for thought.... |
|
|
|
« Last Edit: January 06, 2016, 05:25:53 PM by dream3R »
|
Logged
|
|
|
|
|
dream3R
|
|
« Reply #218 on: January 06, 2016, 05:12:21 PM »
|
|
|
Look @ MEM_EXT:A718
MEM_EXT:A718 calls 0, byte_6AC8 this cannot be a function if you look at the hex.
|
|
|
|
|
Logged
|
|
|
|
vagenwerk
Full Member
Karma: +2/-0
Offline
Posts: 182
|
|
« Reply #219 on: January 06, 2016, 05:16:11 PM »
|
|
|
you guys should work on gen2 controllers. might be a bit more familiar. ive been saving this for a looooong time. might have a few more kicking about as well. what tool did You use to readout this from haldex ? |
|
|
|
|
Logged
|
|
|
|
DT
Full Member
Karma: +20/-1
Offline
Posts: 184
|
|
« Reply #220 on: January 06, 2016, 05:21:53 PM »
|
|
|
Look @ MEM_EXT:A718
MEM_EXT:A718 calls 0, byte_6AC8 this cannot be a function if you look at the hex.
of course not but the sub that calls 0x06AC8 is a legit coded function. sub_A70A: ; CODE XREF: MEM_EXT:88FAP
MEM_EXT:A70A mov [-r0], r9
MEM_EXT:A70C mov [-r0], r8
MEM_EXT:A70E mov [-r0], r7
MEM_EXT:A710 sub r0, #2
MEM_EXT:A712 mov r12, #182h
MEM_EXT:A716 mov r13, r0
MEM_EXT:A718 calls 0, unk_6AC8
MEM_EXT:A71C cmp r4, #0
MEM_EXT:A71E jmpr cc_Z, loc_A726
MEM_EXT:A720 mov r4, #0FFFFh
MEM_EXT:A724 jmpr cc_UC, loc_A77A
MEM_EXT:A726 ; ---------------------------------------------------------------------------
MEM_EXT:A726
MEM_EXT:A726 loc_A726: ; CODE XREF: sub_A70A+14j
MEM_EXT:A726 movb rl4, [r0]
MEM_EXT:A728 cmpb rl4, #0
MEM_EXT:A72A jmpr cc_SGE, loc_A750
MEM_EXT:A72C movbs r9, rl4
MEM_EXT:A72E neg r9
MEM_EXT:A730 mov r4, r9
MEM_EXT:A732 mov r5, #0
MEM_EXT:A734 mov r10, #0ADD7h
MEM_EXT:A738 mov r11, #0
MEM_EXT:A73A calls 0, sub_B5CC
MEM_EXT:A73E mov r7, r4
MEM_EXT:A740 mov r8, r5
MEM_EXT:A742 mov r4, r5
MEM_EXT:A744 mov r5, ZEROS
MEM_EXT:A748 neg r4
MEM_EXT:A74A mov word_E2E0, r4
MEM_EXT:A74E jmpr cc_UC, loc_A770
MEM_EXT:A750 ; ---------------------------------------------------------------------------
MEM_EXT:A750
MEM_EXT:A750 loc_A750: ; CODE XREF: sub_A70A+20j
MEM_EXT:A750 movb rl4, [r0]
MEM_EXT:A752 movbs r9, rl4
MEM_EXT:A754 mov r4, r9
MEM_EXT:A756 mov r5, #0
MEM_EXT:A758 mov r10, #0ADD7h
MEM_EXT:A75C mov r11, #0
MEM_EXT:A75E calls 0, sub_B5CC
MEM_EXT:A762 mov r7, r4
MEM_EXT:A764 mov r8, r5
MEM_EXT:A766 mov r4, r5
MEM_EXT:A768 mov r5, ZEROS
MEM_EXT:A76C mov word_E2E0, r4
MEM_EXT:A770
MEM_EXT:A770 loc_A770: ; CODE XREF: sub_A70A+44j
MEM_EXT:A770 mov r4, #0FFD4h
MEM_EXT:A774 mov word_E2EC, r4
MEM_EXT:A778 mov r4, #0
MEM_EXT:A77A
MEM_EXT:A77A loc_A77A: ; CODE XREF: sub_A70A+1Aj
MEM_EXT:A77A add r0, #2
MEM_EXT:A77C mov r7, [r0+]
MEM_EXT:A77E mov r8, [r0+]
MEM_EXT:A780 mov r9, [r0+]
MEM_EXT:A782 rets
MEM_EXT:A782 ; End of function sub_A70A |
|
|
|
|
Logged
|
|
|
|
|
k0mpresd
|
|
« Reply #221 on: January 06, 2016, 06:33:06 PM »
|
|
|
what tool did You use to readout this from haldex ?
well its psop44, sooo..... |
|
|
|
|
Logged
|
|
|
|
|
dream3R
|
|
« Reply #222 on: January 07, 2016, 07:25:07 PM »
|
|
|
I'm must be reading assembly from hex lol sad.
|
|
|
|
« Last Edit: January 07, 2016, 07:28:45 PM by dream3R »
|
Logged
|
|
|
|
|
dream3R
|
|
« Reply #223 on: January 07, 2016, 10:32:53 PM »
|
|
|
of course not but the sub that calls 0x06AC8 is a legit coded function. sub_A70A: ; CODE XREF: MEM_EXT:88FAP
MEM_EXT:A70A mov [-r0], r9
MEM_EXT:A70C mov [-r0], r8
MEM_EXT:A70E mov [-r0], r7
MEM_EXT:A710 sub r0, #2
MEM_EXT:A712 mov r12, #182h
MEM_EXT:A716 mov r13, r0
MEM_EXT:A718 calls 0, unk_6AC8
MEM_EXT:A71C cmp r4, #0
MEM_EXT:A71E jmpr cc_Z, loc_A726
MEM_EXT:A720 mov r4, #0FFFFh
MEM_EXT:A724 jmpr cc_UC, loc_A77A
MEM_EXT:A726 ; ---------------------------------------------------------------------------
MEM_EXT:A726
MEM_EXT:A726 loc_A726: ; CODE XREF: sub_A70A+14j
MEM_EXT:A726 movb rl4, [r0]
MEM_EXT:A728 cmpb rl4, #0
MEM_EXT:A72A jmpr cc_SGE, loc_A750
MEM_EXT:A72C movbs r9, rl4
MEM_EXT:A72E neg r9
MEM_EXT:A730 mov r4, r9
MEM_EXT:A732 mov r5, #0
MEM_EXT:A734 mov r10, #0ADD7h
MEM_EXT:A738 mov r11, #0
MEM_EXT:A73A calls 0, sub_B5CC
MEM_EXT:A73E mov r7, r4
MEM_EXT:A740 mov r8, r5
MEM_EXT:A742 mov r4, r5
MEM_EXT:A744 mov r5, ZEROS
MEM_EXT:A748 neg r4
MEM_EXT:A74A mov word_E2E0, r4
MEM_EXT:A74E jmpr cc_UC, loc_A770
MEM_EXT:A750 ; ---------------------------------------------------------------------------
MEM_EXT:A750
MEM_EXT:A750 loc_A750: ; CODE XREF: sub_A70A+20j
MEM_EXT:A750 movb rl4, [r0]
MEM_EXT:A752 movbs r9, rl4
MEM_EXT:A754 mov r4, r9
MEM_EXT:A756 mov r5, #0
MEM_EXT:A758 mov r10, #0ADD7h
MEM_EXT:A75C mov r11, #0
MEM_EXT:A75E calls 0, sub_B5CC
MEM_EXT:A762 mov r7, r4
MEM_EXT:A764 mov r8, r5
MEM_EXT:A766 mov r4, r5
MEM_EXT:A768 mov r5, ZEROS
MEM_EXT:A76C mov word_E2E0, r4
MEM_EXT:A770
MEM_EXT:A770 loc_A770: ; CODE XREF: sub_A70A+44j
MEM_EXT:A770 mov r4, #0FFD4h
MEM_EXT:A774 mov word_E2EC, r4
MEM_EXT:A778 mov r4, #0
MEM_EXT:A77A
MEM_EXT:A77A loc_A77A: ; CODE XREF: sub_A70A+1Aj
MEM_EXT:A77A add r0, #2
MEM_EXT:A77C mov r7, [r0+]
MEM_EXT:A77E mov r8, [r0+]
MEM_EXT:A780 mov r9, [r0+]
MEM_EXT:A782 rets
MEM_EXT:A782 ; End of function sub_A70A That's beside my point, decompiled iDA said byte was a function. |
|
|
|
|
Logged
|
|
|
|
DT
Full Member
Karma: +20/-1
Offline
Posts: 184
|
|
« Reply #224 on: January 08, 2016, 03:19:16 AM »
|
|
|
That's beside my point, decompiled iDA said byte was a function.
Well it's not IDA that claims it is a function, IDA only try to present it as a function since there is a legit call to the byte. IDA can't know that there is ASCII on the destination of the calls. AutoIT scripts or even Perl scripts often result in much that is not correct too. I'm wondering if the layout of read from the ECU is bad or if there is an internal ROM in the C167 that is used at lower 32k in certain situations. But sure it could be my lack of knowledge of C167 code too.  |
|
|
|
|
Logged
|
|
|
|
|
