Pages: [1]
Author Topic: ME7.3H4 Memory Map  (Read 8193 times)
Gigiur
Newbie
*

Karma: +2/-0
Offline Offline

Posts: 10


« on: August 29, 2018, 04:22:37 AM »

Hey guys,

I'm attempting to reverse the firmware of a Bosch ME7.3H4 coming from a Fiat Punto like the one I own. It's not mine as I haven't gotten the inteface to do an EEPROM dump yet. The codes of the ECU are identical though (0261206339 with SW Version:1037352995). I'll get my own binary soon(tm).

I've followed though Andy's first tutorial and opened the binary in ida, but I'm having trouble figuring out the memory map. Following through with the RESET routine DPP0-3 are assigned in three different branching locations and I'm not entirely sure which one is the one that gets executed  Huh. It appears they are assigned as follows: DPP0:0x2C, DPP1:0x1, DPP2:0x2, DPP3:0x3. Which if I read the datasheet properly should correspond to the TINY memory model. Could someone with a bit more experience verify if this is correct or if there is something I'm missing and to what memory mapping for RAM and ROM does this correspond? I have attached the binary to this post. Thanks a ton in advance

Logged
woj
Hero Member
*****

Karma: +43/-3
Offline Offline

Posts: 500


« Reply #1 on: August 29, 2018, 05:54:05 AM »

Somewhere close to reset entry you should have a sequence of four DPPX assignments, that's what it would be. DPP0 and DPP3 sounds about right in your case, DPP1 and 2 do not. I once looked at ME7.3H4, but I have it on another computer that I may or may not be able to get to soon.
Logged
woj
Hero Member
*****

Karma: +43/-3
Offline Offline

Posts: 500


« Reply #2 on: August 29, 2018, 08:37:39 AM »

So the bin I have been working on was from a Stilo, not at all sure how similar it is. But there the page registers were these:

DPP0 $204
DPP1 $205
DPP2 $E0
DPP3 $03

(DPP3 is always 3, otherwise it would be impossible to access the CPU register area).

EDIT: Just looked very briefly at your binary, though ECU symbol is the same and the size of the bin too, it looks totally different.
« Last Edit: August 29, 2018, 08:43:18 AM by woj » Logged
Gigiur
Newbie
*

Karma: +2/-0
Offline Offline

Posts: 10


« Reply #3 on: August 30, 2018, 01:31:42 AM »

Welp that's great  Roll Eyes Gotta reverse it with basically no info, since it's totally different. Thanks a ton though.

Assuming the DPP values I listed in the first post are correct how would I go about setting up a proper memory map? IDA says DPP0: 2Ch corresponds to page 0xB0000. But what part of the input binary should I map to that? And should I map that page as ROM or RAM? Does it even make a difference to IDA?

Edit: Apparently the ECU also has an EEPROM which is separate from the flash, if I'm not mistaken. How does that tie in with the memory model?
« Last Edit: August 30, 2018, 03:05:36 AM by Gigiur » Logged
woj
Hero Member
*****

Karma: +43/-3
Offline Offline

Posts: 500


« Reply #4 on: August 30, 2018, 06:09:31 AM »

You are asking the right questions, that's a good start.

