Who's working on disassembly?

a33b · **Joined:** Sat Jun 24, 2017 2:23 pm **Posts:** 315

fenugrec wrote:

"gcc --help" should be, "helpful" : )

LOL, I tried ? and help but not --help

I get what the -o is for, but as for nislib.c; Is gcc compiling both sources into a single executable? Looking at the source it seems very important and I presume I need to include it when compiling the other sources.

I'm having a productive read here

https://www3.ntu.edu.sg/home/ehchua/pro ... _make.html Starting to make sense of things.

Any other details I can submit regarding the potential bug? I'm not getting any other error messages.

fenugrec · **Joined:** Wed Jan 08, 2014 11:07 pm **Posts:** 652

a33b wrote:

I get what the -o is for, but as for nislib.c; Is gcc compiling both sources into a single executable?

Correct. The core functions are split out to nislib for ease of maintenance and reuse by the other tools as well as nisprog.

Quote:

Any other details I can submit regarding the potential bug? I'm not getting any other error messages.

all the command line arguments, and which ROM dump. Ideally I need to be able to reproduce the bug here. Else I can get you to get the info I need but it's a longer explanation. If you change arguments etc does it still crash ?

a33b · **Joined:** Sat Jun 24, 2017 2:23 pm **Posts:** 315

fenugrec wrote:

all the command line arguments, and which ROM dump. Ideally I need to be able to reproduce the bug here. Else I can get you to get the info I need but it's a longer explanation. If you change arguments etc does it still crash ?

Yeah, it has crashed every time, tried with/without min and different reference values. It populates the results quickly and then doesn't seem to want to exit. Still quite usable as I don't have to close my cmd window.

I've been using my 6y303 rom (slightly modified from stock)

fenugrec · **Joined:** Wed Jan 08, 2014 11:07 pm **Posts:** 652

a33b wrote:

Yeah, it has crashed every time

I just tried here on a random file and it crashes similarly - interesting, on my side the only thing that changed is I'm running a 64-bit build. I'll check it out

a33b · **Joined:** Sat Jun 24, 2017 2:23 pm **Posts:** 315

I've learned a lot since posting last. I would like to do some testing still but my evaluation of the code indicates that Nissan ECUs use a bit encoded mask to toggle support for DTCs. This makes things a bit tricky when it comes to toggling them on/off as each byte acts as 8 binary switches.

Anybody want to write some code for RomRaider Editor to be able to handle bitwise operations?
It came up a while ago but never went anywhere.

murphys_law · **Joined:** Tue May 24, 2016 1:45 am **Posts:** 216

a33b wrote:

I've learned a lot since posting last. I would like to do some testing still but my evaluation of the code indicates that Nissan ECUs use a bit encoded mask to toggle support for DTCs. This makes things a bit tricky when it comes to toggling them on/off as each byte acts as 8 binary switches.

Anybody want to write some code for RomRaider Editor to be able to handle bitwise operations?
It came up a while ago but never went anywhere.

I’m not positive, but I thought that you could do bit selections in the definitions. It’s been a while since I looked at it, but I’m thinking Subaru’s used it.

a33b · **Joined:** Sat Jun 24, 2017 2:23 pm **Posts:** 315

murphys_law wrote:

I’m not positive, but I thought that you could do bit selections in the definitions. It’s been a while since I looked at it, but I’m thinking Subaru’s used it.

They use bit stuff in the logger, but I haven't seen any in the editor definitions. Subaru used individual bytes for most of their on/off support flags.

Sasha_A80 · **Posted:** Mon Feb 12, 2018 3:52 pm

Currently you may use ecuFlash for bitwise editing Nissan\Hitachi\JECS ecu's.

darkhalf · **Joined:** Sun Jun 08, 2014 10:55 am **Posts:** 40

Late reply, but been looking at this. With latency, it seems (some) ECUs have their own latency subroutine

Working from CF43D (350Z) since its the most documented (fenugrec lists many symbol names on his site)

Quote:

ROM:00039D7C latency_calc_sub_39D7C: ; DATA XREF: ROM:000035F8o
ROM:00039D7C 2F E6 mov.l r14, @-r15
ROM:00039D7E 4F 22 sts.l pr, @-r15
ROM:00039D80 4F 12 sts.l macl, @-r15
ROM:00039D82 92 21 mov.w #FFFF84C8, r2
ROM:00039D84 E0 71 mov #h'71, r0
ROM:00039D86 D5 11 mov.l #volt_latency_change_7D9F, r5
ROM:00039D88 06 2C mov.b @(r0,r2), r6 ;R6 = (FFFF8539 batt volt?)
ROM:00039D8A E2 AF mov #h'FFFFFFAF, r2
ROM:00039D8C 62 2C extu.b r2, r2 ; R2 = AF
ROM:00039D8E 66 6C extu.b r6, r6 ; R6=byte(R6)
ROM:00039D90 32 68 sub r6, r2 ; R6 batt -= 175dec
ROM:00039D92 66 50 mov.b @r5, r6 ; latency change x batt-175
ROM:00039D94 D5 0E mov.l #inj_latency_846A, r5
ROM:00039D96 66 6C extu.b r6, r6 ; R6 result => byte
ROM:00039D98 06 27 mul.l r2, r6 ; 174*= value

