|
SB_GLI
|
 |
« Reply #75 on: July 11, 2019, 11:55:40 AM »
|
|
|
I suppose you are actually talking about keys like "BiWbBuD101"...
ME7 = "GEHEIM" MED9 = "CodeRobert" MED17 = "BiWbBuD101"  Interesting tidbit about nintendo, Nyet |
|
|
|
|
Logged
|
|
|
|
dexterash
Newbie
Karma: +1/-0
 Offline
Posts: 7
|
|
« Reply #76 on: July 11, 2019, 01:27:48 PM »
|
|
|
I suppose these are used to decode the <data> section and apply only to BOSCH, right? I think it's only for those with 0x11 algo. Do you know anything about 0x01?
[nintendo tidbit: interesting; it's funny how the industry (re)uses different thingies]
|
|
|
|
|
Logged
|
|
|
|
|
gremlin
|
|
« Reply #77 on: July 11, 2019, 02:07:30 PM »
|
|
|
Do you know anything about 0x01?
01 use Simos-Siemens and Magnetti Marelli ECUs Crypt algo is different. |
|
|
|
|
Logged
|
|
|
|
|
gremlin
|
|
« Reply #78 on: July 11, 2019, 02:34:29 PM »
|
|
|
Next levels of compress/crypt algo from Bosch -> A1, AA and 2A use LZRB and AES technique.
Below is screenshots from my FRF coder/decoder.
|
|
|
|
|
Logged
|
|
|
|
d3irb
Full Member
Karma: +134/-1
Offline
Posts: 195
|
|
« Reply #79 on: July 11, 2019, 10:25:11 PM »
|
|
|
Simos18 files use ENCRYPT-COMPRESS-METHOD=AA. The Python code I linked and posted earlier in the thread is the full implementation of method AA for Simos18. Within my implementation I also implement LZSS which is the algorithm nyet was describing. Sure enough I cribbed the decompression code from an open source Nintendo sprite decompressor, although the dictionary size (and therefore the number of bits used for the offset into the dictionary) is different between the two algorithms. LZSS is so common that I'm not sure they copied the Nintendo implementation but it wouldn't be surprising.
|
|
|
|
|
Logged
|
|
|
|
dexterash
Newbie
Karma: +1/-0
Offline
Posts: 7
|
|
« Reply #80 on: July 12, 2019, 12:17:04 AM »
|
|
|
01 use Simos-Siemens and Magnetti Marelli ECUs
Crypt algo is different.
Hmmm... That means the values are different depending on the ECU type - ABS, Multimedia, Cluster etc. I think I also saw 0x01 on Continental's products. |
|
|
|
|
Logged
|
|
|
|
|
SB_GLI
|
|
« Reply #81 on: July 12, 2019, 06:00:04 AM »
|
|
|
Hmmm... That means the values are different depending on the ECU type - ABS, Multimedia, Cluster etc. I think I also saw 0x01 on Continental's products.
0x01 is just bosch encryption without compression The 4 high bits is compression type, the 4 low bits is encryption type |
|
|
|
|
Logged
|
|
|
|
dexterash
Newbie
Karma: +1/-0
Offline
Posts: 7
|
|
« Reply #82 on: July 12, 2019, 08:44:56 AM »
|
|
|
Do you think it is the same, even if the manufacturer is not BOSCH?
|
|
|
|
|
Logged
|
|
|
|
|
SB_GLI
|
|
« Reply #83 on: July 12, 2019, 08:58:08 AM »
|
|
|
Do you think it is the same, even if the manufacturer is not BOSCH?
I can provide this, though not 100% sure of it's accuracy as I have never worked with the other manufactures. //high nibble of data format
public enum CompressionType : byte
{
Uncompressed = 0x00,
Bosch = 0x10,
Hitachi = 0x20,
Marelli = 0x30,
Lucas = 0x40,
BoschUncompressed = 0x90 //for testing
}
//low nibble of data format
public enum EncryptionType : byte
{
Unencrypted = 0x00,
Bosch = 0x01,
Hitachi = 0x02,
Marelli = 0x03,
Lucas = 0x04
}
|
|
|
|
|
Logged
|
|
|
|
dexterash
Newbie
Karma: +1/-0
Offline
Posts: 7
|
|
« Reply #84 on: July 12, 2019, 09:32:08 AM »
|
|
|
That's what I was "afraid". And my assumption is that's ECU-type specific.
|
|
|
|
|
Logged
|
|
|
|
|
gremlin
|
|
« Reply #85 on: July 12, 2019, 11:28:20 AM »
|
|
|
That's what I was "afraid". And my assumption is that's ECU-type specific.
This compress/crypt byte haven't exact meaning as absolute value. It's depends from manufacturer, control unit, etc Some examples on the picture. Of cause it isn't all possible variants. |
|
|
|
|
Logged
|
|
|
|
dexterash
Newbie
Karma: +1/-0
Offline
Posts: 7
|
|
« Reply #86 on: July 12, 2019, 01:05:10 PM »
|
|
|
Thanks. Saw your earlier posts too. From my point of view, this is kind of tricky/non-standard. Or maybe the algos are the same across different manufacturers? And let's say a key or a constant/fixed value changes?
|
|
|
|
|
Logged
|
|
|
|
|
gremlin
|
|
« Reply #87 on: July 12, 2019, 02:18:43 PM »
|
|
|
From my point of view, this is kind of tricky/non-standard.
No. It's fully standard action. Open ISO14229, or 14230 or any other automobile standard, described down/up data transfer/ Read about DFI (data format identifier) parameter and you will see: dataFormatIdentifier
This data parameter is a one-byte value with each nibble encoded separately. The high nibble specifies the
“compressionMethod” and the low nibble specifies the “encryptingMethod”. The value 00 hex specifies that no
compressionMethod nor encryptingMethod is used. Values other than 00 hex are vehicle-manufacturer-specific.The manufacturer can assign DFI value as they like without violating the requirements of the standard. |
|
|
|
|
Logged
|
|
|
|
dexterash
Newbie
Karma: +1/-0
Offline
Posts: 7
|
|
« Reply #88 on: July 12, 2019, 02:41:11 PM »
|
|
|
Thanks for that lesson - didn't knew that. Although, sometimes, I saw or stumbled upon implementations that are not documented/nor standard. Especially at lower levels, debug mode, security access & co. But, yet again, my experience is scarce about this.
Do you think that, for example, Japanese, Chinese or Korean cars would follow the same rule?
|
|
|
|
|
Logged
|
|
|
|
dragon187
Full Member
Karma: +13/-15
Offline
Posts: 106
|
|
« Reply #89 on: May 25, 2020, 01:03:04 PM »
|
|
|
Hi Are there any news on this? If anyone have built some software please contact me. I would buy. Many thanks BR  |
|
|
|
|
Logged
|
|
|
|
|
