rkam
Full Member
Karma: +4/-0
 Offline
Posts: 56
|
 |
« Reply #2205 on: March 13, 2023, 12:29:07 AM »
|
|
|
I made a visual basic macro in excel to extract four bytes from each subroutine.
When the first two bytes are C2 F4, I calculate the RAM address from the next two.
This is done by extracting and removing the DPP number from the two address bytes.
(The two highest bits in the two-byte address if I remember correctly. C167 can be a bit annoying.)
Most will have DPP number 2 and some DPP number 3.
DPP2 is probably 0xC0. 0xC0 multiplied with 0x4000 is 0x300000
DPP3 is probably 0x03. 0x03 multiplied with 0x4000 is 0xC000
You then add 0x300000 to the remaining address (lowest 14 bits) for the values using DPP2, and 0xC000 for the ones using DPP3.
This should give you addresses like 30xxxx and Fxxx.
96FB: 1011 0000 0001 0110 1111 1011
DPP: 10 = 2
16FB: 0011 0000 0001 0110 1111 1011
Assuming DPP2=C0: 16FB+300000=3016FB
|
|
|
|
« Last Edit: March 13, 2023, 12:40:38 AM by rkam »
|
Logged
|
|
|
|
keichi
Full Member
Karma: +11/-2
Offline
Posts: 100
|
|
« Reply #2206 on: March 13, 2023, 01:59:48 AM »
|
|
|
Yeah I'm looking at GPHJ right now, seems the base address is 0x60000 and the table at C4FC returns a list of offsets. Whats more interesting is that IDA is screwing up the ram addresses: ROM:000603EA C2 F4 F8 96 movbz r4, 96F8h ; 31D6F8h
ROM:000603EE DB 00 rets
ROM:000603F0 ; ---------------------------------------------------------------------------
ROM:000603F0 C2 F4 F9 96 movbz r4, 96F9h ; 31D6F9h
ROM:000603F4 DB 00 rets
ROM:000603F6 ; ---------------------------------------------------------------------------
ROM:000603F6 C2 F4 FA 96 movbz r4, 96FAh ; 31D6FAh
ROM:000603FA DB 00 rets
ROM:000603FC ; ---------------------------------------------------------------------------
ROM:000603FC C2 F4 FB 96 movbz r4, 96FBh ; 31D6FBh
ROM:00060400 DB 00 rets
ROM:00060402 ; ---------------------------------------------------------------------------
ROM:00060402 C2 F4 FC 96 movbz r4, 96FCh ; 31D6FCh
ROM:00060406 DB 00 rets
ROM:00060408 ; ---------------------------------------------------------------------------
ROM:00060408 C2 F4 FD 96 movbz r4, 96FDh ; 31D6FDh
ROM:0006040C DB 00 rets
ROM:0006040E ; ---------------------------------------------------------------------------
ROM:0006040E C2 F4 00 97 movbz r4, 9700h ; 31D700h
ROM:00060412 DB 00 rets
ROM:00060414 ; ---------------------------------------------------------------------------
ROM:00060414 C2 F4 01 97 movbz r4, 9701h ; 31D701h
ROM:00060418 DB 00 rets
in any case, assembling all this into an excel sheet with all the parameter names taken from vida is a loooooong process Make sue you set default segment registers in IDA: Edit->Segment->Set default segment register value for every DPP (for Volvo its. 0x4, 0x5, 0xC0, 0x3) Then IDA can calculate physical addres from any long address for you (DPP addresing mode) by pointing value with mouse for example click on 96FBh value and press CTRL+R then select Type:DPP (other fields leave default). You will get 3016FBh. To get back to default value click it and choose Undefine operand. General DPP calculation pattern is: dword(DPPx SHL 14) || word(addr AND 0x3FFF) |
|
|
|
|
Logged
|
|
|
|
t6
Full Member
Karma: +0/-5
Offline
Posts: 56
|
|
« Reply #2207 on: March 13, 2023, 03:40:30 AM »
|
|
|
dla "WCKD"
ESKONF adres 10B0E
US 0C 00 0C F0 00 FC 00 EU 0C 00 0C FC 00 FC CC
US 12 0 12 240 0 252 0 EU 12 0 12 252 0 252 204
|
|
|
|
|
Logged
|
|
|
|
|
prj
|
|
« Reply #2208 on: March 13, 2023, 03:56:51 AM »
|
|
|
I made a visual basic macro in excel to extract four bytes from each subroutine.
When the first two bytes are C2 F4, I calculate the RAM address from the next two.
This is done by extracting and removing the DPP number from the two address bytes.
(The two highest bits in the two-byte address if I remember correctly. C167 can be a bit annoying.)
Most will have DPP number 2 and some DPP number 3.
DPP2 is probably 0xC0. 0xC0 multiplied with 0x4000 is 0x300000
DPP3 is probably 0x03. 0x03 multiplied with 0x4000 is 0xC000
You then add 0x300000 to the remaining address (lowest 14 bits) for the values using DPP2, and 0xC000 for the ones using DPP3.
This should give you addresses like 30xxxx and Fxxx.
96FB: 1011 0000 0001 0110 1111 1011
DPP: 10 = 2
16FB: 0011 0000 0001 0110 1111 1011
Assuming DPP2=C0: 16FB+300000=3016FB Why not go one step further and since the DID's are going to mean the same thing across softwares, make a map between DID <-> A2L RAM ID on known software, and then you have these ram cells on every ECU? Btw, this is the same thing ME7Info does for ME7Logger, just much less advanced. |
|
|
|
|
Logged
|
|
|
|
rkam
Full Member
Karma: +4/-0
Offline
Posts: 56
|
|
« Reply #2209 on: March 13, 2023, 04:15:04 AM »
|
|
|
I believe there could be some difference between models and years, so I would normally link to data for the actual units diagnose part number in Vida SQL tables.
But I have converted the A2L I have to excel, and on some old hard drive in my house I believe there is a spreadsheet comparing data from both A2L and Vida or DHA.
|
|
|
|
|
Logged
|
|
|
|
rlinewiz
Jr. Member
Karma: +16/-1
Offline
Posts: 44
|
|
« Reply #2210 on: March 13, 2023, 06:03:06 AM »
|
|
|
I made a visual basic macro in excel to extract four bytes from each subroutine.
When the first two bytes are C2 F4, I calculate the RAM address from the next two.
This is done by extracting and removing the DPP number from the two address bytes.
(The two highest bits in the two-byte address if I remember correctly. C167 can be a bit annoying.)
Most will have DPP number 2 and some DPP number 3.
DPP2 is probably 0xC0. 0xC0 multiplied with 0x4000 is 0x300000
DPP3 is probably 0x03. 0x03 multiplied with 0x4000 is 0xC000
You then add 0x300000 to the remaining address (lowest 14 bits) for the values using DPP2, and 0xC000 for the ones using DPP3.
This should give you addresses like 30xxxx and Fxxx.
96FB: 1011 0000 0001 0110 1111 1011
DPP: 10 = 2
16FB: 0011 0000 0001 0110 1111 1011
Assuming DPP2=C0: 16FB+300000=3016FB
yes I always have set DPP properly, and started ignoring what IDA is saying and converting from the hex directly. I got about 600 variables before giving up and starting to write a simple .NET app to do it for me, much like your method but also taking into account the bitwise operations, and duplicate variables with differing masks. i realize this sort of work will not help the end user, but will be very helpful reference for anyone wanting to edit the bin assembly [edit] i noticed the code analysis is setting DPP2 to random values in weird places, even though its set properly at the top, so at the beginning of these functions i forced DPP2 back to C0 and all the ram values lined up properly [edit edit] also anyone else who is trying to figure this out at such a low level, do note that any time you see an 'extp' before a lookup, it changes DPP2 for the next instruction. #0C1h sets DPP2 to 0x304000, #0C2h sets DPP2 to 0x308000. This allows lookups into the 305000 and 30A000 ranges |
|
|
|
« Last Edit: March 13, 2023, 10:13:19 AM by rlinewiz »
|
Logged
|
2005 S60R M66-Swapped // Self-tuned @ 22psi
[[forever coding for the OpenMoose project]]
|
|
|
|
prj
|
|
« Reply #2211 on: March 13, 2023, 08:35:48 AM »
|
|
|
I believe there could be some difference between models and years, so I would normally link to data for the actual units diagnose part number in Vida SQL tables.
But I have converted the A2L I have to excel, and on some old hard drive in my house I believe there is a spreadsheet comparing data from both A2L and Vida or DHA. VIDA is completely irrelevant in this case. You know that identifier X is RAM ID Y. All you need is a single A2L. Then you can map at least some RAM IDs on every other ECU from same family. Regardless, I did get C167 to work in my generator tool... Seems like I will have to implement the Volvo specific protocol anyway for ME9 P01, and it should work for ME7 too. But probably free protocol like on ME7 isn't going to happen, since I'd still need to add defs for every single ECU by hand... So not sure there is much point to even bother with ME7, since you guys got most of the ME7 ECU's already very well covered with an opensource tool. Getting my ECU's tomorrow finally, so going to start working on them... |
|
|
|
|
Logged
|
|
|
|
rkam
Full Member
Karma: +4/-0
Offline
Posts: 56
|
|
« Reply #2212 on: March 13, 2023, 11:31:22 AM »
|
|
|
I have only one A2L for ME7 file F1EBI.bin
This is variant 288 in Vida and it has quite a few identifiers that differ from the 1753 variant for QKHJ.
54 08644074 G
55 08644074 H
67 08658507 G
68 08658507 H
145 08689198 A
205 09202858 A
206 09202903 A
207 09202904 A
253 09488048 A
272 09496652 A
273 09496653 A
274 09496654 A
275 09496656 C
288 09497085 A F1EB1.bin A2L
292 09497803 A
293 09497804 A
294 09497805 A
348 30641539 B
349 30641540 B
350 30641541 B
351 30641542 B
352 30641543 B
353 30641543 H
354 30641735 B
356 30641745 B
357 30641745 H
358 30641746 B
359 30641746 H
360 30641841 B
374 30651320 B
375 30651321 B
379 30653031 B
380 30653032 B
454 30668566 A
659 30743290 AA
897 30771311 AA
1370 30785372 AB
1371 30785373 AB
1375 30785374 AB
1379 30785375 AB
1383 30785376 AB
1390 30785377 AB
1391 30785378 AB
1449 31219132 AA
1453 31219133 AA
1749 31219525 AA
1751 31219526 AA
1752 31219527 AA
1753 31219528 AA QKHJ
1754 31219529 AA
1668 31219530 AA
I haven't check the A2L yet.
|
|
|
|
|
Logged
|
|
|
|
|
prj
|
|
« Reply #2213 on: March 13, 2023, 06:06:37 PM »
|
|
|
I have the same A2L. The format is so old, that my A2L parser is not even able to process it... EDIT: Parser now processes it, but my disassembler chokes on it  I wanted to generate from F1EBI -> QKHJ for lulz and see what's going on. I know there's some 1mb A2L's around too. |
|
|
|
« Last Edit: March 13, 2023, 06:14:38 PM by prj »
|
Logged
|
|
|
|
|
prj
|
|
« Reply #2214 on: March 13, 2023, 06:58:03 PM »
|
|
|
Managed to get it to parse, but I think I need to find a 1mb A2L. The 512k is quite different, here's the result, I'm sure tons of them are wrong. [03:55:22] ######## SOURCE BIN ########
[03:55:22] Loading and parsing files...
[03:55:22] Removing bitfields...
[03:55:22] Code segments:
[03:55:22] 008000 - 0089BA Len: 0009BB
[03:55:22] 009000 - 00C229 Len: 00322A
[03:55:22] 022000 - 035DC6 Len: 013DC7
[03:55:22] 035E00 - 07C69E Len: 04689F
[03:55:22] DPP0: 0x0004
[03:55:22] DPP1: 0x0005
[03:55:22] DPP2: 0x00C0
[03:55:22] DPP3: 0x0003
[03:55:22] Parsing instructions...
[03:55:24] Got 7450 refs
[03:55:24] Matching refs to A2L...
[03:55:24] A2L addresses: 5357, with refs: 2285
[03:55:24] ######## TARGET BIN ########
[03:55:24] Code segments:
[03:55:24] 009000 - 00C3CB Len: 0033CC
[03:55:24] 030000 - 036CB0 Len: 006CB1
[03:55:24] 038000 - 0C46E2 Len: 08C6E3
[03:55:24] DPP0: 0x0004
[03:55:24] DPP1: 0x0005
[03:55:24] DPP2: 0x00C0
[03:55:24] DPP3: 0x0003
[03:55:24] Parsing instructions...
[03:55:27] Got 11937 refs
[03:55:27] ######## MATCHING ########
[03:55:27] Found 0 derived references via COPYTRACK in SOURCE.
[03:55:27] Found 0 derived references via COPYTRACK in TARGET.
[03:55:27] Total refs to match - Source: 32730 Target: 55913
[03:55:27] Running REFMATCH: 0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
[03:55:49] Matched 16693 references.
[03:55:49] Conflict resolution...OK
[03:55:49] cnt 246
[03:55:49] instrsum 187
[03:55:49] discard 25
[03:55:49] doublerefs 97
[03:55:49]
[03:55:49] Matched 1553 addresses via REFMATCH, out of them 564 single.
[03:55:49] Array fill... OK, Got 0 addresses.
[03:55:49] Fill...
[03:55:49] Matched 460 addresses via FILL.
[03:55:49] Total matches: 2013
[03:55:49] 2/2025 with same address.
[03:55:49] Writing ECU file: C:\Tuning\Tools\tsunami\ecus\tmp\70195Q8Z.ecu
[03:55:49] Writing ADR file: C:\Tuning\Tools\tsunami\ecus\tmp\70195Q8Z.adr
[03:55:49] Writing GEN file: C:\Tuning\Tools\tsunami\ecus\tmp\70195Q8Z.gen
[03:55:49] FINISHED, time: 00:00:26 |
|
|
|
|
Logged
|
|
|
|
rkam
Full Member
Karma: +4/-0
Offline
Posts: 56
|
|
« Reply #2215 on: March 14, 2023, 12:56:17 PM »
|
|
|
Linking A2L RAM addresses to the ones found through identifier table I get some strange result.
F1EBI.bin contains DiagID 09497085, but the identifier names fit the Vida tables with DiagID 31219528 and NOT 09497085.
|
|
|
|
|
Logged
|
|
|
|
|
prj
|
|
« Reply #2216 on: March 14, 2023, 02:12:20 PM »
|
|
|
So V50 ME9 ECU only replies to a few services on KWP.
You can read and clear DTC, that's it. This is also seen in the service table, as there's those services and the rest is OBD services.
Everything else is on Volcano, so have to implement that crap.
There's also $1A, but it only responds a couple things:
0080: [ME(D)9] 5A 80 4D 45 28 44 29 39
0081: [f] 5A 81 03 97 66 FF
0097: [ME(D)9] 5A 97 4D 45 28 44 29 39
|
|
|
|
|
Logged
|
|
|
|
|
prometey1982
|
|
« Reply #2217 on: March 16, 2023, 02:53:36 AM »
|
|
|
|
|
|
|
|
Logged
|
|
|
|
|
prometey1982
|
|
« Reply #2218 on: March 16, 2023, 10:05:12 AM »
|
|
|
New version of VolvoTools. Added Mongoose JLR support. https://cloud.mail.ru/public/qHDs/RBR5724k3Moreover logger supports j2534 devices with one CAN on 6-14 pins. Flasher wants second CAN to shutdown ECUs on slow network CAN. Maybe it can be ignored if it can't open second. I'm not sure. P1 ME9 also should be supported. |
|
|
|
« Last Edit: March 16, 2023, 11:04:18 AM by prometey1982 »
|
Logged
|
|
|
|
|
prometey1982
|
|
« Reply #2219 on: March 18, 2023, 07:34:50 AM »
|
|
|
New version of VolvoTools. Added Mongoose JLR support. https://cloud.mail.ru/public/qHDs/RBR5724k3Moreover logger supports j2534 devices with one CAN on 6-14 pins. Flasher wants second CAN to shutdown ECUs on slow network CAN. Maybe it can be ignored if it can't open second. I'm not sure. P1 ME9 also should be supported. P1 doesn't support. But now should be supported all j2534 devices. Checked on DiCE, MongoosePro JLR and Openport 2.0. |
|
|
|
|
Logged
|
|
|
|
|
