RE5R05A TCM Reprogramming

Pytrex · **Posted:** Tue Dec 14, 2021 9:15 pm

Here's CD40A. It's from an 03 Z's TCM, which is the external TCM. So I'm not sure how useful it'll be (06 has the TCM incorporated with the valve body). Unfortunately, unpackdat is not able to unpackdat dat, it creates the .bin file, but it doesn't actually add data to it. I think maybe because the size is not standard like ECU ROM's?

P1on3R · **Posted:** Wed Dec 15, 2021 5:01 am

Pytrex wrote:

Here's CD40A. It's from an 03 Z's TCM, which is the external TCM. So I'm not sure how useful it'll be (06 has the TCM incorporated with the valve body). Unfortunately, unpackdat is not able to unpackdat dat, it creates the .bin file, but it doesn't actually add data to it. I think maybe because the size is not standard like ECU ROM's?

It's for Hitachi RE5 TCM board.

Pytrex · **Posted:** Wed Dec 15, 2021 5:14 am

P1on3R wrote:

It's for Hitachi RE5 TCM board.

That reminds me, do you happen to have the reprogramming data for 31036-CF40A? It’s not even in the mega-consult .dat zip or Nissan’s website, so no clue why it remains hidden away.

P1on3R · **Posted:** Wed Dec 15, 2021 8:20 am

Pytrex wrote:

P1on3R wrote:

It's for Hitachi RE5 TCM board.

That reminds me, do you happen to have the reprogramming data for 31036-CF40A? It’s not even in the mega-consult .dat zip or Nissan’s website, so no clue why it remains hidden away.

Hitachi RE5 board reprogrammes without any problems with Consult-3(3+), but when board is a new-one.
In other cases - it 50/50.

Pytrex · **Posted:** Wed Dec 15, 2021 1:22 pm

P1on3R wrote:

Hitachi RE5 board reprogrammes without any problems with Consult-3(3+), but when board is a new-one.
In other cases - it 50/50.

Well, it’s certainly reassuring to receive more confirmation!

Pytrex · **Posted:** Thu Dec 16, 2021 7:11 pm

Also, here are the Seeds:

Code:

$27 01: (Programming Mode)
0x20 0x01 0x08 0x09

$27 81: (Normal Diagnostic Mode)
0x9C 0x4E 0x27 0x13

Any chance these can be converted to keys? I only tried Nisprog's "gk" command once when connected, but it was during programming mode where $AC isn't supported. I don't think it can guess the keys though, because attempting to dump the RAM returned "hack mode : bad AC response 02 EC"

.....Aaaanddd after reading an old post, Fenugrec recommended extending the read timeout for the TCM. So technically all of my ROM/RAM dump testing is useless because the TCM does actually need the read timeout extended in order for it to return full messages at times. Whoops! But attempting to dump the next bytes after the original ROM dump returns "hack mode : bad AC response F7 2D". I tested various sections of ROM and they all returned this (these are all outside the known ROM area).

fenugrec · **Joined:** Thu Jan 09, 2014 3:07 am **Posts:** 652

Code:

 Unfortunately, unpackdat is not able to unpackdat dat, it creates the .bin file, but it doesn't actually add data to it.

I don't think it's a huge problem - look at the screenshots below, there seems to be two "areas" being downloaded with slightly different formats for SID 34 requests. It would probably take minor mods to adapt unpackdat to unpack dat.

Pytrex wrote:

Code:

$27 01: (Programming Mode)
0x20 0x01 0x08 0x09

$27 81: (Normal Diagnostic Mode)
0x9C 0x4E 0x27 0x13

Any chance these can be converted to keys?

No. If you had a lot of *pairs* of seed + keys, maybe, but by then it'll be easier to look at a ROM dump.

Re read timeouts for TCM : that "bad AC response F7 2D" is suspicious and doesn't look like a valid 7F negative response. Maybe delay issues again, hard to say without a bit more context. Also stop trying to dump inexistant memory, heh.

Pytrex · **Posted:** Tue Dec 21, 2021 2:57 pm

fenugrec wrote:

I don't think it's a huge problem - look at the screenshots below, there seems to be two "areas" being downloaded with slightly different formats for SID 34 requests. It would probably take minor mods to adapt unpackdat to unpack dat.

I guess I'm not understanding what's available in a normal .dat file. Does "34 80 80" and "34 81 01" represent actual $34 requests? If so, why would the SID request be formatted in such a way? Since in the ECU ROM dump, the SID requests have function handlers that aren't just strings of commands. I mean, if the dat has a bunch of command strings, I wouldn't be complaining lol It would make things even easier.

Quote:

No. If you had a lot of *pairs* of seed + keys, maybe, but by then it'll be easier to look at a ROM dump.

Well, hopefully I can get this stupid ROM dumped then lol That would be frustrating, getting almost all the steps down just to get stopped by security access haha

Quote:

Also stop trying to dump inexistant memory, heh.

