DrDelphi
Newbie
Karma: +0/-0
 Offline
Posts: 2
|
 |
« Reply #30 on: September 27, 2016, 11:42:38 PM »
|
|
|
Hello guys
Too bad this thread has died.
If the members that posted the above code pieces are still around, I would have some questions if they are kind enough to clear them with me.
So, first of all, where do I get the "key" from ?
Normally, having a SGO and the BIN file, should be enough to find the key, but the seed algo doesn't check. Are you sure it is seed0 = (seed0 + key[kIdx]) * 3 ? Isn't it *2 or *4 or anything else?
The password encrypted SGOs are easier to decrypt. Some passwords I found are BiWbBuD101, GEHEIM, CodeRobert and MILKYWAY.
This should be all for now.
Looking forward for you replies.
Best regards.
|
|
|
|
|
Logged
|
|
|
|
Geremia
Jr. Member
Karma: +11/-10
Offline
Posts: 27
|
|
« Reply #31 on: September 30, 2016, 11:00:34 AM »
|
|
|
The seed0 = (seed0 + key[kIdx]) * 3 you refer, is about decrypting frf to a zip file, inside zip there is odx file, inside odx you find DATA, which is (mont time) encrypted/compressed data you send (as is) to ecu when flashing. In sgo, if i remember well, is a simply xor FF (or sort of) to get an sgm file, which is a container where you find DATA (again, most time compressed and/or encrypted) to send (as is) to ecu. If you are referring to seed in the mean of seed/key auth against ecu, that's another story, SA2 data (you can find it inside sgm and odx) is what you need for passing seedkey in programming session (diag session is another story). I came accross the milkyway too  |
|
|
|
|
Logged
|
|
|
|
|
cherry
|
|
« Reply #32 on: September 30, 2016, 12:58:11 PM »
|
|
|
So far i know DATAblocks in sgm should only be "encrypted" as base64.
|
|
|
|
« Last Edit: March 09, 2017, 11:56:05 PM by cherry »
|
Logged
|
|
|
|
|
cherry
|
|
« Reply #33 on: September 30, 2016, 01:13:52 PM »
|
|
|
Attached sgm example.
|
|
|
|
« Last Edit: March 09, 2017, 11:56:36 PM by cherry »
|
Logged
|
|
|
|
DrDelphi
Newbie
Karma: +0/-0
Offline
Posts: 2
|
|
« Reply #34 on: October 01, 2016, 01:17:50 AM »
|
|
|
Thanks for the reply, Geremia.
I thought that the algo you posted was for decoding SGO blocks. Meanwhile I realized it was for FRF as I succeeded to turn them into ODX and then into BINs.
The problem I am dealing with now is with the SGOs.
The SGO files that are compressed, are also password encrypted and they are easy to decompress / decode. If you don't know the password, but you have the BIN from another source, I can find out the password by compressing the BIN and then XORing the result with the SGO.
The problem is with the uncompressed SGOs that don't use passwords and I couldn't yet figure out how they are encrypted.
If I take a SGO, extract its blocks, then take the corresponding BIN from another source and XOR them, I get some scrambled data. Then if I take the scrambled data and XOR it with another SGO's blocks, I get the correct data result, but it's not a solution I can rely on. It's definitely another XOR algo, but not the one used for FRFs and maybe another key too.
Any hint ?
Thanks in advance and best regards.
|
|
|
|
« Last Edit: October 01, 2016, 01:25:21 AM by drdelphi »
|
Logged
|
|
|
|
Geremia
Jr. Member
Karma: +11/-10
Offline
Posts: 27
|
|
« Reply #35 on: October 01, 2016, 03:11:15 AM »
|
|
|
Well, sgo/odx are only containers, how DATA is compressed/encrypted is ecu and/or car brand specific, you have to reverse the service36 function of the bootloader of the specific ecu to know how it's done, or if you have some encrypted and decrypted pairs, maybe guess it.
|
|
|
|
|
Logged
|
|
|
|
|
prj
|
|
« Reply #36 on: October 05, 2016, 03:51:29 PM »
|
|
|
The problem is with the uncompressed SGOs that don't use passwords and I couldn't yet figure out how they are encrypted. If it's not encrypted then it's XOR FF and result is the file obviously, as has been posted here. If it's BCB compressed XOR encrypted - then breaking the key takes <1 second with a single thread for any file, you don't need to know what's in there nor do you need the key, as it can be computed at runtime. If it's some different type of encryption and/or compression, then you will have to obviously reverse the bootloader of the ECU to find the algorithm. EVC has introduced a SGO/FRF import plugin. Upon asking them which ECU's it actually works with I did not receive a reply... and I am a customer. |
|
|
|
« Last Edit: October 05, 2016, 03:54:49 PM by prj »
|
Logged
|
|
|
|
ladan
Newbie
Karma: +0/-1
Offline
Posts: 5
|
|
« Reply #37 on: November 09, 2016, 11:27:11 AM »
|
|
|
Hi everyone... so where can I find "key" array? Geremia ?
const unsigned char key[4095] = {
#include "key.h"
};
|
|
|
|
|
Logged
|
|
|
|
|
nyet
|
|
« Reply #38 on: November 09, 2016, 12:11:27 PM »
|
|
|
If somebody wants to give me a set of sgo/bin pairs and decent documentation i'd be more than happy to write a decoder and provide source code.
|
|
|
|
|
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
|
|
|
|
prj
|
|
« Reply #39 on: November 10, 2016, 07:59:14 AM »
|
|
|
If somebody wants to give me a set of sgo/bin pairs and decent documentation i'd be more than happy to write a decoder and provide source code.
Did you ignore what I wrote in the other thread? I am bumping thic topic.
What's needed to write such converter? I would donate, others would do the same I guess.
1. Reverse SGO format enough to parse it. 2. Reverse the bootloader on every single ECU type you want to convert. EDC15/ME7/ZF6HP/MED9/ME17 are BCB/XOR. Some have fixed key, others like EDC15 have a different key for every ECU file and version. Other ECU's such as EDC16 and SIMOS have a completely different algorithm that can be only obtained by reversing the the bootloader. I would happily write a converter if somebody can post the specs to the sgo file.
With all due respect, I don't think you are going to break the crypto on EDC16 for example. You need to pull the bootloader apart one by one, it is a very time consuming process. The SGO is easy to reverse even without any specs. I don't think you understand how this works. The code to decode ME7 is already in this forum thread, but it is different for every ecu type. |
|
|
|
|
Logged
|
|
|
|
ladan
Newbie
Karma: +0/-1
Offline
Posts: 5
|
|
« Reply #40 on: November 11, 2016, 03:48:25 AM »
|
|
|
hi Prj,
So what about my question? Don't you know?
As far as I see - all "converters"(FRF 2 ODX/SOX) use original .dll (from DTS7) to convert FRF to ODX, but I searching algo(my solutions are running under Linux).... One posted above looks good but where to find a "key"?
|
|
|
|
« Last Edit: November 11, 2016, 03:50:00 AM by ladan »
|
Logged
|
|
|
|
|
prj
|
|
« Reply #41 on: November 11, 2016, 05:06:57 AM »
|
|
|
hi Prj,
So what about my question? Don't you know?
As far as I see - all "converters"(FRF 2 ODX/SOX) use original .dll (from DTS7) to convert FRF to ODX, but I searching algo(my solutions are running under Linux).... One posted above looks good but where to find a "key"?
Why do you feel entitled to an answer? It is not my job to answer you. I have not even looked at the FRF format, I only wrote an SGO decoder and I had help with reversing the algorithms in some of the ECU's. |
|
|
|
« Last Edit: November 11, 2016, 05:24:17 AM by prj »
|
Logged
|
|
|
|
ladan
Newbie
Karma: +0/-1
Offline
Posts: 5
|
|
« Reply #42 on: November 11, 2016, 05:21:20 AM »
|
|
|
Hm... I just hoped you can help, since you are online....
|
|
|
|
|
Logged
|
|
|
|
ladan
Newbie
Karma: +0/-1
Offline
Posts: 5
|
|
« Reply #43 on: November 12, 2016, 06:57:35 AM »
|
|
|
turned on my brain, read once again, found all I need, wrote unpacker script .... thanks Geremia, tmbinc
|
|
|
|
« Last Edit: November 12, 2016, 06:59:20 AM by ladan »
|
Logged
|
|
|
|
learning1
Newbie
Karma: +3/-0
Offline
Posts: 9
|
|
« Reply #44 on: November 19, 2016, 11:00:44 AM »
|
|
|
NO TOOL can write to OTP areas!!!! EVER!
That is incorrect. OTP is write once area that starts with all binary bits unset value 00 When all binary bits are burned you have FF You can only burn more bits so you can only move towards FF, Tools tend to avoid OTP but the statement that no TOOL can write to this EVER is not TRUE |
|
|
|
|
Logged
|
|
|
|
|
