|
Title: Disassembling MED/EDC17 Post by: MIL_on on October 07, 2014, 02:43:27 AM Hi Guys,
i'm quite sure that this might be a interesting topic not only for me. I tried to disassemble a known EDC17 File to find stuff like the DPF-switch and so on. But i couldnt find any Cross-references nor different adressing modes. So there are 2 possible faults: I did a fault while loading the stuff into IDA or i didnt understand the adressing yet. Here is my route to this point: I decided to analyze the EDC17CP14 File you find attached to this post (03L906022LH 504907 P680_I3WF). While looking into an A2L of another EDC17CP14 we find the following adress ranges: Code: /begin MOD_PAR "EDC17CP14" continues in second post Title: Re: Disassembling MED/EDC17 Post by: MIL_on on October 07, 2014, 02:55:14 AM So based on this i loaded my bin into IDA the first time with the following Specs:
I chose Tricore out of the list and loaded my whole file to 0x80000000. Afterwards i created all RAM-Adress ranges which where defined in the A2L. After IDA had gone through it once i only found 2 RAM-Blocks which were really used: 0xC0000000 and 0xD0000000 and only up to a Range till 0xC0003xxx (same for 0xD...). So i decided that it would be enough to create only these two blocks of RAM like this: (http://www.proboost-engineering.de/wp-content/uploads/2014/10/2014-10-07_1117.png) Question: is it correct to create it as a 16 bit segment or is 32 bit needed in any way? Later i found a quite easy overview of the Tricore Architecture which i would say confirmed this assumption: (http://www.proboost-engineering.de/wp-content/uploads/2014/10/2014-10-07_1137.png) Also mentioned in the doc and the Tricore User Manual is the adressing: (http://www.proboost-engineering.de/wp-content/uploads/2014/10/2014-10-07_1157.png) It is also more detailed in the Full User Manual, but rough said this is the reason why i chose my Default segment as 0x02. correct? The whole doc is also attached. Now back to the analysis: The DPF-Switch is located @ 801EFED4. Looking into IDA theres no cross-referencing: (http://www.proboost-engineering.de/wp-content/uploads/2014/10/2014-10-07_1148.png) also searching for segment and offset didnt lead to success. Maybe i did something wrong there? To those who might be sitting laughing in front of their screens now: I hope you recognize that i dont want to be spoon-fed, but a good hint could be used quite good here :/ Title: Re: Disassembling MED/EDC17 Post by: ozzy_rp on October 08, 2014, 04:41:25 AM Hi
Where IDA project? :) Title: Re: Disassembling MED/EDC17 Post by: MIL_on on October 08, 2014, 05:04:24 AM heres my idb File :)
IDA-Project (http://www.proboost-engineering.de/wp-content/uploads/2014/10/WinOLS-Skoda-Yeti-Original-504907.zip) Title: Re: Disassembling MED/EDC17 Post by: ozzy_rp on December 30, 2014, 01:54:11 PM How about entry point?
Flash memory from 0x80000000h mirrored with 0xA0000000H In user manual written : Start from internal PFLASH 0xA0000000H .... but at this address not working programm code :( Title: Re: Disassembling MED/EDC17 Post by: ozzy_rp on March 02, 2015, 02:39:57 PM I found cross-reference to DPF-Switch.
In EDC17/MED17 using double index link. PFLASH:8005901A loc_8005901A: ; CODE XREF: sub_80058FCE+3Aj PFLASH:8005901A movh.a a15, #@HIS(unk_D0004254) PFLASH:8005901E ld32.a a2, [a9]0x97C //a9 contains base address for table with references (0x80153DDC) //a2 contains address of near link to DPF-Switch (0x801EFED2) // 0x80153DDC+0x97C=0x80154758 //[0x80154758]=0x801EFED2 PFLASH:80059022 lea a15, [a15]@LOS(unk_D0004254) PFLASH:80059026 ld16.bu d15, [a15]0xA PFLASH:80059028 extr.u d0, d15, #0, #8 PFLASH:8005902C movh.a a15, #@HIS(unk_C0007D2A) PFLASH:80059030 lea a15, [a15]@LOS(unk_C0007D2A) PFLASH:80059034 st16.b [a15]0, d15 PFLASH:80059036 movh.a a15, #@HIS(unk_C0007D2B) PFLASH:8005903A lea a15, [a15]@LOS(unk_C0007D2B) PFLASH:8005903E st16.b [a15]0, d0 PFLASH:80059040 ld16.bu d15, [a2]2 ; dpf-switch //and [a2]2 reference to DPF-Switch :) PFLASH:80059042 jeq16 d15, #1, loc_80059052 PFLASH:80059044 jge d15, #2, loc_8005904C PFLASH:80059048 jz16 d15, loc_80059058 PFLASH:8005904A j16 loc_80059056 A slightly confusing :) Title: Re: Disassembling MED/EDC17 Post by: MIL_on on March 09, 2015, 12:35:18 AM wow, this is great! Thank you!
Unfortunately i didnt have quite a lot of time in the past to do anything related to tricore disasm :( The biggest problem for me was or better said is to find the entry of the table stored in a register. Can you tell me how you found out that a9 holds it? I was in the thinking that it might be stored in d4, but couldnt find the point where it is stored/built. Title: Re: Disassembling MED/EDC17 Post by: ozzy_rp on March 11, 2015, 10:29:00 AM Directly I could not find it.
I had to use a trick. I have DAMOS from another MED17 ECU. From him I learned addresses of variables and maps: nmot_w, rlmaxmd_w, LDRXN and LDRXNZK. Then I began to search for a subroutine which according rlmaxmd_w retrieves the value from map LDRXNZK. I found one subroutine and in it i see algorithm to obtain pointers to maps:) According to the internal structure of the blocks MED17 and EDC17 similar. Knowing the algorithm, it was easy to find a reference to a codewort in your flash:) Title: Re: Disassembling MED/EDC17 Post by: Ionut on April 05, 2015, 03:16:31 PM Hello. I have an Audi A4 with EDC17CP20 ecu.
I`ve loaded BIN to 0x80000000m created RAM segments and converted to code. Now what? :D How can i convert references to actual address? For example, i have this piece of code: Code: 0000:800C213C loc_800C213C: ; CODE XREF: sub_800C20BC+76j On my file, at 0xC000 address value is 0x56D (1389) [a15]0x565A means 0xC000 + 0x565A (0x1165A) or 0x56D + 0x565A (0x5BC7) or other thing? All my maps are located between 0x180000 and 0x1FFFFF in WinOLS. Title: Re: Disassembling MED/EDC17 Post by: ozzy_rp on April 06, 2015, 04:55:44 AM movh.a a15, #0xC000
...... lea a15, [a15]0x565A this mean a15=0xC000565A :) Title: Re: Disassembling MED/EDC17 Post by: Ionut on April 06, 2015, 06:06:44 AM Ok, so that is a RAM value. But what should i search in disassembled code to find reference to maps?
0xC0000000 and 0xD0000000 are outside my maps area. Thanks in advance Title: Re: Disassembling MED/EDC17 Post by: marrakech on June 15, 2015, 04:56:50 AM Thanks in advance or this topic! ;)
Title: Re: Disassembling MED/EDC17 Post by: MIL_on on August 13, 2015, 04:14:07 AM instead of starting a new topic, i would like to go on here! One more time i am searching something without success :D
i am trying to find a solution for patching tprot 5-7 in BMW EDC17 of the E-Models EDC17C06, EDC17CP02 to write them via OBD once you unlocked them. Should be managable i thought....but i failed with this assumption. It seems that it isnt implemented the same way it is in the VAG Ecus. I decided to compare it with a MED17.5 which should be the best comparison as it has the same Tprot-Stage and the same Processor. In those VAG Versions theres always a jump to a subroutine zeroed: 2B3Ch - 0000:8000ACD8 j16 loc_8000AD2E ; Jump to TPROT by writing 2B3C to 0000 you disable the whole jump. the subroutine which gets blocked this way looks like this: 0000:8000AD2E loc_8000AD2E: ; CODE XREF: sub_8000AC60+78j 0000:8000AD2E movh.a a2, #0xD001 load a2 with 0xD001000 0000:8000AD32 mov16 d1, #0 load d1 0x01 0000:8000AD34 mov32 d0, #0x10 load d0 0x10 0000:8000AD38 lea a15, [a0]0x19A3 0000:8000AD3C mov16 d2, #1 load d2 0x01 0000:8000AD3E st16.b [a12], d0 0000:8000AD40 lea a2, [a2]-0x34CE build effective address: 0xD0010000-0x34CE = 0xD000CB32 0000:8000AD44 st16.b [a13], d1 0000:8000AD46 st16.b [a15]0, d1 0000:8000AD48 st16.b [a2], d2 put 0x01 to Adresse which is hold in RAM-Cell 0xD000CB32 0000:8000AD4A j32 loc_8000B076 jump back to ret the call of this subroutine is based on what d2 holds before: d2=0 --> jump to 8000ACDA d2=2 --> jump to 8000B076 otherwise jump to the [now blocked] subroutine 8000AD2E. At its end this also just jumps to 8000B076. So by simply preventing to write this 0x01 to the Address which is hold by 0xD000CB32 and 0x0 to the address which is held by a15 the tprot isnt active. I think that this procedure should be quiet similar regardless of the manufacturer? Comparing Op-Code did lead to a few assumptions of course, but none of them was proven to be correct. I also tried to check if Magic Motorsport Tprot off for VAG Ecus might work in this case, but i guess the jump which got modified is wrong as you can find the same sequence in another part of the VAG File! I attached the two files i used to compare and also the working tprot off file for VAG and the automatic created (wrong?) tprot off file for the bmw Title: Re: Disassembling MED/EDC17 Post by: tobygolf66 on September 25, 2015, 01:38:09 AM MIL_On , did you have tested now your Exx Tprot off solution ??
Is it working ? Rgds Title: Re: Disassembling MED/EDC17 Post by: ozzy_rp on October 04, 2015, 04:40:32 AM Some useful information for disasembling MED17.5
1. Calibration area start 0x80040000 size 0x40000. In some units size 0x30000. Other space used for code. 2. The main code is executed directly from the flash. But there is a piece of code that is loaded into RAM. 3.To access the data using different addressing modes: a: movh.a a15, #@HIS(CRC_end_addr) ; st32.w [a15]@LOS(CRC_end_addr), d0 ; b: sha16 d15, #4 movh.a a3, #@HIS(RAM_crc_table) ; lea a3, [a3]@LOS(RAM_crc_table) ; addsc16.a a2, a3, d15, #0 ; c: movh d15, #0xF000 addi d15, d15, #0x4000 ; Load 0xF0004000 d: ld32.w d15, [a0]-0x5F10 4. The main addressing modes is an indirect addressing with address register. These registers contain base addresses for FLASH, RAM and Calibration. Address register a1 used to access data in FLASH. lea a15, [a1]0x52BA ld.hu d15, [a15]0 Address register a0 used to access data in RAM. st32.w [a0]0x414, d10 ; Store to 0xD000B394 ; Can ID Address register a9 used to access data in Calibration Area. ld32.w d15, [a9]0x638 ; mov16.a a15, d15 lea a4, [a15]0x69E ; Title: Re: Disassembling MED/EDC17 Post by: Ionut on October 05, 2015, 03:33:04 PM So, to be sure i`m not making a mistake.
Should load int flash to 0x8000000 and create ram segments at 0xC000000 and 0xD0000000 What to load at 0xA0000000? Ext flash or other thing? Code: movh.a a2, #0xD001 Than 0x5F0C is substracted from that value, so actual value of a2 is 0xD000A0F4 But for this: Code: movh.a a12, #0xD001 then a15 is offset by d15 value? then a15 is loaded with 0x80060000 - 0x6E0C (if d15 offset is actually 0) = 800591F4 Basically i want to know how to search for maps references. ozzy_rp, how did you discovered that 0x80153DDC is address for table with references? Title: Re: Disassembling MED/EDC17 Post by: ozzy_rp on October 05, 2015, 11:52:30 PM So, to be sure i`m not making a mistake. Flash memory from 0x80000000h mirrored with 0xA0000000HShould load int flash to 0x8000000 and create ram segments at 0xC000000 and 0xD0000000 What to load at 0xA0000000? Ext flash or other thing? Code: movh.a a2, #0xD001 Than 0x5F0C is substracted from that value, so actual value of a2 is 0xD000A0F4 But for this: Code: movh.a a12, #0xD001 then a15 is offset by d15 value? then a15 is loaded with 0x80060000 - 0x6E0C (if d15 offset is actually 0) = 800591F4 Basically i want to know how to search for maps references. ozzy_rp, how did you discovered that 0x80153DDC is address for table with references? a15 loaded with 0x80060000 then calc with offset in d15. and load to a15 word from [a15]-0x6E0C :) Pay attention to instruction "LEA" and "LD" I don't find 0x80153DDC in disasembly:( http://nefariousmotorsports.com/forum/index.php?topic=6990.msg72154#msg72154 Title: Re: Disassembling MED/EDC17 Post by: MIL_on on October 09, 2015, 04:02:12 AM Ionut: Make sure you understand how the map-adresses are called:
1. You have the Table which is filled with Adresses of "areas" but not each single map-adress is stored here, otherwise it might become too big. 2. from the Adress stored in the table you are able to take short offsets which can be stored in 16 bit. Adresses for better understanding: rlmx_w = D0001662 Axis Length(0x0012) = 0x8005B05C Axis = 0x8005B05E - 0x8005B081 LDRXNZK = 0x8005B082 - 0x8005B0A5 so if you are going to reverse the whole mechanism you would start like this: -you know where your LDRXN-Map and Axis starts and you know which variable gets stored in the routine which uses these maps (rlmx_w). So you take your RAM-Adress of the Variable (rlmx_w) and use the Cross-Reference function. There are 2 Routines which write into that ram cell and 1 reading it. You know that it gets written by the LDRXN Routine, so you are going down one of those 2 paths. in this routine you will find the following Code: This is based on the 5K0907115, 0261204474, 1037500440 File! 0000:80106C62 ld32.w d15, [a9]0x638 // Table-Index = a9+offset --> Take adress from [Tablestart+0x638] 0000:80106C66 madd d15, d15, d0, #0x4A // choose LDRXN-Map based on Gearbox-Variant ( 0x4A is the length of one complete Table+Axis+Axis Description!) and store it in d15 again. Lets guess we have a manual trans, so d0 will be 0. 0000:80106C6A ld.hu d4, nmot_w 0000:80106C6E mov16.a a15, d15 // store Adress in adress-register 0000:80106C70 lea a4, [a15]0x69E // load effective adress: a15 holds at that moment [Table-entry+0*0x4A] and we add another 0x69E to that Adress and store it in a4. if you dive into the subfunction which gets called in the next line you will find that a4 has to hold the length of the axis and this is @ Adress 8005B05C. 0000:80106C74 call32 sub_800FDC72 0000:80106C78 st32.h rlmx_w, d2 0000:80106C7C j16 loc_80106C86 So as you know that the end of the calculation has to be 0x8005B05C you can go reverse by: 0x8005B5C - 0x69E = 0x8005A9BE. Search for 8005A9BE in your Hex-Editor in 32bit mode and you will find it @ 0x8016E020. From here you know that you have to subtract 0x638 to get to the table-start! This delivers 0x8016D9E8 which you can use now for all other equations! Subroutine not explained: 0000:800FDC72 sub_800FDC72: ; CODE XREF: ROM:80071FA8p 0000:800FDC72 ; ROM:80072004p ... 0000:800FDC72 mov16 d5, d4 0000:800FDC74 mov16.aa a15, a4 0000:800FDC76 ld.hu d15, [a15+]2 0000:800FDC7A mov16 d4, d15 0000:800FDC7C mov16.aa a4, a15 0000:800FDC7E call32 sub_80121FDC 0000:800FDC82 addsc16.a a4, a15, d15, #1 0000:800FDC84 mov16 d4, d2 0000:800FDC86 j32 sub_800FA5EE 0000:800FDC86 ; End of function sub_800FDC72 Title: Re: Disassembling MED/EDC17 Post by: ozzy_rp on October 11, 2015, 08:16:50 AM Small hint to find a0 and a1.
from my med17 file. PFLASH:8010EB0E mfcr d0, #0xFE04 PFLASH:8010EB12 or32 d15, d0, #0x100 PFLASH:8010EB16 mtcr #0xFE04, d15 PFLASH:8010EB1A isync PFLASH:8010EB1E movh.a a0, #@HIS(Base_a0_addr) ; Load base address for RAM PFLASH:8010EB22 lea a0, [a0]@LOS(Base_a0_addr) ; Load base address for RAM offsets PFLASH:8010EB26 movh.a a1, #@HIS(Base_a1_addr) ; Base a1 address 0x8002CE78 PFLASH:8010EB26 ; for offsets PFLASH:8010EB2A lea a1, [a1]@LOS(Base_a1_addr) ; Load base address 0x8002CE78 PFLASH:8010EB2E mov16.a a8, #0 PFLASH:8010EB30 mov16.a a9, #0 PFLASH:8010EB32 mtcr #0xFE04, d0 PFLASH:8010EB36 isync PFLASH:8010EB3A isync PFLASH:8010EB3E dsync PFLASH:8010EB42 mfcr d0, #0xFE00 PFLASH:8010EB46 movh d1, #0xFFF0 PFLASH:8010EB4A and16 d0, d1 PFLASH:8010EB4C mtcr #0xFE00, d0 PFLASH:8010EB50 isync PFLASH:8010EB54 movh d0, #0xD000 PFLASH:8010EB58 addi d0, d0, #0x18 PFLASH:8010EB5C addi d0, d0, #0x3F Title: Re: Disassembling MED/EDC17 Post by: hackish on October 20, 2015, 07:23:28 AM Something to keep in mind, make sure you're running the absolute latest release of IDA Pro. The last tricore file I worked on (this summer) I found a significant number of bugs in the tricore module. Ilfak fixed them (within hours as he usually does) and sent me an updated processor module. It made a huge difference on things that were disassembling completely wrong. I expect that it's been released with the latest update but make sure you're not on an old version.
Title: Re: Disassembling MED/EDC17 Post by: terminator on October 20, 2015, 11:40:56 AM Bug? For example?
Title: Re: Disassembling MED/EDC17 Post by: ozzy_rp on October 20, 2015, 01:00:43 PM I have seen bug with post increment indirect addressing with offset....
Title: Re: Disassembling MED/EDC17 Post by: hackish on October 26, 2015, 10:40:34 PM Bug? For example? I don't remember all of them. That was like 6 months and 3 processors ago. There was a lot of incorrectly decoded instructions/offsets in there. Check out the changes log - they usually list the fixes they made in there. Title: Re: Disassembling MED/EDC17 Post by: dream3R on December 25, 2015, 04:49:14 PM Tricore is difficult with the net versions lol.
Title: Re: Disassembling MED/EDC17 Post by: dream3R on December 30, 2015, 07:38:10 PM I wish he did a version for non pro outfits. It's great and expensive too.
Title: Re: Disassembling MED/EDC17 Post by: kuebk on February 24, 2016, 03:50:24 PM Very interesting topic. I'm trying my best to understand the ASM which stays behind our EDC17 ECUs but I can't make past such subroutines:
Quote ROM:0014E760 sub_14E760: ; CODE XREF: sub_532DE+BD8p ROM:0014E760 ; sub_532DE+C42p ... ROM:0014E760 movh.a a2, #@HIS(unk_D40009D8) ROM:0014E764 lea a2, [a2]@LOS(unk_D40009D8) ROM:0014E768 nop16 ROM:0014E76A ji16 a2 ROM:0014E76A ; End of function sub_14E760 I have no idea how can I find out what is going to be executed, can you guys give me any tips? Title: Re: Disassembling MED/EDC17 Post by: ozzy_rp on February 24, 2016, 11:27:14 PM In this block, have several procedures that copy data from FLASH to RAM.
They use a structure such as: Code: PFLASH:8002DDBC stru_8002DDBC copy_block_struct2 <unk_D4001520, PRAM_data, 0> Title: Re: Disassembling MED/EDC17 Post by: kuebk on February 25, 2016, 12:52:02 PM Thank you. :)
So it seems like: Code: ROM:8002ACC0 copy_block <0xC0003BE0, 0x80023F58, 0xCA0> Code: ROM:8014E760 sub_14E760: ; CODE XREF: sub_532DE+BD8p But at 8000989D I'm landing in the middle of other subroutine: Code: ROM:80009870 sub_9870: ; CODE XREF: ROM:00009732p I think my calculations are not done correctly, what you think? Title: Re: Disassembling MED/EDC17 Post by: ozzy_rp on February 25, 2016, 03:41:40 PM Thank you. :) You wrong at:So it seems like: ROM:8002ACC0 copy_block <0xC0003BE0, 0x80023F58, 0xCA0> ROM:8002ACCC copy_block <0xC0004880, 0x80024BF8, 0x4B6> ROM:8002ACD8 copy_block <0xD000E000, 0x800250AE, 0> ROM:8002ACE4 copy_block <0xD4000000, 0x80020098, 0x1620> ROM:8002ACF0 copy_block <0xF0060000, 0x800223B8, 0x1BA0> ROM:8002ACFC copy_block <0xF0050000, 0x800216B8, 0xD00> ROM:8014E760 sub_14E760: ; CODE XREF: sub_532DE+BD8p ROM:8014E760 ; sub_532DE+C42p ... ROM:8014E760 movh.a a2, #@HIS(unk_D40009D8) ; D40009D8 = 0x80020A70 = 0x49094F94 // a2 = 4909 ROM:8014E764 lea a2, [a2]@LOS(unk_D40009D8) // a2 = 4909 + 4f94 ROM:8014E768 nop16 ROM:8014E76A ji16 a2 // a2 = 989D ROM:8014E76A ; End of function sub_14E760 But at 8000989D I'm landing in the middle of other subroutine: I think my calculations are not done correctly, what you think? ROM:8014E764 lea a2, [a2]@LOS(unk_D40009D8) // a2 = 4909 + 4f94 Here a2=0xD40009D8 And 0xD40009D8-0xD4000000=0x9D8 Remember copy_block <0xD4000000, 0x80020098, 0x1620> Add 0x9D8 to 0x80020098 and we have 0x80020A70 Title: Re: Disassembling MED/EDC17 Post by: superglitch on March 15, 2016, 03:36:45 PM movh.a a15, #@HIS(CRC_end_addr) ; st32.w [a15]@LOS(CRC_end_addr), d0 ; b: sha16 d15, #4 movh.a a3, #@HIS(RAM_crc_table) ; lea a3, [a3]@LOS(RAM_crc_table) ; addsc16.a a2, a3, d15, #0 ; Do you have these actually defined? Curious what they are. Title: Re: Disassembling MED/EDC17 Post by: ozzy_rp on March 16, 2016, 07:03:35 AM Do you have these actually defined? Curious what they are. I look to asm code and i define myself variables, constants, structures, etc... :))) Title: Re: Disassembling MED/EDC17 Post by: superglitch on March 17, 2016, 08:48:02 AM I look to asm code and i define myself variables, constants, structures, etc... :))) I'm still curious if you would share their addresses? I'm versed in RE, just looking for a starting point rather than starting from scratch. Title: Re: Disassembling MED/EDC17 Post by: kuebk on March 24, 2016, 12:28:02 PM There are a lot of interesting measuring points in RAM which are not accessible through measuring blocks, what would be the best way to access them? I was thinking about messing with measuring blocks maps but I'm not sure if other (than already defined) measuring points can be added/modified. Or maybe there is other way to achieve this?
Title: Re: Disassembling MED/EDC17 Post by: dream3R on April 11, 2016, 01:21:27 PM There are a lot of interesting measuring points in RAM which are not accessible through measuring blocks, what would be the best way to access them? I was thinking about messing with measuring blocks maps but I'm not sure if other (than already defined) measuring points can be added/modified. Or maybe there is other way to achieve this? RAM logging? Measuring blocks can be altered too there's a thread on here. Title: Re: Disassembling MED/EDC17 Post by: kuebk on April 11, 2016, 03:10:26 PM You mean this thread: http://nefariousmotorsports.com/forum/index.php?topic=5941.0title=?
Title: Re: Disassembling MED/EDC17 Post by: dream3R on April 11, 2016, 08:39:36 PM think so
Title: Re: Disassembling MED/EDC17 Post by: kuebk on April 21, 2016, 01:22:29 PM The biggest problem with changing RAM addresses for measuring blocks is you need to do it in bootmode, is there any other solution? I found CANape from Vector but I can't afford 6k euro for cheapest solution from them.
Title: Re: Disassembling MED/EDC17 Post by: prj on April 21, 2016, 01:45:56 PM The biggest problem with changing RAM addresses for measuring blocks is you need to do it in bootmode No you don't, get proper tools. Title: Re: Disassembling MED/EDC17 Post by: kuebk on April 21, 2016, 01:47:26 PM Can you please suggest me proper tools?
Title: Re: Disassembling MED/EDC17 Post by: dream3R on April 22, 2016, 10:23:36 PM MPPS @ Cartech
Title: Re: Disassembling MED/EDC17 Post by: kuebk on April 23, 2016, 02:01:00 AM I already got genuine MPPS, how can I use it for ram logging? I'm not very experienced (yet) in this - could you please share any links so I could read more?
Title: Re: Disassembling MED/EDC17 Post by: dream3R on April 23, 2016, 05:25:26 AM MPPS wont do RAM logging but it should let you write the code block instead of using a BDM. Make sure you have a backup :)
Title: Re: Disassembling MED/EDC17 Post by: Teitek on April 27, 2016, 10:47:55 AM Hi.
What software used to build new code ? Tasking Astri? i see that this software is not free. Title: Re: Disassembling MED/EDC17 Post by: dream3R on April 27, 2016, 10:51:06 AM Tasking for C167 not sure on Tricore
Title: Re: Disassembling MED/EDC17 Post by: Teitek on April 27, 2016, 11:06:00 AM Tasking for C167 not sure on Tricore Hi dream3R, yes, too for Tricore. http://tasking.com/products/tricore In IDA appear in target assembler: Tasking ASTRI and Tasking VX Title: Re: Disassembling MED/EDC17 Post by: dream3R on May 02, 2016, 06:50:25 PM correct, I was talking with the owner of mpps last week not sure I said was correct about tools, but this is tricore and we were discussing an older ecu.
Title: Re: Disassembling MED/EDC17 Post by: kuebk on May 07, 2016, 12:36:49 PM I was asking about EDC17.
Title: Re: Disassembling MED/EDC17 Post by: dream3R on May 07, 2016, 01:07:50 PM I was asking about EDC17. My bad, some GNU toolchain for Tricore will have been used, why do you want to know? Title: Re: Disassembling MED/EDC17 Post by: kuebk on June 14, 2016, 03:05:08 PM I would like to know what hardware/software is required to do RAM logging on EDC17, the informations which are available on the web are not much friendly for non experienced people.
Title: Re: Disassembling MED/EDC17 Post by: dream3R on June 14, 2016, 06:04:37 PM Can controller/transceiver and software and knowledge of the diag session and seeds.
Title: Re: Disassembling MED/EDC17 Post by: kuebk on January 13, 2017, 09:21:57 AM I the RAM logging is done (no idea why did I wrote about that in this thread), but back to topic got a question regarding ASM:
Code: mul32 e0, d0, d2 Ex register is 64bit, but what does mul32 mean in that case? Will it strip 64bit result to 32bit and put it to d0 without touching d1, or maybe different way? Title: Re: Disassembling MED/EDC17 Post by: superglitch on February 18, 2017, 06:34:21 PM Anyone know where the jump table is for the logging is on any med17's?
EDIT: Figured it out. Most things that you'd want to log for tuning or code hacks already exists, can all be adjusted in WinOLS no need for IDA. Title: Re: Disassembling MED/EDC17 Post by: jcsbanks on February 26, 2017, 05:41:57 AM mul32 is a 32 bit instruction length. When you assemble with Tricore you just write mul.
Title: Re: Disassembling MED/EDC17 Post by: vwphun on July 09, 2018, 01:18:01 AM What about crypted ImmoData in EEPROM? CRC is clear now (thanks ozzy_rp and H2DeeToo) espec. data block ID 0x08 0x09 0x0A? How are crypted CS, PIN, MAC in eeprom with data from flash OTP sector?
Title: Re: Disassembling MED/EDC17 Post by: navatar_ on November 22, 2019, 11:42:05 AM What about crypted ImmoData in EEPROM? CRC is clear now (thanks ozzy_rp and H2DeeToo) espec. data block ID 0x08 0x09 0x0A? How are crypted CS, PIN, MAC in eeprom with data from flash OTP sector? Have been looking for this answer for the last few days. I think I am correct in saying the relevant OTP data is stored at 0x17f00 - 0x17f7f and is somehow crypted with immodata. Initially I thought it would be a simple xor substitution based cipher but now I'm not so sure. Title: Re: Disassembling MED/EDC17 Post by: AngelPowy on January 27, 2020, 05:07:55 AM Ionut: Make sure you understand how the map-adresses are called: Did you find your A2L on this forum? Or would you mind to share it?1. You have the Table which is filled with Adresses of "areas" but not each single map-adress is stored here, otherwise it might become too big. 2. from the Adress stored in the table you are able to take short offsets which can be stored in 16 bit. Adresses for better understanding: rlmx_w = D0001662 Axis Length(0x0012) = 0x8005B05C Axis = 0x8005B05E - 0x8005B081 LDRXNZK = 0x8005B082 - 0x8005B0A5 so if you are going to reverse the whole mechanism you would start like this: -you know where your LDRXN-Map and Axis starts and you know which variable gets stored in the routine which uses these maps (rlmx_w). So you take your RAM-Adress of the Variable (rlmx_w) and use the Cross-Reference function. There are 2 Routines which write into that ram cell and 1 reading it. You know that it gets written by the LDRXN Routine, so you are going down one of those 2 paths. in this routine you will find the following Code: This is based on the 5K0907115, 0261204474, 1037500440 File! 0000:80106C62 ld32.w d15, [a9]0x638 // Table-Index = a9+offset --> Take adress from [Tablestart+0x638] 0000:80106C66 madd d15, d15, d0, #0x4A // choose LDRXN-Map based on Gearbox-Variant ( 0x4A is the length of one complete Table+Axis+Axis Description!) and store it in d15 again. Lets guess we have a manual trans, so d0 will be 0. 0000:80106C6A ld.hu d4, nmot_w 0000:80106C6E mov16.a a15, d15 // store Adress in adress-register 0000:80106C70 lea a4, [a15]0x69E // load effective adress: a15 holds at that moment [Table-entry+0*0x4A] and we add another 0x69E to that Adress and store it in a4. if you dive into the subfunction which gets called in the next line you will find that a4 has to hold the length of the axis and this is @ Adress 8005B05C. 0000:80106C74 call32 sub_800FDC72 0000:80106C78 st32.h rlmx_w, d2 0000:80106C7C j16 loc_80106C86 So as you know that the end of the calculation has to be 0x8005B05C you can go reverse by: 0x8005B5C - 0x69E = 0x8005A9BE. Search for 8005A9BE in your Hex-Editor in 32bit mode and you will find it @ 0x8016E020. From here you know that you have to subtract 0x638 to get to the table-start! This delivers 0x8016D9E8 which you can use now for all other equations! Subroutine not explained: 0000:800FDC72 sub_800FDC72: ; CODE XREF: ROM:80071FA8p 0000:800FDC72 ; ROM:80072004p ... 0000:800FDC72 mov16 d5, d4 0000:800FDC74 mov16.aa a15, a4 0000:800FDC76 ld.hu d15, [a15+]2 0000:800FDC7A mov16 d4, d15 0000:800FDC7C mov16.aa a4, a15 0000:800FDC7E call32 sub_80121FDC 0000:800FDC82 addsc16.a a4, a15, d15, #1 0000:800FDC84 mov16 d4, d2 0000:800FDC86 j32 sub_800FA5EE 0000:800FDC86 ; End of function sub_800FDC72 Best regards Title: Re: Disassembling MED/EDC17 Post by: Jonny_Z on February 08, 2020, 05:54:07 AM I found some registers like "e2" in MEDC17:
Code: PFLASH:8009286A movh.a a2, #@HIS(unk_D0009B74) It looks like no connection with the whole subroutine, i think i must miss something, could you guys give me a tip? Title: Re: Disassembling MED/EDC17 Post by: gt-innovation on February 08, 2020, 06:26:47 AM I found some registers like "e2" in MEDC17: Code: PFLASH:8009286A movh.a a2, #@HIS(unk_D0009B74) It looks like no connection with the whole subroutine, i think i must miss something, could you guys give me a tip? https://www.infineon.com/dgdl/tc_v131_instructionset_v138.pdf?fileId=db3a304412b407950112b409b6dd0352 page 162 Title: Re: Disassembling MED/EDC17 Post by: Jonny_Z on February 08, 2020, 09:52:31 AM https://www.infineon.com/dgdl/tc_v131_instructionset_v138.pdf?fileId=db3a304412b407950112b409b6dd0352 page 162 What i confused is after the register e2 loads the divided value, there is no next step(load it to a memory address or ...) that i can find. Title: Re: Disassembling MED/EDC17 Post by: prj on February 11, 2020, 06:07:39 AM What i confused is after the register e2 loads the divided value, there is no next step(load it to a memory address or ...) that i can find. Page 46. Title: Re: Disassembling MED/EDC17 Post by: Jonny_Z on February 11, 2020, 11:08:30 PM Page 46. Thanks Prj, i should read the instruction again. Title: Re: Disassembling MED/EDC17 Post by: Praga on April 22, 2020, 04:30:24 PM Great post guys I recently started with MED17.5
Any hints what this subroutine does ? sub_8003A594: ; CODE XREF: sub_8003A77E+6Ep 0000:8003A594 ; sub_8003A82C+84p ... 0000:8003A594 jge.u d4, #0xC, loc_8003A612 0000:8003A598 sha32 d1, d4, #1 0000:8003A59C lea a15, [a0]-0x28DA 0000:8003A5A0 nor32 d0, d5, #0 0000:8003A5A4 lea a3, [a0]-0x28E2 0000:8003A5A8 addsc32.a a15, a15, d1, #0 0000:8003A5AC lea a2, [a0]-0x28DA 0000:8003A5B0 ld16.h d15, [a15]0 0000:8003A5B2 and16 d15, d0 0000:8003A5B4 st16.h [a15]0, d15 0000:8003A5B6 mov16 d0, #0 0000:8003A5B8 mov16.a a15, #0xB 0000:8003A5BA 0000:8003A5BA loc_8003A5BA: ; CODE XREF: sub_8003A594+2Cj 0000:8003A5BA ld.hu d15, [a2+]2 0000:8003A5BE or16 d0, d15 0000:8003A5C0 loop16 a15, loc_8003A5BA 0000:8003A5C2 lea a15, [a0]-0x28DA 0000:8003A5C6 st16.h [a3], d0 0000:8003A5C8 addsc32.a a15, a15, d1, #0 0000:8003A5CC ld.hu d15, [a15]0 0000:8003A5D0 jnz16 d15, loc_8003A5E2 0000:8003A5D2 mov16 d15, #-2 0000:8003A5D4 lea a15, [a0]-0x28DE 0000:8003A5D8 dextr d15, d15, d15, d4 0000:8003A5DC ld16.h d0, [a15]0 0000:8003A5DE and16 d0, d15 0000:8003A5E0 st16.h [a15]0, d0 0000:8003A5E2 0000:8003A5E2 loc_8003A5E2: ; CODE XREF: sub_8003A594+3Cj 0000:8003A5E2 ld.hu d15, [a3]0 0000:8003A5E6 jz16 d15, loc_8003A612 0000:8003A5E8 lea a15, [a0]-0x28DE 0000:8003A5EC ld.hu d15, [a15]0 0000:8003A5F0 jnz16 d15, loc_8003A612 0000:8003A5F2 lea a2, [a0]-0x28DA 0000:8003A5F6 mov16.a a15, #0xB 0000:8003A5F8 0000:8003A5F8 loc_8003A5F8: ; CODE XREF: sub_8003A594+66j 0000:8003A5F8 st16.h [a2+]2, d15 0000:8003A5FA loop16 a15, loc_8003A5F8 0000:8003A5FC mov16 d0, #0 0000:8003A5FE lea a2, [a0]-0x28DA 0000:8003A602 mov16.a a15, #0xB 0000:8003A604 0000:8003A604 loc_8003A604: ; CODE XREF: sub_8003A594+76j 0000:8003A604 ld.hu d15, [a2+]2 0000:8003A608 or16 d0, d15 0000:8003A60A loop16 a15, loc_8003A604 0000:8003A60C lea a15, [a0]-0x28E2 0000:8003A610 st16.h [a15]0, d0 0000:8003A612 0000:8003A612 loc_8003A612: ; CODE XREF: sub_8003A594j 0000:8003A612 ; sub_8003A594+52j ... 0000:8003A612 ret16 Thanks Title: Re: Disassembling MED/EDC17 Post by: 360trev on February 01, 2022, 04:34:16 AM Great post guys I recently started with MED17.5 Any hints what this subroutine does ? sub_8003A594: ; CODE XREF: sub_8003A77E+6Ep 0000:8003A594 ; sub_8003A82C+84p ... 0000:8003A594 jge.u d4, #0xC, loc_8003A612 0000:8003A598 sha32 d1, d4, #1 0000:8003A59C lea a15, [a0]-0x28DA 0000:8003A5A0 nor32 d0, d5, #0 0000:8003A5A4 lea a3, [a0]-0x28E2 0000:8003A5A8 addsc32.a a15, a15, d1, #0 0000:8003A5AC lea a2, [a0]-0x28DA 0000:8003A5B0 ld16.h d15, [a15]0 0000:8003A5B2 and16 d15, d0 0000:8003A5B4 st16.h [a15]0, d15 0000:8003A5B6 mov16 d0, #0 0000:8003A5B8 mov16.a a15, #0xB 0000:8003A5BA 0000:8003A5BA loc_8003A5BA: ; CODE XREF: sub_8003A594+2Cj 0000:8003A5BA ld.hu d15, [a2+]2 0000:8003A5BE or16 d0, d15 0000:8003A5C0 loop16 a15, loc_8003A5BA 0000:8003A5C2 lea a15, [a0]-0x28DA 0000:8003A5C6 st16.h [a3], d0 0000:8003A5C8 addsc32.a a15, a15, d1, #0 0000:8003A5CC ld.hu d15, [a15]0 0000:8003A5D0 jnz16 d15, loc_8003A5E2 0000:8003A5D2 mov16 d15, #-2 0000:8003A5D4 lea a15, [a0]-0x28DE 0000:8003A5D8 dextr d15, d15, d15, d4 0000:8003A5DC ld16.h d0, [a15]0 0000:8003A5DE and16 d0, d15 0000:8003A5E0 st16.h [a15]0, d0 0000:8003A5E2 0000:8003A5E2 loc_8003A5E2: ; CODE XREF: sub_8003A594+3Cj 0000:8003A5E2 ld.hu d15, [a3]0 0000:8003A5E6 jz16 d15, loc_8003A612 0000:8003A5E8 lea a15, [a0]-0x28DE 0000:8003A5EC ld.hu d15, [a15]0 0000:8003A5F0 jnz16 d15, loc_8003A612 0000:8003A5F2 lea a2, [a0]-0x28DA 0000:8003A5F6 mov16.a a15, #0xB 0000:8003A5F8 0000:8003A5F8 loc_8003A5F8: ; CODE XREF: sub_8003A594+66j 0000:8003A5F8 st16.h [a2+]2, d15 0000:8003A5FA loop16 a15, loc_8003A5F8 0000:8003A5FC mov16 d0, #0 0000:8003A5FE lea a2, [a0]-0x28DA 0000:8003A602 mov16.a a15, #0xB 0000:8003A604 0000:8003A604 loc_8003A604: ; CODE XREF: sub_8003A594+76j 0000:8003A604 ld.hu d15, [a2+]2 0000:8003A608 or16 d0, d15 0000:8003A60A loop16 a15, loc_8003A604 0000:8003A60C lea a15, [a0]-0x28E2 0000:8003A610 st16.h [a15]0, d0 0000:8003A612 0000:8003A612 loc_8003A612: ; CODE XREF: sub_8003A594j 0000:8003A612 ; sub_8003A594+52j ... 0000:8003A612 ret16 Thanks This is in the MED17 ignition code, its fade in Ignition Pattern, igndd_fadeInIgnPattern() Title: Re: Disassembling MED/EDC17 Post by: Abricosvw on February 06, 2022, 09:16:14 PM hi
I am interested in the work and changes (editing) of the internal program of the processor (maps, can-bus messages,RAM, e.t.s) i am not understand wher take this data ??? how to take this data ??? movh.a a15, #0xC000 lea a15, [a15]0x565A this mean a15=0xC000565A infineon has development software for these tricore chips https://free-entry-toolchain.hightec-rt.com/ https://hightec-rt.com/en/products/development-platform.html also they have development boards on these processors my chip TC1767 https://www.mouser.com/ProductDetail/Infineon-Technologies/KITTC1767SKTOBO1?qs=sGAEpiMZZMv0NwlthflBi%2FrZhBsGqdRlK%252BTW8zkDb4k%3D maybe there are options to use this toolchain in IDA ??? Title: Re: Disassembling MED/EDC17 Post by: aymen on December 18, 2022, 06:31:55 AM hello all member , i am beginner and i am very curious about med17.5 inside . i bought a file with multimap for my car .. it work fine..
my question :Can someone point me how i can run ram loading/rom adresses for those tricore ? Title: Re: Disassembling MED/EDC17 Post by: aymen on December 18, 2022, 06:51:59 AM hello all member , i am beginner and i am very curious about med17.5 inside . i bought a file with multimap for my car .. it work fine..
my question :Can someone point me how i can run ram loading/rom adresses for those tricore ? Title: Re: Disassembling MED/EDC17 Post by: fknbrkn on January 18, 2024, 05:16:15 AM Well im stuck with MED17 reversing
*Im totally new to MED17 rev btw* Trying to find FHOKH/CDKATSP and so on in unknown sw 04E906057EL which is different to any defined MED17.5.25 i have So ive got IDA8.3 and Ghidra here, also i know that fho_w get comparison with FHOKH and thats my hook Load 06J907309A in IDA, using prjs a2l() and indirect() functions, retrieve a0, a1, stuck with a9 for a while but finally im able to get it (8014FAD8) and now my code is pretty fine Code: PFLASH:800615A2 000 ld32.a a15, [a9](off_8014FD6C - off_8014FAD8) Well i had to manually check PFLASH @ 8014FD6C to get the second base 801CF17A and then apply this to map offset Whats next? Ive got no variables, no offsets at unknown file Im only able to get a0, a1 Cannot use xrefs to variables to find a corresponding routine Seems that the code is a different so i have no luck to trace it with some similar instructions Questions: 1. Is there any script that get the a9 base + offset and checking value in flash and then applies this to a map offset to get nice xrefs? 2. How can i hook to an unknown file? In me7 im able to get some variables with me7logger file and then tracking down to routine but idk how to handle med17 in that way 3. Ghidra shows nice pseudocode, ive set registers but idk how to fix that poor result It groups a0,a1 and a8 a9 Code:
Title: Re: Disassembling MED/EDC17 Post by: prj on January 18, 2024, 05:57:29 AM xrefs to flash in IDA could be possible by doing an "indirect" on a9 but I've never tried.
a9 points to module table. The ram variables should all show up if you have a2l loaded. If they don't show up then a0/a8 are not set correctly. Keep in mind there are 3 apps in the flash: 1. SBOOT 2. CBOOT 3. ASW They all use different configs for globals, make sure you're taking the config from ASW. Title: Re: Disassembling MED/EDC17 Post by: fknbrkn on January 18, 2024, 06:08:37 AM xrefs to flash in IDA could be possible by doing an "indirect" on a9 but I've never tried. Ram variables xrefs works fine in defined file, I have to manually define offset to a map/param but that's finea9 points to module table. The ram variables should all show up if you have a2l loaded. If they don't show up then a0/a8 are not set correctly. Keep in mind there are 3 apps in the flash: 1. SBOOT 2. CBOOT 3. ASW They all use different configs for globals, make sure you're taking the config from ASW. I dont have any a2l or other definition of an another target file. For now I just want to find maps in it. So the main question - how can I find the variables (and then maps) if I don't have any defined Title: Re: Disassembling MED/EDC17 Post by: prj on January 20, 2024, 07:33:42 AM Method 1:
Take a file where you have the a2l, that has similar structure. Find the function in the file that you have a2l for. Make a mask from something in the subroutine, masking out the addresses (AA BB ?? ?? CC ?? etc) and search for it with alt+b to (hopefully) locate it in the file you don't have anything for. Method 2: If you were able to find the same module in the other file calibration area, find the offset of that module from start of module table and search for the [a9]0x1234 load, then you land in the routines that load stuff from this module. Title: Re: Disassembling MED/EDC17 Post by: fknbrkn on January 21, 2024, 09:25:04 AM Method 1: Take a file where you have the a2l, that has similar structure. Find the function in the file that you have a2l for. Make a mask from something in the subroutine, masking out the addresses (AA BB ?? ?? CC ?? etc) and search for it with alt+b to (hopefully) locate it in the file you don't have anything for. Method 2: If you were able to find the same module in the other file calibration area, find the offset of that module from start of module table and search for the [a9]0x1234 load, then you land in the routines that load stuff from this module. After 2 sleepless nights im finally get it )) For the me7 im choosing 1st method due to code and ram-structure pretty similar between ecus but in that case code seems different, im able to find pretty similar block but i was unsure due to different FHOKH values (0.71 vs 0.75) and no similar pattern in nearmap structures so i have to combine them I didnt know that a9 are the modules base (perhaps due to my poor english yay) so thats the key) Well if anyone interested (and as a reminder to myself ::) ) 1st of all i changed prj scripts to be able to use it with IDA8.3 Code: import math Code: import idaapi Now im getting fully defined 06J907309A 0010 file with a2l which i use as a reference and for education purpose, loaded with base 0x80000000 load a2l with Code: a2l("C:/rv/057EL/D1752V02C000B0201g.A2L")Search for "a9," go to "mov16.a a9, #0" youll find that part where a0,a1,a8,a9 getting values and use indirect() to get access to variables, i find a1 pretty useless here Code: indirect("a0",0xD000B600)a9 defined as #0 so with the prjs hint i know that its start or modules reference, this part was unclear to me before Im able to find this code bc i know fho_w compared with FHOKH so this is pretty neat part, im just checking all fho_w refs and choosing one where fho_w compared with <something> Quote PFLASH:800615A2 PFLASH:800615A2 loc_800615A2: ; CODE XREF: sub_80061400+18A↑j PFLASH:800615A2 000 99 9F 14 A0 ld32.a a15, [a9]0x294 PFLASH:800615A6 000 05 DF FA FD ld.hu d15, fho_w PFLASH:800615AA 000 09 F0 EA 08 ld.hu d0, [a15]0x2A PFLASH:800615AE 000 7F F0 05 80 jge.u d0, d15, loc_800615B8 PFLASH:800615B2 000 D5 DA 2F 00 st.t B_khtumres:2, #1 PFLASH:800615B6 000 3C 03 j16 loc_800615BC PFLASH:800615B8 ; --------------------------------------------------------------------------- PFLASH:800615B8 PFLASH:800615B8 loc_800615B8: ; CODE XREF: sub_80061400+170↑j PFLASH:800615B8 ; sub_80061400:loc_8006158E↑j ... PFLASH:800615B8 000 D5 D2 2F 00 st.t B_khtumres:2, #0 PFLASH:800615BC PFLASH:800615BC loc_800615BC: ; CODE XREF: sub_80061400+1B6↑j PFLASH:800615BC 000 05 D4 C0 F9 ld32.h d4, fcoscfmn_w PFLASH:800615C0 000 99 94 14 A0 ld32.a a4, [a9]0x294 PFLASH:800615C4 000 25 D4 C0 59 st32.h fcosawkt_w, d4 PFLASH:800615C8 000 37 04 70 40 extr.u d4, d4, #0, #0x10 PFLASH:800615CC 000 D9 44 34 00 lea a4, [a4]0x34 PFLASH:800615D0 000 ED C0 9D 05 calla unk_C0000B3A PFLASH:800615D4 000 3B F0 00 60 mov32 d6, #0xF PFLASH:800615D8 000 05 D4 C6 5D ld.hu d4, imlskhgs_w PFLASH:800615DC 000 02 25 mov16 d5, d2 PFLASH:800615DE 000 25 D2 FE 49 st32.h word_D0001D3E, d2 PFLASH:800615E2 000 6D 05 DD 03 call32 sub_80101D9C PFLASH:800615E6 000 25 D2 C2 59 st32.h imlskgsa_w, d2 in this file FHOKH @0x801CF1A4 and the first map of the module BBKHAKT is ABKKATTAB 6x1, going to the axis of the map and its size 06 stanging right before the axis @0x801CF17A this is start of the table and start of the BBKHAK module Change in OLS data organization to 32bit lohi and search for 801CF17A -> one result @0x8014FD6C this is module base a9 + offset 0x294 Now 8014FD6C - 294 = 8014FAD8 is the a9 register or start of the modules table, check this offset in hex, this should be first 80xxxxxx or A0xxxxxx in this table, also good sign is the "9000" stanging right before it as its 'rets' instruction okay so Code: indirect("a9",0x8014FAD8)rename 0x8014FAD8 with startOfModules_mod, 0x8014FD6C with BBKHAKT_mod for beatify this code and now BBKHAKT_mod should be referenceable, so im able to find code of all maps in that module (i might be wrong here idk) next step is to manually (i wonder if im able to make this with script, but its too complex for this task) change ld.hu d0, [a15]0x2A to offset variable press CTRL+R where [a15] used -> OFF32, base: 0x801CF17A as its starting of first table in this module in the end this code looks like that, heres 0x801CF1A4 also renamed with FHOKH_map Quote PFLASH:800615A2 000 99 9F 14 A0 ld32.a a15, [a9](BBKHAKT_mod - startOfModules_mod) PFLASH:800615A6 000 05 DF FA FD ld.hu d15, fho_w PFLASH:800615AA 000 09 F0 EA 08 ld.hu d0, [a15](FHOKH_map - unk_801CF17A) PFLASH:800615AE 000 7F F0 05 80 jge.u d0, d15, loc_800615B8 PFLASH:800615B2 000 D5 DA 2F 00 st.t B_khtumres:2, #1 PFLASH:800615B6 000 3C 03 j16 loc_800615BC PFLASH:800615B8 ; --------------------------------------------------------------------------- PFLASH:800615B8 PFLASH:800615B8 loc_800615B8: ; CODE XREF: sub_80061400+170↑j PFLASH:800615B8 ; sub_80061400:loc_8006158E↑j ... PFLASH:800615B8 000 D5 D2 2F 00 st.t B_khtumres:2, #0 PFLASH:800615BC PFLASH:800615BC loc_800615BC: ; CODE XREF: sub_80061400+1B6↑j PFLASH:800615BC 000 05 D4 C0 F9 ld32.h d4, fcoscfmn_w PFLASH:800615C0 000 99 94 14 A0 ld32.a a4, [a9](BBKHAKT_mod - startOfModules_mod) PFLASH:800615C4 000 25 D4 C0 59 st32.h fcosawkt_w, d4 PFLASH:800615C8 000 37 04 70 40 extr.u d4, d4, #0, #0x10 PFLASH:800615CC 000 D9 44 34 00 lea a4, [a4]0x34 PFLASH:800615D0 000 ED C0 9D 05 calla unk_C0000B3A PFLASH:800615D4 000 3B F0 00 60 mov32 d6, #0xF PFLASH:800615D8 000 05 D4 C6 5D ld.hu d4, imlskhgs_w Title: Re: Disassembling MED/EDC17 Post by: elias on January 21, 2024, 09:56:19 AM I want to suggest another method , which i am using all the time in MED9, and
it should work also on MED17: There is a table in flash, which is called KFMWNTK ("measurement blocks-table"), It contains pointers to small functions which will return certain variables. The table is very well defined in the FR and the vars will be always on the same index of that table. Here is a detailed explanation about it for MED9: http://nefariousmotorsports.com/forum/index.php?topic=5941.0title= In MED9 World, there is a tool called "med9info" which can parse this table and show all vars which are defined in this table. I havent seen such a tool in MED17 world yet. If not , i would suggest implementing such a tool. I attached the Table Definition from MED17.5 FR here, so you can have a look what it contains. As soon as you get such tool, its pretty easy to add a lot of variables into ghidra even for binaries where no a2l matches up. Title: Re: Disassembling MED/EDC17 Post by: fknbrkn on January 21, 2024, 10:17:00 AM Now part2 with the unknown file 04E906057EL (btw its 1.6 NA skoda a7)
Ive made same steps with a0,a1,a8 Choosing nearest potentially rare code in block below which i mark yellow color bc all other code are super-common (even with masking out the variables ive got hundred results) Search for '3B F0 00 60 05 D4' gives only few and luckily one of it looks pretty close Quote PFLASH:800840DE D9 0F 7E CB lea a15, [a0](unk_D0006D3E - unk_D000B600) PFLASH:800840E2 09 F0 C0 08 ld.hu d0, [a15]0 PFLASH:800840E6 99 9F 5C 00 ld32.a a15, [a9]0x41C PFLASH:800840EA 09 FF F2 08 ld.hu d15, [a15]0x32 ; <- this one is potentially FHOKH PFLASH:800840EE 7F 0F 05 80 jge.u d15, d0, loc_800840F8 ;<- compared with ram-variable PFLASH:800840F2 D5 DF 36 10 st.t byte_D0000076:7, #1 ;<- set bit 1 or 0 PFLASH:800840F6 3C 03 j16 loc_800840FC PFLASH:800840F8 ; --------------------------------------------------------------------------- PFLASH:800840F8 PFLASH:800840F8 loc_800840F8: ; CODE XREF: sub_80083E00+2AC↑j PFLASH:800840F8 ; sub_80083E00:loc_800840CA↑j ... PFLASH:800840F8 D5 D7 36 10 st.t byte_D0000076:7, #0 PFLASH:800840FC PFLASH:800840FC loc_800840FC: ; CODE XREF: sub_80083E00+2F6↑j PFLASH:800840FC 99 9F 5C 00 ld32.a a15, [a9]0x41C PFLASH:80084100 05 D4 7C B9 ld32.h d4, fcoscfmn_w PFLASH:80084104 09 F5 D2 28 ld.hu d5, [a15]0x92 PFLASH:80084108 25 D4 78 09 st32.h word_D0001438, d4 PFLASH:8008410C 37 04 70 40 extr.u d4, d4, #0, #0x10 PFLASH:80084110 D9 F4 14 20 lea a4, [a15]0x94 PFLASH:80084114 D9 F5 14 20 lea a5, [a15]0x94 PFLASH:80084118 01 55 01 56 addsc32.a a5, a5, d5, #1 PFLASH:8008411C ED C0 ED 0C calla unk_C00019DA PFLASH:80084120 3B F0 00 60 mov32 d6, #0xF PFLASH:80084124 05 D4 7E 0D ld.hu d4, imlskhgs_w PFLASH:80084128 02 25 mov16 d5, d2 PFLASH:8008412A 25 D2 72 09 st32.h word_D0001432, d2 PFLASH:8008412E ED C0 0C 0E calla unk_C0001C18 PFLASH:80084132 25 D2 42 19 st32.h word_D0001442, d2 Thats a good starting point Now im unsure about module start, maybe the good way is to search through some common maps to find first one in any block and get the a9 but im doing this: Search in hex with 32 lohi for from end of the file to beggining (searching from the beggining gives false results) Code: 800?????800?????800?????800?????800?????800?????800?????800?????800?????800?????800?????800?????800?????800?????800?????800?????800????? Results at 0x8016B?? and the table looks like module bases table so i scroll up to Quote F078203B 0003F05F 9000A000 A002018C A0020192 A0020194 A002019C A00201A0 A00201A2 A00201A4 A00201AA A00201B6 A00202E6 A00202F4 A00202FA A0020330 A002033E A0020340 A0020342 A0020346 A0020348 A002034A A002034C A0020350 A0020354 A002035A A00203A8 A00203CA A00203CC A002040C A002041E A002042E A0020430 A0020442 A002044A A0020454 A0020470 A0020482 A0020486 A002048A A002049A A002049E A00204A2 A00205A2 A00205A4 A00205B2 A00205B6 A00205C0 A00205C2 A00205C6 A00205E2 A0020614 A0020660 A00207E6 A00207E8 A0020800 A002085A A00209FC A0020A12 A0020A66 A0020AC4 A0020ACC A0020AD0 A0020AD2 A0020ADE A0020B0A A0020B12 80020C88 80020C8E 80020C90 80020C94 80020C96 80020C9C 80020CA8 80020E28 80020E36 Here i made a mistake and take red one as the start of the table but its at green (and 'rets' or 9000 instruction before it) A002018C stored at 0x8016B08C and thats a start of a modules table Code: indirect("a9",0x8016B08C)after that i renamed 0x8016B08C with startOfModules as i did before Quote PFLASH:800840DE D9 0F 7E CB lea a15, [a0](unk_D0006D3E - unk_D000B600) PFLASH:800840E2 09 F0 C0 08 ld.hu d0, [a15]0 PFLASH:800840E6 99 9F 5C 00 ld32.a a15, [a9](dword_8016B4A8 - startOfModules_mod) PFLASH:800840EA 09 FF F2 08 ld.hu d15, [a15](FHOKH_map - unk_8002DBA2) PFLASH:800840EE 7F 0F 05 80 jge.u d15, d0, loc_800840F8 PFLASH:800840F2 D5 DF 36 10 st.t byte_D0000076:7, #1 PFLASH:800840F6 3C 03 j16 loc_800840FC PFLASH:800840F8 ; --------------------------------------------------------------------------- PFLASH:800840F8 PFLASH:800840F8 loc_800840F8: ; CODE XREF: sub_80083E00+2AC↑j PFLASH:800840F8 ; sub_80083E00:loc_800840CA↑j ... PFLASH:800840F8 D5 D7 36 10 st.t byte_D0000076:7, #0 PFLASH:800840FC PFLASH:800840FC loc_800840FC: ; CODE XREF: sub_80083E00+2F6↑j PFLASH:800840FC 99 9F 5C 00 ld32.a a15, [a9](dword_8016B4A8 - startOfModules_mod) PFLASH:80084100 05 D4 7C B9 ld32.h d4, fcoscfmn_w PFLASH:80084104 09 F5 D2 28 ld.hu d5, [a15](unk_8002DC34 - unk_8002DBA2) PFLASH:80084108 25 D4 78 09 st32.h word_D0001438, d4 PFLASH:8008410C 37 04 70 40 extr.u d4, d4, #0, #0x10 PFLASH:80084110 D9 F4 14 20 lea a4, [a15](unk_8002DC36 - unk_8002DBA2) PFLASH:80084114 D9 F5 14 20 lea a5, [a15](unk_8002DC36 - unk_8002DBA2) PFLASH:80084118 01 55 01 56 addsc32.a a5, a5, d5, #1 PFLASH:8008411C ED C0 ED 0C calla unk_C00019DA PFLASH:80084120 3B F0 00 60 mov32 d6, #0xF PFLASH:80084124 05 D4 7E 0D ld.hu d4, imlskhgs_w PFLASH:80084128 02 25 mov16 d5, d2 PFLASH:8008412A 25 D2 72 09 st32.h word_D0001432, d2 PFLASH:8008412E ED C0 0C 0E calla unk_C0001C18 PFLASH:80084132 25 D2 42 19 st32.h word_D0001442, d2 Checking 0x16B4A8 -> 0x8002DBA2 Quote PFLASH:8016B4A8 A2 DB 02 80 dword_8016B4A8 .word 0x8002DBA2 Seems that dword_8016B4A8 stores the start of first table ABKKATTAB(?) in BBKHAKT module but im unsure due to different engine / ecu / MED version Checking 0x8002DBA2 -> 0006 0000 00FA 03E8 09C4 0FA0 1770 // looks like a 6x1 table, good sign :) the axis and the table values are completely different with previous file btw Now we have to apply this base in suspicious routine CTRL + R at 'ld.hu d15, [a15]0x32' gives me 0x8002DBD4 which is finally FHOKH map Quote PFLASH:800840C2 loc_800840C2: ; CODE XREF: sub_80083E00+2B4↑j PFLASH:800840C2 ; sub_80083E00+2B8↑j PFLASH:800840C2 05 DF 36 14 ld32.bu d15, byte_D0000076 PFLASH:800840C6 6F 3F 0C 80 jnz32.t d15:3, loc_800840DE PFLASH:800840CA PFLASH:800840CA loc_800840CA: ; CODE XREF: sub_80083E00+2BE↑j PFLASH:800840CA 6F 50 17 00 jz32.t d0:5, loc_800840F8 PFLASH:800840CE 99 9F 5C 00 ld32.a a15, [a9](BBKHAKT_mod - startOfModules_mod) PFLASH:800840D2 05 DF 4A 1D ld.hu d15, word_D000144A PFLASH:800840D6 09 F0 EC 38 ld.hu d0, [a15](unk_8002DC8E - unk_8002DBA2) PFLASH:800840DA 3F F0 0F 80 jlt.u d0, d15, loc_800840F8 PFLASH:800840DE PFLASH:800840DE loc_800840DE: ; CODE XREF: sub_80083E00+2C6↑j PFLASH:800840DE D9 0F 7E CB lea a15, [a0](unk_D0006D3E - unk_D000B600) PFLASH:800840E2 09 F0 C0 08 ld.hu d0, [a15]0 PFLASH:800840E6 99 9F 5C 00 ld32.a a15, [a9](BBKHAKT_mod - startOfModules_mod) PFLASH:800840EA 09 FF F2 08 ld.hu d15, [a15](FHOKH_map - unk_8002DBA2) ; <- PFLASH:800840EE 7F 0F 05 80 jge.u d15, d0, loc_800840F8 PFLASH:800840F2 D5 DF 36 10 st.t byte_D0000076:7, #1 PFLASH:800840F6 3C 03 j16 loc_800840FC Title: Re: Disassembling MED/EDC17 Post by: fknbrkn on January 21, 2024, 10:54:43 AM I want to suggest another method , which i am using all the time in MED9, and it should work also on MED17: There is a table in flash, which is called KFMWNTK ("measurement blocks-table"), It contains pointers to small functions which will return certain variables. The table is very well defined in the FR and the vars will be always on the same index of that table. Here is a detailed explanation about it for MED9: http://nefariousmotorsports.com/forum/index.php?topic=5941.0title= In MED9 World, there is a tool called "med9info" which can parse this table and show all vars which are defined in this table. I havent seen such a tool in MED17 world yet. If not , i would suggest implementing such a tool. I attached the Table Definition from MED17.5 FR here, so you can have a look what it contains. As soon as you get such tool, its pretty easy to add a lot of variables into ghidra even for binaries where no a2l matches up. Thats a nice input thanks) I might be wrong ofc but i didnt see any *14230* or *mess*tabelle* in MED17.5.20 / 25 files perhaps its UDS and doesnt operate with MVB values anymore Title: Re: Disassembling MED/EDC17 Post by: elias on January 21, 2024, 11:02:28 AM Thats a nice input thanks) I might be wrong ofc but i didnt see any *14230* or *mess*tabelle* in MED17.5.20 / 25 files perhaps its UDS and doesnt operate with MVB values anymore I cannot tell you if they have dropped it or not on a certain binary. But for UDS there might be a similar table. Title: Re: Disassembling MED/EDC17 Post by: prj on January 21, 2024, 11:05:25 AM I cannot tell you if they have dropped it or not on a certain binary. But for UDS there might be a similar table. This is irrelevant on MEDC17 outside of TP2.0. On UDS on VAG every ODX ID can have completely arbitrary identifiers assigned to the variables. I currently have 16220 definitions in my logger for VAG/Porsche UDS identifiers ($22) for this reason. There are no shortcuts. It makes no sense to parse the tables when all the ID's can have a random offset from one software version to the next. You can often not infer any information at all between different ODX ID's. That ship sailed with MED9. Also even on MED9 for finding ram cells it's a waste of time parsing those things anyway, when you can do this: Code: [20:08:28] ######## SOURCE BIN ######## Completely automatically... and it's not limited to VAG or Bosch. Title: Re: Disassembling MED/EDC17 Post by: elias on January 21, 2024, 12:12:17 PM This is irrelevant on MEDC17 outside of TP2.0. On UDS on VAG every ODX ID can have completely arbitrary identifiers assigned to the variables. I currently have 16220 definitions in my logger for VAG/Porsche UDS identifiers ($22) for this reason. There are no shortcuts. It makes no sense to parse the tables when all the ID's can have a random offset from one software version to the next. You can often not infer any information at all between different ODX ID's. That ship sailed with MED9. Also even on MED9 for finding ram cells it's a waste of time parsing those things anyway, when you can do this: Code: [20:08:28] ######## SOURCE BIN ######## Completely automatically... and it's not limited to VAG or Bosch. What is this tool and where can i find it? It seems like something which can make the life of a lot of people easier. Title: Re: Disassembling MED/EDC17 Post by: prj on January 21, 2024, 04:10:30 PM What is this tool and where can i find it? It seems like something which can make the life of a lot of people easier. Nowhere, it is the engine that makes my logger possible, and how I have measuring data for almost any car. I just gave an idea where to work towards - I don't see much gain in writing parsers for specific tables and specific ecu's. The issue can be approached in a completely different manner. Title: Re: Disassembling MED/EDC17 Post by: elias on January 22, 2024, 07:04:45 AM Ok, i got your point. Not sure exactly what you are doing exactly but i have following idea how to implement such a "A2L Converter". Challenge me:
1. Lets assume that you have a Binary A with A2L and a Binary B without a A2L. You goal is to guess a lot of memory variables in the Binary B correctly. 2. Lets assume that you already loaded both into Ghidra and got the memory-map right and also set the registers for indirect mapping correct. 3. You then export all functions-ghidra-pcode(c-listing) in Binary A to a Database. 3. Do same with Binary B, but to a different DB 4. Then you start comparing function-texts from Database A to Database B. You could remove all "Variables" and "Func" Calls from the Text and then compare both texts to each other. If they match, you know that its the same code, just different variable memory locations. Its more complicated than that for sure, but its a starting point, and here the "magic" must happen. 5. As soon as you got the mapping of functions correct, you could see what variables are used in that particular function on Bin A (using A2L) and name the vars 6. Then you could rename the Vars in Bin B to the same name(as you know the function match up) 7. Export this vars somehow in A2L format. Title: Re: Disassembling MED/EDC17 Post by: prj on January 22, 2024, 08:09:45 AM I don't use any 3rd party tools, the entire disassembly and analysis process is done by my tool.
So that means it has disassemblers for all the architectures. Also, it automatically detects all the code segments based on statistical analysis (that is actually quite simple). Comparing Ghidra text is a waste of time, because if compiler changes and optimization changes then the output is completely different. Some PhD researchers from USA who specialize in this kind of thing tried, and they got less than 30% of the matches of my tool. I was looking to increase the accuracy, but this turned out not to be a viable approach. Not to mention Ghidra is insanely slow compared to this. So a different approach needs to be done - for starters cataloguing all the memory references, accesses, copies and categorizing instructions into different subtypes. Then looking through another binary and trying to find the same places based on the pattern of the pseudocode (or even more crude methods). Then you need strong false positive rejection algorithms. And before you even start you need some kind of A2L parser engine.... The log is all that there is to see: bin and a2l (preprocessed) dragged into one box, another bin dragged into another and then a button pushed. There are no hidden steps, no Ghidra, no Ida, no nothing - no pre-processing of the binary data. The only thing that is pre-processed are the A2L's, into a much more efficient format (because I do that for the logger anyway). From start of button push until end of the process it is 3 seconds. This includes detection and disassembly of all the code areas and the algos mentioned above. Title: Re: Disassembling MED/EDC17 Post by: elias on January 22, 2024, 09:21:20 AM Quote Also, it automatically detects all the code segments based on statistical analysis (that is actually quite simple). Can you elaborate what code segments are? Do you mean this "bosch blocks"?Quote So a different approach needs to be done - for starters cataloguing all the memory references, accesses, copies and categorizing instructions into different subtypes. Quote Then looking through another binary and trying to find the same places based on the pattern of the pseudocode (or even more crude methods). Comparing Ghidra Text was just a example, the matching algorhytm is the secret sauce. It was just an idea.Then you need strong false positive rejection algorithms. Quote And before you even start you need some kind of A2L parser engine.... I have a "selfmade" A2L Parser "Engine" which produces json files:Code: "AACCMNOFF": {@prj: Lets say you would be a Hobbyist and want to get some A2Ls which does not exists for your Hobbyist needs. Which approach would you choose for the "A2L Transfer-Tool"? Your time is limited and you cannot spend years in R&D developing the perfect secret sauce method. Title: Re: Disassembling MED/EDC17 Post by: prj on January 22, 2024, 09:44:23 AM Can you elaborate what code segments are? Do you mean this "bosch blocks"? No I mean literal chunks in the binary that are code. You need to somehow separate data from code in the file when you know nothing about it. You only want to process the code and not try (futile) disassembly of data areas.Bosch has nothing to do with it, my tool doesn't care if it's Bosch, Conti, Kefico or something else. Quote @prj: Lets say you would be a Hobbyist and want to get some A2Ls which does not exists for your Hobbyist needs. Which approach would you choose for the "A2L Transfer-Tool"? Your time is limited and you cannot spend years in R&D developing the perfect secret sauce method. For logging you buy my tool then you use ida to locate the stuff based on similar a2l that you need. Usually you're not going to need all variables, but only very few of them. IDA lets you alt+b search binary masks where you can mask out registers, data etc. You need some familiarity with the opcode binary syntax of course. I mean, technically you could sniff the CAN for the variables you need also, $2C specification is not exactly a secret. But if you want to just work on one ECU then this is the way to go. Building any tools is a waste of time then. I already spent the 1y+ R&D on it and made the datalogging accessible to everyone for what I think is a quite reasonable fee, and my licensing allows hobbyists to purchase perpetual licenses for their cars so they don't have to keep paying monthly fees. There's also no setup fees like dropping 5k on a flash tool etc, I think it's extremely friendly towards hobbyists and I don't think it's cost effective for anyone to develop their own solutions for at least datalogging at this point. Maybe only to satisfy curiosity or as a highly specialized dedicated package for a handful of platforms. Title: Re: Disassembling MED/EDC17 Post by: elias on January 22, 2024, 05:19:03 PM Okey, my mistake, i havent wrote my goals correctly.:
Currently i want to upgrade from 1Q0 907 115C to 1Q0 907 115F. For 115C i have a suitable A2L, but not for 115F. So naturally the topic arises: How do i get a A2L for the 115F? Why do i need to upgrade? Well, i hope they fixxed some bugs there, and its always good to have the newest software right? Why do i need a A2L? Well, it would make my life easier writing (new) features(like the mapswitch). I could do it manually, but its a lot of effort. Besides: I appreciate your work with your logger, but it wont help me currently. Never ever have logged my car besides watching some measurement values in VCDS. Never tuned my car, it came with a tune from previous owner. I am mostly working on some features as a hobby, and need A2Ls for further dev. Also i have sorted one of the "collections" using my "med9info" + scripting to find some A2Ls but unfortunately it did not contain the ones which i wanted. What would be your approach to get your hands on this A2Ls which does not exist in the wild? Its obviously would be writing some tool , but not spending years of work on it. Title: Re: Disassembling MED/EDC17 Post by: prj on January 23, 2024, 12:21:22 AM What would be your approach to get your hands on this A2Ls which does not exist in the wild? Its obviously would be writing some tool , but not spending years of work on it. Either find somewhere to buy it, or if you can't then spend years writing a tool.If not, then deal with it and use IDA with binary matching to find the things you need. Title: Re: Disassembling MED/EDC17 Post by: elias on January 27, 2024, 05:54:23 AM Okey, i fiddled together a tool which is completely suitable for my needs.
Hope it help the MED17 folks. Approach is written down there, and is very similar to the one which you described prj: https://github.com/EliasKotlyar/A2L-Transfer The heavy lifting is done via bindiff, which can match up binary chunks for me. I dont have to deal with it myself, and it produces reliable results. I tested it out on various MED9.1 A2Ls and it looking good. There are some limitations due to "hobbiest" approach and not spending too much time configuring all cases. However its enough to match a big portion of variables, and thats completely sufficient for me. Even if it does not work/produces garbage in some cases, i get a good overview with the matching vars and can work with it more "efficiently" than with no A2L at all. Title: Re: Disassembling MED/EDC17 Post by: prj on January 27, 2024, 10:34:41 AM MED9 is actually super easy to do and the code base differs very little. Same for ME7.
MED17 needs a lot more processing. Your thing will work only for MED9 that you have hardcoded register values for (because they are the same for nearly all MED9 binaries). On MED17 and MG1 they change a lot depending of size of smalldata1 and 2. Also you hardcoded the flash layout, just as an example for VAG alone there are well over a 100 different flashlayouts on newer ECU's. Never mind the other makes and models. Bindiff looks actually very nice. Unfortunate thing is that it needs a Ghidra or IDA project to work. This is very slow on newer ECU's, Ghidra can easily take half an hour to process a binary of a more modern ECU. IDA you need manual scripts and logic to process the globals, at least on TriCore. And also you need to feed it info about where the code segments are and at what address to load the binary. So I would say your thing is not useful for VAG MED17 or MG1. Only for VAG MED9.1, but already not for MED9.1.2 that has intflash, because that requires manually setting everything again... I'd say if you're going to use bindiff, then I don't see much point in your stuff. You can just use it with IDA directly and transfer the symbols. All you did is call ghidra and bindiff and hardcode some MED9 locations - the same could have been done by loading two binaries in ida, using my script to populate the symbols from a2l and then use bindiff directly. In case of MED17/MG1 you will have to load the binary anyway to find the globals or you need a disassembler that can find it in the binary, thus making your scripts redundant. I don't want to shit on your work or anything, I just have a hard time seeing the value in it. Title: Re: Disassembling MED/EDC17 Post by: d3irb on January 27, 2024, 11:04:47 AM Don't let prj's lack of respect for modern tooling dissuade you :) +1 for Bindiff. I've been using the same approach myself and it works very well. If anyone is interested in trying something new, the latest Ghidra has a tool called BSim that also works extremely well. Yes, even on MED17 binaries, even though I don't usually mess with Bosch stuff I just tried a few. Far better than needle-in-haystack pattern mask matching.
Adding detection of Tricore register values isn't rocket science. Especially now that Unicorn supports Tricore it's very easy to auto-configure setup state. And using emulation to do setup plus using bindiff, you just need a memory map, a loader script for whatever BIN format you have, and the entry point for ASW (and the memory map doesn't even need to be right, really, just 0xD -> RAM, 0xB -> LMU RAM, 0xC -> Scratchpad RAM, 0x8 / 0xA -> Flash is sufficient for Tricore usually since there isn't overlap). The whole point of automation instead of "using it with IDA directly and transferring the symbols" is that if something takes 30 minutes, it's not wasting your day anyway. For example, BSim in Ghidra is really slow but is trivial to fully automate from the command line, so it's no issue. It even has all of the plumbing already to let you make a service that will do a ton of binaries in parallel and store the results in a Postgres database. I think this project could easily be extended to be very useful for MED17. I've written a very similar but simpler tool for Simos18 and it's pretty straightforward to get very strong matching working using off the shelf tooling. Title: Re: Disassembling MED/EDC17 Post by: elias on January 27, 2024, 01:06:16 PM Quote MED17 needs a lot more processing. Yes i know, you need to adjust the "import into ghidra" script to your needs. I expect that someone who knows how to deal with a certain ECU knows how to setup Ghidra or IDA Pro.Its a manual process, and depends on the ECU Quote Unfortunate thing is that it needs a Ghidra or IDA project to work. This is very slow on newer ECU's, Ghidra can easily take half an hour to process a binary of a more modern ECU. This may be the case, but as i mentioned before , its a "hobbiest" approach. I can wait 30min and go watch TV. I am (currently) not doing it to make $$$. I respect people who do, but for me its a hobby.Quote You can just use it with IDA directly and transfer the symbols. How do you do that? I am not familiar with IDA Pro, i have looked at it but for me its looking like a stripped down Ghidra Version. I understand it as a more sophisticated disassembler.Quote All you did is call ghidra and bindiff and hardcode some MED9 locations - the same could have been done by loading two binaries in ida, using my script to populate the symbols from a2l and then use bindiff directly. Yes, it would have helped if someone would have told me before i started.Quote I don't want to shit on your work or anything, I just have a hard time seeing the value in it. Value is, that i got my A2L ported in small amount of time. Also i learned something, now i am more confident with "ghidra scripting" and can do much more sophisticated stuff with it.Also i shared my approach and i trigged a discussion about that approach - which seems to be a good thing, as nobody needs to reinvent the wheel and do my appoach again Quote I've written a very similar but simpler tool for Simos18 What exactly did you simplify? I would like to learn more about it. Title: Re: Disassembling MED/EDC17 Post by: d3irb on January 27, 2024, 01:51:31 PM How do you do that? I am not familiar with IDA Pro, i have looked at it but for me its looking like a stripped down Ghidra Version. I understand it as a more sophisticated disassembler. IDA Pro has a built in cross-correlation system similar to Bindiff, called Lumina. It's unclear if prj was referring to that or just using Bindiff inside of IDA (dismissing writing a tool to automate it basically and suggesting that you might as well use a plugin instead, he's just being cranky). Compared to Ghidra overall: IDA has better ergonomics (key shortcuts, UI, etc.), runs faster, has a _way_ better dynamic analysis feature set (debugging) and sometimes a better disassembler in terms of bugs. There's also a much bigger scripting ecosystem for IDA since all the old school people still use it. But Ghidra is better for ECUs IMO by virtue of having a generalized decompiler. Basically on Ghidra, you get decompilation for any supported processor. On IDA, you don't, because the decompiler is a separate product from the disassembler. So there's no decompilation for Tricore or C167 in IDA. This also means that IDA chokes on weird things (generating XRefs from pointers that are calculated twice being a big one) because the disassembler is just a disassembler (vs Ghidra, where the whole thing is hoisted into IR / PCode and then evaluated). I personally use IDA for any OS-hosted binary stuff on a supported platform (ie - Windows x86 or ARM Linux binaries), where it's very polished and fast to use, and Ghidra for everything else. Quote What exactly did you simplify? I would like to learn more about it. It's pretty similar conceptually, I just don't use A2L as the input/output format for my automation. Kind of like what you've done with JSON, I have a separate tool that turns A2L into CSV first, and I never had a need to write A2L back out the other side, so I don't. I also autodetect writes to the global address registers in the ASW execution flow. You can do this using raw disassembly (Ghidra scripting, basically keep fetching the next instruction until it's a load immediate with the global register as target) or emulation (Unicorn). Simos18 is also just simpler in general with primitive tooling because there is less indirection. For example, maps are directly referenced rather than indirectly referenced through a load function like they are in Bosch, so calibration data also gets XRefs by default. This is a double edged sword since it makes hooking and map replacement harder (without using flash emulation at least), but it makes cross-correlation tooling a lot more straightforward. Title: Re: Disassembling MED/EDC17 Post by: jcsbanks on January 27, 2024, 04:27:32 PM If you make names, comments and function names from the a2l in Bin_A, you could perhaps script the BinDiff GUI "import symbols and comments" into Bin_B. Perhaps this could be a simplification, optimization or generalization of the script because all you have to otherwise is process Bin_A and Bin_B the same way (eg on Tricore finding a0, a1, a8, a9, marking code as code and data as data, defining functions).
Title: Re: Disassembling MED/EDC17 Post by: fragolas on January 28, 2024, 01:33:56 PM i have tried bindiff with ida pro, unfortunately it does not transfer variable names from bin_a to Bin_b. it seems to be a bug that has not yet been solved since version 7 of bindiff. this mainly concerns users that want to reverse me7, since guidra does not support c167.
Title: Re: Disassembling MED/EDC17 Post by: prj on January 28, 2024, 02:58:55 PM dismissing writing a tool to automate it basically and suggesting that you might as well use a plugin instead, he's just being cranky There's nothing being automated, that's the thing. In the time he wrote those python scripts he could have loaded the bin in ida 20 times. Automation is detecting the code areas, detecting the global variables. Not putting a bunch of hardcoded addresses into a .py file. You guys are pretty spoiled by MED9.1 and Simos18 where everything is the same. Same flash layout, same globals, same everything. Try doing that on a slightly larger scale, between different vehicle manufacturers... You will end up anyway loading the binaries in IDA to find the globals, to find the flash layout etc. And at that point you can just run bindiff directly. Around MED17/EDC17 is where the Bosch ECU's got all very different, the current approach here is not any better than running bindiff directly from ida pro or Ghidra. Title: Re: Disassembling MED/EDC17 Post by: elias on March 30, 2024, 02:31:28 PM Quote In the time he wrote those python scripts he could have loaded the bin in ida 20 times. If i would know that its possible with IDA-Pro at that time, i would have done that.Quote Automation is detecting the code areas, detecting the global variables. What do you mean by global vars? What kind of variables do you consider "global"?Do you mean registers? Detecting registers on MED9 is pretty straight forward, as you just have to disassemble the whole file and then search the asm output for something like "lis R2, <address>". It should be similar in Tricore arch. You just have to figure out more registers like A1, A10 etc.. Detecting Code-Areas is more complicated, but i suspect you can use some Bosch-Signatures on that. Quote Try doing that on a slightly larger scale, between different vehicle manufacturers... Really not my goal as i am working in my free time.Quote the current approach here is not any better than running bindiff directly from ida pro or Ghidra. At least in Ghidra there is no option for transfering detected vars from one project to another. You have to run your own scripts. Havent tried this yet in IDA Pro. Title: Re: Disassembling MED/EDC17 Post by: prj on March 30, 2024, 03:47:17 PM What do you mean by global vars? What kind of variables do you consider "global"? They are universally called globals. On PPC it's usually R2, R13, R14, R15. On ISA just R2 and R13 most of the time. It's up to the compiler where it assigns them.Do you mean registers? Quote Detecting registers on MED9 is pretty straight forward, as you just have to disassemble the whole file and then search the asm output for something like "lis R2, <address>". It should be similar in Tricore arch. You just have to figure out more registers like A1, A10 etc.. But you did not do it. You just hardcoded values.Quote Detecting Code-Areas is more complicated, but i suspect you can use some Bosch-Signatures on that. And what happens if you try a non-bosch ECU?The real answer is statistical analysis. Run an analysis of most used opcodes and you can do a frequency table based on certain bytes that will give you a pretty good idea. It's not trivial, but doable. Quote Really not my goal as i am working in my free time. There is a certain pattern I see. You post things on github that have no real value, and then you make a hype post on the forum about it.I don't understand the reasoning behind it. Don't get me wrong, it's always good if people work on stuff and share. But "oversharing" stuff that nobody has any use for also does not have a point. Title: Re: Disassembling MED/EDC17 Post by: elias on March 30, 2024, 04:22:32 PM Quote They are universally called globals. On PPC it's usually R2, R13, R14, R15. On ISA just R2 and R13 most of the time. It's up to the compiler where it assigns them. I was thinking that its behaviour of the compiler and there is no real name to this. Thanks for clarifyingQuote But you did not do it. You just hardcoded values. Yes i did, and i admit it. I am too lazy to write that script. On VAG MED91 the globals are always same, so i had no need to find them. Quote The real answer is statistical analysis. Run an analysis of most used opcodes and you can do a frequency table based on certain bytes that will give you a pretty good idea. Great idea, but for now i stick to bindiff as its giving me the results which i want. Usually its enough to do a so called "A2L Transfer" from Bin A to Bin B. Quote There is a certain pattern I see. You post things on github that have no real value, and then you make a hype post on the forum about it. Your right, that should end. Reason is, that i try to resolve a Problem which i have and do it in a way that can benefit others. I would like to make things that matter to people, but unfortunately nobody cares about MED91 (anymore). Do you have a idea where i should move to? I dont see much demand in any of the work which i have done. I don't understand the reasoning behind it. Title: Re: Disassembling MED/EDC17 Post by: prj on March 31, 2024, 03:08:25 AM Your right, that should end. Reason is, that i try to resolve a Problem which i have and do it in a way that can benefit others. I would like to make things that matter to people, but unfortunately nobody cares about MED91 (anymore). Do you have a idea where i should move to? I dont see much demand in any of the work which i have done. You can always do as little or as much as you want - you don't owe anyone anything.My remark was more towards the quality of stuff posted. If you make something super specific that is useful in one tiny use case, then it's not going to be very useful for anyone. There's not really any point posting up code that solves some super specific task, which no one except you most likely has need for. For example: For VAG MED9.1 almost every hex/a2l is available in a large damos pack that got leaked. 9.1.1 and others is a different story, but your stuff does not work for it, because it's just a bunch of hardcoded values. Your topics mostly just say "MED9", which is kinda misleading. Then we get back to the fact bindiff/symbols in the first place are useful only for those of us who actually modify code. Everyone else uses WinOLS to quickly transfer the needed maps and be done with it, because that doesn't require a comp-sci background to be successful. And logging wise my product solves the issue, and again does not require a degree to use. Hell, even those who are perfectly capable of writing similar software use it, because there is zero point in reinventing the wheel. So if you ask - what to do that is beneficial for others, then the answer is mostly not "some kind of python contraption that requires a degree to use", when there's alternative solutions already available for free or for a small fee. Doing things that are really beneficial require a significant amount of time, at which point it becomes a full time job. Because for it to be beneficial it has to cover 90% of cases, not a single narrow 1% use case, and the devil is always in the details. Title: Re: Disassembling MED/EDC17 Post by: jcsbanks on April 01, 2024, 04:37:12 AM Do you have a idea where i should move to? I dont see much demand in any of the work which i have done. Are you wanting to make a career out of work related to disassembling ECU code? I did and left a career in medicine to do it full time, and still (mostly) love it, it started from a hobby and many things I experimented with over 18 years of doing it have ended up monetized. Mostly the challenges for me were to give people what they want, better than the alternatives so they want to pay you, in a way you can support and enjoy, like any business. Title: Re: Disassembling MED/EDC17 Post by: prj on April 01, 2024, 05:09:11 AM I also left my fulltime software development job to do this. Learned calibration, ICE theory and practice etc. Built up a successful company. Then at some point quit the day-to-day tuner job.
Went back to developing software, but this time for automotive, because there was a niche in the market for datalogging, which I now filled. John actually has a very valid point here. Are you looking to make this stuff a full time job? Title: Re: Disassembling MED/EDC17 Post by: elias on April 02, 2024, 04:12:36 AM Quote Are you looking to make this stuff a full time job? No, not at all. At least for now, i am really settled with my fulltime job and work on the ecu projects in my free time. I am just wondering if i can make a few bucks on the side writing ECU-code. Reselling Other people work is something which i try to avoid, so the classic "file reseller"-career is not for me. I am more interessted in more complicated and sophisticated stuff. |