I only looked at your binary layout and the reset code briefly, and I think your DPP-s you posted are actually right. The question how to load the binary is another story. DPP0 would be the RAM block, DPP1/2 the data block. Or vice versa, you will have to figure it out (if something is written to, then it's RAM Wink). For RAM you just create a properly sized section (certainly more than the 16K that one page has, the other part of the RAM would be accesses with explicit paging requests). For the data block you need to load the right part of the binary there, and for the code beyond 0000-4000 actually too. Finding the docs for the particular ST10 flavour might help here. But, to try something out, the data block would typically have data checks at its borders of the sort 3C3C / C3C3 / 5A5A / A5A5 / CC33 / 33CC. In the code you would find explicit checks of these locations against these values. If your mapping syncs with these checks, then you are almost home.

EEPROM is not mapped, it is accessed externally through SPI. But it does typically have a copy in RAM.

EDIT: Looking for check sum blocks would be another way to find out which address ranges are valid. Having said that, I do not see any in your file, are you sure it is a correct complete dump? It has suspiciously many FF blocks in it...
« Last Edit: August 30, 2018, 06:16:50 AM by woj » Logged
Gigiur
Newbie
*

Karma: +2/-0
Offline Offline

Posts: 10


« Reply #5 on: August 30, 2018, 07:23:31 AM »

Thanks a ton for the info! I'll keep eveything in mind  Grin. It's been very useful, I'd be totally stuck without your input. I've done my fair share of reversing but it was mostly desktop x86 stuff, and just a single relativley well documented embeded ARM device so I tend to have a bit of trouble with the lower level, processor/device specific, stuff like memory mapping...

I got the current image from a random forum online, it was the only one I found (excluding paid ones) matching my ECU's model number and version. Now that you're raising doublts about its completeness and validity i guess I'll just wait to dump my own since I've already ordered a KKL interface that should arrive tomorrow. If it were to not work I'll just steal Galletto off of a friend of mine, I'm sure he won't mind  Cool.
Logged
Gigiur
Newbie
*

Karma: +2/-0
Offline Offline

Posts: 10


« Reply #6 on: September 01, 2018, 08:20:29 AM »

So the my KKL interface didn't arrive on time Undecided But I looked at some other images from similar ECUs and they all look alike with large empty chunks. I think I figured out the memory layout though.

I think the flash is simply all mapped at 0x0 and contiunes linearly for it's entire length of 512KiB. There are also two RAM regions: one at 0xB0000 that is 32KiB long and one at 0xC0000 that is of an unkown length (but only the first few bytes are used). Does this sound reasonable enough to you?

Now the main reason I'm reversing my ECU (apart from pure curiosity) is to get rid of what appears to be a relativley significant delay from when you press the throttle to when the throttle body/engine responds to that input.  Looking at the ME7.3.1H Alfa Romeo Documentation it appears that FUDEKSA is the function responsible for calculating throttle body opening. And within that there is a subfuction VERZWDKS simply designed to delay the whole process. Am I correct in thinking this may be the culprit? Now assuming that the ME7.4H3 in my punto is similar enough to the ME7.3.1H for the documentation to be applicable, could you give me some tips on how would I go about finding out the location of this function? And by extension the location of the TVWDKS parameter which controls the delay.

Hopefully I've understood the documenation well enough to not have said something moronic, as It is quite dense and at times unclear if you aren't intimatley familiar with the ECU already. But thank god it exists otherwise the task would be 1000x more difficult....
Logged
woj
Hero Member
*****

Karma: +43/-3
Offline Offline

Posts: 500


« Reply #7 on: September 01, 2018, 03:02:55 PM »

Eventually you become very intimate with it, from some point on it starts to go very fast.

I have seen at least one other ST10 based ECU where the bin was essentially linear with the memory map, so it may as well be in your case. 0xB0000 for RAM sounds plausible too. 0xC0000 though, if you claim there is only a couple of locations used, sounds more like some special register area. For example, on my ECU 0xE0000 is Flashing registers area.

My hint - find out which exact ST10 flavour / family your ECU has and find the particular doc for it. It will have a section on memory / flash / registers map. It will be enlightening, I promise.

Can't help you with the throttle though, if you do not have a map definition for your ECU, or something close, it's not a straightforward thing to identify particular routines unless you have seen several of these ECUs. The way I always started with ECUs that had no docs / definitions was from the diagnostics interface. Diagnostics protocol is typically documented somewhere, or standard, and finding CAN / K-line communication routines is doable, though on ME-s not trivial. From that you can get basic ECU parameters and start tracing them back to routines.
Logged
Gigiur
Newbie
*

Karma: +2/-0
Offline Offline

Posts: 10


« Reply #8 on: September 01, 2018, 03:23:57 PM »

Thanks a ton woj very useful as always.

Problem is I think I'd have to disassemble the ecu to know exactly what chip is in it. I don't really wanna do that for fear of fucking up as I only got one and if it shits the bed my car is kinda fucked, I'm planning to buy a spare ECU as soon as I can though.

Thanks for the advice I was thinking of taking a similar approach anyway. I've got a long and arduous road ahead of me, first I gotta learn how these diagnostic protocols operate before I can even start searching for the relevant routines. I might open a new topic, maybe there's someone with a bit more experience with FCA ME7s that is willing to lend a hand.

Please excuse any mistakes I'm replying from mobile.
Logged
woj
Hero Member
*****

Karma: +43/-3
Offline Offline

Posts: 500


« Reply #9 on: September 02, 2018, 02:05:39 PM »

And it's also one of these ECUs:

https://www.ferrarilife.com/forums/attachments/modern-v8s-360-f430/52872d1357035439-how-bench-flash-your-me7h4.jpg

Not sure if you can even read the CPU tag on this. In any case, it is indeed not advised to open this ECU unless necessary.

 
Logged
Gigiur
Newbie
*

Karma: +2/-0
Offline Offline

Posts: 10


« Reply #10 on: September 04, 2018, 12:02:27 PM »

Well butter my ass and call me a biscuit, this ecu ain't even an ME7  Huh

To be more precise it appears to be an ME7 hardware wise but after a cursorly glance the software running on it appears to be much more similar to the ME2.1 for which I found a damos online (coming off my same model car). When you look at the version strings inside the ME7 it reports itself to be an "ME3.1/ ME7.3H4 FIAT / ALFA / LANCIA", which further confuses things, is it an ME3.1 or an ME7.3? As far as I know those are completely different ECU generations with completelry different features! Furthermore in Galletto my car is listed with an ME7.2.1/ME7.3H4, I know it's not the most reliable of sources but still. While the official bosch website lists it as a ME7.3H4, the software does not reflect this one bit. But holy hell, this versioning stuff is making me crazy.

Now I want to find a damos for an Alfa ME7.3.1 and judge how similar that is to mine, if it happens to be more similar than the Punto ME2.1 I'll be exhilarated since there is an engilsh documentation for that, otherwise trying to make sense of what the ME2.1 parameters do is going to be quite difficult, especially since the damos is in german. As far as you know is there any Bosch documentation for the ME2 series of ECUs?

Edit: Confirmed not an ME7.... The Alfa's firmware is much more similar to other ME7 firmwares such as the VAG ones. I'm dealing with an MESomethingElse.Unknown

« Last Edit: September 04, 2018, 12:10:09 PM by Gigiur » Logged
360trev
Full Member
***

Karma: +68/-2
Offline Offline

Posts: 235


« Reply #11 on: September 12, 2018, 02:31:18 PM »

It looks like they used ME7.3H4 hardware but compiled ME3.1 to *run* on the newer hardware...

I've taken a quick look using my Swiss Army Knife tool and it identifies the DPP registers as the
following...

-[ DPPx Setup Analysis ]-----------------------------------------------------------------

>>> Scanning for Main ROM DPPx setup #1 [to extract dpp0, dpp1, dpp2, dpp3 from rom]
main rom dppX byte sequence #1 found at offset=0x4a8.

dpp0: (seg: 0x002c phy:0x000b0000)
dpp1: (seg: 0x0001 phy:0x00004000)
dpp2: (seg: 0x0002 phy:0x00008000) ram start address
dpp3: (seg: 0x0003 phy:0x0000c000) cpu registers

Note: dpp3 is always 3, otherwise accessing CPU register area not possible


So its quite easy to load this rom into IDA to do some further analysis...

I did that (using the above setup to manually load it)

And then you can find the reset handler @ 0x2f4...

ROM:02F4 RESET_handler:                         
ROM:02F4                 mov     CP, #stack
ROM:02F8                 calls   0, bootinit
ROM:02FC                 reti


And there you can trace the bootinit function and see the dppx registers..

ROM:04A8                 mov     DPP0, #2Ch
ROM:04AC                 mov     DPP1, #1
ROM:04B0                 mov     DPP2, #2
ROM:04B4                 mov     DPP3, #3

These refer to segments of 16kbyte each segment. So you multiply the value by 16*1024 (which is 16384 in decimal or 0x4000 in hex). This is how you translate them to become physical addresses...

So... 0x2c x 0x4000 = 0xB000 which is exactly the address where your RAM is mapped to on this rom...
The rom itself is mapped to 0x0 which is different to most ME7.3H4's (Not all though as I've seen the same on some Alfa's too).

I searched for a few signatures and found some common ones which you may find useful such as;

Offset 0x486F8 is the call for SetDTCME75() with r12 = ErrorCode

Offset 0x44a08 is the offset to the main ROM Checksum variable initialisation code.
Offset 0x44a30 is the offset to the main ROM Checksum function.

Not familar enough with ME3.1 code to know precisely how it works but it looks pretty simple and I recognize the 'dna' applied in ME7.3 Smiley

Offset 0x44e60 is a UnsDiv32by16bit_16bit() function
Offset 0x44be2 services the watchdog handler

ServiceWatchdog_44be2: mov     WDTCON, r12
                                   srvwdt
                                   rets

etc...

If you need any more help let me know.. I surprised how little code there is in ME3.1 so pretty quick to fully disassemble it to be honest Wink
Logged
Gigiur
Newbie
*

Karma: +2/-0
Offline Offline

Posts: 10


« Reply #12 on: September 13, 2018, 12:10:37 AM »

Wow thanks a ton for the info! I had already used your multi-tool and it helped me identify the main checksum function but that's about it. I have the damos file for an ecu supposedly coming from the same car, it looks siminar enough but not quite the same, i'll attach it to this post. One of the subsections in that damos file is "EGAS: Dashpot und Lastschlagdämpfung" (EGAS: Dashpot and impact absorption), I assume the maps contained within (DSWDPA, DSWDPM, DSWLSDA, DSWLSDM, LSDPCOD, NISTV08, SWREV08, VANF) are resposible for the horrible delayed throttle response of the car. Do you think I might be right in this conclusion?

Problem is, I can identify them in the binary that I have the dam for, but for the life of me can't find them in the one I'm analyzing in IDA. Could you give me a hand at locating them? Maybe do you happen to know if there are any other easily identifiable maps used in proximity to the dashpot function ones that would allow me to locate them. I'm especially interested in LSDPCOD since it appears to be the code flags for the dashpot functions, which would theoretically allow me to disable them, leading to a more direct throttle response in theory.

I think I'm also using a different binary from the original one I posted, still not from my car, don't remeber why I switched, probably no reason at all. I'll also attach it to the post. Today I should finaly have my FDTI interface delivered so I can dump my ECU using galletto and work on that binary instead of random ones from the internet.
Logged
Gigiur
Newbie
*

Karma: +2/-0
Offline Offline

Posts: 10


« Reply #13 on: September 13, 2018, 07:47:34 AM »

Finally managed to dump my own car's ECU, it seems that the checksums are calculated in a different manner  Huh Could someone give me a hint on how to correct them if I edit the file?

Edit: nevermind I'm a retard. Was looking at a different function. One thing, there is only one checksum in this rom right? The function that calculates it is at 0x42EC6 . Are there any additional checksums?

Edit2: found all of the other checksums. Uploaded the updated file to the ECU, car started! That's a good sign  Grin Sadly disabling the dashpot function did nothing...
« Last Edit: September 14, 2018, 03:22:52 PM by Gigiur » Logged
Pages: [1]
  Print  
 
Jump to:  

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