This is a topic that has been attempted many times by many people, and never seems to get anywhere (except for one person who capitalized on his findings). If you work for Volvo or whoever developed VIDA, don’t be mad, I love your software like I love my car, and I just want to make it better. I’m not looking to make money on this, I simply believe that when you own a car you have the right to know how it works.

Now then, I’ve been tinkering with the Volvo can bus for a few years, picking it up, learning a little more, then putting it away to do other things. Thus far I’ve been able to log my own can bus, pick apart the various data, and build a small Arduino-based device that can pull various data and show it on an LCD screen for me. This is where most people stop, because sorting through that much data is difficult and very time consuming. The car sends hundreds and hundreds of messages every second, and there is no reference available to figure out which codes are coming from which devices. The method people have been using is to start the log, activate the device you want (fog light switch, window down, etc) a bunch of times, then sort through the log and hope you see something that matches up. From there you can pick apart the headers and data as per can bus standard specifications. Again, time consuming.

I had a bit of a different idea. the VIDA software is quite popular in the Volvo enthusiast community, since it has the ability to poll data and program parameters all over the car. Even though its clunky, difficult to make work, bloated, and proprietary, it contains all the information we need hidden somewhere deep inside.

So lets take a look at how VIDA works. It’s installed as a service and relies heavily on Microsoft SQL server. It’s pretty safe to say that all the juicy data in the program will be hidden in SQL databases. Luckily I am fluent in SQL so lets do some poking around…

Ahah! Inside the VIDA\db folder we have all the SQL database files. The MDF files are what contain all the data, but the VIDA SQL service has locked the files and marked them as unreadable by the user. Killing the VIDA service and then a simple trip to the Security tab in the Properties page lets me take ownership (and doesnt affect VIDAs operation at all so dont worry), and now I can browse them with any off-the-shelf SQL MDF browser or recovery program.

Now we are getting somewhere, the CarComRT_Data database is packed with information on various protocols, devices, timings, and a handy list of ECUs its able to communicate with. But, I’m not seeing any identifiers or commands, so lets look elsewhere. If you look in the DiagSwdlSession_Data database, it contains all the detailed information about your specific car if you’ve ever scanned it, from the VIN to a list of ECUs, fault codes, and more. Coincidentally, the VIN of the person who originally ripped this software is listed in here as well, from a scan made in 2006. Neat!

In the massive DiagSwdlRepository_Data database there are many many references to the various ECUs complete with a massive list of scripts that correspond to VIDAs reading, activations, and programming functions. I think we are getting close, but this program doesn’t let me extract binary data so, lets use something more powerful..

Alright now we can grab the binary data and discover what secrets lie beneath. It looks like a hex string, so I’ll run it through a hex decoder and see what happens.

Okay now this is getting good, like a treasure hunt. If that’s not a zip file, I don’t know what is.

And there is a single unknown file inside, considering the compression it’s probably text so let me check..

Yep, an XML file, I will run it through a markup cleaner to make it easier to read and…

Fascinating! We can see how the program matches scripts to various vehicles by model and year, which makes sense because of how many protocol variations there are. We also get to see the delicious identifier information! Finally! According to this script, to read the Steering Angle data, we have to perfom a “read-9” operation to get value “09” from ECU# “593101”.

The fun part is figuring out what all this means, which isn’t all that difficult now. By poking around the SQL database some more, I found that ECU 593101 is not something my car has, so this script is useless for me. This can be confirmed because “mdl384yr2005” (my car) isn’t listed in the script.

So how do we sort out only the scripts that apply to my car? Well thats only a little tricky but does require some programming. In the dbo.ScriptContent table there are 89,534 scripts. SIGH. Oh wait, each script is multiplied by 17 languages, so lets only select the language we want. Another table in the same database says 15 is english, so:

SELECT * FROM dbo.ScriptContent WHERE fkLanguage=15;

and now we have 5,271 scripts. Whoopee! Unfortunately we can’t filter them out further than this using SQL, because the data is compressed and converted to a hex string, so now it’s time to get creative. I exported the results of my last query to a CSV file, and wrote a simple VB.NET app to parse the CSV, convert the HEX string to binary data, write the binary data to a series of zip files, extract every file, rename the extracted files to their original titles, then parse all 5,271 files, deleting the ones that don’t match my car. In the end, I’m left with 714 compatible scripts (many of these scripts still wont work because they are further dependent on options which my car may not have).

Looking at a script called “Read Steering Angle Sensor” I can see it communicates with ECU# 645902 , to perform a read of value “0009”. According to my session database, ECU 645902 is the SAS (Steering Angle Sensor module) located at ECU address 50 (&H32)

Well this has been enlightening. A goldmine of information was sitting right here the whole time, now to sort through a few hundred scripts and note all the addresses and identifiers. Until next time…