[robocode-developers] How secure is robocode?

[casperjeff]

(sorry that I cross posted this to the sourceforge forum as well...I
determined later that this was probably a better place to post)

My buddy and I are about to throw-down in an epic bot versus bot
battle. There is a little money, bragging rights, first born child,
and some sort of cheese snack hanging in the balance. My buddy is a
smart guy...has even done some JVM hacking in the past. How secure is
robocode against 'trickery'? (note that the battle will be running on
a box I control)

Cross-thread interference?
Class-loading/overriding wackiness?
CPU/memory hogging?
Anything else?

Any information would be appreciated....because that cheese snack is
looking pretty good.

[Pavel Savara]

We tried hard to make it as secure as possible.
It's not just for fun/cheating, but security of our users agains
malware.

> Cross-thread interference?
Robot's can't touch each other instances.
Of same robot, possibly, but I can't imagine how you could elevate
your rights this way.

> Class-loading/overriding wackiness?
Each robot has separate custom/secured classloader, rest of it is as
safe as your JRE.

> CPU/memory hogging?
There is no memory limit per robot, so one could eat it all and whole
process will be getting outofmemory exception.
This is not win strategy I think.

> Anything else?
We are not aware of anything else.
I you or he manage to find security hole, we would appreciate bug
report.

Cheers
Pavel

[Patrick Cupka]

>> Cross-thread interference?
> Robot's can't touch each other instances.
> Of same robot, possibly, but I can't imagine how you could elevate
> your rights this way.

If you use multiple threads in your bots, the extra threads are not
(or in the past, weren't) tracked as far as a bot's CPU time goes. So,
theoretically, you could use an alternate thread to hog CPU during the
opponent's turn and make them skip turns. I'm not aware of anyone ever
doing this, but it has been a point during discussions on the ethics
of multi-threading.

If security is disabled, there's all sorts of things you could do. But
if you control the box/installation, that stuff is moot.

Probably the single easiest way to cheat would be to take code from an
existing bot. Lots of bots (including the top bots in Melee and 1v1)
in the RoboRumble (darkcanuck.net/rumble, robowiki.net?RoboRumble) are
open source.

-Voidious

--
Patrick Cupka, pcu...@gmail.com
http://www.dijitari.com/void
--

[casperjeff]

On May 12, 8:25 am, Patrick Cupka <pcu...@gmail.com> wrote:

> If you use multiple threads in your bots, the extra threads are not
> (or in the past, weren't) tracked as far as a bot's CPU time goes. So,
> theoretically, you could use an alternate thread to hog CPU during the
> opponent's turn and make them skip turns. I'm not aware of anyone ever
> doing this, but it has been a point during discussions on the ethics
> of multi-threading.

This was actually one of the things I was concerned about. I don't
know enough about robocode internals to know how it enforces the
current cpu limits....but from a quick glance at the code it simply
enforced turn skipping if responses aren't timely. Robot threads (and
sub threads) aren't really 'suspended' between 'ticks' are they?

[Flemming N. Larsen]

Hi Jeff,

Robocode is not able to directly put a limit on the CPU usage for the
thread.
A robot runs in its own thread in the JVM. When a robot executes all pending
commands, it is automatically put into sleep. In the battle main loop,
Robocode checks if all robots are in sleep after some time. This time is
controlled by the "CPU constant", which is calculated/benchmarked to take
the processing power and OS into account. If the robot is not in sleep after
"CPU constant" time, it will skip a turn. This means that the robot has not
been called execute() within the time limit. When the robot has skipped too
many turns, it is banned from the battle, i.e. punished, and it will get 0
score.

In the future, we might introduce a mechanism to measure the exact CPU time
used be a robot. The same goes for the memory usage. But currently, the CPU
usage is updated with huge time intervals (e.g. 10-20 milliseconds on
Windows), which means that e.g. 50-200 turns could have taken place before
we receive a new update for the exact CPU usage by the individual thread.
This is too coarse for Robocode (we need the thread-cpu-usage update for
each turn/tick). Hence, the way we do it now is still the best approach for
us. Regarding monitoring memory usage, there is no way to measure this with
the individual thread - currently.

Regards,
- Flemming

-----Oprindelig meddelelse-----
Fra: robocode-...@googlegroups.com
[mailto:robocode-...@googlegroups.com] På vegne af casperjeff
Sendt: 12. maj 2010 18:08
Til: robocode-developers
Emne: [robocode-developers] Re: How secure is robocode?

[Alex Schultz]

Hi Jeff,

Beyond what has already been stated, I'd like to quickly note my
perspective on the issue of fairness of competition:

The aspects that Robocode currently can't control (CPU use of threads,
and memory usage), can only really break the bounds of fairness in a
pretty blatent way, that leaves very clear signs and is of no harm to
the host system.

Like was mentioned by Patrick, there is the issue of copying bots from
other people. My view is that if one has enough reason to be confident
in the bot's originality, then one surely has enough evidence that the
bot isn't abusing threading or memory. I say that because it's just so
much easier to spot the effects of threading/memory abuse, than it is
to verify origionality.

Alex