No, Zwift Racing Wasn’t Hacked. Yet. Sorta. Let Me Explain.

In the computer security world there are a pile of conferences where security folks get together and present various sessions. I use ‘security folks’ as a loose term that can broadly cover everybody from IT professionals working for a non-profit like Red Cross, to government security peoples, to folks with less altruistic goals. These conferences have been around a while, and are generally considered good for the IT security community – assuming things like security bug disclosures are done properly (the concept of giving a company reasonable time to fix the bug before you talk about it).

One of the most well-known conferences from a lore standpoint is Def Con, but there are also many other huge ones such as BlackHat, SANS, and RSA, and other vendor-specific ones like BlueHat (run by Microsoft for Microsoft technologies) or government-specific ones. Again, in general the goal of these summits is to learn about security and improve security practices.

This past Sunday at Def Con (considered one of the more rambunctious events on the circuit) a presentation was given around Zwift and ‘hacking’ it – titled “Cheating in eSports: How to Cheat at Virtual Cycling Using USB Hacks”. Now one has to understand that while in the ‘mainstream’ the term ‘hacking’ is usually akin to ‘breaking’, in the computer world, the term ‘hacking’ is often a bit more nebulous. Sometimes used interchangeably with ‘tweaking’ or ‘optimizing’, and sometimes used in the less ideal variant such as ‘credit cards were hacked’. So one has to take any usage of that term with a bit of sanity check to see what’s going on.

In this case, the presentation was given by Brad Dixon (with support from Mike Zusman), security researchers with the consulting firm Carve Systems. This company has historically done penetration testing for other organizations (pen testing is trying to see if you can break into a system), but has switched in recent years to a more holistic security consulting approach where they do pen testing and then assist companies in making the fixes. More or less this is run of the mill security company stuff, nothing too crazy.

In this case though, two of the employees there are also avid cyclists and wanted to see where what they could do from a Zwift standpoint security-wise.

(Preemptive note: There are far easier ways to cheat at Zwift such as entering your weight or height incorrectly, or mis-calibrating your trainer. I’ve outlined them all in my past piece on the topic here in January. This post is focused on this specific security presentation.)

(Secondary note: There are now financial and career reasons to cheat in Zwift – including UCI sanctioned events, anyone telling themselves otherwise is thinking it’s still 2018. So we’re going to use the very real baseline that people are and will continue to cheat in Zwift where real stuff is on the line beyond bragging rights.)

(Tertiary note: This entire piece could be re-written without Zwift, and with ‘Bkool Racing’ instead. It applies equally. Minus the fact that nobody is actually using any of those platforms for major competitions. Thus when you’re the elephant in the room, it’s appropriate to still call you an elephant.)

(Quaternary note: What I discuss here is well-known in the trainer industry, this won’t surprise anyone. What it might do this is spur on developments to actually start securing this stuff, instead of just continuing to stick one’s head in the sand and think it won’t matter. If people are presenting Zwift hacks at Def Con, it’s time to actually address these issues. Nobody is better positioned than Zwift to do that.)

The ‘Hack’:

I had a chance last week before the conference to do a video conference with Brad and Mike and understand their presentation a bit more. We walked through the technology and where their ‘hack’ fit into things. I’m using the term ‘hack’ here in more of the ‘tweaking’ variant, than the ‘breaking’ side of things.

And in fact, one of the things they noted right at the top of the call was that when they started their research into Zwift they made the decision early on to “not screw people”, in Brad’s words. Specifically, that meant that they never competed in a Zwift race/event with the hack, nor did they save any rides. For clarity, this doesn’t minimize the effectiveness of it, it just simply means it didn’t meaningfully impact others.

Still, the obvious end-goal here is cheating in races. After all, that’s sorta the whole point. And in his presentation at Def Con, he points out what may be obvious to us, but might not be obvious to security researches in the room: “Cyclists are the best cheaters… Tom Brady should learn from these people”, and he goes on to discuss some of the history of cheating in cycling, be it doping or otherwise.

(Side note: It’s actually a fascinating part of the presentation with some crazy Tour de France cheats that have occurred over the last 100 years, it’s in the first few minutes in the YouTube video a bit further below).

