Pages: [1]
Author Topic: Clarification on map addressing  (Read 7629 times)
HelperD
Full Member
***

Karma: +25/-6
Offline Offline

Posts: 112


« on: November 28, 2017, 02:16:54 PM »

Hi everyone,

I have looked for the answer but to no avail.  If you all believe this to have been previously discussed outside of this: http://nefariousmotorsports.com/forum/index.php?topic=753.0 please link me to what you have found.

I have found instances in the binary I have decompiled where map addresses are looked up in the manner of that thread above.  For instance in my specific file if I have LAMFA at 0x81C9EC I can see that in the decompiled code there is movement of #9ECh to a register.  I have found this true in every instance of a me7.1 I have decompiled.

The problem I run into however is that MOST maps do not follow this addressing scheme.  Is there someone that can point me in the right direction of how most maps are looked up in these ECUs?  I will pay if need be however if someone would be so kind to lay it all out here on the open forum I will share my experience and a detailed HOWTO after I have a better understanding.
Logged
fknbrkn
Hero Member
*****

Karma: +176/-18
Offline Offline

Posts: 1401


mk4 1.8T AUM


« Reply #1 on: November 28, 2017, 03:59:07 PM »

there is a few methods to call a map
sometimes its a direct call to a beginning of a map like lamfa with moving map addr to r12 and axes to r13,r14 (iirc)
another way - map with axes in front of it with structure like X-axis size;Y-axis size;X-axis data;Y-axis data;Map data in that way called first x-axis size (ldrxn for example)

sometimes there is page/segment offsets in code like a example in your link