Technically, it's not inexistant! If you look at the internal memory map, we currently only have CMF Flash A and B dumped thus far! Technically, what's left is 26kb of RAM and 64kb of "Control Registers and IMB2 Modules".

fenugrec · **Joined:** Thu Jan 09, 2014 3:07 am **Posts:** 652

Pytrex wrote:

Does "34 80 80" and "34 81 01" represent actual $34 requests? If so, why would the SID request be formatted in such a way?

Well that's the idea... their reflash tool needs to know what requests to send, and they decided to specify the SIDs quite litterally like this in the .dat. So I'd imagine it parses the .dat file and pretty much sends those frames as-is.
After the "34 80 80" or whatever, look for maybe a "# of ROM bytes in this frame" field, and "address where this ROM data ends up". With the Address field changing for every frame, of course.
And at the end of each frame possibly a checksum (in addition to the iso14230 checkusm that will be added once the frame is sent, unless it's already in there - I haven't noticed)

Pytrex · **Posted:** Tue Dec 21, 2021 5:04 pm

Holy crap, you weren't joking. The .dat file is LITERALLY just $34 requests with the proper data. I mean, that's the ENTIRE .dat file's contents. So that's how you could get the ROM dump, by just removing the $34 requests and the checksum value of "0x28" at the end of each request. That's actually really freaking cool!

Findings:
This actually makes PERFECT SENSE NOW! Do note, the following addresses are NOT confirmed! I'm just making assumptions as to what certain ARB ID's represent. We would need to look into what exactly $34 80 80 is doing, and seeing why $34 81 doesn't cover a consistent ROM block.

$34 80 Formatting and Covers;
$34 80 80 XX XY 20 ALWAYS. Where XX XY = Address.
0x6000 -> 0x8000

$34 81 Formatting and Covers;
$34 81 XX XY XZ 20 where XX = 0x01, 0x02, 0x03, 0x04, 0x05, 0x09, 0x0A, and 0x0D. XY XZ = Address.
Do note that I'm fairly certain that XX XY XZ is the entire address, but I separated them until we can confirm that.
0x10000 -> 0x59400
0x8FF00 -> 0xA2500
0xDFE00 -> 0xDFFE0

Attached below is the $34 commands and the data provided by the commands in two separate text files (hex formatting).

Pytrex · **Posted:** Tue Dec 28, 2021 11:49 pm

Here's something interesting.

Code:

$1A Request and Response in Diagnostic Session 85 (Reprogramming Mode):
DISCLAIMER: The ARB ID is included in the response normally, but I removed it for this explanation. 

$1A 80 - BB020209BOSCH GS19 MPC555 CC_OFFBDM_RBWERK 1270H00114 000000000000000000000000

