Pages: 1 ... 3 4 [5] 6
Author Topic: FRF and SGO - Differences?  (Read 40510 times)
Jerin
Newbie
*

Karma: +0/-0
Offline Offline

Posts: 9


« Reply #60 on: January 03, 2019, 02:39:26 PM »

So I tested a small script with a similar struct.unpack:
Code:
import struct
h = 'Hi'
s = struct.unpack('>H', h)[0]
print s
and I got the same error as above.  Online this script works fine.

Conclusion- the script here that I am having the issue with is programmed for Python version 2.  It will need to be re-worked for version 3.

My lazy (smart) fix was to uninstall Python3 and install Python2.
Logged
Jerin
Newbie
*

Karma: +0/-0
Offline Offline

Posts: 9


« Reply #61 on: January 07, 2019, 10:52:55 PM »

My odx has 5 <DATA> sections:
<DATA> section 3
 80000000-80003FFF
 3FFF bytes = 16383 dec

<DATA> section 1
  80004000-8000FEFF
  BEFF bytes = 48895 dec

<DATA> section 2
  80020000-8027FFFF
  25FFFF bytes = 2490367 dec

<DATA> section 4
  80283000-8037FFFF
  FCFFF bytes = 1036287 dec

<DATA> section 5
  80380000-803FFEFF
  7FEFF bytes = 524031 dec

I have labelled the sections from 1 to 5 but section 3 is defined in the header as the lowest hex location.
Running the "unpack BCB Type1 compressed data" script on each section leaves many remaining bytes and none produce the needed 4 MB binary.
Stacking the sections in 12345 order and running through the script produced a very small output but no remaining bytes.
The 31245 order was nearly the same.

Please, how is this supposed to work?

A positive note, section3 unpacked does show the actual SW number related to the frf.
Logged
kuebk
Jr. Member
**

Karma: +0/-0
Offline Offline

Posts: 30



« Reply #62 on: January 08, 2019, 01:41:35 PM »

FRF/SGO might not give you full binary, some sections might be missing.
Logged
Jerin
Newbie
*

Karma: +0/-0
Offline Offline

Posts: 9


« Reply #63 on: January 19, 2019, 09:25:55 PM »

My odx has 5 <DATA> sections:
<DATA> section 3
 80000000-80003FFF
 ..
<DATA> section 1
  80004000-8000FEFF
 ..etc


Ok, data sections show the data locations, just fill the empty sections with 00 00 00..
up to the final file size 3fffff (first byte is at 0).
No extra checksum to do.
Logged
birchbark506
Sr. Member
****

Karma: +5/-9
Offline Offline

Posts: 377


« Reply #64 on: January 20, 2019, 06:34:55 AM »

can a sgo be modded and then reflash back using odis? i am running in to a problem with cmd on med17 with tp20 tuning protection i have odis to flash the modded sgo back with
Logged
cherry
Full Member
***

Karma: +5/-1
Offline Offline

Posts: 73


« Reply #65 on: January 21, 2019, 10:52:22 AM »

Most expensive tool and struggling with a TP20 ecu, buy PCMflash for these ecu...

To the question, it doesnt make sense to pack it into a sgo. The problem is not to write it but the RSA signature. So either you bypass it via OBD unlock or patch flash via bootmode, then you can write OBD. Only ecu lower TP07 can be written via OBD without "tprot"-bypass. This is very old stuff.
Logged
Jerin
Newbie
*

Karma: +0/-0
Offline Offline

Posts: 9


« Reply #66 on: January 21, 2019, 11:43:01 AM »

.. it doesnt make sense to pack it into a sgo. The problem is not to write it but the RSA signature.

Won't Odis know how to get past the RSA?  Probably why he wants to repack.

Quote
So either you bypass it via OBD unlock ..

So absolutely no need to open the ECU even once?

Quote
..via OBD without "tprot"-bypass.

I though that Tprot is different from RSA.  You need to descramble a random RSA passkey to read or write to the ECU but if the Tprot bytes are set, you can't dump the tuner's info.
Have I got this right?

Logged
birchbark506
Sr. Member
****

Karma: +5/-9
Offline Offline

Posts: 377


« Reply #67 on: January 21, 2019, 01:41:16 PM »

i wish cmd would update it and give a VR read to be able to read and write ecu with RSA code, seems like all the med17 tp in canada are locked dose pcmflash give VR and checksum before flashing back to ECU
Logged
cherry
Full Member
***

Karma: +5/-1
Offline Offline

Posts: 73


« Reply #68 on: January 21, 2019, 06:37:46 PM »

Odis just write content what´s inside the sgo/sgm, there is no RSA during flash, it´s done from Bosch. Also there is RSA in older MEDC17 or even EDC16, but it was not checked hard enough, so a calculation was possible.
Logged
d3irb
Newbie
*

Karma: +12/-0
Offline Offline

Posts: 8


« Reply #69 on: February 20, 2019, 02:26:12 PM »

Hi - I posted a reply to the Simos18 thread earlier but I have reversed the Simos18 encryption and compression setup so I can convert Simos18 ODX to BIN.

Please find my Python3 script attached to http://nefariousmotorsports.com/forum/index.php?topic=10364.msg122889#msg122889 .

A few things relevant to this thread:

1) "BCB Type1" is basically "LZSS" compression. I adapted an LZSS library from elsewhere and the code is much cleaner than what has been posted in this thread. My script contains the LZSS decompression routine which should work for your other ECUs. This code was modified from https://github.com/magical/nlzss