And he’s right. It’s hard to come up with another sport where cheating (except perhaps bodybuilding) is as widespread and deeply engrained in over a century of athletics, at all event levels from major and minor competitions, and from pro to amateur. All with unrelenting mainstream media attention. Still, that’s beside the point.

What was their hack? They inserted code between the trainer/power meter and Zwift via USB, effectively boosting the power values that Zwift received.  Except, it was slightly more complex than that (and, also slightly less complex too). More specifically, they created a small device that you plug your normal ANT+ USB stick into (it’s off the shelf hardware with custom code atop it), which intercepts your ANT+ values and manipulates them with a tweaked value to Zwift on your computer:

(Note: All the slides/diagrams you see here are from their presentation)

So in effect, let’s take the most popular trainer out there and what they used for their demo: The Wahoo KICKR.

What they’ve done is inserted themselves in between Zwift and the KICKR, modifying those numbers before Zwift sees it. So let’s say you’re pedaling at 200w, what their little device does is tell Zwift that you’re really doing 220w, or 250w, or anything you want.

They’ve configured an Xbox controller to modify power, cadence, and heart rate. But they’ve also got simple scripts that do other actions. They showed two core ways to control their platform:

EPO Mode: Boosts your performance with a set multiplier
Slacker Mode: Automatically rides for you, and then fakes your HR and cadence based on terrain (so you can sit on the couch)

However, one of the biggest keys here is that the hack correctly replicates the source trainer from an appearances standpoint. Meaning, it looks exactly like a real legit Wahoo KICKR to Zwift. More specifically, this means that they re-passed all of the nuanced parameters of a KICKR, tweaking only the power metrics. That’s a core difference to using something as basic as the industry tool ANT+ simulator (used for testing by companies), which doesn’t really emulate something like a Wahoo KICKR or Tacx NEO – it just emulates a generic power device.

With their hack as is today, there are some requirements though:

A) Only works with Mac/PC (because USB), and not with Android/Apple TV/iOS (totally wireless, no ANT+)
B) You’ve gotta own the hardware, meaning it’s really only good for at-home events
C) Only applicable over ANT+

Now that last one might imply this is an ANT+ vulnerability. But it’s really more simplistic and could be achieved on both ANT+ or Bluetooth Smart. They just started with ANT+ because it was an easier starting point given how much of the code was already out there and developed. But technically speaking both protocols would operate the same way.

But there are also some challenges with the hack as well. As they noted, they didn’t use it in racing – because they didn’t want to mess with other people’s results.  That’s OK though, because we don’t need race performances to know where the hack breaks down a bit. It doesn’t do any of the following:

A) Doesn’t emulate a specific historical/past ride on the course
B) Doesn’t properly emulate the nuances of a human-driven power meter/trainer
C) Doesn’t correctly emulate the nuances of a human’s heart rate

When I say ‘nuances’, I mean that a human pedaling a power meter is constantly shifting their power by a few watts. No matter how perfect you think you are, you’re not actually pedaling exactly 250w every second. Instead, it’s roughly 248w, 253w, 247w, 250w, 255w, etc… (and that’d be a crazy precise person too). As such, algorithms from Zwift and 3rd party site Zwift Power (where results are tabulated) could more easily flag these efforts as they fail to appear like a human’s actual performance. Note that in EPO mode it would have the variability because it’s using your actual power as baseline.

So, in a nutshell, the hack presented as-is, is exclusively for use at home (where you control the environment), with a PC/Mac, and in a case where there might not be a ton of focus on your actual output numbers. Still, it’s a starter point. In the next section we’ll talk about where this goes from here.

However, if you’d like to watch the full presentation on YouTube, check it out below (it’s an audience recording, the official recordings aren’t up yet). Also, here’s their site with all the documentation details/etc

The Next Gen Hack:

