d3irb
Full Member
Karma: +134/-1
 Offline
Posts: 195
|
 |
« Reply #15 on: December 18, 2020, 09:51:10 AM »
|
|
|
A TC1797 has PMEM0 and PMEM1 too  it's just NOT a TC1791 Okay, okay, I read the docs, which is more than I ever intended to do with Simos12... I see now, the two PMEMs in TC1797 are contiguous instead of separated, now next time I get challenged to a round of Tricore Trivia I won't lose. |
|
|
|
|
Logged
|
|
|
|
|
IamwhoIam
|
|
« Reply #16 on: December 19, 2020, 04:38:48 AM »
|
|
|
LOL |
|
|
|
|
Logged
|
I have no logs because I have a boost gauge (makes things easier)
|
|
|
Wommesz
Newbie
Karma: +2/-0
Offline
Posts: 12
|
|
« Reply #17 on: December 19, 2020, 02:07:34 PM »
|
|
|
There's definitely a lot to learn for me on these ecu's, thank for the help d3irb.
Being a bit curious: There should also be cars out there with Simos10, FL_03F906070GN_4046 for example.
Do you happen to have an unencrypted version of that one as well?
Getting the key/iv for that one seems like a good practice for me.
|
|
|
|
|
Logged
|
|
|
|
|
gremlin
|
|
« Reply #18 on: December 19, 2020, 04:13:57 PM »
|
|
|
Being a bit curious: There should also be cars out there with Simos10, FL_03F906070GN_4046 for example.
Do you happen to have an unencrypted version of that one as well?
Getting the key/iv for that one seems like a good practice for me.
It's Simos10.24 FRF isn't AES crypted and use another methode. Here is decrypted CAL block example. |
|
|
|
« Last Edit: December 19, 2020, 04:22:20 PM by gremlin »
|
Logged
|
|
|
|
Wommesz
Newbie
Karma: +2/-0
Offline
Posts: 12
|
|
« Reply #19 on: December 20, 2020, 07:14:03 AM »
|
|
|
Ah, interesting. The decrypted data is all zeros at the end. The encrypted data repeats every 256 bytes at the end. Maybe encryption is a 256-byte xor key? Some file sizes: encrypted/compressed: 90761 unencrypted: 245760 LZSS compression: 86208 Zip : ~56kb RLE: 186840 The LZSS ( https://github.com/bri3d/VW_Flash/tree/master/lzss) pattern of 0-data repeats every 17 bytes, so that doesn't fit the repetition pattern of the encrypted data very well. So compression seems to be something in spirit of LZSS, but with slightly worse compression ratio. I was trying to guess the first part of the key by guessing the first part of the compressed data. Then applying that to the 0-encrypted data to get to a repetitive pattern, but that went nowhere. I'll keep you guys posted. Not that I think that I'm telling you something new, but then at least you know that you gave someone a good puzzle to solve. |
|
|
|
|
Logged
|
|
|
|
|
prj
|
|
« Reply #20 on: December 22, 2020, 01:54:50 AM »
|
|
|
Okay, okay, I read the docs, which is more than I ever intended to do with Simos12... I see now, the two PMEMs in TC1797 are contiguous instead of separated, now next time I get challenged to a round of Tricore Trivia I won't lose.
Boom |
|
|
|
|
Logged
|
|
|
|
d3irb
Full Member
Karma: +134/-1
Offline
Posts: 195
|
|
« Reply #21 on: December 27, 2020, 11:44:49 AM »
|
|
|
Ah, interesting. The decrypted data is all zeros at the end. The encrypted data repeats every 256 bytes at the end. Maybe encryption is a 256-byte xor key? Some file sizes: encrypted/compressed: 90761 unencrypted: 245760 LZSS compression: 86208 Zip : ~56kb RLE: 186840 The LZSS ( https://github.com/bri3d/VW_Flash/tree/master/lzss) pattern of 0-data repeats every 17 bytes, so that doesn't fit the repetition pattern of the encrypted data very well. So compression seems to be something in spirit of LZSS, but with slightly worse compression ratio. I was trying to guess the first part of the key by guessing the first part of the compressed data. Then applying that to the 0-encrypted data to get to a repetitive pattern, but that went nowhere. I'll keep you guys posted. Not that I think that I'm telling you something new, but then at least you know that you gave someone a good puzzle to solve. Usually when you see 256-byte repeating XOR like this, the XOR key is some permutation of a byte counter. I believe this could be the case for this file too, although I don't have any originals handy to try on. Try something simple like (psuedo code of course): for i in range(len(file)):
output.write(file[i] ^ (i & 0xFF))
|
|
|
|
« Last Edit: December 27, 2020, 04:04:42 PM by d3irb »
|
Logged
|
|
|
|
|
prj
|
|
« Reply #22 on: December 28, 2020, 05:45:32 AM »
|
|
|
There are fully unpacked S12 dumps available. Why not dump the routine?
Ghidra will probably make short work of it.
|
|
|
|
|
Logged
|
|
|
|
fastboatster
Full Member
Karma: +3/-0
Offline
Posts: 78
|
|
« Reply #23 on: January 27, 2021, 11:46:47 PM »
|
|
|
Great thread, don't want to hijack it too much but I'm also playing with another older Simos ecu, Simos 8.4/8.5 in my case. Because of this thread and http://nefariousmotorsports.com/forum/index.php?topic=10364.0, I was able to identify start addresses and checksum locations in cboot, asw and cal (only one asw section there) as well as identify references to maps in cal. I'm trying to dig into this further and reverse the part of the cboot which gets copied into RAM, however I'm having trouble with this. FR says this cboot part is getting copied to 0xd4000000 and presumably it should be 0xbfff bytes: Figure 18.1.1: RAM start address where to load the reprogramming routine
RAM start address where to load the reprogramming routine
Project specific value defined during project memory mapping (must be 32bit aligned)
NC_LOAD_RAM_START_ADR_RPG = 0xd4000000h
Figure 18.1.2: RAM maximum end address where to load the reprogramming routine
RAM maximum end address where to load the reprogramming routine
Project specific value defined during project memory mapping
NC_LOAD_RAM_END_ADR_RPG = 0xd400bfffh
However, I can't find anything which copies 0xbfff bytes to 0xd4000000. Wonder if it's more obvious to somebody else. CBOOT starts at 80020000, asw is at 80080000 and cal is at a0040000 P.S. odx payload is not compressed and can be "decrypted" as shown in one of the posts above, i.e., it's xor'ed. |
|
|
|
« Last Edit: January 30, 2021, 07:00:56 PM by fastboatster »
|
Logged
|
|
|
|
nickvag
Newbie
Karma: +0/-0
Offline
Posts: 1
|
|
« Reply #24 on: June 28, 2023, 02:57:37 AM »
|
|
|
HI all , this is my first post, i followed this thread and Bri3d project for a while now, I've been working on the Simos12 patch for the last 6 month , but unfortunately I can now tell for certain that is not possible flashing it using the exploid used in simos 18 ecu (write without erase). With VW_Flash for simos 12 from now you can flash only signed ori files but ... IF you have the possibility to Full bench write your ecu once you can flash my patched CBOOT and then you can use VW_flash like for simos 18 because the car will validate all blocks.
|
|
|
|
|
Logged
|
|
|
|
cube
Newbie
Karma: +0/-0
Offline
Posts: 3
|
|
« Reply #25 on: August 17, 2023, 08:10:08 AM »
|
|
|
HI all , this is my first post, i followed this thread and Bri3d project for a while now, I've been working on the Simos12 patch for the last 6 month , but unfortunately I can now tell for certain that is not possible flashing it using the exploid used in simos 18 ecu (write without erase). With VW_Flash for simos 12 from now you can flash only signed ori files but ... IF you have the possibility to Full bench write your ecu once you can flash my patched CBOOT and then you can use VW_flash like for simos 18 because the car will validate all blocks.
Hi there! Is there any updates on this? I've seen your github, I'm in the same situation, I could help. |
|
|
|
|
Logged
|
|
|
|
|
prj
|
|
« Reply #26 on: August 17, 2023, 08:11:27 AM »
|
|
|
Take a commercial tool and sniff. All of them can portflash S12.
|
|
|
|
|
Logged
|
|
|
|
cube
Newbie
Karma: +0/-0
Offline
Posts: 3
|
|
« Reply #27 on: August 17, 2023, 05:20:33 PM »
|
|
|
Take a commercial tool and sniff. All of them can portflash S12.
I have kess v2 but I’m a supporter of open source so I’d like to help with anything:) |
|
|
|
|
Logged
|
|
|
|
|
