RomRaider

Ok, im trying to step into the disassembly game and after messing with it for a couple day I cant get a handle on things

Ive had some experience with messing with disassemblies from turbo dodges, and I have been able to create code mods and such with that. But this subaru stuff is confusing the heck out of me...


Ive pretty much gotten to jumping to 0x220 and hitting "C" and thats about it lol. Ive used the .xml files to find data areas and convert the hex bytes to data that matches with what romraider shows. But some of the tables wont even show up, like "Primary Open Loop Fueling" @ 0x28E12 (Im testing on an 03wrx map A4TC300L), when I try to jump to 0x28E12 it doesnt even exist because the rom dissy only goes to 0x27FFF????

When I open the rom I put in "motorola series: 6816", but then it asks for rom and ram areas???

How do I get to the point where I can have each subroutine named and commented so that I can see whats going on???


Any help would be awesome. Thanks

If you have a 32 bit ECU try this:
viewtopic.php?f=25&t=6303
Otherwise read the ECU Analysis forum from last post to the first.

I'm guessing he has a 16-bit ECU based on his choice of a Motorola 68XX CPU. Unfortunately my thread is somewhat 32-bit specific since that's the only flavor I know.

If someone with 16-bit experience can provide some details I'll be happy to incorporate them into that thread so it can be useful to everyone. I'll give credit whoever provides that info, of course.

What's the CPU type?
What are the addresses and sizes of the ROM and RAM segments?
How do you find the first instruction, to start the unfolding process?
Is the SSM vector laid out the same way? Do the same tricks work for finding it?
A link to the instruction-set reference would be very useful, too.

Thanks!

I'm pretty sure all that is covered in this forum (and on openecu). It just takes time to read all the threads to accumulate the key points. I had spent some time doing that last fall and winter to get myself started in this process. Unfortunately there is no substitute for reading, until someone invents that cool Matrix downloading interface and process. That would be great and I suggest the first course be the processor manual and instruction set. It would be great to look at the code and see it running in your minds eye...

Ok im starting out with trying to understand the SSM stuff. I read through this thread viewtopic.php?f=25&t=5543 and I think I understand how to find everything but im just not able to?

In the thread above, andy seems to be disassembling the group-n rom. I opened this rom up with IDA and found the ecu-id "3D04EA4605" which was right after the "A210". The problem is that in my IDA the ecu-id is at address "0x23163" and andy finds it at "0x2b163". If I search for a reference to "23163" I get nothing but when I search for a reference to "2b163" I find a reference at "0x25D04" and thats the SSM LUT. So im confused as to why the address in my IDA is 8000h off?



But regardless I have found the SSM LUT. Now comes my other issue, im supposed to find a reference to the address at which one of the SSM parameters is located in the SSM LUT right? So the SSM LUT starts at 25D00 and I was looking for the ECT (located at the 8th index?) then that would be at "0x25D20". The way I understand it is, this SSM LUT is an indexed look-up table that has a bunch of pointers right? So if you want to find the coolant temp value you would go to this SSM table and find the 8th index which starts at address "0x25D20" and this index holds the data of 00020CFE which is in itself another address where the coolant temp is stored???




But I cant find any reference to "20CFE" or "020CFE", so I read that thread and andy says to search for the last two bytes "0CFE". So I do that and I get taken to this subroutine which doesn't seem right. And why would it only go off the last two bytes and not the whole address??

anybody?

Dunno about 16-bit code, but in 32-bit ROMs, addresses in the SSM LUT are pointers to functions. So you go to the function address, turn that into code, and you'll usually find a few instructions that pull something from RAM, call a function to convert it to a 1-byte value, and then return.

because you are missing the RAM segment which is 0x8000 bytes

Is the RAM segment static based on the processor or is it different between roms? How do I go about finding what it is?

its interesting that you try to disassemble without knowing the platform (it is 68HC16)
the ram segment is at 0x20000, 0x8000 bytes long

Not sure why I didn't see this thread sooner, but in the hopes of getting more people interested, here's what you need to do for 16bit ROMs:

-Convert the ROM to 192kb by adding the RAM segment. You can use any hex editor(I use TinyHexer) and insert the file I attached at 0x20000.

-Load the file in IDA, select the Motorola 6816 processor and hit ok on the next few screens. You don't have to change any of the other parameters.

-Hit 'g', 220, enter, 'c', enter.

That will give you most of the ROM unfolded. From there, use the existing defs, and the processor data sheets to work your way through the ROM. If there is interest, I will start a thread going into more detail and allow for questions. Let me know.

Andy

Yes please do that thread. There was one started but it's focused on 32 bit stuff.
Have a look at the format and maybe follow it if it works for you.
viewtopic.php?f=25&t=6303

Or I can rename that thread and make it more generic. It's mostly just missing three things:

1) RAM and ROM segment definitions (see #4 under "How do you open a ROM?")
2) Where to start disassembly (See #6)
3) Interesting address ranges (in the 3rd or 4th message in that thread)

Let me know and I'll be happy to include the 16-bit stuff and give you credit of course.

I sent you a PM with something I wrote up. Hopefully you can get it posted up in your thread. Anyone that is interested should keep an eye out over here---http://www.romraider.com/forum/viewtopic.php?f=25&t=6303

Thanks for the PM! I need some time to ponder how to integrate your 16-bit stuff with the rest and still keep the whole thing readable... maybe Saturday, but probably some night next week.