Kompatibilität und Informations System (KIS) Advanced Table Viewer

A great member of the BMW Coding community (SS :)) asked me a while back if I can write a KIS table viewer. It took me awhile what with all the retrofit activities I've been doing, but finally, I found a good library to utilize. And the result: KIS Advanced Table Viewer:

KIS is part of E-Sys and is runnning in the background. E-Sys reads and load all KIS database on start up -and this is probably why E-Sys frequently runs out of memory at its default configuration. The HyperSQL code and GUI is based off of umpakba's work. It's heavily modified to make KIS work, however.

While the tool is free, I don't think it's for everybody. KIS database contains some great information, but only if you make sense of it. Otherwise, it's pretty useless.

The tool is free, but I'm not making it available to the general public. HMU if you want it, but let me know how you're going to use it :)

EDIT: 12/14/2014
I can now share this publicly: KISATV

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.

Random Musing #1

#1: Dog eats Dog...

So, in one of my earlier blog, I pointed out a guy selling tokens. This guy generates his own token, BUT, uses patched files from the original developer. What this guy did is reversed-engineered the solution and started generating his own token, then sells them. Geez, what a rip off

And I didn't think it would get worse!!! So, another guy bought a token from then first developer. He then again reversed-engineered this, "created patches" and pass it on as his own. D'uh. And this is actually worse. The first developer, uses 2 patched files, the new guy patches 3. This tells me he didn't really know what he's doing and just patches things left and right. VERY dangerous

...And it gets worse still!!! I learned of a guy who got a token from me, and is now selling token too, derived from the third guy. Next thing you know, he'll mix and match solution, ending up with a FrankenToken lol.

See, these guys bit the hands that fed them. Keep doing that and the hands will eventually stop feeding. These guys chose to ripped people off. We're not exactly saints, but I spent a lot of time developing my original solution without looking at others work. I came up with a patchless solution because I not only studied the software, but the platform which it was built on. I was very careful in my method and made sure the app remained true for whatever it is designed to do.

Dog eats dog, pirates pirating the hackers. Back in the days, these never happened and we had code. We had respect for each others work. We collaborated when we needed something from each other and not rip each other.

#2: 3.22.x ~ 3.24.x is defeated

As most already know, I came up with the first ever patchless solution, but not only it is patchless, it's multi-version as well. The same 20kb file, the same token can be use from version 3.22.x up to and including 3.24.3, or whatever the latest version is on the 3.24 series.

So, this is no news anymore, time to move on

But then...came 3.25.x!!!

#3: 3.25

3.25 came out last year. It was almost redesigned, security-wise. I can almost say, the only change that was implemented was everything about the security. I can't say whether it was the programmer's decision or that of the Architect's, but if I was the PM, I'd be majorly pissed at the direction it went. It added no value, and only caused problem.

3.25.2 would not even FDL code!!! But guess what? I made it run and coded my car. 3.25.3 fixed the issue with FDL coding, but the UI bug remained. The software as a whole is solid, and I give props to the whole development team. It's just that 3.25 shouldn't have went where it did.

3.25 series was a pain. And let me tell you that I spent more time analyzing it than I did on the previous versions. And this is me armed with previous knowledge. It was hard and I almost doubted whether it can be done or not.

And that, folks, is why you don't trust pirates! These guys are selling it for cheap, and why not? They didn't have to do anything. But then, ask them if they can support you, or if you can get upgrade.

#4: Unbeatable?

With the amount of time and effort it took to beat 3.25.x, it's not too far off to think that eventually, we'll be faced with an unbeatable software. This is when the hand stops feeding, the hand will stop giving. Instead of a software that costs few pennies, we'll all end up with a software that is pretty much out of everyone's reach, including mine. And we'll all have the pirates to thank for.