PHEV alarm can be switched off using hacked wifi [merged]

Mitsubishi Outlander PHEV Forum

Help Support Mitsubishi Outlander PHEV Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
Have to say that having read through all this stuff, my view remains that life's too short to get worked up about this or worry about it. I'm far more worried about some random idiot deciding to key the side of my car, or throw acid over it, than I am about some computer wizard going to all this hassle and trouble to disable the alarm on my car. If they really want to get into it then just smash a window and carry on while everyone else in the neighbourhood ignores the alarm and curses the owner for having a car in which the alarm keeps going off accidentally.

Even if the by the remotest possibility the car did get stolen then that's what I've got insurance for, right ?

Appreciate there is a theoretical technical gap here that has been proven by some IT nerd, but there are far more practical, real life things to worry about than this.
 
greendwarf said:
This is presumably a problem those of us down here in steerage with our Gx3s don't have. :D

The locking wheel nuts will see you straight sir! - as long as you cloak their IP address...

I have just been out and covered my PHEV in tin foil (doubling the bodywork thickness :p ) connected to an earthed stake, well watered. I have tweaked an old CB radio set to bleed radio waves all over and its jamming everything for miles, finally I built a low brick wall around on all 4 sides, hack that then!
 
neergh said:
For the past 4 days there has been a van parked outside my house, do I need to worry? :D

Only if it looks like this...

truck1_front.jpg
 
Going to leave my alarm off tonight just to catch the villains out. They'll spend their time hacking my alarm to turn it off when it's off already...take that dastardly wifi hackers!
 
Apparently, the factory alarm does exist in the Dutch models, but it is disbled. The biggest concern now is that bad guys may turn it on accidentally or purposely, leaving us with an active alarm that we cannot turn off :lol:
 
I've just returned from my annual pilgrimage to the Information Security show at (Kensington) Olympia. Pen Test Partners (the ones who discovered the problem) were there using Outlanders (they had two, one outside and one on their stand) to promote their business - they're well regarded in the industry and have some good people. I had a chance to talk with their sales bods and also their tech experts.

So, the fundamental problem is that the password for the WiFi (the one that's printed inside the owner's manual) isn't long enough to withstand a 'brute force' attack (i.e. using a computer to try every possible combination). A fast PC will take a couple of days to crack it, and they say they're building a specialist rig that will reduce that time substantially - if you're prepared to pay for a few thousand pounds of 'cloud' resources from Amazon, it could be cracked in a few minutes. You can then use WiFi from a laptop to do anything the phone app can do, including turning off the alarm. Their argument was that you could then put it onto a low loader without the alarm sounding - I guess we all know that it wouldn't be quite as simple as that without a key to unlock the parking brake, but I'm not trying to argue that there isn't a real problem that Mitsubishi should be concerned about.

The good news (for us owners) is that they're now working with Mitsubishi on a fix and they say they've been down there to test the revised software and pronounced it 'very good' - when we're likely to see it (presumably as an update to the app) I don't know. They're also looking at and talking to other manufacturers and I don't think Mitsubishi are the 'worst' (most concerning) example they've found.
 
I was going to visit the security show at Olympia, but someone has gone on holiday, so instead I'm doing phone support.
During the day, I saw bits of the video so many times on BBC news 24, but I didn't link the timing of this to the timing of the show.

I guess lots of their potential customers would be the sort of people who would qualify for a PHEV as a company car, and I guess PTP will now be remember much more than the stand with the pretty girlie giving out nicer carrier bags with leaflets in.


Some people call me an "I.T. nerd" others are not so polite.
so I've downloaded a Linux distribution that has a load of hacking and penetration testing software on, just so I can see if I can hack into my car, and see what, if anything else can be done.
I'm not going to be spending thousands of pounds on cloud cracking stuff, so I'm just going to use a spare i5 laptop that I was going to give to one of my children.

The wording of the PTP video, and the BBC one, and the one on the daily mail and transport evolved make it sound so easy.
If I can't break in after a month, or the new version comes out, then I recon it's not as bad as they make it sound.

I wonder how long until there is an update from Mitsubishi?
Perhaps we could get them to fix a few other things at the same time?
Like when you set the timer to pre-heat in the morning, and it is still plugged in, then top the battery back up if you are still inside the timing window instead of using the battery and starting the day with a couple of miles missing!
 
jaapv said:
The last bit is battery protection. Topping up when it is nearly fully charged will impact battery life.

Why do you think that is so?

I ask the question after many years of watching the charging characteristics of chargers used for admittedly much smaller battery packs for model aircraft but I believe the algorithms used much be pretty much the same irrespective of the size of the packs.

I would be surprised if any charge (other than the 80% capacity limited fast charge) is not a 'balanced' charge....that is the charging circuitry ensures that at the end of the charge all of the cells in the pack have the same or vey similar voltage.

