Custom CDC to SID text

[Karlis]

I wonder if anyone has been able to crack this yet... :)

The basic thing is that it seems CD changer doesn't send any text directly to SID. Instead it "reports" its status to IHU, which in turn then sends the text to SID. For example "CD1 PLAY MM:SS".

So far I've tried "blasting" the custom text via 0x328 (SID audio text) but that causes the text on the SID to flicker alternating from the "original" message to the one I was sending on power on and on any button related action. I've seen people on the web sending custom text via 0x337 (SPA to SID text). That I believe works fine but I'm not quite sure how it would behave on cars with the actual SPA installed.

Could we intercept the original 0x328 message somehow and tell SID to ignore it and take our custom one with a higher priority? Some sort of software "man in the middle" attack, without the need of splicing the wires.

Any ideas are welcomed. :)

[Ziq]

Unfortunately, it won't be possible to intercept the original message and replace it. I wouldn't give up on your alternative priority just yet though.

As I have a NAV system there are no audio display messaces on the SID and by copying your (perhaps old) implementation I still got flickering results. Of what I can see you did not set the changed bit, perhaps that can be a source? I'm also not convinced that you need to wait for permission to write, could it not be that nodes always sent their messages and that 368h simply informs who is currently granted access? In that case it could be that you wait to long after 348h before you send 328h...

I have limited time for this with small kids at home but for tomorrow I have warned my wife that I will dissappear to the parking garage for a while for some measurements. I will make a log of all message with a usb-can device and see how the SPA message is handled. Will let you know the results when I've had time to analyze it!

[Sandwer]

There is a definite difference between early facelift and the later facelift 9-5's - I had Saablin working faultlessly on an '03 - scrolling song titles and so on, yet the same on an '05 (shark nose), I had the flashing and delays.  

It almost points to a change in the way the messages are interpreted and displayed in later models. I couldn't say for certain if it was anything to do with the change to the SID (upper case vs lower case).  
Incidentally, my iPod bluesaab exhibited the same issues....

Maybe something and nothing...

Ziq, do you have the Kenwood based nav or the Denso?  

[Ziq]

Well, then we might  just have to reverse engineer the new way!

I've got the Denso one. The touchscreen died with my last battery so I'm basically bound to the operations of the steering wheel buttons but that shouldn't matter in this project.

[Ziq]

Well, I've only looked really quickly but it looks like Karlis interpretation is correct. The text is only sent if permission is granted by 368h.

The reason for my flickering is due to the fact that my nav unit sends 348h saying there is nothing to display. I looked at the SPA control 357h and it also sends a nothing to display message every second. If the car does not have parking assist then perhaps this message is not there...

Since my message usually was on for half a second and then gone for half a second I figured that this might be the case, however sometimes the display seemed stable. The question is if Karlis suggestion to intercept a message could really be something to look at. It would be impossible to stop it from reaching it's target but perhaps we can overwrite the information with a new message directly after and hope that the display doesn't have enough refresh rate. Of what I can see it takes about 20 ms from the 357h to request permission until 368h grants it and we shoukd be able to send new information long before then!

[Karlis]

I did a quick lookup of Saablin's code. It looks like that code intercepts the default SPA -> SID text ("SAAB PARK ASSIST") and tells that this text shouldn't be displayed. Then it alters the text and sends it over to SID. If I'm not mistaken, Tomi did the same thing within his OpenTech project. So intercepting and altering messages works. We should be able to do it the "Jedi way" and leave the SPA -> SID functionality intact just to avoid any problems for people having SPA installed on their car. :)

[Ziq]

Responding to every 348h with a new 348h was successful in my case. There were a few short glitches (1-2 times per minute maybe) but I think they can be attributed to the lack of CAN filters in my application so it's to slow responsing to relevant messages.

Hopefully you can do the same for 328h as well.

As a side not I am not using an internal timer to get my messages out in time. 348h is now always cyclic due to inherentance from the IHU and I actually put  my CDC status (3C8) to be sent at the same event. I was planning to respond with the CDC status if the Lock status said unlocked but this is probably just as good.

[Da Bear]

I have tried this.

When I receive a 348h with byte 0 = 0x82 (NEW text) or 0x42 (update current text) (IHU sends "CD PLAY" to SID) I instantly respond and send the following:
368h 02 1E 00 00 00 00 00 00
348h 11 02 05 1E 00 00 00 00
328h 42 96 02 xx xx xx xx xx (Byte 0 is 0x82 if I'm writing a new text, 0x42 if text is not changed)
348h 42 96 02 xx xx xx xx xx (Repeat 328h message)
8ms delay
328h 01 96 02 xx xx xx xx xx
348h 01 96 02 xx xx xx xx xx
8ms delay
328h 00 96 02 xx xx 00 00 00
348h 00 96 02 xx xx 00 00 00

Then I monitor the time since I last sent a text to the SID and update it every 840ms - IF I'm granted access to row 2.

368h byte 1 0x1E is my try to give the module a node id between the IHU (0x19) and ACC (0x23). Same with the first 348h byte 3.
xx being the text I send, ie. "bluetooth"
Then I blast out my text groups with an interval of 8ms.

With this I don't get any flickering - BUT row 1 on SID gets blocket and won't display anything. Big problem.

Worth mentioning is that I have the AS2/AS3 IHU and a pre 2004 SID2 that's only capable of displaying 12 characters.

[Ziq]

Aren't 368h supposed to be coming from the SID? Does it have any effect when you send it?

I think you are making the timing a bit more complex than it needs to be. Since the IHU is already requesting the display (either blank or with text) every second there is no need for extra timers. There is also no need for a delay between the messages. See my implementation here: https://developer.mbed.org/users/petter/code/Saab-BT/file/7bb8b161e00b/CDC.cpp

If "1E" works for you maybe you can take the rest of my implementation directly.

[Karlis]

Hey Ziq,

Maybe you could integrate your display handling code into the 'dev' branch of SAAB-CDC code? It would be really nice to give it a test. Cheers!

[Ziq]

Since I run a different platform and a different IDE I can't make sure that it would compile for you. I've published my code (link above) so you are welcome to copy relevant parts.

Basically I do the following:
setup fixed parts of the message arrays during init
When calling display I update the message arrays and request write access to the display.
When I receive a display request from the IHU I send my own display request.
When I get display resource granted I send the message arrays.

Let me know if you need anything else explained.
Just let me know if you need anything explained. Only cdc.c is relevant for display functions.

[Ziq]

Just for reference - I tried out swapping the definition of CDC_SID_FUNCTION_ID from 0x19 to 0x1E to test and then my display function stopped working. I haven't spend time to debug it but it looks like I wasn't granted any rights to the display anymore.  

[Da Bear]

We'll just have to try different things until we get it working. :)

I might have an idea, I'll come back to that when I've made some tests.

[homerisback]

It may be something you guys already thought about but did you get in touch with the Trionicsuite guys who made OpenSID ?
One can display engine parameters from Trionic 7 on SID, so it should be able to display something else than CD1 PLAY 01.

[Karlis]

Yes, we are working on this feature. But this is very low priority now as we have more important issues to fix. From what I've seen OpenSID guys use SPA->SID text control logic to get the custom text to appear. That's, of course, one way of doing it. But not quite the "Jedi" way, as this technically messes with the actual SPA system (on some models) displaying its text on SID.

[Da Bear]

OpenSID channels is just what I'm experimenting with.
It sort of works but needs to be controlled without disturbing DICE, TWICE, RDS Radio etc. etc.
Thank of OpenSid as a crazy pitbull without a leach. It'll eat everything ;)

Den 15 maj 2016 23:40 skrev "homerisback [via BlueSaab Forum]" <[hidden email]>:

It may be something you guys already thought about but did you get in touch with the Trionicsuite guys who made OpenSID ?
One can display engine parameters from Trionic 7 on SID, so it should be able to display something else than CD1 PLAY 01.

02' 9.3 SE Conv - AS3 - Nexus 5 Android M 6.0.1 (mob30d)

---

If you reply to this email, your message will be added to the discussion below:

http://bluesaab-forum.2349123.n4.nabble.com/Custom-CDC-to-SID-text-tp90p345.html

To start a new topic under Software, email [hidden email]
To unsubscribe from BlueSaab Forum, click here.
NAML

[Karlis]

Oki-doki.... So here's a small update (story). Did some coding today and concluded that SID software is buggy (or maybe it's just me :)). This fact may also explain why there are a number of SID software versions out there. So here's the idea I'm trying to implement: since we are not a "man-in-the-middle" type of deployment, we can't just hijack IHU text frames and alter them before they are sent to SID. We have to be a bit cleverer.

From testing me and Seth have done previously, these messages appear to be sent at an interval of 1000ms. The message begins with IHU node ID = 348 and is followed with something like:

    0x11, 0xFF, 0x02, 0x19, 0x00, 0x00, 0x00, 0x00

Now, I'm pretty sure that 0x02 means "I wan't to write something on the 2nd 'object' (let's call it this way)". From what I understand, SID consists of three objects:

   0 = "Both rows of SID"
   1 = "1st row of SID"
   2 = "2nd row of SID"

Now back to the message - 0x19 apparently is some sort of confirmation to the node id 348, meaning "yes, I'm IHU and the text is coming from me".

I bet 0x11 means some sort of "priority", which is tied to a particular node.

Now to this 348 request, SID replies with a group of three messages outlining which 'object' it grants the requester to write on. I've seen three messages being sent at an interval of 1000ms with the same node ID. This is pretty much the same as described on Tomi's site:

00 FF 00 00 00 00 00 00
01 FF 00 00 00 00 00 00
02 19 00 00 00 00 00 00

This means, "ok, no one is allowed to write on 'object' 0 (the whole SID) or 'object' 1, but hey you - number 19 (IHU), whatever it is you want to say, do it so now!". At this moment IHU happily sends it's text control message with id 328, which in our case usually is "CD1 PLAY".

Now, after a lot of testing done, I don't believe any SID software version has been provisioned with acceptance of display resource requests coming from a CD changer. CD changer reports its status to IHU and IHU then sends text to SID on behalf of CD changer. Clear as mud, heh? :)

So what I tried to do today is use the same idea that was described in this post earlier with a little tweak. Basically I was trying to sit on the bus and listen for IHU to send "display resource request" messages to SID. When those messages appeared, I immediately sent another one saying "well, ok there's nothing to show for now. Clear whatever text you have on 2nd SID 'object'", anticipating that the second row would "free up" and I could immediately send my own text. That didn't work. So I wen't a step further and added some code that would send "clear everything on 'object' 0" on every loop of the code. This is where the fun begins... :)

Initially SID obeyed my code commands and wasn't displaying anything except clock, which was fine. I already started to think that this might actually work, but then... SID went out, the engine fan kicked off and all sorts of weird stuff started to happen. I quickly reverted the code changes and had to pull ECU reset fuse to get everything back to normal.

So, lesson learned - SID is to be handled with white gloves as it is more powerful than we could imagine... All hail to the SID. :)))

To be continued...

[Da Bear]

My observations so far. A little bit different than Karlis. (WALL OF TEXT )

IHU NODE ID = 19
348 is IHU TEXT CONTROL ID
IHU sends (To SID) 348 -> 11 2 3 19 0 0 0 0
Byte 0, is always 11
Byte 1, can be either 02 or 82. 02 = text not changed. 82 = new text
Byte 2, NODE ID (19 for IHU)

SID response with a grop of three 368 (Or does it? It might be sending 368 regardless, need to check this)
368 -> 0 FF 0 0 0 0 0 0
368 -> 1 FF 0 0 0 0 0 0
368 -> 2 19 0 0 0 0 0 0
368 is like a gatekeeper and decides what NODE is allowed to write is't text
Byte 0; SID ROW. 0 = Both rows. 1 = ROW 1. 2 = ROW 2.

In the above, both rows are free and NODE 19 (IHU) is granted write access.
IHU then sends a group of three 328:
328 -> 42 96 2 43 44 31 20 50
328 -> 1 96 2 4C 41 59 20 20
328 -> 0 96 2 20 20 0 0 0
328 is IHU TEXT to SID
Byte 0 in the first group, is always 42 when only writing to SID ROW 2. (If it was 45, it would start writing at SID ROW 1 (And counting down; 04 - row 1 col 2, 03 - row 1 col 3 etc...))
Byte 1 is the NODE ID (should be) of the SID.
Byte 2 can be either 02 or 82. 02 = text not changed. 82 = new text

Since I have OpenSID activated in my car I could sniff what that send to the SID.
This is what I have now

OpenSID NODE ID = 32
OpenSID TEXT CONTROL ID = 358
OpenSID TEXT TO SID = 33F

But since NODE 32 is very high priority it takes over the SID and any NODE with lower ID don't stand a chance to get write access to the SID, especially SID ROW 2, when something wants access to both rows.

As of now I monitor 368 and stores byte 1 from all three 368 messages in an array.
(Why? Because I need to know the state of ALL rows before I can make a decision to give write access or not, since the code now loops and don't care if its row 0, 1 or 2 that has values in them ).

arr[0] -> byte 1 from 368 00 FF ...
arr[1] -> byte 1 from 368 01 FF ...
arr[2] -> byte 1 from 368 01 FF ...

Then I can take actions from that and allow the bt module to write or not.
So if arr[0] is anything else than FF, the bt module is not allowed to write.
If arr[2] is 19 or 32, but nothing else, the module is allowed to write.
Nothing of the above, the module can write.

Example:
I get this in my 368 array
0: 0xFF  <-- Both rows free
1: 0xFF  <-- Row 1 is free
2: 0x32 <-- Row 2 is available for node 32

- Module is allowed to write

I send a TEXT CONTROL to SID to tell it that text is on the way to ROW 2
358 -> 21 2 3 32 0 0 0 0 (Byte 0 must be 21)
delay 5-10 ms
I then send my text in a group of three with a delay between so the SID can keep up.
33Fh 42 96 82 xx xx xx xx xx
delay 5-10 ms
33Fh 1 96 82 xx xx xx xx xx
delay 5-10 ms
33Fh 0 96 82 xx xx xx xx xx

33F byte 2 is then changed to 02 when I send the same text again.
If the text changes, byte 2 changes to 82 again.

Second example:
I get this in my 368 array
0: 0x23  <-- Both rows are occupied by ACC
1: 0xFF
2: 0x32

- Module is NOT allowed to write

Third example:
I get this in my 368 array
0: 0xFF  <-- Both rows free
1: 0x0F
2: 0x32

- Module is allowed to write.

ROW 1, byte 1, 0x0F is the text "CHECKING" / "CHECK OK" displayed in SID when turning on the ignition.

It's not 100% perfect, but my text "BLUETOOTH" is there 95% (some flickering is still there, timing issues?) of the time without f-ing up SID ( like my previous attempt just grabbing a node id out of my a$$ ).
I have not fully tested forcing other NODEs to send messages, but ACC gets through without any problems.

NODE IDs I have found so far:
Lower ID = lower priority to send text to SID, ie ACC overrides IHU. OpenSID overrrides everything.
0x12 = SPA
0x19 = IHU
0x21 = TRIONIC
0x23 = ACC
0x2D = TWICE
0x32 = OpenSID
0xFF = Nothing


0x348 = IHU_SID_TEXT_CONTROL
0x328 = IHU_SID_TEXT

0x358 = OPEN_SID_TEXT_CONTROL
0x33F = OPEN_SID_TEXT

0x357 = SPA_SID_TEXT_CONTROL
0x337 = SPA_SID_TEXT

0x356 = T7_SID_TEXT_CONTROL
0x338 = T7_SID_TEXT

Work in progress...
TODO:
Check that every NODE except IHU can take over the SID when needed.
Sort out timing so the text doesn't flicker.
Take control over both rows in SID to display Title/Artist etc.

[Da Bear]

I recorded a short video today showing that "it works".

https://youtu.be/mar2BgNtSYE

Also tried my SPA today and it works as it should with my code.

[Karlis]

Thumbs up! Great job, Bjorn! Any chance you want to integrate the code into 'main'? :)