Pages: [1]
Author Topic: PROKONAL codewords searching?  (Read 5533 times)
amd is the best
Sr. Member
****

Karma: +11/-5
Offline Offline

Posts: 268



« on: February 10, 2020, 09:37:40 AM »

Guys,

What's the best way to define the PROKONAL section of a binary? Is the only (or best) way in assembly?

Guess and check takes way too long and no matter how similar another defined ECU seems to be, prokonal codewords always seem to be different.

Can anyone give some tips?

Thanks in advance!
Logged

2012 Golf TDI
2001 Audi A4 2.8 30v Supercharged
1991 Audi 200 20v
mdccode5150
Full Member
***

Karma: +11/-4
Offline Offline

Posts: 122


« Reply #1 on: October 07, 2020, 05:34:39 PM »

I'm interested in this also! I'm reading the Function Documents now. I will post if I can figure it out. My strategy is to compare the Damos/A2L of different ECU's.
Logged
prj
Hero Member
*****

Karma: +903/-420
Offline Offline

Posts: 5787


« Reply #2 on: October 08, 2020, 04:46:42 AM »

Dissassembly, but it's one of the harder sections to reverse...
Logged

PM's will not be answered, so don't even try.
Log your car properly.
mdccode5150
Full Member
***

Karma: +11/-4
Offline Offline

Posts: 122


« Reply #3 on: October 21, 2020, 12:15:32 AM »

I found a Bosch project for MED17 3.6L TSFI, and have been reading the files, logs, C, H, O code, and A2L / Hex files...It's so missive compared to ME7's. I don't know coding but it still interests me.
Logged
IamwhoIam
Hero Member
*****

Karma: +43/-99
Offline Offline

Posts: 1030


« Reply #4 on: October 21, 2020, 01:43:27 AM »

I found a Bosch project for MED17 3.6L TSFI, and have been reading the files, logs, C, H, O code, and A2L / Hex files...It's so missive compared to ME7's. I don't know coding but it still interests me.

Care to share the hex file from this project with us?
Logged

I have no logs because I have a boost gauge (makes things easier)
mdccode5150
Full Member
***

Karma: +11/-4
Offline Offline

Posts: 122


« Reply #5 on: October 29, 2020, 10:00:40 AM »

YES! I will figure out how to make a link to Google for download...And I am translating other Version Coding Documents now. I will also share.
Logged
mdccode5150
Full Member
***

Karma: +11/-4
Offline Offline

Posts: 122


« Reply #6 on: November 07, 2020, 06:44:41 PM »

Care to share the hex file from this project with us?
Sorry for the delay
Let me know if it downloads...
https://drive.google.com/file/d/1gjo9-LSAj_l3o1nGwV3psBwcdmr4Gz_n/view?usp=sharing

Also most files can be read with Notepad++ free download https://notepad-plus-plus.org/downloads/
« Last Edit: November 07, 2020, 06:48:32 PM by mdccode5150 » Logged
terminator
Sr. Member
****

Karma: +15/-4
Offline Offline

Posts: 425


« Reply #7 on: March 04, 2021, 09:11:23 AM »

for me7
http://nefariousmotorsports.com/forum/index.php?topic=16741

Logged
360trev
Full Member
***

Karma: +66/-2
Offline Offline

Posts: 235


« Reply #8 on: December 09, 2021, 12:20:27 PM »

Someone recently asked me to comment on this subject as a software developer

OK here goes. It helps to look at the source-code posted by mdccode5150 as even though its for ME17 the Project Configuration hasn't really changed all that much from ME7.x days. The reason why you don't get a match is related to "code generation" and the fact they change compilers and C167 GNU CC based compilers got better at code optimization as they get newer. Its also conditionally compiled for different projects...

First lets look at the macro's used (C language) to define bits..

Code:
#define b_MASK        (uint8)0xFFu

#define SETBIT_B(basis,bitpos)     ((basis) |= ((uint8)1 << (bitpos)), TRUE)
#define CLRBIT_B(basis,bitpos)     ((basis) &= b_MASK - ((uint8)1 << (bitpos)), FALSE)
#define GETBIT_B(basis,bitpos)     (((basis) & ((uint8)1 << (bitpos))) != 0)
#define PUTBIT_B(basis,bitpos,val) ((val) ? SETBIT_B(basis,bitpos) : CLRBIT_B(basis,bitpos))

