Malicous RC Code?
 

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:

1) It's technically interesting :D
2) 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...

Re: Malicous RC Code?
 

I'm gonna find out now...

Thanks for the treasure hunt. :)

--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. :)

Re: Malicous RC Code?
 

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...

Re: Malicous RC Code?
 

Man Texan! You're quick on the draw! I hadn't even fixed my spelling mistakes and, BAM!, you'd replied :-)

I'm on vacation right now, but I REALLY want to look at the code all of the sudden!

Must... find... loophole...

Re: Malicous RC Code?
 

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 ;)

Re: Malicous RC Code?
 

Plus, not all computers require you to press the prgm button. If you can find out why, you can overcome that. :)

Re: Malicous RC Code?
 

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.

Re: Malicous RC Code?
 

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:

Re: Malicous RC Code?
 

But say you had a radio. You could set it to just scan all the channels that the radios could possibly be on. It isn't that many! :)

Re: Malicous RC Code?
 

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.

Re: Malicous RC Code?
 

It really comes down to the "Master Processor." Is that programmable? More importantly, is the code that drives it available?

Re: Malicous RC Code?
 

Hello,

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.

Re: Malicous RC Code?
 

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.

Re: Malicous RC Code?
 

That's only on some systems. In my case, if it doesn't work the first time it's having a bad day: try again. If it still doesn't work, check cables.

Re: Malicous RC Code?
 

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.

Re: Malicous RC Code?
 

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? :D

Re: Malicous RC Code?
 

Wouldn't an EMP bust the computers running the match? Just wondering: that would be a lot of field errors in a row.

Re: Malicous RC Code?
 

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 :) ...)

Re: Malicous RC Code?
 

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.

Re: Malicous RC Code?
 

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).

Re: Malicous RC Code?
 

If you could figure out the 'robot disable' message of competition control...... :ahh: :ahh: :ahh: :ahh:

Re: Malicous RC Code?
 

I hope you guys remember that these boards are read by LOTS of people in the FIRST community, many of them having very important roles. I'm not saying what you are trying to do is a bad idea, but if something does happen at a competetion, they will know exactly who to look for. :rolleyes:

Re: Malicous RC Code?
 

Not me, I'm sure...

Just in case it does, I was asleep. ;)

Re: Malicous RC Code?
 

Okay, time for a rant! :D
Anything I say after this point is not intended to offend anyone, yada yada, etc.

We should ALL be interested in "malicious code" and other "scary hacker things." If there is a vulnerability (and this goes for all complex systems) someone, somewhere, will find it. The responsible (and challenging/fun) thing to do is to hunt down the vulnerability and inform those responsible to make the world a more secure place. What you should not, under any circumstances do, is try to get your point across by releasing your code into the wild, to the detriment of the common good, to fuel your ego.

FIRST strives to be a microcosm of the engineering world. Security is a very real facet of any system, and if we really want to educate FIRSTers we should pay attention to this.

What really bothers me is that if someone does go out and release code similar to what I've described, I stand a good chance of taking heat for it.

This bothers me, because I've had something similar happen in school and if anything goes wrong on the network it's always "that uppity linux kid's fault." I remember one of my friends being carefully monitored while on the computer, simply because he hung around me a bit and liked to talk computers :rolleyes:

So then, when I get some spare time (see: Summer-Vacation) I plan to seriously look into this, because it would really [expletive deleted] hard to have a competition high-jacked by a few broadcast happy l33t kiddies.

End Rant. End Self-righteous indignation.

Re: Malicous RC Code?
 

Now you just need a small nuclear reaction :rolleyes:

Re: Malicous RC Code?
 

Nope. I have plans for an emp device sitting in my room. I didn't realize it until I actually read my book. Its not really that complicated but deadly if you don't know what you are doing.

Re: Malicous RC Code?
 

Small Soldiers anyone?

Seriously, you should go about the robot comms as a wireless network, if you can interfere with the data from OI to RC and impersonate it, with a stronger signal, you can very easily override another controller....in theory. As far as reprogramming it goes doesn't that button connect to a digital input? I bet you could find some way to trigger it if you dig deep enough in the code.

Re: Malicous RC Code?
 

I'm sure just garbling the signal is enough. Freaking someone out wouldn't be difficult. But there is a laptop that monitors com and such.

Re: Malicous RC Code?
 

They'll never find me!!!!!

Whoops. And by the way, I'm on your team if anyone asks. :)

Re: Malicous RC Code?
 

I JUST THOUGHT OF IT! :evil:

Find out the memory location of team number/channel/alliance info and change it at run time. MUAH HA HA HA!!!

Like, change it to 0 so you don't stop at the end.

Re: Malicous RC Code?
 

First off you could NOT do this at runtime because it is controlled by the Master processor not the user processor. The only way to do this would be to hack the Master processor code.

As for buffer overruns.... Not possible. First off, I'm sure packet/frame inetgrity is verified as this is a wireless protocol subject to corruption. Assuming you could get in malformed packets PICs CANNOT EXECUTE INSTRUCTIONS FROM DATA MEMORY. THEY HAVE A SEPERATE PROGRAM MEMORY. The most you would be able to do is crash the Master processor, and thats probably backed by a watchdog supervisor to restart it in the event of a crash anyway.

Re: Malicous RC Code?
 

Who said it spread like a virus? I thought of that under the assumption that the procs have shared memory. But if they don't, set EEPROM, wait 10 ms, and then have an electrical reset. ;) [The master proc will then reset to team number 0.]

Re: Malicous RC Code?
 

Simple... you short pins 6 and 8 on the competition port.

http://innovationfirst.com/FIRSTRobo...nout_Guide.PDF