Pages: 1 ... 3 4 [5]
Author Topic: FRF and SGO - Differences?  (Read 39131 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: 374


« 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: 374


« 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: +9/-0
Offline Offline

Posts: 6


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

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