Pages: [1] 2 3 ... 5
Print
Author Topic: Another hex dump interpretation  (Read 2587 times)
log1call
*
Offline Offline

Posts: 62


View Profile
« on: January 12, 2009, 08:28:51 PM »

this time for a jecs ecu from a 1990 ej20 NA Auto.

 Hi Phil, that's very kind of you to take on the overseeing of yet another beginner. Thank you very much.
 
 I have got the hex dump using the polaris software you recommended and that is attached below.
 I have also had a read of some 6502 instruction set, which is what I understand from your various posts this is using. I downloaded and read those from here...
 http://e-tradition.net/bytes/6502/6502_instruction_set.html
 If that is not the right set of instructions to be studying up then please let me know.

 I know practicaly nothing about programming Phil, apart from a bit of very basic Basic programming when I was homeschooling my two sons, so please be patient. I am however a mechanic and have a bit of experiance examining and interpreting data logs for subarus so, hopefully, we will be able to explain, each from his own field of experiance, what others might need to know to undertake this work some time in the future on their own cars. I'm really looking forwards to learning a more direct and accurate method of finding addresses than my current "guess and refine" method.
 
Well thanks again Phil for taking the time here and in the other forums.
                                                                                       Cheers, Brett.

 
Logged
b3lha
*
Offline Offline

Posts: 196



View Profile WWW
« Reply #1 on: January 13, 2009, 06:31:50 AM »

Hi Brett,

I assume this ECU uses the Mitsubishi M37791 CPU chip like my SVX, so I've sent you the M37700 series disassembler. You can download the instruction set and datasheet from my website: http://www.alcyone.org.uk/ssm/ecuinfo.html

Rensu's polaris software copies the last 32K of the 64K address space. Before attempting to disassemble the code, it is necessary to add 32K of junk to the start of the file so that the location of each byte in the file matches the location in the memory.

I included a 32K file of binary zeros in the zip. Use the following command to concatenate the two files into a new 64k file:

copy /b 32k.bin + hexdump703315.hex 703315.bin

Then run the disassembler against the 64K file

dis 703315.bin 703315.txt

It will run for an hour or so and create an assembler listing called 703315.txt
Logged

See my Subaru ECU and TCU website.
http://www.alcyone.org.uk/ssm
log1call
*
Offline Offline

Posts: 62


View Profile
« Reply #2 on: January 14, 2009, 02:45:11 PM »

Hey there newboy Daniel,
                                   you can sit next to me if you want.

 Phil, i did the first step and combined the two files, twice as it happened because the first time I must have typed something wrong and it only came out as a 32Kb bit file. I now have it as a 64 Kb file but when I try to "dis" it, it keeps on reporting "The system can not execute the specified program". I have tried numerous times, checking carefully my spelling, syntax, locations etc. I tried re-unzipping and installing the dis program, I even tried to find another copy online to check that first one wasn't corrupted, but I couldn't find a copy. I did find that program that Daniel is mentioning... the Melps... I downloaded that and made another folder with everything in it to run that program but it wouldn't run either succesfully either. It gave a message about the free program having a size limit it would dissassemble so I tried to dissassemble just a small part but it still gave the same response so I went back to your program again having concluded that the bin file must be defective. Does that sound logical? I have tried remaking the bin file but... No luck.

 No rush Phil, I'm happy to try and figure as much as I can for myself and will carry on trying various tests to try and figure out where I am going wrong.

 I hope you are having better luck Daniel. Keep me posted whether you have any success with the melps.
Logged
b3lha
*
Offline Offline

Posts: 196



View Profile WWW
« Reply #3 on: January 15, 2009, 06:15:47 AM »

Hi Guys,

The disassembler that I sent to Brett was corrupt. I've sent out a good version to both of you. I've also included a program to split the disassembler output into a separate file for each subroutine. I find this makes the code a little easier to work with.

There are now 4 files in the zip.

dasm77.exe - this is Hitoshi Kashima's disassember program
dis.exe - this is Eric Honsch's program that calls dasm77
32k.bin - this is my file of binary zeroes
split.exe - this is my program to split the disassembler output into a separate file for each subroutine.

Instructions same as before:

Concatenate the 32K of zeros and the 32K of rom to make a 64K file:
copy /b 32k.bin + hexdump703315.hex 703315.bin

Then run the disassembler against the 64K file:
dis 703315.bin 703315.txt

Then split it into separate subroutines
split 703315.txt

Hitoshi Kashima and Eric Honsch are legends in the ECU hacking community so I'm sure they would approve of what we are doing here.

Let me know when you've got that far.
Logged

