5EAT TCM JECS ROM Image

SergArb · **Posted:** Thu Mar 21, 2024 1:52 am

Wow, thank you!

Found them:

Attachment:

Keywords.jpg

Can't find anything about boot mode

"Or, the encryption words might be able to be figured out from sniffing original ROM -vs- encrypted ROM during an upload / download."
How can I do that? Just sniff reading and writing flow from J2534 device?

rimwall · **Joined:** Fri Aug 21, 2020 6:05 am **Posts:** 315

Quote:

Found them:

Yes, much simpler once you know what they are

. Finding them took a few hours and a little luck.

For boot mode, see Ch 6.5 of the M32R Hardware Manual (I will send it to you). @jimihimisimi has just done something similar for a TPMS module, so might be able to help.

Quote:

How can I do that? Just sniff reading and writing flow from J2534 device?

Yes, compare unencrypted data and captured encrypted data and then brute force 16^16 combinations (4 encryption words) until you get a match. This assumes algo and number of words is the same. 16^16 sounds a lot, but shouldn't take too long to crunch through. Much more feasible than 16^64 for security words! Also a lot more data to validate solutions (compared to only 4 bytes for security step). First solutions might not be unique, so might have to try a few different data sets.

SergArb · **Posted:** Thu Mar 21, 2024 7:53 am

Oh... I can't imagine how to do that brute force stuff

Readings and Writings have exactly same bytes at logs from J2534. But differs with saved rom.

Maybe some program available for it, to put part of bytes from logs and bytes from rom?

jimihimisimi · **Joined:** Tue Apr 05, 2022 12:57 pm **Posts:** 58

Getting the data out via 'boot mode' or similar is going to require removing the TCU and moving 'strap' resistors around to get the MOD inputs in the correct config. I am assuming this is a no-go based on the previous responses.

@rimwall - can you give a quick primer on how this data gets encrypted and what is preventing the bytes from being read out from the lower address unencrypted? I don't think any of the M32R series have security-on-chip, but I am not familiar with the entire family.

EDIT: This is wrong, I am used to the M2150, the newer models can lock sections of flash.

Decrypting the data is probably the only way forward on this for now. The lower addresses (0x0000) are going to be all the the vectors, so I would assume the leading bytes for each of these will be '0x00 0x00 0xXX 0xXX' for big endian. This would reduce the amount of brute forcing, or at least make finding the successful decrypt easier as the dataset will have a lot less entropy than the encrypted.

SergArb · **Posted:** Thu Mar 21, 2024 10:23 pm

jimihimisimi wrote:

Getting the data out via 'boot mode' or similar is going to require removing the TCU and moving 'strap' resistors around to get the MOD inputs in the correct config. I am assuming this is a no-go based on the previous responses.

Hi, I'm not aware the soldering iron ;-)

Few MD pins is not scaring. After this viewtopic.php?f=40&t=17584

MiikaS · **Joined:** Tue Jun 06, 2017 2:11 pm **Posts:** 206

jimihimisimi wrote:

Getting the data out via 'boot mode' or similar is going to require removing the TCU and moving 'strap' resistors around to get the MOD inputs in the correct config. I am assuming this is a no-go based on the previous responses.

@rimwall - can you give a quick primer on how this data gets encrypted and what is preventing the bytes from being read out from the lower address unencrypted? I don't think any of the M32R series have security-on-chip, but I am not familiar with the entire family.

Decrypting the data is probably the only way forward on this for now. The lower addresses (0x0000) are going to be all the the vectors, so I would assume the leading bytes for each of these will be '0x00 0x00 0xXX 0xXX' for big endian. This would reduce the amount of brute forcing, or at least make finding the successful decrypt easier as the dataset will have a lot less entropy than the encrypted.

Don't remember/know about this particular chip, but many others (like Renesas SH) protect their memory being read by erasing whole memory when entering boot mode and reading it is only possible after writing (to verify it). So there needs to be some other interface enabled to use for reading.