CMF Flash Area Address - ASCII String
0xFD74 - BOSCH GS19 MPC555 CC_OFFBDM_RBWERK 1270H00114 000000000000000000000000 
0xFFE5 - BB020209 (Technically there should be a C at the beginning, but not sure why it doesn't return that)


$1A 81 - 0x03 0x8A 0x68 0x04 0x8B 0x6F 0x69 0x06 0x8C 0x6F 0x6F 0x6F 0x61 0xFF

While that $1A 80 ASCII response is taken from the CMF Flash Area (it must combine two separate ASCII strings), the $1A 81 response doesn't exist in the CMF Flash Area nor does it appear to mean anything in ASCII. According to NERS, the $1A 80 response is considered to be "Vehicle Info". $1A 81 response is considered to be "Part NB Discriminated Number" and "ECU Part Number".

sirnixalot · **Joined:** Tue Nov 24, 2020 2:20 pm **Posts:** 13

Still out here lurking in the shadows with zero clue what's going on :lol:

Thanks for the continued efforts!

n00bz · **Joined:** Thu Feb 09, 2017 12:10 am **Posts:** 60

Pytrex wrote:

Here's CD40A. It's from an 03 Z's TCM, which is the external TCM. So I'm not sure how useful it'll be (06 has the TCM incorporated with the valve body). Unfortunately, unpackdat is not able to unpackdat dat, it creates the .bin file, but it doesn't actually add data to it. I think maybe because the size is not standard like ECU ROM's?

Im wondering if that is the same as the g35 Infiniti

If so i believe I have the same style external TCM for re505ra so I'm willing to dumb and attempt uploads if people want me to try some steps. I can simply replace the external tcm a lot easier than you guys with it being buried in the box

Pytrex · **Posted:** Thu Feb 17, 2022 6:28 pm

Hmmm. I suppose it’s worth trying. Not trying to reflash, but just seeing what’s available for your TCM. None of the stuff I’m gonna have you try should have any chance of bricking the TCM, but there’s technically always a chance. But I tested literally ever possible SID and my TCM is still running fine haha So while the odds are low, do note that they’re not zero.

But first, see if you can attempt to dump the TCM ROM with Nisprog. In your Nisprog.ini, change the “destaddr” value to 0x18 and remove the runkernel command. I can send an example Nisprog.ini file if needed. If it connects (might need to send “nc” a few times if the timing is off), then we can start messing with some stuff.

So if it connects, try running “dm” or “dumpmem” and seeing if you can dump the ROM. That’ll be a good place to start for now. Also, would you be willing to run some specific SID requests and recording the output from Nisprog? (By just copying the command window results)

n00bz · **Joined:** Thu Feb 09, 2017 12:10 am **Posts:** 60

Pytrex wrote:

Hmmm. I suppose it’s worth trying. Not trying to reflash, but just seeing what’s available for your TCM. None of the stuff I’m gonna have you try should have any chance of bricking the TCM, but there’s technically always a chance. But I tested literally ever possible SID and my TCM is still running fine haha So while the odds are low, do note that they’re not zero.

But first, see if you can attempt to dump the TCM ROM with Nisprog. In your Nisprog.ini, change the “destaddr” value to 0x18 and remove the runkernel command. I can send an example Nisprog.ini file if needed. If it connects (might need to send “nc” a few times if the timing is off), then we can start messing with some stuff.

So if it connects, try running “dm” or “dumpmem” and seeing if you can dump the ROM. That’ll be a good place to start for now. Also, would you be willing to run some specific SID requests and recording the output from Nisprog? (By just copying the command window results)

Quote:

diag_os_gethrt() resolution <= 0us, avg ~0us
diag_os_getms() resolution: ~16ms.
Calibrating timing, this will take a few seconds...
Calibration done.

**************** nisprog v1.04-8e3390d+ ****************
interface is now DUMB
Note concerning generic (dumb) interfaces : there are additional
options which can be set with "set dumbopts". By default
"K-line only" and "MAN_BREAK" are set.
nisprog: Type HELP for a list of commands
nisprog: Type SCAN to start ODBII Scan
nisprog: Then use MONITOR to monitor real-time data
nisprog: **** IMPORTANT : this is beta software ! Use at your own risk.
nisprog: **** Remember, "debug all -1" displays all debugging info.
running commands from file nisprog.ini...
interface is now DUMB
Note concerning generic (dumb) interfaces : there are additional
options which can be set with "set dumbopts". By default
"K-line only" and "MAN_BREAK" are set.
port set to: \\.\COM4
dumbopts set to: 72
testerid: using 0xFC
destaddr: using 0x18
Connected to ECU !
ECUID: AQ504
Key candidate dist (smaller is better)
0: 0x75B4C26D 4
1: 0x3E29F056 4
2: 0x968148AD 15

Using best choice, SID27 key=75B4C26D. Use "setkeys" to change if required.
nisprog: Settings loaded from nisprog.ini

nisprog> setdev 7055
now using 7055.
nisprog> dm re5r05a.bin 0 0
Starting dump from 0x00000000 to 0x0007FFFF.

Retry score: 75
Starting dump from 0x00000000 to 0x0007FFFF.

hack mode : bad AC response 02 EC

Retry score: 50
Starting dump from 0x00000000 to 0x0007FFFF.

hack mode : bad AC response 02 EC

Retry score: 25
Starting dump from 0x00000000 to 0x0007FFFF.

hack mode : bad AC response 02 EC

Retry score: 0
Too many errors, no more retries @ addr=00000000.
nisprog>

Quote:

port set to: \\.\COM4
dumbopts set to: 72
testerid: using 0xFC
destaddr: using 0x18
p3 set to 0 (0x0).
rxe set to 40 (0x28).
diag_l2_iso14230.c:766: Read/Write timeout.
diag_l2.c:435: Read/Write timeout.
L2 StartComms failed
nisprog: Settings loaded from nisprog.ini

nisprog> nc
Connected to ECU !
ECUID: AQ504
Key candidate dist (smaller is better)
0: 0x75B4C26D 4
1: 0x3E29F056 4
2: 0x968148AD 15

Using best choice, SID27 key=75B4C26D. Use "setkeys" to change if required.
nisprog> p3
Unrecognized command. Try "help"
nisprog> npconf p3
p3 is currently 0 (0x0)
nisprog> npconf rxe 40
rxe set to 40 (0x28).
nisprog> dm re5r05a.bin 0 0
device type not set. Try setdev, or specify bounds manually.
nisprog> dm re5r05a.bin 0 448000
Starting dump from 0x00000000 to 0x0006D5FF.

Retry score: 75
Starting dump from 0x00000000 to 0x0006D5FF.

hack mode : bad AC response 02 EC

Retry score: 50
Starting dump from 0x00000000 to 0x0006D5FF.

hack mode : bad AC response 02 EC

Retry score: 25
Starting dump from 0x00000000 to 0x0006D5FF.

hack mode : bad AC response 02 EC

Retry score: 0
Too many errors, no more retries @ addr=00000000.
nisprog>

RomRaider

Forum rules

RE5R05A TCM Reprogramming

Who is online