See my Subaru ECU and TCU website.
http://www.alcyone.org.uk/ssm
mrdjc
*
Offline Offline

Posts: 38


View Profile
« Reply #4 on: January 15, 2009, 01:02:15 PM »

Hi Phil,

Thanks for the files!

Ok, I've done all this now, dissasembly took about 5 min, you stated previously it would take about an hour?

I now have lots of Sub files, what's the next step?

For anyone who doesn't know how to go about this, thought I'd add (Windows XP):
Rename your dump file to your ECU ID (742FA1 in my case) and add "hexdump" to the front of it:
"hexdump742FA1.HEX"

Unpack Phil's zipfile to the desktop, the folder will be called "dasm".
Copy your hexdump742FA1.HEX file into the folder.
Go to start, run and type in "CMD", hit enter.
Type in "cd Desktop" and hit enter.
Then "cd dasm" and hit enter.
You should now be in the dasm folder (C:\Documents and Settings\Administrator\Desktop\dasm)

Then just follow Phils instructions, remembering to change the ROM ID name to yours. So in my case 703315 becomes 742FA1.

Cheers,
Daniel.
Logged
b3lha
*
Offline Offline

Posts: 196



View Profile WWW
« Reply #5 on: January 15, 2009, 04:25:03 PM »

Daniel, can you email me your rom dump so I can see what we are talking about.
Phil.
Logged

See my Subaru ECU and TCU website.
http://www.alcyone.org.uk/ssm
log1call
*
Offline Offline

Posts: 62


View Profile
« Reply #6 on: January 16, 2009, 12:08:50 AM »

Hi Phil, Daniel,
                   I got those programs this morning and started again in a new folder and it ran very smoothly. It didn't take anywhere as long as expected though; about fifteen minues I think.
 
 I've just come in and have had a very quick read of the txt file and I think I recognised some familair addresses. Tomorrow, it being a Saturday, I intend to read over your,(Phil's),  previous descriptions on the various sites you contribute to, then the instructions set, then I am going to have some searches and see if I can track some data handling. Whoo ho!
 
 That sounds like a very excellent Saturday morning recreation!
 
I was a bit confused how the data it reads is all rom, yet some seems to be coming from addresses that I thought were readable with the ssm as ram memories. It has been a vrey busy day though! 

  There has been something else Phil I had been meaning to ask. With the 91 problem, have you tried keeping the wires from the ecu to the rs232 chip as short as possible? Once the signal has been picked up by the chip it is amplified up and is fairly immune to interferance or loss after that. I started off using longish leads for my convenience but soo found that if the ecu/chip wires were kept to about 200 mills then signal and conectivity problems were far fewer.

 Ok, I'm looking forwards to an interesting few hours so I'm off. Have a good night all and a good weekend too.
                 Cheers, Brett.
Logged
b3lha
*
Offline Offline

Posts: 196



View Profile WWW
« Reply #7 on: January 16, 2009, 04:49:00 AM »

Ok, I've done all this now, dissasembly took about 5 min, you stated previously it would take about an hour?
It didn't take anywhere as long as expected though; about fifteen minues I think.
 
I guess you guys have newer and faster PC's than me.  Grin

Daniel, I'll start a new thread to talk about your ECU, to try and avoid confusion when talking about addresses and so on.
http://www.subiesmart.com/forum/index.php/topic,44.0.html
« Last Edit: January 16, 2009, 05:02:03 AM by b3lha » Logged

See my Subaru ECU and TCU website.
http://www.alcyone.org.uk/ssm
b3lha
*
Offline Offline

Posts: 196



View Profile WWW
« Reply #8 on: January 16, 2009, 06:37:07 AM »

Next, download "Free Hex Editor Neo" if you haven't already got a hex editor.

Looking at the Sub-nnnn.txt files output from the split program, I notice that the first subroutine starts at address 9300. (ie the lowest numbered file is Sub-9300.txt).

