Learning to disassemble ROMs

Re: Learning to disassemble ROMs

Postby DreamWalker » Tue Nov 10, 2009 12:54 am

Andy, sorry for my english! I can do some mistakes.....

As I have understood, you have collected enough of analytic information!
All files and the documentation which you have are very necessary for me.

Can you send me it via e-mail or put it on the file exchange-server.
Thanks.

Givi
User avatar
DreamWalker
 
Posts: 6
Joined: Mon Nov 09, 2009 12:14 am
Location: Russia, Rostov-on-Don

Re: Learning to disassemble ROMs

Postby elevenpoint7five » Tue Nov 10, 2009 1:12 am

Hey no problem man! I figured you were asking for the files. PM me or post up here with your email address and I'll send it over to ya. In order to use the files you'll need IDA Pro 5.2 Advance though. I don't think they'll work with any older versions. They only other files I have are some Excel spreadsheets that you can download on page 1 on this thread, and the users manuals for the processors which I can email if you'd like but they are hosted around here somewhere as well. Just let me know!

Made some decent progress today in understanding some more of the code. It helps when I have someone else around to talk to about it, sometimes just typing what I'm thinking makes me realize little mistakes. Some things I learned today:

-In a subroutine, if there is a # sign before a number, it means it's actually a number
-In a subroutine, if there is NOT a # sign before a number, it means it's a memory location
-If you right click on a word or a byte, there are menu options that say "chart of xrefs to" and "chart of xrefs from", which lay out all subroutines, before or after, that word or byte. Basically a nice flow chart of how the logic is moving up to, or after, that point.
-If you have a ROM file that is 160kb in size, you need to first open it in a hex editor. at 0x20000 you need to insert a space, or sequence of 0's that is 0x8000 long. Basically from 0x20000 to 0x28000 needs to be all 0's before you chose an entry point(0x220).

I do not claim to be an expert on any of this, but I think I am starting to get the hang of it. If anyone wants to talk more, or has questions, or needs help, please, let me know. I'm more than happy to try!

Andy
elevenpoint7five
 
Posts: 20
Joined: Mon Aug 18, 2008 3:17 pm
Location: Chicago

Re: Learning to disassemble ROMs

Postby DreamWalker » Tue Nov 10, 2009 6:44 am

Send me manuals for processors! e-mail in pm.
And do you know How i can recognize in what processor is in my ECU? Subaru Forester 99' EJ205
User avatar
DreamWalker
 
Posts: 6
Joined: Mon Nov 09, 2009 12:14 am
Location: Russia, Rostov-on-Don

Re: Learning to disassemble ROMs

Postby elevenpoint7five » Tue Nov 10, 2009 8:40 am

I don't see a 1999 Forester listed as an available download on scoopypedia. I assume this means that nothing has been done with it. All of the ones I see in the def files are the same processor as the STi, which means my manuals would do nothing for you. I will send them over, however, you'll need to figure out what processor you have on your own, sorry!

Andy
elevenpoint7five
 
Posts: 20
Joined: Mon Aug 18, 2008 3:17 pm
Location: Chicago

Re: Learning to disassemble ROMs

Postby DreamWalker » Wed Nov 11, 2009 5:50 am

Here http://www.romraider.com/Documentation/SupportedECUs
I found that

3. European Domestic Market (EDM)
Forester Turbo
01/02 A4SE700E (MT/AT)
03 A4RL100J (MT/AT)

A4se700e - this is type of ECU's firmware?
User avatar
DreamWalker
 
Posts: 6
Joined: Mon Nov 09, 2009 12:14 am
Location: Russia, Rostov-on-Don

Re: Learning to disassemble ROMs

Postby elevenpoint7five » Thu Nov 12, 2009 9:39 am

That is not a 1999 though. That number is the ECU's Internal ID number.
elevenpoint7five
 
Posts: 20
Joined: Mon Aug 18, 2008 3:17 pm
Location: Chicago

Re: Learning to disassemble ROMs

Postby elevenpoint7five » Tue Nov 17, 2009 12:09 pm

I'm having some issues as of late, and I was wondering if anyone following this might be able to help me out. I also posted this in an old post about IDA as it seemed to fit pretty well. At least the first part.

First, I was wondering if the issue in IDA has been fixed in newer versions?

* there is an intentional non-standard ordering of operands for the BRCLR and BRSET opcodes. this is becaise IDA doesn't seem to follow branches if the code addresses are in an operand position greater than 3 (which happens when you use indirect addressing with X, Y, and Z). as a fix, i turned what should be:

BRCLR yOffset, Y, #bitmask, branchaddress

and changed it to

BRCLR yOffset, Y, branchaddress, #bitmask


Secondly, I'm having an issue getting the addressing down. It seems that sometimes the program is storing the contents of an accumulator to a memory location that seems to be part of a subroutine, specifically, an opcode, rather than storing it to a memory location that seems to be just that, a memory location. Is this a way of changing the logic that has been programmed, or am I reading it wrong?

Another issue I am having with the addressing is the offsets. For instance, I've been trying to figure the NPS out which according to the logger defs for RR is a switch at byte 0x000062 bit 7. So I created a custom def to log memory location 0x000062 as opposed to each individual bit. The number changed accordingly, depending on what I did. So that is obviously the correct location, however in IDA it seems to be stored elsewhere. The same location(0x000062) is set to what seems to be a pre-determined number using this code:
Code: Select all
lde #36h
ste 62h, Y

Can anyone explain how this index addressing works? Also, why it is being set in the program when I've logged it and found that it is changed by sensor input(even though I haven't been able to find any logic to support his idea, I know it to be true from logging)?

Thanks in advance to anyone that can lend a hand here, this has been kicking my ass all week and I am determined to learn this.

Andy
elevenpoint7five
 
