Rolling-PWN Question

  • SpinRite v6.1 Release #3
    The 3rd release of SpinRite v6.1 is published and may be obtained by all SpinRite v6.0 owners at the SpinRite v6.1 Pre-Release page. (SpinRite will shortly be officially updated to v6.1 so this page will be renamed.) The primary new feature, and the reason for this release, was the discovery of memory problems in some systems that were affecting SpinRite's operation. So SpinRite now incorporates a built-in test of the system's memory. For the full story, please see this page in the "Pre-Release Announcements & Feedback" forum.
  • Be sure to checkout “Tips & Tricks”
    Dear Guest Visitor → Once you register and log-in please checkout the “Tips & Tricks” page for some very handy tips!

  • BootAble – FreeDOS boot testing freeware

    To obtain direct, low-level access to a system's mass storage drives, SpinRite runs under a GRC-customized version of FreeDOS which has been modified to add compatibility with all file systems. In order to run SpinRite it must first be possible to boot FreeDOS.

    GRC's “BootAble” freeware allows anyone to easily create BIOS-bootable media in order to workout and confirm the details of getting a machine to boot FreeDOS through a BIOS. Once the means of doing that has been determined, the media created by SpinRite can be booted and run in the same way.

    The participants here, who have taken the time to share their knowledge and experience, their successes and some frustrations with booting their computers into FreeDOS, have created a valuable knowledgebase which will benefit everyone who follows.

    You may click on the image to the right to obtain your own copy of BootAble. Then use the knowledge and experience documented here to boot your computer(s) into FreeDOS. And please do not hesitate to ask questions – nowhere else can better answers be found.

    (You may permanently close this reminder with the 'X' in the upper right.)


New member
Nov 15, 2020
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?
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.
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.
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.