and special way - call with some kind of shit like a mov r12, [r4+#460h]
Logged
HelperD
Full Member
***

Karma: +25/-6
Offline Offline

Posts: 112


« Reply #2 on: November 28, 2017, 04:40:46 PM »

Thanks for the response man.

I just want to get this clear in the way that I can search for the call to the map.

In my MBOX 002 file I have LDRXN x axis start @ 1DCD2
Does this mean I should be looking for a call along the lines of "DA 81 D2 DC" or am I thinking about this the wrong way? -  EDIT I definitely am thinking about this the wrong way ...
« Last Edit: November 28, 2017, 04:43:56 PM by HelperD » Logged
fknbrkn
Hero Member
*****

Karma: +176/-18
Offline Offline

Posts: 1401


mk4 1.8T AUM


« Reply #3 on: November 28, 2017, 05:47:18 PM »

yeah because there is 10 00 before axis (16bit data) which means axis size = 00 10 => 10h => 16
and thats where is code called map in this case

you should load it to ida, hex searching for map calls is not a good idea
« Last Edit: November 28, 2017, 05:49:20 PM by fukenbroken » Logged
HelperD
Full Member
***

Karma: +25/-6
Offline Offline

Posts: 112


« Reply #4 on: November 28, 2017, 06:22:48 PM »

Ok I definitely found the access point in MBOX 002

Pictures for explanation.  Any input after this would be appreciated.

So I noticed from the first linked post that r12 was used for LDRXN and again reconfirmed by fukenbroken. 

The goal here is to make my own map switching function from scratch, I know it has been done a few times before but I want to challenge myself with something I have written from scratch. 


Attached is gallery of pictures of the process in which I found the call to map address Smiley
Thanks Fukenbroken for the input, it's much appreciated.


I will update this as time progresses Smiley

Album with thought process!
https://imgur.com/a/LFgRs


Logged
HelperD
Full Member
***

Karma: +25/-6
Offline Offline

Posts: 112


« Reply #5 on: November 28, 2017, 07:37:45 PM »

So, as mentioned above the addressing has been figured out for LDRXN.

I wanted to go forward and use this "call" location and place another call that leads down to free memory. I have done this and added some custom code to point at another free section which points to an exact duplicate of LDRXN in free space.  I am able to keep the ECU happy and it calls towards the new map however map access according to OLS300 shows that only the first section of the "new LDRXN" is being called. 

If I were to look at LDRXN in its normal location I would see access at both the first axis data and the first point in the map itself (when engine is not running)

I am not seeing this characteristic.  Any ideas?

Link below is to show that in small blank space below LDRXN I was able to add a second map with the switch working perfectly.  However, when I try to do the same thing in a further blank space it will only call the beginning of the axis info, not the map information as it does in this video. I can only imagine somewhere in the code there is something that is pointing to a specific page in the flash.  Any input would be much appreciated Smiley

https://youtu.be/gaou_7Y2sdU
« Last Edit: November 28, 2017, 10:04:31 PM by HelperD » Logged
HelperD
Full Member
***

Karma: +25/-6
Offline Offline

Posts: 112


« Reply #6 on: November 30, 2017, 12:05:40 PM »

So just a little update. 

I have been playing with page numbers and trying to find an ideal spot in my mbox to place all "alternate maps".  I have found a place under the rest of the standard map information on page number 3 which I will be using Smiley

 With this approach I was able to retain map recognition where it accesses first the map size, axis info and then actual map data!

Video of proof of application.

https://youtu.be/MmG9Qb65PkI
« Last Edit: November 30, 2017, 12:09:11 PM by HelperD » Logged
HelperD
Full Member
***

Karma: +25/-6
Offline Offline

Posts: 112


« Reply #7 on: November 30, 2017, 01:40:30 PM »

Success with LAMFA (3D Map), now onto timing and other relevant maps!
Shit this is fun as hell!!!

https://youtu.be/L0TRI55xcXE
Logged
HelperD
Full Member
***

Karma: +25/-6
Offline Offline

Posts: 112


« Reply #8 on: December 01, 2017, 09:05:58 AM »

Don't know if I am being annoying yet but thought I would update you guys again.

I was able to create alternative lookup maps for the following:

LDRXN
KFZW
KFZW2
LAMFA

I ran into a snag of using free space in different regions of the flash.  I was able to consolidate LAMFA and LDRXN to one empty space area and KFZW/2 to another empty space memory further up.  I personally don't like this because that means that the maps will be spread between two separate areas but I suppose I will have to deal with it for the time being.  If anyone has some input on addressing this issue please let me know. Basically I have tried every page number under the sun to try and get KFZW/2 in the same region as LAMFA/LDRXN but to no avail.

C
Logged
fknbrkn
Hero Member
*****

Karma: +176/-18
Offline Offline

Posts: 1401


mk4 1.8T AUM


« Reply #9 on: December 01, 2017, 11:34:35 AM »

well there is a call to math routine after kfzw/2 maps/axes moved to registers

and as i remember there is no availability to change page/segment in this case, its hardcoded to 204 or 206 some kind of that
so when you want to mov your kfzw maps at the end of a file you should basically run your own math routine based on a stock but with page pointers before every memory mov operator i.e.

mov r12, kfzw (ive done this years ago and really forget how to, just example)
mov r13, kfzw_axis
etc
calls #81h, #FFFh ; some routine to calc kfzw outpu

this calls to stock math routine; some kind of

mov r3, [r12+2] ; this square brackets means read from memory where kfzw starts + map offset
mul r3
etc

add some kind of
extp #22Ah, #1 ;new kfzw page num

before every square brackets operation with moved map / axis. (and no change if axis on a stock place)

put this math routine anywhere you want (personally im using 0xB0000 for my own routines and maps because of a tonns of free space usually) and call it instead of a stock
« Last Edit: December 01, 2017, 11:44:29 AM by fukenbroken » Logged
HelperD
Full Member
***

Karma: +25/-6
Offline Offline

Posts: 112


« Reply #10 on: December 05, 2017, 01:27:21 PM »

Thanks for the reply man Smiley

Just going to buckle down and take the stock binary apart piece by piece to figure out a way around the hardcoding. 
Logged
nubcake
Sr. Member
****

Karma: +53/-4
Offline Offline

Posts: 401


« Reply #11 on: December 10, 2017, 03:17:19 PM »

Thanks for the reply man Smiley

Just going to buckle down and take the stock binary apart piece by piece to figure out a way around the hardcoding. 

One of the workarounds I've done previously:
Find some large flat (filled with constant values) map in the same page that you need (e.g. 0x10000-0x13FFF). Then find where it's read in the code. Replace the "lookup" call with "mov r4, <map value>". Now you basically have free space where that map used to sit. Smiley

Be careful with implementing, and make sure that you don't mess up. Smiley
Logged
HelperD
Full Member
***

Karma: +25/-6
Offline Offline

Posts: 112


« Reply #12 on: December 10, 2017, 04:44:41 PM »

This is exactly what I've had to do for the time being.

Thank you for your response nontheless  Smiley
Logged
nubcake
Sr. Member
****

Karma: +53/-4
Offline Offline

Posts: 401


« Reply #13 on: January 18, 2018, 05:49:17 PM »

Just had another idea recently (didn't test how it works, though): you can try changing DPP1 to alternate page before "lookup" call, then change it back after you got the result.
Logged
Pages: [1]
  Print  
 
Jump to:  

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