And here's a custom macro specific to a given bit (auto generated by some scripts)

Code:
#define SET_B_autget ((bits |= (uint8)1u << 0))
#define CLR_B_autget ((bits &= (uint8)(((uint8) b_MASK) - ((uint8)1u << 0))))
#define GET_B_autget ((bits & ((uint8)1u << 0)) != (uint8)0u)
#define PUT_B_autget(val) ((val) ? SET_B_autget : CLR_B_autget)
Here's some snippet. Lets look at CWKONFZ1 on ME7.3 projects.
Note: Different projects defined bits settings to mean different things!!

Code:
/******************************************************************/
/** CWKONFZ1 Config. Vehicle         */
/******************************************************************/
  PUT_B_autget ( GETBIT_B(KW_CWKONFZ1,0) );
  PUT_B_mt     ( GETBIT_B(KW_CWKONFZ1,1) );
  PUT_B_cvt    ( GETBIT_B(KW_CWKONFZ1,2) );
  PUT_B_f1getr ( GETBIT_B(KW_CWKONFZ1,3) );
//PUT_B_xxx    ( GETBIT_B(KW_CWKONFZ1,4) );
//PUT_B_xxx    ( GETBIT_B(KW_CWKONFZ1,5) );
  PUT_B_asrfz  ( GETBIT_B(KW_CWKONFZ1,6) );
  PUT_B_4wd    ( GETBIT_B(KW_CWKONFZ1,7) );

So these macro's are generating code... All they are doing is retrieving given bits from a CW byte and setting a given bit in another memory location. Its those other memory locations which are checked at runtime to see if the bits are set or not set by individual functions. These Control words simply set bits. Nothing more.

When you run this through one of the earlier compilers (as used on ME7.3) it spits out pretty crappy un-optimized code which looks something like this...

Code:
get_cw_sy_flags+0:   F3 F8 1F 00   movb    rl4, CWKONFZ1   ; CWKONFZ1 : Codewort fnr Konfiguration Fahrzeug [PROKON]
get_cw_sy_flags+4    69 81         andb    rl4, #1         ; #0x01 = .bit 0
get_cw_sy_flags+6    3A 88 88 36   bmovn   USR0, Z
get_cw_sy_flags+A    4A 88 00 63   bmov    PROKON_FD00.3, USR0 ; b_autget

get_cw_sy_flags+E    F3 F8 1F 00   movb    rl4, CWKONFZ1   ; CWKONFZ1 : Codewort fnr Konfiguration Fahrzeug [PROKON]
get_cw_sy_flags+12   69 82         andb    rl4, #2         ; #0x02 = .bit 1
get_cw_sy_flags+14   3A 88 88 36   bmovn   USR0, Z
get_cw_sy_flags+18   4A 88 01 66   bmov    PROKON_FD02.6, USR0 ; b_mt

get_cw_sy_flags+1C   F3 F8 1F 00   movb    rl4, CWKONFZ1   ; CWKONFZ1 : Codewort fnr Konfiguration Fahrzeug [PROKON]
get_cw_sy_flags+20   69 84         andb    rl4, #4         ; #0x04 = .bit 2
get_cw_sy_flags+22   3A 88 88 36   bmovn   USR0, Z
get_cw_sy_flags+26   4A 88 00 64   bmov    PROKON_FD00.4, USR0 ; b_cvt

get_cw_sy_flags+2A   F3 F8 1F 00   movb    rl4, CWKONFZ1   ; --
get_cw_sy_flags+2E   67 F8 08 00   andb    rl4, #8         ; #0x08 = .bit 3
get_cw_sy_flags+32   3A 88 88 36   bmovn   USR0, Z
get_cw_sy_flags+36   4A 88 00 68   bmov    PROKON_FD00.8, USR0 ; B_f1getr: Condition F1-gearbox (electronic clutch)

get_cw_sy_flags+3A   F3 F8 1F 00   movb    rl4, CWKONFZ1   ; CWKONFZ1 : Codewort fnr Konfiguration Fahrzeug [PROKON]
get_cw_sy_flags+3E   67 F8 40 00   andb    rl4, #40h ; '@' ; #0x40 = .bit 6
get_cw_sy_flags+42   3A 88 88 36   bmovn   USR0, Z
get_cw_sy_flags+46   4A 88 00 62   bmov    PROKON_FD00.2, USR0 ; b_asrfz

