Rolling-PWN Question

[Skiddywinks]

Hi all. Long-time listener, very part-time stalker, and basically no-time poster.

Just caught up with the last two weeks of SN last night, and I had a question about Rolling-PWN. I can't find the answer on the author's blog post, and a quick search of both these forums and the author's twitter does not come up with an answer. Hopefully, someone here knows the answer, or failing that hopefully this might spark some dicussion and speculation.

So my understanding of Rolling-PWN is that the attacker can resync the clock on the vehicle, allowing a previously captured command to be sent again (replay attack), despite the rolling codes being implemented explicitly to avoid this kind of attack.

The thing I don't follow, and for anyone reading this that is unaware of how these work, it is my understanding that rolling codes in vehicles have a window of x codes forward that the vehicle will accept. This is necessary since if an owner tries their fob when out of distance, and the car doesn't see it, the fob will cycle to the next code and the vehicle will not. Now you are permenantly locked out of wireless unlocking/anything else the codes control. So instead, the car allows any of the next, say, ten codes; once it sees one, it now only accepts the next ten codes from that code, and so on. This window allows for those cases where the owner might otherwise get locked out, but still provides the protection against replay attacks since no previously used code will ever be accepted again (unless it hapens to repeat, in which case I'd imagine the chances of that happening within the next window being vanishaly small).

So this attack allows an attacker to send codes to a vehicle which resets the window to some other, previous, state. This allows codes collected in the past to be used again. The thing I am unsure about, is the specifics of this windows reset. If this is a "feature" of the security system, I would expect the reset to return it to the beginning, in which case captured codes on anything but a brand spanking new car are going to be useless until the window encompasses those codes. So the only thing I can assume from this attack is that it is not a feature being exploited, but some very specific and frankly mind-boggling exploit that allows an attacker to somehow control where the resync returns to, allowing the immediate use of the codes again. However, I can't find any solid answers on these specifics, and it's really bugging me.

Does anyone know anything about this detail?

 

[PHolder]

Does anyone know anything about this detail?

They have explicitly withheld some information because they don't want to enable more attackers, but then there have been other people to independently verify the fault. I would assume it works like this: If the car hears the keyfob send a valid code, that is rolled forward, it will catch up to that point. If the car hears a great many replays of old codes, it will eventually enter into a mode whereby it assumes there's a problem and will reset to an initial code, which the fob can then send a code which is rolled forward, and the car accepts it and catches up again.

It's PROBABLY meant to make life easier for the car owner, in case something strange happens, they just keep pressing the button and eventually the problem fixes itself... saving a service call. If that's the case, it implies the the keyfob has a separate authentication stream from the rolling code stream, because you wouldn't assume that some one else's fob for a different car could do this. It has to be a fob the car has seen before.

If they designed it as I surmised above, they probably never even thought of a "record it and play it back over and over" attack.

 

[Ralph]

An interesting discussion. Now I'll have to think twice about continually pressing my key fob to locate my car in a parking lot. On past and present cars I've never had the unlock from key fob stop working due to too many presses, and there have been times I've done it a lot. I still like mechanical locks. Sure they can be picked, but the picker must be at the lock to do it, not driving by with a laptop in their car. My Jeep has one mechanical lock on the driver's door, but if opened with the key the alarm goes off. Both systems have their vulnerabilities.

 

[SeanBZA]

Been around for a while, in that it takes around 20 minutes to roll through the entire keyspace and repeat. Most of the chipsets default to keeping a copy of the last few hundred codes in RAM, and the next few hundred codes, and simply validate the code sequence as being part of this to be valid. Actually was a documented service procedure for when they lost sync, due to the transmitter fob being press while far out of range too much, and running out of the valid codes range, to simply have the remote near the vehicle, and press and hold for around 20 minutes, to roll back around to within the valid window, or to disconnect the battery, and wait 15 minutes for the battery bus to discharge, with the door open as a resistive load from the interior light, and connect up again. Then the remote unlock would synchronise with the transmitter again, after a minute or so of pressing and holding the button.