Malicous RC Code? [Archive]

phrontist

06-04-2004, 16:55

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

Ryan M.

06-04-2004, 16:56

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

dez250

06-04-2004, 16:59

phrontist

06-04-2004, 17:00

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

phrontist

06-04-2004, 17:02

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

Ryan M.

06-04-2004, 17:03

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 ;)Plus, not all computers require you to press the prgm button. If you can find out why, you can overcome that. :)

Bongle

06-04-2004, 17:06

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

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.

phrontist

06-04-2004, 17:08

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:

Ryan M.

06-04-2004, 17:09

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

phrontist

06-04-2004, 17:12

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

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.

phrontist

06-04-2004, 17:16

The new 2004 FRC Robot Controller (RC) takes the collected data from both the 2004 Operator Interface and the on-board sensors and then processes it using its internal microcontrollers. There are two Microchip 18F8520 PICmicro® microcontrollers inside the Robot Controller. The first is the Master processor which handles radio communications, generates most of the PWM output signals, and oversees the general operations of the Robot Controller. The second microcontrollers is the User processor, and is programmable by the user. The user’s program takes the input data, determines what to do with the outputs to make the robot behave as desired, and sets the PWM and Relay outputs to the appropriate states.

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

Venkatesh

06-04-2004, 17:17

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.

phrontist

06-04-2004, 17:27

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.

Astronouth7303

06-04-2004, 18:20

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

Astronouth7303

06-04-2004, 18:41

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.
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 really comes down to the "Master Processor." Is that programmable? More importantly, is the code that drives it available?
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:
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.Yes. It's RS-422. You make a spy cable similar to the one found on BeyondLogic.org (http://www.beyondlogic.org/protocolanalyser/protocolanalyser.htm).
I'm (fairly) certain it's impossible to get the actual code from the microcontroller.
From not For. Decompile the firmware and the libs.
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.
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.

The Lucas

07-04-2004, 01:23

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

Astronouth7303

07-04-2004, 11:29

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

golf_cart_john

07-04-2004, 22:13

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

Astronouth7303

08-04-2004, 12:52

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.

The Lucas

08-04-2004, 15:22

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

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

jdong

25-04-2004, 10:07

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

Tom Bottiglieri

25-04-2004, 10:22

Ryan M.

25-04-2004, 13:45

phrontist

25-04-2004, 14:08

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:

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.

Ryan F.

25-04-2004, 14:09

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

Now you just need a small nuclear reaction :rolleyes:

Adam Y.

25-04-2004, 14:13

Now you just need a small nuclear reaction
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.

Matt Krass

25-04-2004, 15:20

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

Astronouth7303

26-04-2004, 07:29

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.

Ryan M.

26-04-2004, 08:47

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.They'll never find me!!!!!

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

Astronouth7303

07-05-2004, 21:41

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.

Rickertsen2

26-08-2004, 21:35

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