get_cw_sy_flags+4A   F3 F8 1F 00   movb    rl4, CWKONFZ1   ; CWKONFZ1 : Codewort fnr Konfiguration Fahrzeug [PROKON]
get_cw_sy_flags+4E   67 F8 80 00   andb    rl4, #80h ; 'Ç' ; #0x80 = .bit 7
get_cw_sy_flags+52   3A 88 88 36   bmovn   USR0, Z
get_cw_sy_flags+56   4A 88 00 60   bmov    PROKON_FD00.0, USR0 ; b_4wd [ ** NOT REFERENCED ANYWHERE ** ]

Lets look at just one of these generated code's for a moment...

Code:
get_cw_sy_flags+4A   F3 F8 1F 00   movb    rl4, CWKONFZ1   ; CWKONFZ1 : Codewort fur Konfiguration Fahrzeug [PROKON]
get_cw_sy_flags+4E   67 F8 80 00   andb    rl4, #80h ; 'Ç' ; #0x80 = .bit 7
get_cw_sy_flags+52   3A 88 88 36   bmovn   USR0, Z
get_cw_sy_flags+56   4A 88 00 60   bmov    PROKON_FD00.0, USR0 ; b_4wd

Lets remove 'code generator specifics' to make the signature a little bit more 'generic'...

Code:
get_cw_sy_flags+4A   F3 F? ?? ??   movb    r??, ??????   ; CWKONFZ1 : Codewort fur Konfiguration Fahrzeug [PROKON]
get_cw_sy_flags+4E   67 F? 80 00   andb    r??, #80h     ; '#0x80 = .bit 7
get_cw_sy_flags+52   3A ?? ?? ??   bmovn  ?????, ??
get_cw_sy_flags+56   4A ?? ?? ??   bmov    ?????.??, ????; b_4wd

Here we've removed the 'registers' F? ... and then the physical referenced address, e.g  F3F8 1F00  becomes F3F? Huh?

This is because F3 is the opcode for 'moveb'  F8 is references 'rl4' and finally 1F00 is (byte swapped to 001F is referencing map region +1F). so 0x810000+0x1F which is 0x81001F or file offset 0x1001F in this specific case...

67 is the opcode for 'andb' again 'register' F8 is referencing 'rl4' and then 80 00 becomes (byte swapped) 00 80 or 0x0080 which is the 7th bit...

So the mask to detect this exact field is "F3 F? ?? ?? 67 F? 80 00 3A ?? ?? ?? 4A ?? 00 ??"

And here's code generation on a different GCC compiled with large memory model.

Code:
D7 40 06 02                             extp    #206h, #1
F3 F2 C5 01                             movb    rl1, CWKONFZ1
8A F1 02 00                             jb      r1.0, _bit_clear

6F 88                   _bit_set:       bset    USR0
0D 01                                   jmpr    cc_UC, _cont

6E 88                   _bit_clear:     bclr    USR0
3A 88 00 60             _cont:          bmovn   PROKON_Flags_FD00.0, USR0

You can see logically it does exactly the same as the original macros. The difference here is the extp #1 so it explicitly calls out that this is at segment 0x206. If you understand these opcodes (see C167 instruction manual) you'll see that means its at address 0x206*0x4000 (each segment is 0x4000 in size). So that equates to an address offset of 0x818000 + 0x01CF, so in this particular case its referencing 0x81801CF, or file offset 0x181CF.

However this is NOT really the best way to detect these fields using crude 'static signature detection' because you'd literally have to detect all the different compiler variants used as the code is pretty different every time... why? Its because its FAR far better to find the byte and bit offset which actually USES these bit-fields and search for the bits referenced backwards from that... So in this case find all references to code using FD00.0.... Search for the signature which uses of one of them and extract the bit and byte offset used there and that will de-reference the memory set by the project bit setups. In this way its possible to fully automate detection of all prokon bits in a rom you've never even seen before..

Same technique works on MED9 (PowerPC) and ME17 (tricore) just with difference instructions. Any questions just ask..
Logged
Pages: [1]
  Print  
 
Jump to:  

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines Page created in 0.037 seconds with 17 queries. (Pretty URLs adds 0.001s, 0q)