Not an issue, Simos 18.4 question inside.

[Magnum828]

Hello, first and foremost big thanks to all of you involved in this project!

I have a question about flashing Simos 18.4, as I have been reading and looking through commits I saw that 18.4 simos was removed from GUI and also from github description, but it is still referenced in readme.md. The methods provided and .frf files for unlock reference SCG and SC8 codes.

My ECU is 8W0906259D so SCB50S00 cboot according to the box_codes.csv provided.

I would like to ask as of today, is flashing of Simos 18.4 possible in any way?

[bri3d]

It will flash fine if it's unlocked, it's the same UDS protocol as any other Simos18 and the AES keys are already in the project, but I need to finish an unlocking patch.

The big issue with doing so is that no commercial tool has bench/boot support. I made progress on making my Simos18_SBOOT project work, but FlexRay interfaces are expensive.

I removed the unlocking patch I had written because I couldn't test it and had one report that it was buggy and caused a brick. Writing an unlock patch should be simple (it's virtually the same as Simos18.10 with some locations changed), but without the ability to recover, writing a working unlocking patch is an expensive and difficult testing proposition.

[Magnum828]

Ohhh, I forgot about this ecu being FlexRay based. The ECU is OEM locked as of now. If I could be of any help then I would like to volunteer as a tester. Soldering or setting up raspberrypi based bench equipment is not a problem (gathering a FlexRay interface seems to be the main problem). Consider the "issue" closed. Thanks for your time and answer!

[FirewinX]

Bitbox have a protocol for simos18 in Bootmode.

[Michae11g]

I wanted to add to this in case other people stumble upon it and see "..had one report it was buggy.." and decide to give it a shot like I did. Long story short, the included 18.41 patch resulted in a brick for me as well.

I figure I might as well add some additional information and raise some questions regarding SIMOS18.41 in case anyone has some thoughts or insight 🙂. Let me know if I should split this off into a new issue, or if there is a better forum for this discussion.

I flashed the ECU from 8W0906259J_0002 to 80A906259F_0008 then attempted the unlock flash. Once it started flashing*, it ran to completion including the patched block, however the ECU never came back after the final reset (no comm). To me this sounds like the flash process is fine, however the resulting ASW was invalid and the ECU never makes it to a working CBOOT.

• I had to change some timeout values to get it to start the flash (ECU kept exceeding the P2/0.030s timeout 🤷).

I'm planning on giving this a second shot soon, but I want to understand why it failed first to hopefully reduce my chances of making a second (or third) brick 🤞.

So far, I've noticed a few differences about the sample flag / mode. For instance, SIMOS18.1 (and SIMOS18.10) uses the memory location b000218c (and b00035f0), where as SIMOS18.41 seems to have two memory locations b00035f0 (same as 18.10) and b00035f5 (!!!). I found these two locations by following the patch_cboot() logic found in patch_cboot.py and following the references in the two "set sample mode" functions.

I'm hoping someone can shed some light on the difference between the two "set sample mode" functions in 18.1/.10 and why we patch both in patch_cboot() but only patch one in patchXXXX.bin. If only the 2nd function needs to be patched, why do we bother patching both in patch_cboot().

Given that SIMOS18.41 seems to use two separate flags, each set by one of the two functions, should we be patching both functions in patch_1841.bin? Or should we be patching the other function at 8080dc16 (so as to change b00035f0 as with SIMOS18.10)?

My hunch is that this difference wouldn't cause a brick, maybe just a locked ECU. If anyone has any hintsor direction as to where to look next that would also be helpful!

Thanks in advance, cheers!

Some additional information:

• I have logs of the flash if someone thinks they're needed. The flash/patch seemed fine so I didn't bother attaching.
• I'm using these FRFs for my analysis: 8V0906259H0001 (18.1), 5G0906259Q0005 (18.10), and 80A906259F__0008 (18.41). It's just static analysis so far (no working EMU setup yet).

[bri3d]

Sorry for causing a brick. Thanks. I'll update the documentation and perhaps pull the patch for now.

I'm hoping someone can shed some light on the difference between the two "set sample mode" functions in 18.1/.10 and why we patch both in patch_cboot() but only patch one in patchXXXX.bin.

One of these functions is in the flash bootloader and one is in the RAM bootloader.

We only patch one in patchXXXX.bin because it is only necessary to patch the RAM bootloader in the patch, as that is what we are jumping into. Once we write the main bootloader into Flash, we patch both locations.

My hunch is that this difference wouldn't cause a brick, maybe just a locked ECU. If anyone has any hintsor direction as to where to look next that would also be helpful!

I agree, I doubt this is the actual problem. My suspicion is that the 18.41 patch was not injected into the correct place in Flash - that the series of nops which I overwrite with the jump into the patch code is not the right part of code.

[Michae11g]

Sorry for causing a brick.

No problem at all, all part of the process!

We only patch one in patchXXXX.bin because it is only necessary to patch the RAM bootloader in the patch, as that is what we are jumping into. Once we write the main bootloader into Flash, we patch both locations.

Ahh gotcha, that makes sense. Curious as to why 18.41 uses different memory locations for these two functions then. Still digging into this, hopefully I'll see something :)

My suspicion is that the 18.41 patch was not injected into the correct place in Flash - that the series of nops which I overwrite with the jump into the patch code is not the right part of code.

That would make sense. I'll have a crack at that as well -- It will get a little expensive to blindly try all nop sleds

[Magnum828]

I would start from the SBOOT side of things, as you mentioned checking all od the NOP sleds could get pretty expensive 😅 If @bri3d would be interested maybe we could setup some kind of donation for him to buy FlexRay interface and other required equipment. Just my two cents 🙂

[Michae11g]

Turns out there are only 3 nop sleds (ending with dsync), and the remaining 2 are both in ASW1*. Won't be too expensive to try them both.

Edit: Current hook is in ASW1, there is 1 other in ASW1

Thinking I'll start with a simpler patch and just copy CBOOT as is with no patching

[bri3d]

I would usually identify the "correct" (for some definition) nop sled by the nearby presence of a disable instruction; if there isn't a disable instruction, you should add one to the patch or things will crash when the scheduler interrupt hits and ASW swaps tasks out from under you before CBOOT has loaded. Otherwise, the RAM CBOOT can generally set up peripherals and so on from pretty much any point it's injected at, which is nice - this is one of the things I really liked about this patching approach.

[Magnum828]

But making SIMOS18_SBOOT work with FlexRay ECUs would enable brick recovery and would be useful when creating ASW code patches to recover said bricks. If @bri3d would be interested in pursuing the project I'm willing to be the lab rat 🙂

[Michae11g]

Would be nice to make use of my growing pile of paperweights 😅

I did find this, one of these days I'll hook up a logic analyser and do a bit of sniffing. Maybe we can just "bitbang" the protocol with a sufficiently fast MCU and appropriate transceiver https://github.com/robbederks/FlexRayAnalyzer

[jared52005]

Cheapest MCU FlexRay capable hardware which you can get is Devkit for 100GBP (It used to cost 50GBP before pandemic) https://fi.farnell.com/en-FI/nxp/devkit-mpc5744p/dev-kit-32bit-power-architecture/dp/2890648

It should be possible to get basic hardware setup from NXP by downloading their Autosar drivers and then digging out the C/CPP pieces for MPC5744 FlexRay setup. I also saw a Comma.ai repository in the past with MPC57xx implementing FlexRay, but can't find it anymore.

Or here is the FlexRay based on FTDI MPSSE, no idea if it works https://github.com/Roboy/flexrayusbinterface/tree/master

I am working on the same problem. I have here Simos 18.4, Vector hardware, MPC5748 (with Ethernet), MPC5744 and TC1798 devkits, all have FlexRay. Currently I am stuck on the fact that I don't know following:

1. What is FIBEX for SBOOT?
2. Is SBOOT able to coldstart FlexRay bus or not?

What is FIBEX for SBOOT? FIBEX is setup of FlexRay network. Baudrate is just not enough, you need to know size of the carousel, timing, etc. This can be reverse engineered from SBOOT itself. So, does somebody have full read of production Simos 18.4 including SBOOT?

Is SBOOT able to coldstart FlexRay bus or not? On FlexRay can be 2 types of nodes. The coldstart ones and the normal ones. To get FlexRay bus running, you need at least 2 coldstart nodes to create a bus and then other nodes will integrate into the bus. However if SBOOT is not a coldstart node, then you would need 2 FlexRay devices in order to establish the bus before the SBOOT can integrate and start talking to you. Coldstart property is defined in FIBEX, which leads back to question 1.

[bri3d]

@jared52005 check your email.

Overall, I think getting the WriteWithoutErase/CBOOT exploit going on an ECU in a car (behind a gateway) would be an amazing help here. We can use the exploit and a custom diagnostic handler ("High Speed Logging" style patch) to dump things we're missing, like production SBOOT and especially the public keys from OTP. And, once we "unlock" an ECU in a car this way, we can dump the passwords from flash and get in via CAN BSL, so as long as we can get one ECU working we have an "unbrickable" test bench.

[jared52005]

Thank you, as I described in the email, it is more straightforward with little bit of math and you can use also bricked/immo locked ECUs.

[Michae11g]

I am working on the same problem. I have here Simos 18.4, Vector hardware, MPC5748 (with Ethernet), MPC5744 and TC1798 devkits, all have FlexRay. Currently I am stuck on the fact that I don't know following:

1. What is FIBEX for SBOOT?

Have you been able to interact (log / listen) with the FlexRay bus of a running car / ECU? Or are the parameters for that unknown as well? Could they have just reused the same interface on SIMOS18.41 like they reused ISO-TP for other SIMOS18 SBOOT implementations?

I would assume the CBOOT/ASW FlexRay parameters are available from the flash (Follow the ERAY registers) or just logging the vehicle bus with a logic analyser.

[jared52005]

If you have tools, you can listen to the FlexRay bus (baudrate is enough), see here https://github.com/jared52005/Monitor if you want to interact with FlexRay, you need to know the FIBEX.

The FIBEX is different for each OEM manufacturer. FlexRay is configuration heavy and each ECU needs to know the length of the carousel in advance (aka, which FR cycle and in which timeslot of a cycle it should transmit and when it should be quiet). This configuration must be exactly same in each ECU in the system.

That means that when you take ECU from BMW, it won't work with ECU from VAG, because the systems are different (slots, ECU counts) and thus configurations are different. This also means that setup from SBOOT and generic VAG FIBEX will be different too and applying a VAG FIBEX which can have N ECUs on SBOOT which was likely intended as 2 or 3 ECU network is not going to work.

You can try to figure out VAG FIBEX from logs here: https://github.com/robbederks/q8_flexray_dumps It is much simpler, as you are hinting, to just take bootloader, let the emulator fill the registers and then just parse what is inside to get back FIBEX.

[Michae11g]

...This also means that setup from SBOOT and generic VAG FIBEX will be different too and applying a VAG FIBEX which can have N ECUs on SBOOT which was likely intended as 2 or 3 ECU network is not going to work.

That makes sense. Sounds like it is definitely easier to get the CBOOT exploit working then dumping / emulating a production SBOOT.

[Techsimplex0]

Hi guys, Just acquired a 2018 Allroad Simos 18.4, and I have a Kess versions 3, and it does not have any support for this Simos version unfortunately After a quick google search I found this nifty tool. I understand, as of right now there is not any unlock support for simos 18.4. My question is, If I found an unlock solution, would it be possible to use vw_flash to flash the car? I have a spare Simos 18.1 ecu and I was trying ecu_flash on the bench with Tactrix and Mongoose JLR PRO and its working just fine with the ecu immo offed.

[Michae11g]

Unfortunately, the current implementation doesn't work with Simos 18.4. and if you dig up the old S18.4 patch from previous commits it will brick your ECU :(

If you had a working unlock patch (from where!?) I'm sure some of us would be interested in comparing it!