NefMoto

So I thought I'd make my first proper post a contribution to the knowledge on here by sharing my findings.
I'm not making a complete tutorial as I had to figure things out by taking the time to look and think, and I'm glad I did.
However if it can provide someone with a few pointers hopefully in the right direction all good.


First job was just studying the flash ROM in WinOLS

So I knew where the maps were because I study 2d shapes and number sequences really hard or I'm just lazy and found a DAMOSs or a2ls-
however regardless they come in compact blocks rather than scattered through the file.
To me it seemed a good hint there as to what is going on and how it links data to code.

It became even more clear when looking at a ROM file with more than one block of data.
Most maps shared the same last four digits in their address e.g A1234 B1234 with maps of the same function in the next block of data.

A quick hex sequence search for these addresses seemed to highlight a useful area
(http://nefariousmotorsports.com/forum/index.php?action=dlattach;topic=10475.0;attach=20136;image)

Its easier to spot on EDC15C than EDC15P but still clear enough. Now what would that be there for I thought...

On to the eternal question of DPP's.

Well if I knew where to find the data references then logically thats where the dpp's point.
Or even if they didn't and on startup the whole data block was transfered to another area; it doesn't really matter at least for now as the same code will be calling the same piece of data albeit from a different place.

So I loaded the file in IDA and to start with I converted nearly everything other than the map area into code. I could undefine later any bits which were not code.
So surely EDC15 follows the ME7's tradition of defining the DPP's soon in the code, it's running on the same hardware isn't it?
And sure enough I came across the relevant code.

So plugging it in suddenly I got:
(http://nefariousmotorsports.com/forum/index.php?action=dlattach;topic=10475.0;attach=20138;image)

Remember the slope? A bit of playing with offsets and labelling and it became easy to see which functions were calling the maps.

I'm no expert on code but whatever logic the subroutines take they need to follow the path shown in the Funktionsbeschreibung for the RAM values passed along and order of maps.
So follwing the xrefs took me to where the maps where being used in the subroutine
(http://nefariousmotorsports.com/forum/index.php?action=dlattach;topic=10475.0;attach=20140;image)
3 registers in a row then passed to a subroutine in the IROM for a 2d map. Wasn't to hard to imagine what the 2 other references were and start labelling.

Finally looking at the function in graph view is like reading the flow charts in the EDC15Funktionsbeschreibung.
I must have worn out google translate by now.

(http://nefariousmotorsports.com/forum/index.php?action=dlattach;topic=10475.0;attach=20142;image)

All functions sat there ready to start abusing, mutating, chopping and patching.

Now by no means am I saying everything I've done is 100% right, there's probably lots of mistakes I'm sure people smarter than me can see. And there's loads I don't know yet so any help would be much appreciated.
The work and information on the forum here is great so hopefully some development on this ECU can be encouraged from this.

Credit to you man!

Sent from my E6853 using Tapatalk

Im quite noob in reverse engineering, but is it hard to add some functions to this ecu?

thanks a lot for this post! was about to loose hope on disassembling my edc15vm.
will try out what you posted
regards

hey
can you tell me the addresses of
-IROM
-RAM
-flash

Hi,
The best thing to do would be to download a copy of the C167 user manual as I couldn't attach it. It will save a lot of headaches as Bosch can only work with what is in there.

IROM
Chapter 3 Memory Organisation:

RAM
Same as above. Wherever the DPPs and code point is where it is. From what I can tell EDC15 doesn't use an external memory like ME7 just the IRAM. I'd be glad to know otherwise though.

To be honest neither the IROM or RAM locations matter for starting disassembly as it doesn't change the code we're looking at.

ROM
I did this the hard way trying the file at 0x0, 0x8000 0x10000 0x40000 0x80000 etc

Credit and many thanks to ne0h as he's already put this information on the forum:

If the ROM is at the correct location the code references from the reset handler point to the right places.
The other way to work it out is find the DPPs and subtract from the datablock to the start of the file.

Hope this helps you.

Personally I'd appreciate any help with the EEPROM location.
From what I see from the ADDRSELs there's some used space at 0x110000 to 122000. Would anyone know any more?

hey,
thanks for the reply
just to be clear-
-I loaded the IROM at 0x0000 upto 0x7FFFh
-Loaded the flash at 0x8000(paragraphs)

The IROM was disassembled automatically by IDA. But the flash wasnt. I understand that it has to be done manually or by a script. But how would i recognize data from code? I tried manually decoding but the data xrefs were going beyond the size of the flash area.
what am i doing wrong?
regards

Then your flash is loaded in the wrong place.
Have you read the C167 manual yet?
I don't mean it disrespectfully but you need to be familiar with information that is available and you would know where you have gone wrong.

For the data xrefs to be beyond the flash on first loading i'm guessing you've loaded the file actually at 0x8000, as the default DPPs point as close to the start as possible.
It would be impossible to load the flash at 0x8000 though as the file would run over the upper 4Kb of segment 0 and:


Have you looked closely at everything in the first post? I could have cropped out the addresses in the pictures. Maybe you could compare them to yours?

While it's interesting, it isn't necessary to load up the IROM, especially for first disassembly.
It makes it a lot simpler to work with one file to start with.


Data is in your data block and code isn't. Data makes useless code and code makes useful code. You can always undefine. DB 00.

EDC15 is the first thing I ever disassembled, the first time I used IDA and the first time I saw assembly lanuguage, so I'm saying just keep going. If I can then you can.

yes, I have read the memory map part of the c167 user manual.
the 00'F000h...00'FFFFh addresses are shown as IRAM,ESFR's,etc by IDA.
So the IROM is loaded at the correct address.
I'll try reloading the flash at 0x80000

Thanks a lot for your help, really appreciate it!

PS: did you use a script for converting flash data to code?

running into a dead end while reversing with IDA, hope that someone would be able to set me on the right track...

I loaded IROM at 0x0000h
Loaded flash at 0x80000h
when disassembling the flash contents, the data xrefs are to addresses in the range 0x8000h-0xE000h( the memory addresses right after the IROM and just before the XRAM)
As the screenshot shows, data is moved to r4 from location 0xC020h.
But no data is loaded from the map area in the flash file.
what am i doing wrong? I guess its something to do with DPP's but cant figure what.

regards.

Bump?

Nothing really wrong with the addresses your screenshot.
Just a lot of RAM being moved around conditionally
I've got a fairly good feeling though the line above the screenshot would include an address somewhere in your data.
A lot of functions have nothing to do with the "map" data anyway as I'm sure you are aware.

But you are right, without defining the DPPs there wont be anything pointing to the data blocks

The ECU has no idea where the data is in the file until it is told where to look.
It could be a single data block right and the beginnning, middle or end, two banks, or on some ECU's the whole flash is loaded to RAM and accessed from there.
The point being there must logically be instructions in the code that tells the ECU what to set the DPPs to.
And we enter those values under Set Default Register Values.

DPP0,1,2 and 3 are the first 4 SFRs- find them and look at the xrefs.
Or be really lazy and divide the data block's address (e.g 0xA0000 or 0xB0000 etc.) by 0x4000.
But then you'll have no idea why its that value or what to do with it. Plus it's not as satisfying.

hey Tim, thanks for the reply

0x4000 corresponds to 16kB so by dividing the address by 0x4000 will give the data page number in hex

so the first data block is at dp 0x33 and second at 0x3b.

looking at the xrefs for dpp0,1,2,3; none of these are set to 0x33 or 0x3b by any of the code xrefs.

also you said that a lot of ram is being moved. but the addresses being referred to are not part of the RAM. The RAM begins at 0xF600h but the data is being moved from locations like 0xC020h

edit: i had forgotten to add 0x80000 offset while calaculating the data page numbers. but even these are not set by any code.

Like I said the lazy way isn't really the best, unless you put the information here together.
The best way is to find the code that sets the DPPs and a little trial and error.

User Manual 3.2-Internal RAM and SFR Area
No there's loads of RAM and places for data to be called from before 0xF600.
IDA does all this hard work for us anyway.

im having trouble in correcting checksum for edc15p. it uses vag41-2002 checksum algorithm.

i made a change in unused flash memory(no maps or code).

winols, vagchkfix and mpps say that checksum is fixed but ecu doesn't boot. This happens only if the change is made in area 14000- 4FFFF. any other area I can change and checksum will be correct and ecu boots.

which tool do y'all use to correct checksum?
is there any way to disable the checksum function? I have identified the checksum routine(it is the only routine using seeds 0x8631 and 0xEFCD) what should i do to disable it?

i was planning on implementing new functions but have hit a dead end cause of this checksum issue.

regards

Are you sure the space is unused?
What kind of change- random hex, extra maps, or code added?
0x4FFFF takes you beyond the start on the "map" area on EDC15P. There are many commonly changed maps before that (drivers wish, torque limit, smoke MAF) so surprised for a checksum not to be able to correct that area. WinOLS shows which checksum block is in the current selected area- maybe you could find the checksum for that block and see if it is being corrected for any changes made.

Checksums is an interesting topic though, I'd be interested in being able to disable/control them too.
Would anyone know the best way of going about it?

The registers before calling the checksum subroutine seem to define which area is to be checked. Maybe we could change these values to just keep checking the IROM?
I guess the roughest way would be reversing a jump to just continue with a wrong checksum instead of jumping to reset- would it work?
nops?

AFAIK, he already did just that.  ;)

Actually there are two checksums on the edc15

When the ecu boots, the IROM checksums the flash in address range 10000-13FFF and then the code in the flash checksums the remaining area. So the checksum as such cant be dosabled entirely cause we can't write to irom( or is this possible on the c167,,, i just need to change one "0x2D" to 0x0D, to disable checksum entirely).

Winols corrects the checksum for 10000-13fff if you make the code addition/changes within winols.. it does not if you import an edited bin

I wrote a simple program to calc checksum for 10000-13fff and disabled the rest of the checksum function...
You could also just copy the checksum funtion from irom to Keil and load the hex file, and see the checksum result and then correct checksum...

FYI, it should do that if you import the edited file as a version of the original one. Didn't test it with EDC, but definitely works that way with ME7.