RomRaider

Ah, thanks! I'm amazed at how much different 32bit addressing and architecture is from 16bit... I will get it though! I am determined!

Andy

Does this look normal to anyone? I am a little confused with the breaking up of the code. When I select graph mode, IDA shows this all as one sub routine, which doesn't seem to be the case...

Also, does the bar up top look like I have it opened correctly? Thanks guys!

This is an 04 STi ROM



Andy

I'm not too familiar with the rom, but it looks like you have most of it. What method did you use?

IDA will display loc_26334 as part of the first subroutine. I opened this rom, and the second subroutine in the picture is not part of nor referenced by the first, and it showed up as a separate subroutine in graph mode.

Thanks! I was misreading it as far as the second part goes. I am glad to hear that it looks like it's opened up ok though, I was pretty nervous about all the labeling I have done being wrong haha!

I'm still reading the manuals for the processors and I am starting to understand a bit, but I think I am missing a manual or my eyes aren't working as they should. I can't seem to figure out how an address is referenced. For instance if we used turbo dynamics proportional in the 04 STi the table address would be 0x567C4, but it doesn't seem to be called that way in any of the sub routines. In the 16bit ROMs there was always an offset, like 67C4, Z where Z = 5. Is there a similar case here?

Andy

Not sure about the 16bit roms, but in 32bit it goes like this:

Looking at turbo dynamics proportional, after address 0x1383E, the subroutine loads 0x537B4 into r4 and immediately jumps to sub_208C.


Data tables in rom (addresses from the definitions):


Looking at 0x537B4:


This is the "lookup table" for the TD_proportional table. The first longword and last two longwords contain data about the size of the table, type of data, and conversions. The second long is the TD_prop axis, and the third is the TD_prop data.

Sub 208C is passed the LUT in r4, and the current axis value in fr4, and returns the interpolated value to fr0. This sub, as far as i know, is used for all the 2D map pulls, and there is another similar routine used for 3D map pulls.

So, to find the lut, go to the search drop down box and select binary pattern, then type the data table address (from the definitions), and a red dot will show on the big bar, clicking it will take you to the LUT.

Since most of the LUTs are right next to each other, if you have all the data tables named (I suggest using the XMLtoIDC app to to this automatically, before you crack open the rom), all you need to do is highlight the third longword in the LUTs and the name of the table should show up, then you can name the LUT.

There is more information in this forum about the other values in the lut, I don't recall them offhand. Notice how the axis data is stored in longwords, while the data itself is in words, this info would be in the LUT.

This is from Freon's SD code, VEdef is 3d, dyndef is 2d:


If you aren't familiar with UINT16 or single precision IEEE-754 floating point values, it will help to learn about them.

Wow! Thank you so much! That was very informative!

Were your examples from an 04 STi? Because my screen looks much different... I was able to follow along with what you were saying in my head but not in the ROM.





Also, I have tried the xmltoidc thing but it prompts me to enter text or something(I can't remember offhand) when I try to load the idc file, any idea what I am supposed to put there?

Andy

My examples were taken from the A2ZJ710J Rom, not sure which you're using, perhaps there is another revision.

For XMLtoIDC, select "IDC file" from IDA's file menu, pick the file, OK. Then it pops up a small window. From there, you go back to File->IDC Command, and enter DefineA2ZJ710J(), or whichever rom you're using.

Also double check that your IDC file properly inherited the map definitions, with some rom revisions there is a problem and you only get logger definitions, ie: A8DH201X vs A8DH200X, in the definitions, there are no table defs for the 201X, just a 'inherits 200X' statement. To correct the issue, I just make IDCs for both roms and copy the map names over. If your IDC shows any map definitions at all, you're good to go.

Ok, I will give that a try, thanks!

Did you see the difference in our examples? It seems like your numbers are all put together to for hex numbers, where mine are still in line by line format, do you know what I did wrong?

Thanks so much for all of your help so far!

Andy

"can't rename byte as 'whatever' because this byte can't have a name(it is a tail byte)" is the only output I get with the xmltoidc program.

EDIT: I take that back, it did work! Just not for 3 bytes, oh well. THANK YOU!!!

I am using the same ROM as you.

Andy

Yep, it looks like you're using the same rom, but the analysis didn't bunch those data.b bytes into data.l longwords. It's really hit or miss and depends how you open the rom. I used the VBR method on this one, and sometimes I have data tables that are arranged in bytes not words or longwords. I think it may have to do with the order in which you name them. For example, naming the address before opening/analyzing the rom may result in a different data size than naming after analysis.

In any case, the 'D' key changes the data size. Note that you'll need to do this at a longword boundary, ie: in this case, addresses ending in 0, 4, 8, and C.

Oh man, this program is really confusing me! I appreciate your patience with me!

EDIT: I got it! There was some box that needed to be checked about combining data stuff in the final pass. Stupid box.

Andy

Things are coming along pretty decent now! Thanks again for all your help tonight! Could you tell me if this looks right? I have NO idea what it means, line 56768:



I'm not sure what .sdata is and it doesn't look like it belongs there...

Andy

I've seen the .sdata thing before and I'm not entirely sure what it is, and usually just change it to hex. I believe either the d or o key will change it.

Regarding the VBR, its pretty simple. In all the roms I've looked at, there is a long list of subroutines at the very end of the rom. At the end of the rom is the rom name, preceded by the VBR subroutine. Clicking this location takes you to it, then pressing 'p' marks it as a subroutine. From there, make sure you have 'make final pass' checked in the options, and reanalyze program, it should open up from there.

I think if someone could document one 16-bits and one 32-bits ROM dissassembly with the procedure in IDA (just the basics) , it would jumpstart a lot of people I believe.

I'm getting close to finishing up a couple patches for my rom, then I plan on compiling everything into a PDF including everything from opening a rom in IDA to the basics of pipeline flow and optimization.