Usually software bootloaders just prevents reading/writing some protected areas if "security level" is not high enough, or preventing it no matter what to protect it. If I recall right, older Subaru Hitachi ECUs prevents writing over that lower area (it just ignores write command) but reads it ok.

So reading/writing it with some other tool and sniffing communications can give hint of seed keys and answers and possible way to test algos against those combinations.

SergArb · **Posted:** Fri Mar 22, 2024 1:04 am

MiikaS wrote:

jimihimisimi wrote:

So reading/writing it with some other tool and sniffing communications can give hint of seed keys and answers and possible way to test algos against those combinations.

Hi! That's we are trying to do now

MH8104F has a QFP-144 case, which looks similar to 32176F4.
But I can't find any software to read them in boot mode. Only erase and write - UFLA32r software.
So, it's useless for our purposes

jimihimisimi · **Joined:** Tue Apr 05, 2022 12:57 pm **Posts:** 58

SergArb wrote:

MiikaS wrote:

jimihimisimi wrote:

So reading/writing it with some other tool and sniffing communications can give hint of seed keys and answers and possible way to test algos against those combinations.

Hi! That's we are trying to do now

MH8104F has a QFP-144 case, which looks similar to 32176F4.
But I can't find any software to read them in boot mode. Only erase and write - UFLA32r software.
So, it's useless for our purposes

So a couple of thoughts on exploiting the UFLA32r software:
- You can use the 'lock bits' function to confirm those addresses are locked
- Run the 'verify' command and sniff the RS323 data between the PC and the ECU during the command execution to see what data gets passed back and forth. In many cases the 'Boot ROM' has just enough code to bootstrap the ECU and then the host PC passes a binary blob with a bunch of code over the 232 to load into the ECUs RAM. Also the CPU is going to need the whole ROM contents to run the checksum on, so the locked regions may get accessed via some undoc commands and passed back to the programmer. This is all a bunch of speculation, but I have had success with this in the past on other processors.

Obviously, but worth mentioning, DO NOT run the program or erase commands!

rimwall · **Joined:** Fri Aug 21, 2020 6:05 am **Posts:** 315

Quote:

@rimwall - can you give a quick primer on how this data gets encrypted and what is preventing the bytes from being read out from the lower address unencrypted? I don't think any of the M32R series have security-on-chip, but I am not familiar with the entire family.

Under normal comms, any upload / download to / from the ROM is decrypted / encrypted by the firmware residing on the processor. The routines on the processor that handle the normal comms restrict the addresses that can be read / written.

Quote:

thoughts on exploiting the UFLA32r software:

Good point about the checksum calcs. Maybe @SergArb can sniff this out.

I've edited the ROM file to modify the assembly so that the normal SSM 0xa8 command should report values at ROM addresses less than 0x8000. I have no way of checking whether the revised assembly actually works. I've loaded it into Ghidra and it decompiles successfully and looks like it will work. There were some instruction addresses that were no longer being accessed, so I've overwritten them with values that should mean the overall checksum doesn't change. This is assuming the ROM uses a 32 bit checksum like most Subaru ROMs.

Use at own risk! This could brick your TCU and you won't be able to recover it without using boot mode, or maybe UFLA32R. If you're curious, the assembly mods are at addresses 0x3c86c onwards.

To use it, you need to send a 5 byte 0xa8 command for each address to be read. Command syntax is:
0xa8 0x00 [addr_high] [addr_mid] [addr_low]

So, to read the bytes from 0x0 to 0x7fff you would use these commands:
0xa8 0x00 0x00 0x00 0x00
0xa8 0x00 0x00 0x00 0x01
0xa8 0x00 0x00 0x00 0x02
0xa8 0x00 0x00 0x00 0x03
...
0xa8 0x00 0x00 0x7f 0xfe
0xa8 0x00 0x00 0x7f 0xff

To implement, modify the FastECU code.

There are a number of reasons why this may not work. In particular, the processor may have internal protection (read protection is possible on a M32R). Fingers crossed...!

SergArb · **Posted:** Sat Mar 23, 2024 9:26 am

Flashed modified rom. It's not bricked :-)

Trying to implement A8 command, but there is no answer from TCU, tried two different formats:

Code:

[2024-03-23 21:18:02.793]  Read memory with flashmethod 'sub_tcu_hitachi_can' and kernel 'kernels/ '
[2024-03-23 21:18:04.043]  Connecting to Subaru TCU Hitachi CAN bootloader, please wait...
[2024-03-23 21:18:04.053]  Checking if kernel is already running...
[2024-03-23 21:18:04.053]  Send msg: 00 00 07 e1 31 02 02 01 
[2024-03-23 21:18:04.263]  Received msg: 00 00 07 e9 7f 31 12 
[2024-03-23 21:18:04.263]  Trying TCU Init...
[2024-03-23 21:18:04.263]  Sent: 00 00 07 e1 aa 
[2024-03-23 21:18:04.283]  0: 0xAA response: 00 00 07 e9 ea a4 10 40 b1 d3 f0 80 00 01 00 80 04 00 00 00 00 8d 02 00 00 00 00 00 00 00 00 00 00 9c 06 00 0a 21 c0 00 00 05 1f 80 80 00 00 00 00 00 00 00 16 e1 c0 00 00 00 04 20 00 00 00 40 00 00 00 00 00 00 bb 7e 40 00 00 00 00 00 00 00 80 
[2024-03-23 21:18:04.283]  Init Success: CAL ID = B1D3F08000
[2024-03-23 21:18:04.283]  Trying 0x09 0x04...
[2024-03-23 21:18:04.293]  Sent: 00 00 07 e1 09 04 
[2024-03-23 21:18:04.293]  0: 0x09 0x04 response: 00 00 07 e9 49 04 01 5a 35 44 33 46 30 38 30 00 00 00 00 00 00 00 00 
[2024-03-23 21:18:04.303]  Init Success: TCU ID = Z5D3F080
[2024-03-23 21:18:04.403]  Send msg: a8 00 00 00 01 
[2024-03-23 21:18:04.713]  Received msg: 

Code:

[2024-03-23 21:12:54.302]  Read memory with flashmethod 'sub_tcu_hitachi_can' and kernel 'kernels/ '
[2024-03-23 21:12:55.612]  Connecting to Subaru TCU Hitachi CAN bootloader, please wait...
[2024-03-23 21:12:55.622]  Checking if kernel is already running...
[2024-03-23 21:12:55.622]  Send msg: 00 00 07 e1 31 02 02 01 
[2024-03-23 21:12:55.832]  Received msg: 00 00 07 e9 7f 31 12 
[2024-03-23 21:12:55.832]  Trying TCU Init...
[2024-03-23 21:12:55.842]  Sent: 00 00 07 e1 aa 
[2024-03-23 21:12:55.852]  0: 0xAA response: 00 00 07 e9 ea a4 10 40 b1 d3 f0 80 00 01 00 80 04 00 00 00 00 8d 02 00 00 00 00 00 00 00 00 00 00 9c 06 00 0a 21 c0 00 00 05 1f 80 80 00 00 00 00 00 00 00 16 e1 c0 00 00 00 04 20 00 00 00 40 00 00 00 00 00 00 bb 7e 40 00 00 00 00 00 00 00 80 
[2024-03-23 21:12:55.852]  Init Success: CAL ID = B1D3F08000
[2024-03-23 21:12:55.852]  Trying 0x09 0x04...
[2024-03-23 21:12:55.862]  Sent: 00 00 07 e1 09 04 
[2024-03-23 21:12:55.862]  0: 0x09 0x04 response: 00 00 07 e9 49 04 01 5a 35 44 33 46 30 38 30 00 00 00 00 00 00 00 00 
[2024-03-23 21:12:55.872]  Init Success: TCU ID = Z5D3F080
[2024-03-23 21:12:56.072]  Send msg: 00 00 07 a8 00 00 00 01 
[2024-03-23 21:12:58.302]  Received msg: 

Code:

    // Trying to impement A8 Command
    output.clear();