Code:
def decompress_raw_lzss10(indata, decompressed_size):
    """Decompress LZSS-compressed bytes. Returns a bytearray."""
    data = bytearray()

    it = iter(indata)

    def writebyte(b):
        data.append(b)
    def readbyte():
        return next(it)
    def readshort():
        # big-endian
        a = next(it)
        b = next(it)
        return (a << 8) | b
    def copybyte():
        data.append(next(it))

    while len(data) < decompressed_size:
        b = readbyte()
        flags = bits(b)
        for flag in flags:
            if flag == 0:
                copybyte()
            elif flag == 1:
                sh = readshort()
                count = (sh >> 10)
                disp = (sh & 0x3ff)
                for _ in range(count):
                    writebyte(data[-disp])
            else:
                raise ValueError(flag)

            if decompressed_size <= len(data):
                break
    return data

2) I see a lot of confusion here. To be crystal clear: ODX is simply an XML file which contains the payload for ODIS to send to the ECU. Each ECU has its own system for decrypting, decompressing, and flashing, which differs from ECU to ECU. While some things are shared (like this compression type), other things (like the AES keys for Simos18, which you can find in my script) are different from ECU to ECU. Because ODIS does not need to flash modified maps, it is not as capable as third-party/aftermarket flashing tools - it never needs to do anything like "fix checksums" or "RSA" because the files it is flashing are already valid and come from VW.

For example, "RSA protection" is a check which exists only inside the ECU - ODIS knows nothing about it. When the ECU boots it attempts to verify the RSA signature of the various protected areas on its own. In the case of the ECUs which ME7Sum can fix, a foolish property of VW's protection is exploited: the flash routines in the ECU don't check the RSA signature against the currently running code, so both the signatures and the public key can be replaced so long as they match ("self-signing" the flash). The flash routine will happily write the file and the file itself will happily verify because it's been signed with its own key. For some newer ECUs, signatures are checked by the flash routine so this is no longer possible.
« Last Edit: February 20, 2019, 02:29:57 PM by d3irb » Logged
pechspils
Newbie
*

Karma: +0/-0
Offline Offline

Posts: 1


« Reply #70 on: July 07, 2019, 05:59:17 AM »

I've used the information posted in this thread to write (yet another) *.frf dumper. Obviously, it wont decrypt the flash payloads but it's an easy way to extract the odx and/or peek into the odx structure without opening it in an editor.

https://github.com/trick77/frfdumper

If someone has info on how to decode compression method 11 please feel free to contact me.
Logged
birchbark506
Sr. Member
****

Karma: +5/-9
Offline Offline

Posts: 377


« Reply #71 on: July 09, 2019, 04:41:27 PM »

cmd did a update to allow write on med17 tropt7+ works with out a problem. i also got pcmflash now as well.
Logged
SB_GLI
Hero Member
*****

Karma: +91/-7
Offline Offline

Posts: 1015


« Reply #72 on: July 10, 2019, 07:24:41 AM »

If someone has info on how to decode compression method 11 please feel free to contact me.

Repeating bytes are compressed into a single byte and then created as a block.  Non repeating bytes are created as a block.  There's a few header bytes before each block that defines the size of the block.  After this simple compression, each byte is XOR encrypted using a key that is unique to the type of ecu.   I am quite sure there are examples of this on this forum, but in a nutshell, that's how it works.  - this is bosch 0x11 compression/encryption.
« Last Edit: July 10, 2019, 07:27:55 AM by SB_GLI » Logged
nyet
Administrator
Hero Member
*****

Karma: +424/-51
Online Online

Posts: 9524


WWW
« Reply #73 on: July 10, 2019, 08:48:00 AM »

Repeating bytes are compressed into a single byte and then created as a block.  Non repeating bytes are created as a block.  There's a few header bytes before each block that defines the size of the block.  After this simple compression, each byte is XOR encrypted using a key that is unique to the type of ecu.   I am quite sure there are examples of this on this forum, but in a nutshell, that's how it works.  - this is bosch 0x11 compression/encryption.

Hilariously, I believe bosch stole it from Nintendo (even though there are many examples of run length compression that aren't Nintendo's)
Logged

ME7.1 tuning guide (READ FIRST)
ECUx Plot
ME7Sum checksum checker/corrrector for ME7.x

Please do not ask me for tunes. I'm here to help people make their own.

Do not PM me technical questions! Please, ask all questions on the forums! Doing so will ensure the next person with the same issue gets the opportunity to learn from your experience.
dexterash
Newbie
*

Karma: +1/-0
Offline Offline

Posts: 7


« Reply #74 on: July 11, 2019, 04:31:07 AM »

Repeating bytes are compressed into a single byte and then created as a block.  Non repeating bytes are created as a block.  There's a few header bytes before each block that defines the size of the block.  After this simple compression, each byte is XOR encrypted using a key that is unique to the type of ecu.   I am quite sure there are examples of this on this forum, but in a nutshell, that's how it works.  - this is bosch 0x11 compression/encryption.
Hello

So you are saying the key is only one byte long? Or multiple bytes?
Does this apply to all ODX files with <ENCRYPT-COMPRESS-METHOD TYPE="A_BYTEFIELD">11</ENCRYPT-COMPRESS-METHOD> and, maybe, <ENCRYPT-COMPRESS-METHOD TYPE="A_BYTEFIELD">01</ENCRYPT-COMPRESS-METHOD>?

Thanks!

L.E.
I suppose you are actually talking about keys like "BiWbBuD101"...
« Last Edit: July 11, 2019, 05:42:43 AM by dexterash » Logged
Pages: 1 ... 3 4 [5] 6
  Print  
 
Jump to:  

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