in order to achieve this, when the charger is first connected and activate (by whatever means) it first analyses the battery pack condition including that of all the individual cells.

Charging will then progress according the findings from the previous exercise and if the entire pack is already (say) 80% full then charging will progress at a reduced rate compared with a pack that is 'empty' whilst the charging circuitry ensures that all of the cells in the pack arrive at roughly the same voltage when the pack is deemed to be fully charged.

I see from simply observing the behaviour of model charges that topping up, after initial analysis of the battery condition by the charger, results in very low charge rates when the battery pack is only partially discharged.

If the Outlander PHEV charging regime is less sophisticated than that of model vehicles I would be surprised and very disappointed.

I don't see what the problem is.

JimB
 
jaapv said:
The last bit is battery protection. Topping up when it is nearly fully charged will impact battery life.
Don't you think battery life is equally impacted when you top it up from a much lower SOC? I am familiar with the recommendation to not top it up when it is near full, but I have always believed it is a matter of "weighing the pros and cons": do you really want to hit it again, even when you are not going to gain much SOC?

Apart from that, it does top up the battery after pre heating. As long as you are not using the timer. I can hardly imagine they purposely choose to only protect the battery against top up damage only when the charge timer is on.
 
Maybe this is a bit besides the point, but what I do not understand is how one can speed up the cracking process by hiring computing power in the cloud.

I would think that the challenge is not so much with generating codes to try out (as unlike bank account numbers, any code that you can think of is valid) but with testing the codes you have generated. And for this, you need a WiFi radio in reach of the AP you want to crack and the AP itself .... So, the bottleneck is IMHO not the code generation process, but the Wifi radios and the AP itself. What am I missing?
 
anko said:
Maybe this is a bit besides the point, but what I do not understand is how one can speed up the cracking process by hiring computing power in the cloud.

I would think that the challenge is not so much with generating codes to try out (as unlike bank account numbers, any code that you can think of is valid) but with testing the codes you have generated. And for this, you need a WiFi radio in reach of the AP you want to crack and the AP itself .... So, the bottleneck is IMHO not the code generation process, but the Wifi radios and the AP itself. What am I missing?

As far as I am aware first the phone talking to the car is recorded via a sniffer. The cloud or whatever computing you wish to use then runs analysis to reverse engineer the passkey used for the WiFi. As the phone may connect arbitrary as soon as you enter the vehicle with the handset in your pocket, the sniffer can grab the info right then,

The reverse engineering can be done for pennies/free and practically instantly depending on the source of the computing power and how legitimately the computing was procured.

I would be very surprised if the car couldn't be unlocked and driven away via the appropriate WiFi command.
 
Okay, I think I get it. They grap the encrypted key sent by the phone and use brute force to find which (unencrypted) key generates that particular encrypted key. So, they don't need the AP to validate the generated key. Is that it?

But in that case, they first need to listen in on the traffic between the app and the car for every next car they want to hack. Right? I thought they were trying keys against the AP directly.

Also, I thought they listened in on the traffic, only to learn the protocol and command set.
 
anko said:
Okay, I think I get it. They grap the encrypted key sent by the phone and use brute force to find which (unencrypted) key generates that particular encrypted key. So, they don't need the AP to validate the generated key. Is that it?

But in that case, they first need to listen in on the traffic between the app and the car for every next car they want to hack. Right? I thought they were trying keys against the AP directly.

Also, I thought they listened in on the traffic, only to learn the protocol and command set.
Yes, as I understand it.

Hopefully the WIFI keys are different :lol: so yes a different key for each car.

You could easily automate the whole thing, grab key, send off to cracking computer, have the response and key back in a few seconds.

Thinking further you could potentially take control of the vehicle whilst it's being driven, accelerate, brake, reduce power assistance to the steering, shut off the car etc.

Yeah I'm leaving my WIFI off till they fix the issue.
 
SolarBoy said:
Thinking further you could potentially take control of the vehicle whilst it's being driven, accelerate, brake, reduce power assistance to the steering, shut off the car etc.
Have you looked at the electronics architecture of the car? The Wifi module is not connected to the CANBUS, but to the REMOTE ECU (which in turn is connected to the CANBUS). Chances are the WiFi module only allows you to do things that the REMOTE ECU was designed to do and nothing more. For the time being, and as far as we know, nobody has been able to do more than just that. Unless it was explicitly programmed to pass on CANBUS traffic, the REMOTE ECU would be a natural firewall.
 
Good question, the precedent was set by Jeep, https://blog.kaspersky.com/blackhat-jeep-cherokee-hack-explained/9493/

The 'air gap' between the wireless connection and the rest of the car was bypassed.

Sure it took the folks that found the Jeep issue ages to work it out, Mitsubishi have made it easier via the App which according to the chap on this forum has a ton of function available not implemented by the App's UI, so dead easy for an App developer to knock something up in a few days.
 
Back
Top