An interesting thought just occurred to me. I was thinking about the VCU regional, all those microcontrollers with radio links sitting around, and the (obvious?) issue came to mind. Would it be possible for a program to replicate via radio link, perhaps through some clever buffer overflow? I’m guessing the answer is no, but it’s worth looking in to because:
It’s technically interesting
You’d want to patch that before someone else has a similar thought :eek:
NOTE: Yes, I know this would be horrible, I don’t advocate this kind of thing. Yada, Yada, Yada…
–EDIT–
Or maybe not repicate like a virus. Maybe you could just imitate the OI radio (with a stronger signal, so that you override the real one) and make it appear that the OI is missing, effectively disabling the RC.
The FRC is designed to only download code via the prog port. Though i bet that there could be someway a program could be written to beable to download via radio link. Now the biggest issue is the manual control of a download. Prior to any code being able to be downloaded or stored into the memory, you must first manually press the program button, this activates the firmware for a download. So i do not know if it is possible to force a download via the radio link with people not knowing…
Ah but your missing the key idea here! You don’t NEED to download the code! You just need to find a point in the code at which you can overflow a buffer which would allow you to dump arbitrary machine code onto the stack. Thats the idea anyway
There was about a 50/50 split between times we had to press the program button, and times where we didn’t. Sometimes we’d just fire up the robot and IFI_LOADER, and the program would go, and sometimes we’d have to hit the program button first. I think the bigger problem is that the RC has its radio channel set in hardware with the little switches, so you wouldn’t be able to communicate with any other RC’s.
Is that REALLY set in hardware? I was under the impression that it was under code control, and that the code simply set it according to those DIP switches. That would be really easy to abuse. :ahh:
Yeah, the possibility of being able to screw up the RC’s via radio seems good, but it’s really not THAT horrible. What would be far more interesting would be if it actually spread from controller to controller.
To actually program the robot controller is a little bit complicated task. The processors are PICs and don’t lend themselves to easy programming. I would love to dissect one of these controllers to see how the programming circuit is wired.
This idea, to try and overrun a buffer in the RC to execute code, not a bad idea. It is a greater possibility. However think about the sequence for data from the radio. The PIC reads the output from the radio (very small packets) and splits it into even smaller packets. Fitting malicious code in tiny packets will be very difficult, at least.
I don’t remember if the PIC is a Harvard or von Neumann (sp?) system. However if it cannot execute stuff from the data parts of the processor, overflows will be very hard indeed.
Good luck with your experimenting.
However, I will stay away from u at competetion… =)
btw, the master processor is not normally programmable. And its code is not readily available. I have asked IFI before, and they have refuse, citing the possibility of ignoring competetion commands.
I figured they wouldn’t give that up, and thats probably a good thing. The question remains however, whether the “proprietary radio system,” could be reverse engineered. I’m (fairly) certain it’s impossible to get the actual code from the microcontroller.
That’s on the OI. The Controller scans radio channels until it finds one with its Team number (which is set when you tether it). After that, it stays on that channel.
It’s as programmable as the user proc. but it’s code is on non-volatile ram (Flash, eeprom, etc.). The code that runs it is the firmware update. So if you can decompile it, find a loop hole, and exploit it, you’ll be able to make the first FIRST virus! :yikes:
Yes. It’s RS-422. You make a spy cable similar to the one found on BeyondLogic.org.
From not For. Decompile the firmware and the libs.
Remember, the controllers themselves are from Microchip, not IFI. They are probably more forthcoming on info than IFI is.
Of course, the packets are continuous, so it delimits them. This nature makes it very dificult to create a buffer overflow.
And above all, if they catch you, you didn’t hear it from me.
I believe if you have a programming link (IE serial cable in prog port connected to laptop) to the RC at power-up you don’t need to press the program button.
The old Pbasic controller had these modems (EWave Stampers) you could buy to debug and program the robot remotely (very useful, cut debug time in half). I could not get them to work on this year’s RC (but they possibly could be modified to work). Maybe Ewave will develop new modems for the PIC RC in the future. If you were to plant the modem on a robot (well a 2003 bot) then you could program it from the stands to do a dance or whatever (would make an interesting practice round).
As for this year, small device could handshake with the program port on power-up and then download the machine code for the aforementioned “Dance Program” from an EEPROM in the device. Now there is an offseason project for you
Disclaimer: I am just kidding and tossing ideas around (like hopefully everyone on this thread). Actually reprogamming a competitor’s robot maliciously during a match would probably be the worst violation of Gracious Professionalism in FIRST History. However, it is fun to joke about these things. Come on, Who hasn’t proposed an EMP burst bot or Tesla coil bot during Brainstroming?
Earlier this year, I asked a guy from IFI about setting the radio channel. He said you can do it with the little switches OR by using some serial-ish thingummy through the competition port. So, your code probably can’t affect the channel unless it convinces a human to plug something into the competition port. The RC must still control its channel, though.
You might be able to do viral stuff by changing the team number and/or the backup battery behavior. Many people forget to reset their RCs after turning the robot off, letting it run on backup power. If you could change the firmware, you could have the RC use the radio while the robot is truned off. Then, you could scan channels and team numbers to establish contact with another robot.
Don’t forget, this is entirely for your own entertainment. You’d better not actually use it at a competition (well, not at mine, at any rate …)
If you could find a way to do buffer overflow, you could change the firmware. But since buffer overflow is based on a terminating character, not likely.
Yes it would. That was a counter arguement. One would have to tweak the power of the burst to only affect things in a yard radius (it would take tremendous amount of power just for this) and deploy it when you bump another bot. Also, one would need to shield the electronics on one’s own bot (or temporarily turn them off like in Broken Arrow).