//    output.append((uint8_t)0x00);
//    output.append((uint8_t)0x00);
//    output.append((uint8_t)0x07);
    output.append((uint8_t)0xA8);
    output.append((uint8_t)0x00);
    output.append((uint8_t)0x00);
    output.append((uint8_t)0x00);
    output.append((uint8_t)0x01);
    delay(100);
    send_log_window_message("Send msg: " + parse_message_to_hex(output), true, true);
    serial->write_serial_data_echo_check(output);
    delay(100);
    received = serial->read_serial_data(20, 200);
    send_log_window_message("Received msg: " + parse_message_to_hex(received), true, true);
    delay(200000);

Perhaps I'm doing it wrong...

SergArb · **Posted:** Sat Mar 23, 2024 11:18 am

Another try, but no success

Code:

[2024-03-23 23:16:20.076]  Trying TCU Init...
[2024-03-23 23:16:20.076]  Sent: 00 00 07 e1 aa 
[2024-03-23 23:16:20.091]  0: 0xAA response: 00 00 07 e9 ea a4 10 40 b1 d3 f0 80 00 01 00 80 04 00 00 00 00 8d 02 00 00 00 00 00 00 00 00 00 00 9c 06 00 0a 21 c0 00 00 05 1f 80 80 00 00 00 00 00 00 00 16 e1 c0 00 00 00 04 20 00 00 00 40 00 00 00 00 00 00 bb 7e 40 00 00 00 00 00 00 00 80 
[2024-03-23 23:16:20.091]  Init Success: CAL ID = B1D3F08000
[2024-03-23 23:16:20.091]  Trying 0x09 0x04...
[2024-03-23 23:16:20.107]  Sent: 00 00 07 e1 09 04 
[2024-03-23 23:16:20.107]  0: 0x09 0x04 response: 00 00 07 e9 49 04 01 5a 35 44 33 46 30 38 30 00 00 00 00 00 00 00 00 
[2024-03-23 23:16:20.107]  Init Success: TCU ID = Z5D3F080
[2024-03-23 23:16:20.107]  Not yet implemented: Reading ROM from TCU Subaru Hitachi using CAN
[2024-03-23 23:16:20.107]  Settting dump start & length...
[2024-03-23 23:16:20.122]  Start reading ROM, please wait...
[2024-03-23 23:16:20.122]  Initializing bootloader...
[2024-03-23 23:16:20.122]  Send msg: a8 00 00 00 00 
[2024-03-23 23:16:20.559]  Received msg: 
[2024-03-23 23:16:20.559]  Received pagedata: 
[2024-03-23 23:16:20.559]  Kernel read addr:  0x00000000  length:  0x00000001,       1  B/s    4341 s remaining
[2024-03-23 23:16:20.575]  Send msg: a8 00 00 00 01 
[2024-03-23 23:16:21.012]  Received msg: 
[2024-03-23 23:16:21.012]  Received pagedata: 
[2024-03-23 23:16:21.012]  Kernel read addr:  0x00000001  length:  0x00000001,       2  B/s    2170 s remaining
[2024-03-23 23:16:21.027]  Send msg: a8 00 00 00 02 
[2024-03-23 23:16:21.448]  Received msg: 
[2024-03-23 23:16:21.448]  Received pagedata: 
[2024-03-23 23:16:21.448]  Kernel read addr:  0x00000002  length:  0x00000001,       2  B/s    2170 s remaining
[2024-03-23 23:16:21.464]  Send msg: a8 00 00 00 03 
[2024-03-23 23:16:21.901]  Received msg: 
[2024-03-23 23:16:21.901]  Received pagedata: 
[2024-03-23 23:16:21.901]  Kernel read addr:  0x00000003  length:  0x00000001,       2  B/s    2169 s remaining
[2024-03-23 23:16:21.916]  Send msg: a8 00 00 00 04 

rimwall · **Joined:** Fri Aug 21, 2020 6:05 am **Posts:** 315

You still need the CAN ID for it to work.

So you need ‘0x00 0x00 0x07 0xe1’ as the first 4 bytes. Then ‘0xa8 0x00 [addr high] [addr mid] [addr low]’ as the next 5 bytes

SergArb · **Posted:** Sat Mar 23, 2024 10:57 pm

