Don't use macports! Use homebrew, you'll be a happier human being

To use brew to install objdump, you can use the formula I just finished. First enter:

brew edit binutils

then just paste in the following:

require 'formula'

class Binutils < Formula
url 'http://mirrors.ibiblio.org/pub/mirrors/gnu/ftp/gnu/binutils/binutils-2.22.tar.bz2'
mirror 'http://ftp.gnu.org/gnu/binutils/binutils-2.22.tar.bz2'
homepage 'http://www.gnu.org/software/binutils/binutils.html'
md5 'ee0f10756c84979622b992a4a61ea3f5'

def install
system "./configure", "--disable-debug",
"--disable-dependency-tracking",
"--program-prefix=g",
"--prefix=#{prefix}",
"--infodir=#{info}",
"--mandir=#{man}",
"--disable-werror",
"--enable-interwork",
"--enable-multilib",
"--enable-targets=x86_64-elf",
"--enable-targets=arm-none-eabi",
"--enable-targets=m32r"
system "make"
system "make install"
end
end

Save, and exit your editor. Then do:

brew install binutils

it will install everything with a "g" prefix (so that it won't override some of the MacOS builtin binaries). Once it's all done:

gobjdump -b binary --architecture=m32r --disassemble-all --disassemble-zeroes -EB myrom.hex > myrom_asm.txt

You should now have a disassembled ROM.

I'll also be submitting the formula to homebrew so hopefully soon the brew edit step won't be necessary in a bit.

 

Thanks for all that lodi but as I mentioned, I downloaded and compiled my own objdump, so that part of the challenge is over. Still got much more bigger fish to fry...

 

Yeah, reread your post and saw that, sorry. What is your strategy at this point?

I've been using the ecuflash xml files to locate addresses of tables, then looking for references to them in the code and starting to grok and comment code from there. Trying to follow richard's style as much as possible.

As soon as I have a decent amount of progress, I'm going to post my files up on github and start accepting pull requests from anyone who wants to participate.

 

Pretty much the same direction here. Been given the same advice by richard.
Unfortunately, his hands are abit tied in providing e.g.s

We'll see how far I'm able to get ... .

 

Nah, I'm totally 100% happy to provide examples of how to bounce through code to tables... backtrack from tables to code, suss out scales, etc. If that's what you want.

What I'm not able to do is provide annotated, dissected, commented code of other peoples' patches.

I've got my own patches too, of course. Those are totally fair game for anyone, and I'm happy to provide commented code for all of those.

A table discovery project is a great starting point for learning how all this stuff hangs together. My advice was (and is) to go for the tables first. Biggest gain for least pain... and a brilliant learning experience.

Rich

 

I'd love to learn more about table discovery... I've seen some posts on it they seem to like to mention things like "triangulation" that I know nothing about.

As you may have noticed I'm all about building tools to automate things and sharing those with others. So if I learn how to do table discovery I will figure out a way to automate it and I will open source the tools for doing it.

 

Alright. I have a tool now that will automagically comment all tables in the assembly as well as find and comment references to all tables. If you're interested in helping me check the references it found for accuracy, let me know and I will send over the fully commented disassembly for whatever ROM you want.

 

wow lodifreefly, that was RAPID!

I'm still slowly working my way through my first table.

I'll PM you my request.

 

Here are the common scale and table "header" structures...



Scales - 16 bit format

2 bytes: Destination Variable Address (relative to fp)
2 bytes: Source Variable Address (relative to fp)
2 bytes: Number of elements that follow
...
...then the scale data.


Tables - 8 bit format, 2-Dimensional

1 byte: Style of table. 02 = 2-dimensional
1 byte: Value offset (a fixed value to add to every raw table element)
2 bytes: Source Scaling Variable Address (relative to fp)
...
...then the table data.


Tables - 8 bit format, 3-Dimensional

1 byte: Style of table. 03 = 3-dimensional.
1 byte: Value offset (a fixed value to add to every raw table element)
2 bytes: Source X Scaling Variable Address (relative to fp)
2 bytes: Source Y Scaling Variable Address (relative to fp)
1 byte: Number of rows (or columns... I forget)
...
...then the table data.


Tables - 16 bit format, 2-Dimensional

2 bytes: Style of table. 0002 = 2-dimensional
2 bytes: Value offset (a fixed value to add to every raw table element)
2 bytes: Source Scaling Variable Address (relative to fp)
...
...then the table data.


Tables - 16 bit format, 3-Dimensional

2 bytes: Style of table. 0003 = 3-dimensional.
2 bytes: Value offset (a fixed value to add to every raw table element)
2 bytes: Source X Scaling Variable Address (relative to fp)
2 bytes: Source Y Scaling Variable Address (relative to fp)
2 bytes: Number of rows (or columns... I forget)
...
...then the table data.




There are some weirdo extra formats that crop up in later year ROMs (eg. 2011), but the above will cover 99.9% of all data styles.

If any typos have snuck in, let me know and I'll edit to fix.

Rich

 

I think it's pretty safe to say that we just blew the doors off this whole thing Thank you richard for giving me the info necessary to make this tool... I can't wait to see what it helps people find in these cars. For anyone who is serious about ROM disassembly, you can find my tool's source code at http://github.com/javiermuniz/ecutools

If you have any questions about it, or are having issues with it, feel free to drop me a PM.

If you find the tool useful to you I have one request: share what you find. I do not have a paypal account and will not be making one. I don't want donations. I just want access to the information that this tool helps you get

 

Javier, wait, you wrote an app that will go through a ROM and find tables automatically?

 

God mode enabled

 

I can find and annotate tables from XML, and their references all the way from RAM addresses.

Automatic table discovery is next. If all goes well I should have it working this weekend. The tricky part will be making it aware that two tables in different ROMs are the same, but based on what I've learned this week about the subroutines in these ROMs, I should be able to determine that with near certainty.

 

Just got automated scale discovery working. That was the big missing step towards automated table discovery. Now that I have this working I can look for valid table headers since the source address of the header will match the source address of a known scale, and the rest of the header will be valid. Figuring out the size of the table (# of elements in X/Y axis) is the only missing step at this point, I'm not sure if I can nail that 100% because it requires automated backtracing which gets very complex when you encounter branch statements in the assembly, but we'll see what I can get out of it

The last run of the program found about 168 previously undocumented scales, the # of elements, as well as the input and output addresses.

Of course, the real trick will be figuring out what these tables *do* but the fact that the application outputs valid EcuFlash XML and auto-comments the assembly should make tracking this stuff down way, way easier.

 

Automated table discovery is now a reality.

Can't vouch for it's accuracy just yet, but what richard calls the "rombot" just found and generated XML for 307 new tables in the 52690021 ROM. I am going through right now and checking the scaling values by hand, so far so good.