Here’s the thing: In the grand scheme of hacks, this hack isn’t super impressive. Not yet. In fact, Keith Wakeham already outlined a more sophisticated hack in terms of resiliency to getting caught back in March. I asked Brad and Mike if they had seen it, and surprisingly they hadn’t. They noted they had started their research back in February before Keith’s video, and given that they came up with a fairly different solution – that seems pretty likely they didn’t know of Keith’s video. Speaking of which, here’s that video from Keith:

While both hacks seem similar – they’re actually fairly different. Specifically the following:

Keith’s hack is ANT+ based and doesn’t re-transmit anything from an existing trainer, but just acts as the sole source of data. Importantly though, it includes slight bits of variation to power/cadence/HR to more accurately emulate a human. He notes he has tried it in races and never triggered any sorts of cheating audits in place today.



Brad’s hack is ANT+ based but re-transmits existing hardware (trainers/power meters/etc…). It doesn’t include any human variability, but does more accurately replicate the source/original trainer – making it harder for Zwift to detect hardware anomalies.

But what lies ahead is more interesting, and useful. Brad says their next step is to convert over to Bluetooth Smart instead, which means that the entire setup is portable and easily moved to actual Zwift racing venues (such as what we saw here). Specifically, they could create a small bit of hardware that sits in a jersey, or even in a bag somewhere nearby. It wouldn’t matter – it’s all wireless.

Such a device would first connect to the trainer and take over the KICKR’s (or any other trainer’s) Bluetooth Smart connection. Because all of the trainers on the market today only transmit a single Bluetooth Smart connection, that takes away that connection and the trainer would disappear from Zwift (there are some nuances to this, but mostly trivial). But then a split second later the special device would rebroadcast the altered signal to Zwift. Because dropouts and such are totally normal in indoor trainer setups (especially if it were done pre-race), nobody would blink an eye.

At that point there’s a slew of ways the device could function. It could simply operate in the Digital EPO mode and boost your power slightly, just enough to give you an advantage. It would do so entirely silently in the background and nobody would ever know. Or, it could load a previous activity file (perhaps culled from Strava) and replicate that effort with slight tweaks to the power numbers. Seriously, the world is one’s oyster here.

So how does Zwift (or any other indoor trainer platform) protect against this? Well, they have to start taking it seriously.

Sure, Zwift has released their long policy document on cheating – but none of that would stop anything here. Not a single bit of it. Much of this isn’t entirely Zwift’s fault. For example, there’s no end to end encryption or authentication that occurs today from trainers to Zwift, atop via ANT+ or Bluetooth Smart. Just like there isn’t any atop power meters either.

If trainer companies were to implement some form of authorization or encryption (which both ANT+ & Bluetooth Smart already support), that would go a long way to stopping this particular man in the middle type cheat. Of course, that has a higher level of complexity for both trainer companies and app companies. And for the most part there isn’t actually great technical cooperation between Zwift and trainer companies, despite what these sides might say in public. While Zwift holds an annual conference for trainer companies each year at Eurobike, it doesn’t ever extend to technical working groups akin to what we see at the ANT+ Symposium (which Zwift doesn’t attend). Instead it’s more focused on larger business elements of the industry. And there’s nothing wrong with that either – it’s just there’s a gap to fill still.

Going forward:

In a lot of ways, it really comes down to whether or not Zwift believes esports and racing are the future of their platform. Everything they’ve said in the past 6-12 months says they deeply do believe that to be the case. They’ve spent more money than ever before on these efforts, with professional racing being the most heavily promoted aspect of Zwift in 2019, including UCI sanctioned events. They’ve also noted their aspirations to make this an Olympic sport by 2028.

Yes, it’s true that none of these are direct hacks against Zwift as a platform. But that’s sorta akin to saying “We didn’t have encryption on our banking website, so it’s not our fault someone stole your money”. That kind of security mindset stopped in the early 2000’s. Security extends beyond your direct premises, including the API’s that interact with it. In this case, Zwift’s API’s are effectively ANT+ and Bluetooth Smart, and the trainer and power meter companies on the other end. All of which easily fit into a single conference room at your local Holiday Inn (not even a ballroom required, mind you).