Thank you, seems it's reading something. Very slow, so i reduced delay between commands to "50".
Leaving it for while, will see...

Code:

[2024-03-24 10:45:51.200]  Read memory with flashmethod 'sub_tcu_hitachi_can' and kernel 'kernels/ '
[2024-03-24 10:45:54.920]  Connecting to Subaru TCU Hitachi CAN bootloader, please wait...
[2024-03-24 10:45:54.920]  Checking if kernel is already running...
[2024-03-24 10:45:54.920]  Send msg: 00 00 07 e1 31 02 02 01 
[2024-03-24 10:45:55.130]  Received msg: 00 00 07 e9 7f 31 12 
[2024-03-24 10:45:55.130]  Trying TCU Init...
[2024-03-24 10:45:55.130]  Sent: 00 00 07 e1 aa 
[2024-03-24 10:45:55.150]  0: 0xAA response: 00 00 07 e9 ea a4 10 40 b1 d3 f0 80 00 01 00 80 04 00 00 00 00 8d 02 00 00 00 00 00 00 00 00 00 00 9c 06 00 0a 21 c0 00 00 05 1f 80 80 00 00 00 00 00 00 00 16 e1 c0 00 00 00 04 20 00 00 00 40 00 00 00 00 00 00 bb 7e 40 00 00 00 00 00 00 00 80 
[2024-03-24 10:45:55.150]  Init Success: CAL ID = B1D3F08000
[2024-03-24 10:45:55.150]  Trying 0x09 0x04...
[2024-03-24 10:45:55.160]  Sent: 00 00 07 e1 09 04 
[2024-03-24 10:45:55.160]  0: 0x09 0x04 response: 00 00 07 e9 49 04 01 5a 35 44 33 46 30 38 30 00 00 00 00 00 00 00 00 
[2024-03-24 10:45:55.160]  Init Success: TCU ID = Z5D3F080
[2024-03-24 10:45:55.170]  Not yet implemented: Reading ROM from TCU Subaru Hitachi using CAN
[2024-03-24 10:45:55.170]  Settting dump start & length...
[2024-03-24 10:45:55.170]  Start reading ROM, please wait...
[2024-03-24 10:45:55.180]  Initializing bootloader...
[2024-03-24 10:45:55.180]  Send msg: 00 00 07 e1 a8 00 00 00 00 
[2024-03-24 10:45:55.230]  Received msg: 00 00 07 e9 e8 ff 
[2024-03-24 10:45:55.230]  Received pagedata: ff 
[2024-03-24 10:45:55.230]  Kernel read addr:  0x00000000  length:  0x00000001,       1  B/s    4341 s remaining
[2024-03-24 10:45:55.240]  Send msg: 00 00 07 e1 a8 00 00 00 01 
[2024-03-24 10:45:55.290]  Received msg: 00 00 07 e9 e8 00 
[2024-03-24 10:45:55.290]  Received pagedata: 00 
[2024-03-24 10:45:55.290]  Kernel read addr:  0x00000001  length:  0x00000001,      16  B/s    2771 s remaining
[2024-03-24 10:45:55.300]  Send msg: 00 00 07 e1 a8 00 00 00 02 
[2024-03-24 10:45:55.350]  Received msg: 00 00 07 e9 e8 03 
[2024-03-24 10:45:55.350]  Received pagedata: 03 
[2024-03-24 10:45:55.350]  Kernel read addr:  0x00000002  length:  0x00000001,      17  B/s     844 s remaining
[2024-03-24 10:45:55.360]  Send msg: 00 00 07 e1 a8 00 00 00 03 
[2024-03-24 10:45:55.410]  Received msg: 00 00 07 e9 e8 00 
[2024-03-24 10:45:55.410]  Received pagedata: 00 
[2024-03-24 10:45:55.410]  Kernel read addr:  0x00000003  length:  0x00000001,      16  B/s    2771 s remaining
[2024-03-24 10:45:55.420]  Send msg: 00 00 07 e1 a8 00 00 00 04 
[2024-03-24 10:45:55.492]  Received msg: 00 00 07 e9 e8 ff 
[2024-03-24 10:45:55.492]  Received pagedata: ff 
[2024-03-24 10:45:55.492]  Kernel read addr:  0x00000004  length:  0x00000001,      11  B/s    7667 s remaining
[2024-03-24 10:45:55.512]  Send msg: 00 00 07 e1 a8 00 00 00 05 
[2024-03-24 10:45:55.562]  Received msg: 00 00 07 e9 e8 ff 
[2024-03-24 10:45:55.562]  Received pagedata: ff 
[2024-03-24 10:45:55.562]  Kernel read addr:  0x00000005  length:  0x00000001,      14  B/s    7452 s remaining
[2024-03-24 10:45:55.582]  Send msg: 00 00 07 e1 a8 00 00 00 06 
[2024-03-24 10:45:55.632]  Received msg: 00 00 07 e9 e8 ff 
[2024-03-24 10:45:55.632]  Received pagedata: ff 
[2024-03-24 10:45:55.632]  Kernel read addr:  0x00000006  length:  0x00000001,      14  B/s    7452 s remaining
[2024-03-24 10:45:55.652]  Send msg: 00 00 07 e1 a8 00 00 00 07 
[2024-03-24 10:45:55.702]  Received msg: 00 00 07 e9 e8 ff 
[2024-03-24 10:45:55.702]  Received pagedata: ff 
[2024-03-24 10:45:55.702]  Kernel read addr:  0x00000007  length:  0x00000001,      14  B/s    7452 s remaining
[2024-03-24 10:45:55.722]  Send msg: 00 00 07 e1 a8 00 00 00 08 
[2024-03-24 10:45:55.772]  Received msg: 00 00 07 e9 e8 ff 
[2024-03-24 10:45:55.772]  Received pagedata: ff 
[2024-03-24 10:45:55.772]  Kernel read addr:  0x00000008  length:  0x00000001,      14  B/s    7452 s remaining
[2024-03-24 10:45:55.792]  Send msg: 00 00 07 e1 a8 00 00 00 09 
[2024-03-24 10:45:55.842]  Received msg: 00 00 07 e9 e8 ff 
[2024-03-24 10:45:55.842]  Received pagedata: ff 
[2024-03-24 10:45:55.842]  Kernel read addr:  0x00000009  length:  0x00000001,      14  B/s    7452 s remaining
[2024-03-24 10:45:55.862]  Send msg: 00 00 07 e1 a8 00 00 00 0a 
[2024-03-24 10:45:55.912]  Received msg: 00 00 07 e9 e8 ff 
[2024-03-24 10:45:55.912]  Received pagedata: ff 
[2024-03-24 10:45:55.912]  Kernel read addr:  0x0000000A  length:  0x00000001,      14  B/s    7452 s remaining
[2024-03-24 10:45:55.932]  Send msg: 00 00 07 e1 a8 00 00 00 0b 
[2024-03-24 10:45:55.982]  Received msg: 00 00 07 e9 e8 ff 
[2024-03-24 10:45:55.982]  Received pagedata: ff 
[2024-03-24 10:45:55.982]  Kernel read addr:  0x0000000B  length:  0x00000001,      14  B/s    7452 s remaining
[2024-03-24 10:45:56.002]  Send msg: 00 00 07 e1 a8 00 00 00 0c 
[2024-03-24 10:45:56.052]  Received msg: 00 00 07 e9 e8 ff 
[2024-03-24 10:45:56.052]  Received pagedata: ff 
[2024-03-24 10:45:56.052]  Kernel read addr:  0x0000000C  length:  0x00000001,      14  B/s    7452 s remaining
[2024-03-24 10:45:56.072]  Send msg: 00 00 07 e1 a8 00 00 00 0d 
[2024-03-24 10:45:56.122]  Received msg: 00 00 07 e9 e8 ff 
[2024-03-24 10:45:56.122]  Received pagedata: ff 
[2024-03-24 10:45:56.122]  Kernel read addr:  0x0000000D  length:  0x00000001,      14  B/s    7452 s remaining
[2024-03-24 10:45:56.142]  Send msg: 00 00 07 e1 a8 00 00 00 0e 
[2024-03-24 10:45:56.192]  Received msg: 00 00 07 e9 e8 ff 
[2024-03-24 10:45:56.192]  Received pagedata: ff 
[2024-03-24 10:45:56.192]  Kernel read addr:  0x0000000E  length:  0x00000001,      14  B/s    7452 s remaining
[2024-03-24 10:45:56.212]  Send msg: 00 00 07 e1 a8 00 00 00 0f 
[2024-03-24 10:45:56.262]  Received msg: 00 00 07 e9 e8 ff 
[2024-03-24 10:45:56.262]  Received pagedata: ff 
[2024-03-24 10:45:56.262]  Kernel read addr:  0x0000000F  length:  0x00000001,      14  B/s    7452 s remaining
[2024-03-24 10:45:56.282]  Send msg: 00 00 07 e1 a8 00 00 00 10 
[2024-03-24 10:45:56.332]  Received msg: 00 00 07 e9 e8 ff 
[2024-03-24 10:45:56.332]  Received pagedata: ff 
[2024-03-24 10:45:56.332]  Kernel read addr:  0x00000010  length:  0x00000001,      14  B/s    7452 s remaining
[2024-03-24 10:45:56.352]  Send msg: 00 00 07 e1 a8 00 00 00 11 
[2024-03-24 10:45:56.402]  Received msg: 00 00 07 e9 e8 00 
[2024-03-24 10:45:56.402]  Received pagedata: 00 
[2024-03-24 10:45:56.402]  Kernel read addr:  0x00000011  length:  0x00000001,      14  B/s    7451 s remaining
[2024-03-24 10:45:56.422]  Send msg: 00 00 07 e1 a8 00 00 00 12 
[2024-03-24 10:45:56.472]  Received msg: 00 00 07 e9 e8 03 
[2024-03-24 10:45:56.472]  Received pagedata: 03 
[2024-03-24 10:45:56.472]  Kernel read addr:  0x00000012  length:  0x00000001,      14  B/s    7451 s remaining
[2024-03-24 10:45:56.492]  Send msg: 00 00 07 e1 a8 00 00 00 13 
[2024-03-24 10:45:56.542]  Received msg: 00 00 07 e9 e8 2a 
[2024-03-24 10:45:56.542]  Received pagedata: 2a 
[2024-03-24 10:45:56.542]  Kernel read addr:  0x00000013  length:  0x00000001,      14  B/s    7451 s remaining
[2024-03-24 10:45:56.562]  Send msg: 00 00 07 e1 a8 00 00 00 14 
[2024-03-24 10:45:56.612]  Received msg: 00 00 07 e9 e8 ff 
[2024-03-24 10:45:56.612]  Received pagedata: ff 
[2024-03-24 10:45:56.612]  Kernel read addr:  0x00000014  length:  0x00000001,      14  B/s    7451 s remaining
[2024-03-24 10:45:56.632]  Send msg: 00 00 07 e1 a8 00 00 00 15 
[2024-03-24 10:45:56.682]  Received msg: 00 00 07 e9 e8 ff 
[2024-03-24 10:45:56.682]  Received pagedata: ff 

rimwall · **Joined:** Fri Aug 21, 2020 6:05 am **Posts:** 315

Yes, it looks like it’s working. Cool

.The bytes aren’t all 0xff or 0x00 so that’s good.

It will be slow, one byte at a time for 0x8000 bytes, but we should only have to do this once. Not worth optimising.

Did you have to alter checksum with PCM Flash? Or did you flash it unchanged?

Once you have the 0x8000 bytes, use them to overwrite the 0xff in your ROM file and upload the fixed 512kB file. I should be able to find the encryption words pretty fast.

SergArb · **Posted:** Sat Mar 23, 2024 11:29 pm

PCMflash says the checksum is OK, so i flashed it unchanged.
Damn, I'm reading 80000 instead of 8000

Will be waiting...

RomRaider

5EAT TCM JECS ROM Image

Who is online