Jerin
Newbie
Karma: +0/-0
 Offline
Posts: 9
|
 |
« Reply #60 on: January 03, 2019, 02:39:26 PM »
|
|
|
So I tested a small script with a similar struct.unpack: 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
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: +3/-0
Offline
Posts: 47
|
|
« Reply #62 on: January 08, 2019, 01:41:35 PM »
|
|
|
FRF/SGO might not give you full binary, some sections might be missing.
|
|
|
|
|
Logged
|
VAG immo solutions (clone, immo off, repair) MEDC17, SIMOS, SDI, BCM2, ELV, DQ/DL/VL gearboxes, INVCON, MED9.x crypto
|
|
|
Jerin
Newbie
Karma: +0/-0
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
|
|
« 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
|
|
« 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
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. So either you bypass it via OBD unlock ..
So absolutely no need to open the ECU even once? ..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
|
|
« 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
|
|
« 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
Full Member
Karma: +134/-1
Offline
Posts: 195
|
|
« 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/nlzssdef 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
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/frfdumperIf someone has info on how to decode compression method 11 please feel free to contact me. |
|
|
|
|
Logged
|
|
|
|
|
birchbark506
|
|
« 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
|
|
« 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
|
|
« 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 guideECUx PlotME7Sum checksumTrim heatmap toolPlease 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 ex
|
|
|
dexterash
Newbie
Karma: +1/-0
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
|
|
|
|
|