Posts: 20
Joined: Mon Aug 18, 2008 3:17 pm
Location: Chicago

Re: Learning to disassemble ROMs

Postby Rhinoman » Tue Nov 17, 2009 1:07 pm

The code loads the value 36h into E and then stores it at the address 62h + (the contents of) Y. You will have to look back at the code to see what value is stored there
It is common practise to use each pointer for a seperate purpose, for instance Y may be used to index programme code and registers, Z for addressing RAM and X for addressing data memory.
Rhinoman
 
Posts: 27
Joined: Thu Jan 11, 2007 3:53 am
Location: High Wycombe, UK

Re: Learning to disassemble ROMs

Postby elevenpoint7five » Tue Nov 17, 2009 2:07 pm

I suppose I should have included the full code there to be more helpful.

Code: Select all
...
ldy #0F200h
...
lde #36h
ste 62h, Y
...


That would indicate that it is storing the value 36h(54 in dec) to the memory location 62h + 0F200h which is F262h, or 0x00F262, correct? If that's the case then this particular sub routine has nothing to do with what is stored at 0x000062, correct?

Please say I'm wrong because that just complicates things more haha!

Andy
elevenpoint7five
 
Posts: 20
Joined: Mon Aug 18, 2008 3:17 pm
Location: Chicago

Re: Learning to disassemble ROMs

Postby Rhinoman » Tue Nov 17, 2009 2:30 pm

That is correct, although the address is actually YFF200, where Y has nothing to do with the Y index register but represents a value that depends on the memory mapping. Which processor variant do you have? I'm not familiar with one that has a module at F200.
Rhinoman
 
Posts: 27
Joined: Thu Jan 11, 2007 3:53 am
Location: High Wycombe, UK

Re: Learning to disassemble ROMs

Postby elevenpoint7five » Tue Nov 17, 2009 3:23 pm

68HC16, the processor that is used in the 16bit Subaru ECU's. YFF200 doesn't seem like any address I've ever seen...Could that be a 32bit thing?
elevenpoint7five
 
Posts: 20
Joined: Mon Aug 18, 2008 3:17 pm
Location: Chicago

Re: Learning to disassemble ROMs

Postby Rhinoman » Tue Nov 17, 2009 3:33 pm

There is usually an address map for the device at the beginning of the datasheet, Y is often used to represent the most significant byte of the address, either 7 or F. The SCIMRM says this:

The state of the module mapping (MM) bit in the SCIM configuration register
(SCIMCR) determines where the control register block is located in the system memory
map. When MM = 0, register addresses range from $7FF000 to $7FFFFF. When
MM = 1, register addresses range from $FFF000 to $FFFFFF.


There have been a lot of different 68HC16 processors, unfortunately there are few datasheets available.
Rhinoman
 
Posts: 27
Joined: Thu Jan 11, 2007 3:53 am
Location: High Wycombe, UK

Re: Learning to disassemble ROMs

Postby elevenpoint7five » Tue Nov 17, 2009 3:39 pm

Does this help at all?

ROM:00000000 ; Processor : 6816
ROM:00000000 ; Device name : MC68HC16Z
ROM:00000000 ; Target assembler: CA6816

From the disassembly in IDA. The addresses you're referring to do not exist in this processor though as the ROM files are only 160-192Kb.
elevenpoint7five
 
Posts: 20
Joined: Mon Aug 18, 2008 3:17 pm
Location: Chicago

Re: Learning to disassemble ROMs

Postby Rhinoman » Wed Nov 18, 2009 1:17 am

I don't think that IDAPro can differentiate between different variants, the Z is the 132-pin variant and there are at least four different Z variants. The 68HC16 doesn't seem to have the variant or mask version stored anywhere in memory, unlike a lot of other processors.
The memory map can be a little difficult to understand at first, the 68HC16 has addresses from 00000h to FFFFFh. However the addresses are often just abreviated to the least significant 16-bits which are the bits that you usually use in the programme (X,Y,Z registers). This is because the data field is only 16-bits wide so when performing index operations the full address must be stored in two registers, the most significant bits of the address are stored in the extension registers XK, YK, ZK, so the full address of Y is actuall XY,Y.
Where pointers are always used to point to the same parts of memory, ie Y for programme memory, Z for RAM etc, the extension register is written to at the very beginning of the programme and can be ignored from then on.
To complicate matters further the MM bit can be used to move the location of the control registers from the lower half of memory to the top half, this is intended to be used when the processor is operated in one of the external modes and can make it easier to map external memory or peripherals to the bus without them clashing with internal functions.
The address space maps in the User Manuals are quite useful, below is a link to the Y3 User Manual, see page 3.21

http://www.rhinopower.org/ECUs/TLR/MC68HC16Y3UM.pdf
Rhinoman
 
Posts: 27
Joined: Thu Jan 11, 2007 3:53 am
Location: High Wycombe, UK

Re: Learning to disassemble ROMs

Postby elevenpoint7five » Wed Nov 18, 2009 4:47 am

That is actually starting to makle sense thank you! Also, I already have that pdf, thanks for the link though. So using the example I gave, is there a way to determine exactly where the value is being stored? I know you said its Y200Fh(I think, I'm on my phone and can't look back without losing this message :)) but that still doesn't make sense to me when looking at the logic. It seems to me that the program is initiating memory locations or something, but I'm just not seeing how the MM is set or determined. Thank you again for all your help, I really want to learn this, unfortunately there aren't many people that can do it, and the ones that do know how either won't help or they haven't seen my multiple requests for it.
Andy
elevenpoint7five
 
Posts: 20
Joined: Mon Aug 18, 2008 3:17 pm
Location: Chicago

PreviousNext

Return to Subaru (all models)

Who is online

Users browsing this forum: No registered users and 12 guests