Cheating - A potential issue with Open Source?

[LukeTheCoder64]

At the FTC Tech Open Forum at Words, dmssargent sated that, according FTC staff and others in authority, cheating would be an issue with Open Sourcing the FTC SDK. When I inquired about what kinds of cheating, dmssargent replied with..

The example given was modifying the Driver Status to provide feedback to the Robot Controller about where the robot was.

In my opinion, this argument given by FTC seems flawed for it is already illegal to modify the driver status during autonomous mode (there would be no need to do this in Teleop. It would be easier to just drive the robot) - see <GS1>.
Another option to find the position of the robot (with an Open SDK) would be to monitor the wifi direct signal strength of the driver station. However, it seems to me that finding where an object is located using only wifi signals would be a huge accomplishment for a group of high schoolers, not an illegal exploit.

So, what kind of cheating do they mean?

Luke

P.S. There are probably some other issues (*cough* legal *cough*) with Open sourcing the SDK, but I'd like to discuss cheating here.

[GearTicks]

At the FTC Tech Open Forum at Words, dmssargent sated that, according FTC staff and others in authority, cheating would be an issue with Open Sourcing the FTC SDK. When I inquired about what kinds of cheating, dmssargent replied with..


In my opinion, this argument given by FTC seems flawed for it is already illegal to modify the driver status during autonomous mode (there would be no need to do this in Teleop. It would be easier to just drive the robot) - see <GS1>.
Another option to find the position of the robot (with an Open SDK) would be to monitor the wifi direct signal strength of the driver station. However, it seems to me that finding where an object is located using only wifi signals would be a huge accomplishment for a group of high schoolers, not an illegal exploit.

So, what kind of cheating do they mean?

Luke

P.S. There are probably some other issues (*cough* legal *cough*) with Open sourcing the SDK, but I'd like to discuss cheating here.

Tom Eng sounded fairly open to open-sourcing the Robot Controller app, although there are still some legal difficulties, concerns about people messing up their version of the app, etc. Someone else asked about open-sourcing the Driver Station and it seems that is much less likely to occur. Cheating could be accomplished by connecting the Driver Station to the internet, using the phone's orientation sensors to control the robot by tilting the phone, attaching more input devices via USB, getting imagery from its camera, circumventing the match stop (for example, in order to move a servo that wouldn't be visible to the judges after the end of the match), etc.

[Cheer4FTC]

Someone else asked about open-sourcing the Driver Station and it seems that is much less likely to occur. Cheating could be accomplished by connecting the Driver Station to the internet, using the phone's orientation sensors to control the robot by tilting the phone, attaching more input devices via USB, getting imagery from its camera, circumventing the match stop (for example, in order to move a servo that wouldn't be visible to the judges after the end of the match), etc.

I would think that this type of cheating could be avoided by saying that Driver Station phones had to be flat on a table/platform (cameras down and up) during autonomous.

A worse form of cheating could be someone actually driving the robot during the autonomous period from the stands using another unseen driver station phone and app?

[Varun Singh]

I would think that this type of cheating could be avoided by saying that Driver Station phones had to be flat on a table/platform (cameras down and up) during autonomous.

A worse form of cheating could be someone actually driving the robot during the autonomous period from the stands using another unseen driver station phone and app?

This would be possible even without open source. But any sort of driver control during autonomous would be almost immediately recognized, just because it is extremely difficult to be exact.

[Philbot]

This would be possible even without open source. But any sort of driver control during autonomous would be almost immediately recognized, just because it is extremely difficult to be exact.

One possible issue with open sourcing the driver station code (with the ability to create custom versions) has to do with the intentional randomizing of Autonomous starts.

Right now, the way that the Auto period is randomized is that once the robots are setup, the field is randomized and the only allowed player interaction is a single click to start auto.
(ie: although not 100% foolproof, any attempt by a player to now tell the robot about the field is difficult, without being observed)

If teams were able to modify the driver station, it's quite possible that the "single click" to start could be modified to enable the driver to provide randomized field information to the robot as it is started.
eg: click on the left side of the screen to indicate goal was rotated left etc.

It seem to me that to enable customization of the Driver station would require the communications path, and game start sequences to be locked down, but that there would need to be a "game save" means to add custom display data.

This could possibly be achieved by providing a "user Fragment" (that can be modified) which only runs when teleop is active.

As an aside... it's also possible that poorly written code could cause various control and telemetry issues that would be impossible for the field personnel to debug.
eg: failures to connect that could be unrelated to radio issues.

BTW, this issue is not unique to FTC. The FRC Driver station for is ALSO locked down, even though all the rest of the Robot and Dashboard can be modified.

Phil.

[dmssargent]

Perhaps not opening up the entire Driver Station and maintaining a separate communications library that requires a significant amount of knowledge and time to reverse engineer could be used.

I am no security engineer, but the best solution I can see would be providing the DS app version, signing key, comm. library version, SHA512 of the app plus a salt over a TLSv1.2 session to RC with a PFS cipher to the RC to confirm the app is not a custom version (for actual competitions). The actual verification part could happen in JNI, with the various static parts (like the strings) being built on-the-fly, in heavily obfuscated code. In cases of suspected cheating the FTAs could mandate that the team's specific driver station and forcibly remove the team's DS version with the official FTC provided app. But take this with a grain of salt, since the entire protocol may end up being trivial to crack. If the team's results do not statistically significantly change with n number of rounds on probation (like a "yellow card" with a chance of the marker to nullify itself with certain requirements posed on the suspected team), with the FTA provided DS app, the team results count, if not treat it like an red card on the team.

The above would be assuming the Driver Station would be open-sourced and open to modifications, but the offical FTC DS app would be required for use at competitions. I don't how the cheating with a custom version of the Driver Station is different if the Driver Station is open-sourced, FIRST would just be lowering the bar to achieve the custom version.