And of course, this isn’t just a Zwift issue – it’s an indoor trainer issue. At some point, other legit competitors to Zwift racing will come along (for real, they will, it’s only a matter of time). And they too will face these same underlying issues and attraction for cheating. While each year Zwift holds their Zwift Summit at Eurobike, a night later the rest of the indoor trainer industry (including every trainer manufacturer, many power meter companies, and major trainer apps) have historically also had a gathering, often to discuss more specific technical issues. Yet a few weeks later – everything from both events is mostly forgotten and nothing tangible happens till the next year.

Ultimately, the indoor trainer industry has to take itself seriously as an entity if it wants to be seen seriously by the likes of UCI and the Olympics. Otherwise, the result won’t likely be much different than other aspects of cycling: Full of cheating.

With that – thanks for racing…I mean, reading.

DC Rainmaker:

View Comments (58)

  • In the end, Zwift will have to have procedures much like UCI/WADA in order to prevent cheating for important events. Equipment inspections, random drug tests, automatically testing winners, etc., etc. Even that doesn't entirely prevent cheating in physical events where everyone is gathered at one place. If you wanted to cheat from home? Easy.

    The dongle isn't strictly necessary, is it? I'm not sure if Apple or Microsoft give you all the tools to do this, but between the place where the data enters the USB port and it's fed to the program that will transmit it to Zwift via TCP/IP surely you can manipulate the data? That would be completely invisible to any inspectors that might exist.

    • Yeah, Zwift has done a lot actually in the first paragraph you have, but most of it is athlete/protocol specific. Some of it ties into technology, like the rider not touching the trainer/etc.. Good first steps for sure, especially compared to back in January.

      But it all stops short of mitigating what I outlined in the 'Next Gen Hack' section, which frankly, isn't that hard. It would realistically take Brad or Keith or other minds a few days to port something into that realm, if they haven't already. Fine-tuning it? A little bit longer. But we're not talking months or years here. However, all of those attacks would be stopped dead with app to trainer authorization and encryption.

      And this isn't untested waters per se. Other connectivity modes on trainers have existed for a while actually. For example, Wahoo has a mode for their gym systems that allows ERG modes to be pre-programmed ahead of time on the KICKR, helping keep them in sync despite connectivity issues. It's certainly not encrypted or such, but it shows that trainer companies are doing unique things. There's even talk of a 'locked down' KICKR that can't be re-calibrated except with a PIN code.

      I don't think the dongle would be necessary per se, but it just makes it easier.

    • Hacking ANT+ is so easy, why bother? A simple Raspberry Pi script could win any Zwift race.
      Doing something better would be a compatibility nightmare. Someday maybe an authenticated secure connection but not on current gen hardware

  • "So how does Zwift (or any other indoor trainer platform) protect against this? Well, they have to start taking it seriously."

    Or just use ANT+ as most do anyway and see _all_ connections ¯\_(ツ)_/¯

    • I think he is referring to the comment about Bluetooth only connecting to one device at a time and then once connected to the device Zwift doesn't see it. ANT+ supports multiple devices therefore you wouldn't be able to hide the real power source.

  • there are already a good amount of "suspicious" performances (just check Zwiftpower power profiles in some "popular" events... cough cough Gcn ALPE cough cough..) from racings.
    6W/Kg for 30, 35 minutes (and indoor) are a good path for a (really) solid pro contract, not just for e-racing.
    The accidental overestimation/outlier can happen, btw.
    But constant over readings? mainly from bad quality (?) trainers* or lack of zeroing/calibration or even simpler and thus not "accidental" associations with an "inflated" PM **?
    These are more and -already- in use ways to cheat in e-racing.

    * I bet old/not upgraded Kickrs are in fashion in the top 25/50 "ranking"
    * A reason for which a double source data (e.g. PM+trainer), unfortunately, is not really a "transparency" tool.

    • Yup, I totally agree: The vast majority of cheating that occurs today is from crappy accuracy on trainers - old and new.

    • I agree that dual-recording of power is worthless in catching cheaters and I don't understand how it's suddenly becoming a thing.
      If you are cheating and boosting power from one source it is all to easy to also do it from another source or even just generate a second fit-file after the fact. It would be trivial to make a tool to do that.
      Some left crank-arm powermeters like 4iii even has a tool where you can decide how much extra the left measured power should be multiplied with (in case you have an inbalance in your legs).

  • Great post, never would have thought ANT+ would feature at DefCon!
    Trying to solve for ANT+ with online events will be tough. Perhaps someone could make an ANT+ stick that encrypted data before it passed over USB, and say only worked with Zwift software (locking 'trusted' users to Mac/PC) ... but then ANT+ becomes the next vector, and you need the sensors to actually use ANT+/BT encryption. Which hurts battery life & compatibility, and which manufacturer wants to wear that?
    Live events would be easier to protect (as noted) - could use ANT+ proximity search to scan for wireless middleman devices (like the magic UCI tablets!). And if a device was modifying the sensor/trainer signals, the original sensor will still be visible to a dedicated ANT+ detector running a background search (either as unconnected, or if they duplicate the device ID the original messages will still be visible).

    Your Bluetooth scenario will give me something to ponder. All I've got so far is a vague idea that (for a live event) it should be possible to externally observe nearby established BT connections with BT sniffers. Then it's down to sherlocking the source/destination & a whole lot of triangulation!
    Or just put the riders in a faraday cage :)

    • After some light Bluetooth spec reading, sniffing nearby active connections should provide enough info to defend from MITM devices. In a live/venue event you would know the BT Addresses for the venue receivers and the provided trainers. Any other athlete Power/HR sensors could get checked/registered (addresses are required to be printed on consumer devices I think?).
      Connection sniffing should be able to capture enough data over time to pick up the source & destination of enough packets to match against the known devices. Any packets that don't match either should indicate MITM devices if connected to known devices.
      One thing I'm guessing here is that all sensors & trainers use public/fixed BT addresses? Not like the random addresses iphones use when advertising?
      Another challenge is frequency hopping with lots of devices around. Would need a fair chunk of hardware power to give confidence of sniffing a spurious signal during an event - not possible/practical to snoop all the data, but enough to make detection likely.
      Something like this should cover the simpler attacks, hopefully limiting truely dedicated e-dopers into doing something uneconomic.

    • Yeah... not what I'm talking about. Yes these guys are going to do a proof of concept how a MITM could work over bluetooth. I'm far more interested in how the obvious vulnerabilities can be externally protected, making any nefarious devices easy to spot. I'm sure there are other possible expoits with open protocols like these.

  • Those nuances would be trivial to get around with some slightly more refined code in the dongle.

    Ultimately though (and thankfully), this is just some fun tech geekery rather than anything that properly threatens anyone.

  • Just a thought: If Zwift also recorded Di2 data, then the only way for the total picture to make sense would be if the EPO mode spoofed both power and cadence proportionally, right? And although different riders use different cadences, in the course of a race, I'd think it would be easy to spot someone who periodically spins out to a suspicious degree (because their cadence is being multiplied by 1.2 or whatever).

    • If I was to cheat in a live event, I'd knobble the better competitors, by lowering their performance. Then there would be nothing suspicious to detect about me.

  • I'm surprised this was something worth of a DefCon presentation TBH. It's actually relatively simple to do.

    I've played around with coding with Ant+ before, and technically it's trivial to setup a device with two Ant+ dongles (something like a Raspberry Pi) that listens to the values coming out of your PowerMeter or trainer, adjust them, and broadcast them using the other Ant+ dongle. The make Zwift read this output for power, and voilá

    "Faking" the trainer name is as simple as giving it whatever name you want too

    I've toyed with the idea of doing something like this to set a custom power offset curve to the values coming out of my trainer so that they match those coming out of my power meter. Then the two values would match more accurately, so I can rely on the same values indoor or outdoors.

    Alas, no time :-(

    * trivial & simple does not mean little work to get it done, just not hard

    • I felt the same reading about this. 2.5 years ago I was just getting started to use my spin bike after ignoring it for a long while. I heard about Zwift but had none of the hardware for it. I bought a cheap Wahoo BLE cadence and speed sensors but of course that wasn't enough for Zwift. So I simply wrote my own Bluetooth receiver and transmitter code that would connect with the speed sensor and I would set a relative difficulty setting from how far I had the spin bike knob set using a keyboard. That would make up a power value and I would transmit that over BLE where I had Zwift connect to. I was doing this to see if I would be interested in actually using Zwift, I wouldn't even have considered racing that way. I used it a few days and then got a bike and trainer that at least Zwift supported.

      Just a few months ago my 7 year old wanted to use Zwift with me and we have a Concept2 rower already. I had heard of people using Zwift with rowers so pieced together mostly existing code to read off USB from the rower to broadcast power and heartrate over ANT+. Same idea. The power numbers can easily be "tweaked" at this point.

      It never crossed my mind that maybe this was something that would be worth presenting at DefCon. I will admit though that their "hack" is much more polished than anything I did.

    • Same here, using my Daum 8008 using a serial 232 interface -> ant stick to send the data to a second ant stick receiving the data by zwift. Sounds strange but there is no official interface but ant and BLE...
      So for me a really nice way of using my old and trusted silent trainer!
      Cheating would be easy but what’s the point?
      I would even prefer a public supported interface, like that we won’t rely on zwift to support a given hardware...
      For official races there is no save way on own hardware - everything can be tweaked or simply use a motorcycle on the trainer :-)

    • Totally plausible once they decide which of the two last standing trainer companies they want to acquire.

    • There would be serious antitrust concerns with such an acquisition. Even creating a Zwift branded trainer with encryption could open them up to antitrust suits IF they don't allow other trainers access to the standard (that's called "tying," and SRAM successfully sued Shimano for doing it years ago). Doing the same thing with a merger is an even clearer no-no. If you have market power in one market, you're not allowed to use vertical mergers to extend your monopoly into another, previously competitive market. Example:

      European antitrust authorities are even more aggressive.

    • No real issues with anti-trust at this point, at least with acquisition. If they restricted it - perhaps, but that's more of a free-market thing, since it'd be no different than Peloton (who has a far larger user base).

      Knowing the actual numbers between Tacx/Elite/CycleOps/Wahoo (the big four), it's not as gap'd as one might think. Wahoo wins on revenue (due to higher unit price) and for 2018 unit volume, Tacx is 2nd, and then Elite. But Elite is selling a ton of units, just at a lower unit price. Then down the road a ways is CycleOps. After that you eventually get to Kinetic and others.

      All of these companies operate over FTMS and ANT+ today, and so all is pretty even. And at present, I don't think Zwift actually has the hardware technical leadership to pull this off without acquisition. Again, the question of whether post-acquisition they'd start to lock things down is different. There's a lot of love for the Peloton model, but there's also the reality that Zwift has already snagged all the low-hanging (and high-value) fruit.

      I think they realize that. Or, I hope they do anyway.

    • Free markets and antitrust are in constant tension. It would be pretty typical for an antitrust enforcement agency to require openness to other hardware as a condition of approving the acquisition.

      The difference with Peloton is that they started with that model from the ground up. The standard for stopping the unilateral business practices of a single firm is much more stringent (as it should be) than the standard for stopping (or more realistically putting conditions on) a merger.

  • What if the trainers (Tacx / Wahoo) sent a hashed code every few minutes confirming the data sent or let the API ping the trainer for an instant point-in-time validation check.

    • The hack would just send it's own hashed code that validates the fake ANT+ data it is sending zwift. Not sure what an "instant point-in-time validation check" is but why couldn't the hack just intercept that and respond how it wants as well?

  • I just hope that, if Zwift does add support for encryption, already-purchased trainers will receive updates to support it. But I’d worry the manufacturers used CPUs that were just powerful enough and no more, and thus won’t have the CPU bandwidth to apply fairly expensive encryption. If someone just spent $1200 on a trainer and in 6 months’ time their Zwift profile is missing some sort of “secure data” tick, that’d be pretty terrible.

    • I wouldn't expect such a task would add significant load to the CPU. I also wouldn't expect we'd see trainer companies go terribly far back either.

1 2 3

By continuing to browse the site you are agreeing to the use of cookies