Pages: 1 ... 4 5 [6]
Author Topic: FRF and SGO - Differences?  (Read 40711 times)
SB_GLI
Hero Member
*****

Karma: +91/-7
Offline Offline

Posts: 1015


« 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"

Smiley

Interesting tidbit about nintendo, Nyet
Logged
dexterash
Newbie
*

Karma: +1/-0
Offline 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
Full Member
***

Karma: +48/-4
Offline Offline

Posts: 219


« 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
Full Member
***

Karma: +48/-4
Offline Offline

Posts: 219


« 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
Newbie
*

Karma: +12/-0
Offline Offline

Posts: 8


« 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 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
Hero Member
*****

Karma: +91/-7
Offline Offline

Posts: 1015


« 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 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
Hero Member
*****

Karma: +91/-7
Offline Offline

Posts: 1015


« 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.

Code:
//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 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
Full Member
***

Karma: +48/-4
Offline Offline

Posts: 219


« 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 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
Full Member
***

Karma: +48/-4
Offline Offline

Posts: 219


« 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 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
Pages: 1 ... 4 5 [6]
  Print  
 
Jump to:  

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines Page created in 0.02 seconds with 18 queries. (Pretty URLs adds 0s, 0q)