Start from the function call list in the A33 code, and work through this so find a similar routine to the above.

I've found latency subroutine to be just before the injection multiplier (K) subroutine in this ECU

If you can find the battery voltage then it will make life easier (but consult battery voltage is at FFFF85BE for CF43D so not sure how it gets into this address FFFF8539). Looking at the FFFF8539 address in NissanDataScan I can see it is definately representing batt voltage.

The above is IDA output, but the problem is that IDA does not decode and keep track memory addresses/registers as operations are performed. More code simulation is required (similar to TRACE32 but there you are single stepping code). It therefore fails with searching for known memory addresses throughout the entire code base

fenugrec · **Joined:** Wed Jan 08, 2014 11:07 pm **Posts:** 652

darkhalf wrote:

Working from CF43D (350Z) since its the most documented (fenugrec lists many symbol names on his site)

Well it's "my" site but anyone can add to it, in theory - I think Shuher is pretty much the only one to have done so !

Quote:

If you can find the battery voltage then it will make life easier (but consult battery voltage is at FFFF85BE for CF43D so not sure how it gets into this address FFFF8539).

Hehe, it could be one of the RAM variable blocks that get copied around a lot. I've been meaning to write about this for a while but never got around to it, until this morning : https://nissanecu.miraheze.org/wiki/Fir ... references

In CF43D, the areas of interest are memcpy at 0x4124 which is called many times from "main_copystuff" at 0x2C38.

Quote:

IDA does not decode and keep track memory addresses/registers as operations are performed.

Indeed. I have some tools and scripts to help with this on my github repo, they usually find most read / write accesses. But some access patterns are hard to statically analyze and quickly confuse my heuristics; others like calls to memcpy need a bit of luck and instinct to find.

For those and other pathological cases I've sometimes used Renesas' HEW simulator with memory breakpoints. This is tedious because there's absolutely no way of simulating the entire codebase at once. What I did was tweak the calltable worker function to go through all the call tables, and also manually run some other top-level functions and interrupt handlers; IIRC that's how I found main_copystuff().

Sasha_A80 · **Posted:** Sun Apr 15, 2018 10:28 am

darkhalf wrote:

I've found latency subroutine to be just before the injection multiplier (K) subroutine in this ECU

This is exactly the same algorithm that used in Subaru JECS\Hitachi ecu's.

14V battery base voltage and injector dependable slope are used for latency calculations.

a33b · **Joined:** Sat Jun 24, 2017 2:23 pm **Posts:** 315

I had found injector latency for my rom (6Y303)! I think I found it working backwards from the values murph found in CM31C/CF43D. I verified my findings by working through the code. The latency subr in 6Y303 uses a different ram variable for battery voltage than that referenced by the CID definitions. Not sure yet what would prove to be a more reliable method of finding these values for other ROMs. I guess I should upload my updated defs to git.

Sasha_A80 · **Posted:** Sun Apr 15, 2018 10:59 pm

Magic h'AF 14.0V battery voltage value may help a lot.
I have never seen another base voltage for latency calculations for Nissan\JECS\Hitachi ecu.

darkhalf · **Joined:** Sun Jun 08, 2014 10:55 am **Posts:** 40

Yeah the older code is so much easier to read

6802 example:

Quote:

A65A BRA_A65A_Calculate_Inj_Latency_Change:
A65A : 86 AF ldaa #$AF
A65C : 90 09 suba RAM_0009_BATTERY_VOLTAGE
A65E : F6 BF 73 ldab ROM_BF73_LATENCY_CHANGE
A661 : 24 07 bcc BRA_A66A_Latency_pos
A663 : 40 nega
A664 : BD 80 00 jsr BRA_8000_A19_Mul_AxB
A667 : 40 nega
A668 : 20 03 bra BRA_A66D_Cold_Start_Enrich

Tijgetje57 · **Joined:** Tue Nov 03, 2020 10:43 am **Posts:** 11

im trying to get it up and running, but what's best to use and where to get it from?

I make Bin files and read out the car with pcmflash myself.

RomRaider

Forum rules

Who's working on disassembly?

Who is online