Pages: [1] 2
Author Topic: EDC15 Reversing  (Read 31164 times)
Tim
Newbie
*

Karma: +6/-0
Offline Offline

Posts: 12



« on: June 03, 2016, 10:00:12 AM »

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


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:


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

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.



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.
« Last Edit: June 03, 2016, 10:09:51 AM by Tim » Logged
n0ble
Full Member
***

Karma: +2/-0
Offline Offline

Posts: 192


« Reply #1 on: June 03, 2016, 11:00:16 AM »

Credit to you man!

Sent from my E6853 using Tapatalk
Logged
eeds35
Newbie
*

Karma: +0/-0
Offline Offline

Posts: 9


« Reply #2 on: June 15, 2016, 01:07:08 PM »

Im quite noob in reverse engineering, but is it hard to add some functions to this ecu?
Logged
nihalot
Full Member
***

Karma: +41/-3
Offline Offline

Posts: 117


« Reply #3 on: July 13, 2016, 03:19:49 AM »

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

www.tangentmotorsport.com

multimap/LC/rolling antilag for MG1/MED17/EDC17/MED9/EDC15

contact for reverse engineering services of any ECU/TCU
nihalot
Full Member
***

Karma: +41/-3
Offline Offline

Posts: 117


« Reply #4 on: July 13, 2016, 04:39:10 AM »

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

Logged

www.tangentmotorsport.com

multimap/LC/rolling antilag for MG1/MED17/EDC17/MED9/EDC15

contact for reverse engineering services of any ECU/TCU
Tim
Newbie
*

Karma: +6/-0
Offline Offline

Posts: 12



« Reply #5 on: July 13, 2016, 02:30:21 PM »

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:
Quote
Most internal memory areas are mapped into segment 0, the system segment. The
upper 4 KByte of segment 0 (00’F000H … 00’FFFFH) hold the Internal RAM and Special
Function Register Areas (SFR and ESFR). The lower 32 KByte of segment 0
(00’0000H … 00’7FFFH) may be occupied by a part of the on-chip ROM/Flash/OTP
memory and is called the Internal ROM area. This ROM area can be remapped to
segment 1 (01’0000H … 01’7FFFH), to enable external memory access in the lower half
of segment 0, or the internal ROM may be disabled at all.

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:
Quote
At first I was changing every DPP to the values present in the IROM and so having a lot of problems locating anything... Sad
DPP3 it's used for RAM\CAN access so the default value (3) is OK for the entire file.
The 29F400BT flash is mapped @ 0x80000 so loading in IDA you have to put 0x8000 (paragraphs).
I suggest to first locate a RAM variable like dzmNmit (engine rpm) or something like this,
will give you a nice picture of how the system control strategy works.
There are NO direct Maps references in EDC15 due to codeblocks so its a bit tricky to found how they're addressed.

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?

Logged
nihalot
Full Member
***

Karma: +41/-3
Offline Offline

Posts: 117


« Reply #6 on: July 15, 2016, 12:10:29 AM »

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
Logged

www.tangentmotorsport.com

multimap/LC/rolling antilag for MG1/MED17/EDC17/MED9/EDC15

contact for reverse engineering services of any ECU/TCU
Tim
Newbie
*

Karma: +6/-0
Offline Offline

Posts: 12



« Reply #7 on: July 15, 2016, 02:03:33 PM »

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:

Quote
The upper 4 KByte of segment 0 (00’F000H … 00’FFFFH) hold the Internal RAM and Special
Function Register Areas (SFR and ESFR)

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.

Quote
But how would i recognize data from code?

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.
« Last Edit: July 15, 2016, 02:10:20 PM by Tim » Logged
nihalot
Full Member
***

Karma: +41/-3
Offline Offline

Posts: 117


« Reply #8 on: July 17, 2016, 12:23:20 AM »

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?
Logged

www.tangentmotorsport.com

multimap/LC/rolling antilag for MG1/MED17/EDC17/MED9/EDC15

contact for reverse engineering services of any ECU/TCU
nihalot
Full Member
***

Karma: +41/-3
Offline Offline

Posts: 117


« Reply #9 on: August 07, 2016, 10:39:15 AM »

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.
Logged

www.tangentmotorsport.com

multimap/LC/rolling antilag for MG1/MED17/EDC17/MED9/EDC15

contact for reverse engineering services of any ECU/TCU
nihalot
Full Member
***

Karma: +41/-3
Offline Offline

Posts: 117


« Reply #10 on: August 10, 2016, 10:53:33 PM »

Bump?
Logged

www.tangentmotorsport.com

multimap/LC/rolling antilag for MG1/MED17/EDC17/MED9/EDC15

contact for reverse engineering services of any ECU/TCU
Tim
Newbie
*

Karma: +6/-0
Offline Offline

Posts: 12



« Reply #11 on: August 11, 2016, 04:36:40 AM »

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.
Logged
nihalot
Full Member
***

Karma: +41/-3
Offline Offline

Posts: 117


« Reply #12 on: August 11, 2016, 10:24:25 AM »

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.
« Last Edit: August 11, 2016, 11:22:03 AM by nihalot » Logged

www.tangentmotorsport.com

multimap/LC/rolling antilag for MG1/MED17/EDC17/MED9/EDC15

contact for reverse engineering services of any ECU/TCU
Tim
Newbie
*

Karma: +6/-0
Offline Offline

Posts: 12



« Reply #13 on: August 12, 2016, 07:42:55 AM »

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.

Logged
nihalot
Full Member
***

Karma: +41/-3
Offline Offline

Posts: 117


« Reply #14 on: August 24, 2016, 04:01:38 AM »

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

Logged

www.tangentmotorsport.com

multimap/LC/rolling antilag for MG1/MED17/EDC17/MED9/EDC15

contact for reverse engineering services of any ECU/TCU
Pages: [1] 2
  Print  
 
Jump to:  

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