Open up the 64K 703315.bin file in the hex editor and scroll down to the start of the ROM at address 8000. Page down through the hex and just look at it. You can patterns in it, like this for example:
Code:
00008120   7D 7D 7D 7D 7E 7F 80 80 80 80 80 80 80 80 80 80   }}}}~...........
00008130   7D 7D 7D 7E 80 82 81 80 81 81 7F 7F 7F 7F 7F 7F   }}}~............
00008140   7F 80 80 80 80 7F 80 7F 7F 80 7F 7E 7E 7E 7E 7E   ...........~~~~~
00008150   7E 7E 7E 7F 7F 7F 7E 7E 7F 7F 7F 7F 7F 7F 7F 7F   ~~~...~~........
00008160   7F 7F 7F 7E 7D 7C 7D 7E 7F 7F 7F 7E 7E 7E 7E 7E   ...~}|}~...~~~~~
00008170   7E 7E 7E 7D 7C 7C 7C 7D 7E 7E 7E 7E 7E 7E 7E 7E   ~~~}|||}~~~~~~~~
00008180   7D 7D 7D 7D 7C 7D 7D 7D 7E 7E 7E 7D 7D 7D 7E 7E   }}}}|}}}~~~}}}~~
00008190   7C 7C 7C 7C 7B 7B 7B 7C 7D 7D 7D 7D 7D 7D 7D 7D   ||||{{{|}}}}}}}}
000081A0   7C 7C 7C 7C 7C 7C 7C 7C 7D 7D 7E 7E 7D 7C 7C 7C   ||||||||}}~~}|||
000081B0   7E 7E 7E 7D 7C 7C 7D 7E 7F 7E 7E 7D 7D 7C 7C 7C   ~~~}||}~.~~}}|||
000081C0   7E 7E 7E 7D 7C 7D 7D 7E 7F 7F 7E 7E 7E 7E 7E 7E   ~~~}|}}~..~~~~~~
000081D0   7E 7E 7E 7E 7E 7F 7F 7F 7F 80 7F 7F 7E 7E 7E 7E   ~~~~~.......~~~~
000081E0   7F 7F 7F 7F 7F 7F 7F 7F 7F 7F 7F 7F 7E 7E 7E 7E   ............~~~~
000081F0   7F 7F 7F 7F 7F 7F 7F 7F 7F 7F 7F 7F 7E 7E 7E 7E   ............~~~~
00008200   80 80 80 80 80 80 80 80 80 80 80 7F 7F 7F 7F 7F   ................
00008210   80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80   ................
This is ROM data, where the the maps and constants are stored. When you get down to 9300, you will see a change, the data appears more random with no discernable patterns. This is program code.
Code:
00009300   C9 F0 F0 04 90 02 A9 F0 42 A9 00 80 1B C9 F8 F0   ........B.......
00009310   04 90 02 A9 F8 42 A9 00 80 11 C9 E0 F0 04 90 02   .....B..........
00009320   A9 E0 42 A9 00 4A 42 6A 4A 42 6A 4A 42 6A 4A 42   ..B..JBjJBjJBjJB
00009330   6A 4A 42 6A 42 48 D8 29 FF 00 78 8E 7A 40 18 6D   jJBjBH.)..x.z@.m
00009340   7A 40 58 AA F8 42 68 F0 31 B5 01 38 F5 00 F0 2A   z@X..Bh.1..8...*
00009350   B0 18 49 FF 3A 42 49 FF 42 3A 78 42 8D 7A 40 89   ..I.:BI.B:xB.z@.
00009360   0D 7A 40 58 89 28 18 75 01 60 78 42 8D 7A 40 89   .z@X.(.u.`xB.z@.
00009370   0D 7A 40 58 89 28 18 75 00 60 B5 00 42 A9 00 60   .z@X.(.u.`..B..`
At the end of the file, from addresses FFD4 onwards, is an important area called the interrupt vector table (IVT). The position and layout of this table can be found in the datasheet for the CPU. So it is the same for all ECUs that use the M37791 CPU.
Code:
0000FFD0   0D 05 07 FF 0E 97 D8 FE D8 FE 24 DC 0E 97 AE CE   ..........$.....
0000FFE0   0E 97 5F CE 0E 97 E2 CE 27 CE 0E 97 0E 97 F9 CB   .._.....'.......
0000FFF0   0E 97 0E 97 0E 97 A6 FF BD FF 0E 97 0E 97 0E 97   ................
The IVT is a list of 16 bit addresses that correspond to particular events that might occur. When one of these events occurs, the CPU stops whatever it is doing, looks up the appropriate address in the IVT and then runs the subroutine at that address. Later on, if it encounters an RTI instruction (return to interrupt), it will return and continue with what it was doing previously.

The layout of the IVT looks like this. I have filled in the addesses for you, but you can see how they match up with the hex data above. Notice that this CPU is "little-endian". That means that when a 16bit number is stored in the memory, it is stored with the lowest 8 bits first, then the highest 8 bits. For example, the address 970E is stored as "0E 97"
Code:
FFD4: A/D Interrupt control - 970E
FFD6: UART0 tx interrupt - FED8
FFD8: UART0 rx interrupt - FED8
FFDA: UART1 tx interrupt - DC24
FFDC: UART1 rx interrupt - 970E
FFDE: Timer D interrupt - CEAE
FFE0: PWM1 interrupt - 970E
FFE2: Timer B1 interrupt - CE5F
FFE4: TG2 interrupt - 970E
FFE6: TG1 interrupt - CEE2
FFE8: Timer B4 interrupt - CE27
FFEA: Timer B3 interrupt - 970E
FFEC: Timer C2 overflow - 970E
FFEE: Timer C1 overflow - CBF9
FFF0: Timer C2 strobe interrupt - 970E
FFF2: Timer C1 strobe interrupt - 970E
FFF4: External INT interrupt - 970E
FFF6: Watchdog timer - FFA6
FFF8: Debug - FFBD
FFFA: BRK instruction - 970E
FFFC: Divide by zero - 970E
FFFE: Reset vector - 970E
The most important one here is the "Reset Vector". This tells the CPU what to do when you first power it on. In this case, it runs the subroutine at 970E. You will notice that there are some other vectors pointing at 970E, Divide by zero, for example. Effectively this means, "Reboot if this event occurs".

The next thing to do is to label the subroutines called by these interrupt vectors. Starting at the beginning of the list we want to rename Sub-970E.txt to Sub-970E-Reset-Vector.txt. But we don't have a Sub-970E.txt because my split program hasn't split out the interrupt vectors. oops! If you open Sub-966D.txt and scroll down, you will see that subroutine 966D ends at 970D.
Code:
009709    A9FF00        lda     ax, #0x00ff                     ; Branch target from 9702
00970C    F8            sem                                     ; m:1 x:0, Branch target from 9707
00970D    60            rts     

VECTOR: A/D interrupt control address: 970E   Length: 159  M:0 X:0
00970E    D8            clm                                     ; m:0 x:0
00970F    A90000        lda     ax, #0x0000
009712    5B            tad     
You could split these out manually, but to save you the trouble, I'll send you a fixed version of the split program. Just delete the Sub-nnnn.txt files and run the new split against your 703315.txt file.
Logged

See my Subaru ECU and TCU website.
http://www.alcyone.org.uk/ssm
b3lha
*
Offline Offline

Posts: 196



View Profile WWW
« Reply #9 on: January 16, 2009, 06:45:52 AM »

Hopefully you have renamed your Interrupt Vector Subroutines something like this:

Sub-970E-Reset-Vector.txt
Sub-FED8-UART0-Vector.txt
Sub-DC24-UART1tx-Vector.txt
Sub-CEAE-TimerD-Vector.txt
Sub-CE5F-TimerB1-Vector.txt
Sub-CEE2-TG1-Vector.txt
Sub-CE27-TimerB4-Vector.txt
Sub-CBF9-TimerC1overflow-Vector.txt
Sub-FFA6-Watchdog-Vector.txt
Sub-FFDB-Debug-Vector.txt
Logged

See my Subaru ECU and TCU website.
http://www.alcyone.org.uk/ssm
b3lha
*
Offline Offline

Posts: 196



View Profile WWW
« Reply #10 on: January 16, 2009, 07:00:23 AM »

Next thing is to figure out the locations of the RAM in this ECU.

Run the command
Code:
findstr sta Sub-*
This means search through the Sub-* files and find lines containing the word "sta". sta is the store command, it means store a value in the memory. You get a long list of lines scrolling up the screen. You can see that most of them are storing values at addresses from 4000 up to 47FF.

Then, open the the Sub-970E-Reset-Vector.txt subroutine, reading through it, you can see that it sets the stack pointer to 47FF. This is most certainly the top of the RAM.

Code:
00971A    A2FF47        ldx     #0x47ff
00971D    9A            txs

All of the parameters you are looking for will be somewhere between 4000 and 47FF. That's only 2K of data to search rather than 64K.
Logged

See my Subaru ECU and TCU website.
http://www.alcyone.org.uk/ssm
b3lha
*
Offline Offline

Posts: 196



View Profile WWW
« Reply #11 on: January 16, 2009, 10:08:01 AM »

Now for something a little more interesting.

Lets find out how the check engine codes work. This will help us to find the parameter addresses. For example, if we can find the code that generates a temperature sensor error then the coolant temperature parameter will most likey be in the same subroutine.

Every Subaru ECU that I have seen so far has a table of the error codes in the middle of the code, immediately following the error subroutine, rather than in the data area at the start of the rom.

Open up the 64k binary file in the hex editor and search for "11 12 13 14" (IIRC on some ECUs it is in the reverse order "14 13 12 11"). It should find them at A90B. In fact you can see the list of CE codes starting from A8FB and running through to A912. Now search for the subroutine that references the start if the table at A8FB.

findstr a8fb Sub-*

You should see that Sub-A891 references this table. This is the "Lookup Error Codes" subroutine. You can rename it to "Sub-A891-Lookup-CE-Codes.txt".

Now search for subroutines that call a891

findstr a891 Sub-*

You should see that it is called by Sub-A747.txt. Now open up this file in notepad and find the places where it calls subroutine a891. "JSR 0xA891".
Code:
00A7A4    A24140        ldx     #0x4041
00A7A7    2091A8        jsr     0xa891
.....
00A800    A23944        ldx     #0x4439
00A803    2091A8        jsr     0xa891
Because I've previously spent a lot of time looking at this, I can tell you that one of these calls is to lookup "current" codes and the other is for looking up "stored" codes. The addresses loaded into the X register before the call are where the ECU stores its internal error flags.
For example, if you read RAM at addresses 4041 through 4043 and convert them to binary. You should see something like this:
00000000 00000000 00000000
Each one of the bit positions corresponds to a different CE error. You need to determine which bit corresponds to which error code. You can do this either by reading to code, or by generating some check engine errors (unplug sensors on at a time etc) and watching how the values change using the Hex Com Tool program.

I'm short on time at the moment, so I'll come back to this on Monday.
Logged

See my Subaru ECU and TCU website.
http://www.alcyone.org.uk/ssm
log1call
*
Offline Offline

Posts: 62


View Profile
« Reply #12 on: January 16, 2009, 05:02:35 PM »

Hi Daniel, Phil,
                   I got waylaid by two teenage sons dragging me into some gardening whilst the morning was overcast and cool. It has now got too hot and I have been dismissed.

 Phil, that's a great explanation. I have just read through it and I think I am going to be able to follow that! I'll be trying shortly(I hope).
 
 Daniel, I'm just about to go have a look in your new thread  and I will keep posting as I get through the steps.
Logged
b3lha
*
Offline Offline

Posts: 196



View Profile WWW
« Reply #13 on: January 16, 2009, 08:12:15 PM »

In reply to the last bit (Back onto this thread, I know.)

I tried searching for the value "11 12 13 14" and "14 13 12 11", then just "14" and they all come up blank. Should I be looking in Hex? I.e. 14 which (I think..) is "0E",13 "0D", 12 "0C", 11 "0B"Huh?

I looked at the adress you gave, but can't find a patern relating to Check Engine codes.

I take it "A90B" is 0000a900 and bit 0b?
*Edit* Oooh, I just clicked on it and it came up with A90B! You learn something new every day.*Edit*
My value there is "4c" which is hex for what? 4 + 12 ? Code 16? Which would be Fuel Injector No. 3 according to the table? I am confusselled. Huh? Is that the way you are meant to add the values to create numbers?

Brett, please let me know how you get on with the puzzle, and check over to "my" thread so we can compare notes.

Cheers,
Daniel.



Daniel, look at address A884 in your ECU.
Logged

See my Subaru ECU and TCU website.
http://www.alcyone.org.uk/ssm
mrdjc
*
Offline Offline

Posts: 38


View Profile
« Reply #14 on: January 16, 2009, 08:32:51 PM »

Phil, I can see clearly now, thanks for the pointer.. I feel a tad stupid now.
Just to explain how to use the search function in Free Hex Editor in that case for future reference:
I just hit Ctrl + F and typed in 11 12 13 14, then tried just 11, then just 14 and they all came back with no results... You need to set the  search type to "Hex Bytes" rather than "ASCII String" which it is set at default. Took me a while to figure this out... Brain wasn't computing quite right!

Back to "my" thread now!

On a sidenote, Phil, Could you please post a snippet of code from the Hex editor so I can see exactly what values and addresses you are using or are working out?
I can clearly see 11 12 13 14 15 etc in my values but I have no idea what is the actual START of the code, is it 11? Or before that? There's way to many numbers in there to see clearly and I have no idea where the rest are hidden, there are so many random numbers in there I dont know if they represent CEL codes or not.

Quote
Open up the 64k binary file in the hex editor and search for "11 12 13 14" (IIRC on some ECUs it is in the reverse order "14 13 12 11"). It should find them at A90B. In fact you can see the list of CE codes starting from A8FB and running through to A912. Now search for the subroutine that references the start if the table at A8FB.

Basicly that is the part I would like to see, A8FB to A912 so i can reference what you have typed and compare it to mine.

Cheers,
Daniel.

« Last Edit: January 16, 2009, 09:38:34 PM by mrdjc » Logged
Pages: [1] 2 3 ... 5
Print
Jump to: