Seems like he should do the opposite, Only release versions with Mazda unsafe titles with a note "Doesn't work on Mazda. Contact their customer support here to complain"
It was the % in the show title that fouled up the Mazdas, so they were already doing that before the fix.
Even then it was a nearly invisible problem for the podcast itself, not something that would have been significant enough to investigate and correct for if that wasn't also content for the show.
The % sign broke mazda's infotainment system? That's really bad, I mean the % is even in the basic ascii character set. Unless they try to interpret titles as JS or HTML or something. That too would be bad.
You don't need to exploit it, at least you didn't before...
They used to autorun specifically named files on a USB stick.
Then some busybody journalists picked up on that and Mazda was forced to lock it down despite the fact that there is complete physical separation from safety systems, and that situations like this article are exactly where it helps.
Although I don't disagree with your thought here and that was actually the podcast host's/other contributor's original hunch too, this wasn't actually an issue with interpolation. I know it sounds bizarre, but the paraphrasing of the podcast hosts and comments from the infotainment system code author suggest that he was treating all strings as percent encoded[0] without any checks or guards in place. Since "% I" isn't a valid character reference, it chokes on it.
The % bug is a separate bug to do with a Podcasts's title, I suspect you just need a phone and an MP3 file with a suitably prepared title tag.
The original articles issue is a HD Radio (not DAB) issue to do with images, although it might still be a string parse issue of some kind as it apparently involves "image files with no extension", so presumably filenames? So the RF side can indeed be fun on consumer electronics with modern digital standards. Another example is this claimed RCE over DVB-T: https://twitter.com/David3141593/status/1481963959532011520
My understanding was that the implementation was protected by patents.
And can one call something a standard if the codec is not documented and needs to be reverse engineered?
Like I said, it's the protocol that is standardized. HD Radio as a whole is not, because of the codec. I think it's absolute BS that the FCC went down the path of a proprietary format, but it's the way things are. And the fact is, we do have at least one FOSS implementation. Since it's not DRM, I believe (but IANAL) that it's perfectly legal to reverse-engineer it.
I doubt Xperi really cares, since HD Radio is a trademark so it's not like you could build, sell and market an "HD Radio" device without licensing from them anyway.
You're sort of on the right track if you're familiar with URL/percent encoding, actually. I have no idea why, but paraphrased comments by the podcast hosts from the code author (they contacted him) suggest that he was attempting to decode all incoming strings as if they were percent encoded[0] without any failsafes in place. Since "% I" isn't a valid character reference (or even hexadecimal), it chokes on it.
That’s right. When a podcaster forces their stuff to not work on my car, I spend my time contacting the car company to get collective action through for change. I don’t hit the next button and listen to something else. This is how I and most other humans function.
