Why Hacking XMLCrypto is Bad, Really Bad!!!

From the get-go, I've always avoided cracking XMLCrypto. Every time I see a discussion about hacking it, I always say leave it alone. To some people, that came across as protecting my vested interest. That can never be farther from the truth.

I've also been in discussion with a few people wanting to do their own solution, and they always focus on this one class: The XMLCrypto class. I don't blame them. I mean, this is the shortest way to their goal. I mentioned in one of my previous blogs that I looked at this and have almost considered doing exactly just that. But...my training and experience pushed me to find another way. And there's always another way. Working for a top tier security company, I've seen all this happen too often. Bad guys are always trying different things to spread harm. And I love my car too much to have to worry about this problem.

More and more solution are coming out and they're all centered on cracking XMLCrypto. There's one solution that is particularly bad. For one, this was based off of somebody else's work. For another, it entailed patching 3 class files. 3 Class Files!!! Seriously?!? If he knew what he was doing, he wouldn't be patching 3 files. If everyone had at least some sort of basic security training, they'd leave XMLCrypto alone. If everyone cares about their cars and their friend's cars as much as I do mine, they'd leave XMLCrypto alone.

So, why is it bad? For those who know E-Sys, you know that it is only part of a bigger solution. PSdZ (PSdZData) is what makes it work. All files in PSdZ are digitally signed, encrypted and some are even compressed. There's a reason for that. The very reason we digitally sign a document is to preserve its integrity and verify it's authenticity.  When you patch XMLCrypto, you take all that away. You dump the digital signature and accept everything blindly.

XMLCrypto is our last defense in verifying FA, FP, CAFD and everything else. It is our protection from tampered files. Think of it as the firewall of PSdZ. It only allows trusted and verifiable files.

Figure 1: XMLCrypto doing its job

Like I said, patching it takes away all these feature and benefits. It's akin to creating a wide hole in the firewall. Wait, not just a hole, but you're actually breaking down the entire defense wall. Why anyone would do it is well beyond me. It such a shame they don't understand this concept and the danger of doing such a thing.

Figure 2: Patched XMLCrypto Class

Proof of Concept: Download this file: Modified CAFD This is an CAFD, altered and repackaged. Unpatched E-Sys will never accept this CAFD file as it knows it's tampered and will never pass verification. But those with patched XMLCrypto will have no trouble using this file. In fact, the app will gladly accept anything you throw at it.

But what can a tampered CAFD do, you ask? CAFD is a file template which contains things like default values base on your Vehicle Order. Unfortunately, it also contains values for transport mode. What is "Transport Mode"? It's when your car needs a ride to the dealership because it wouldn't start on its own :).

Kidding aside, it is very easy to get these values and replace the ones used as default values, package and distribute it as "New" version of PSdZ. None would be the wiser, certainly, not your patched E-Sys.
 
This is why I didn't patch XMLCrypto. I hope everybody realizes this.