Cheating at Seti@home

Megor writes "Well it was bound to happen, people are cheating on Seti@home to inflate their work unit statistics, and the people who administer Seti are ignoring the complaints. ZDNET has an article explaining how they are cheating."

Wasn't cheating to be "impossible" ?

[holle2]

I thought the move to close the source of SETI@home back in the old days was meant to stop the cheating ?
Could it be that the protocol should be redesigned to contain, say digital signaures embedded into the binary (well not really a save place for that anyway ..)

Join Team Lamb Chop?

[LordKronos]

With SETI@Home, if you arean't already part of a team, can't you join a team and give them credit for all of your previously completed work units? With the project coming to a close, maybe we could all join Team Lamb Chop and give them a boost to keep them ahead of these cheaters.

Re:Wasn't cheating to be "impossible" ?

[Enocasiones]

M$ products & others' are closed and look at all the "cheats" (exploits) you can use on them. You cant stop the cheating through obscurity, as the linked page [distributed.net] in the First Post states.

Our experiences from running the rc5-56 challenge

[jukal]

run at cyberian.org [cyberian.org] some 4 years ago was that people will do anything to get their team/name listed in the first page of the statistics. Some of the people were even arrested by police for hacking into machines to make them crunch rc5 for their name. And it seems this trend is only getting worse. This is kind of sad, because it is not very good for the reputation of such efforts.

Google Toolbar version.

[hopbine]

I havent seen any /. comments about the Google version of this. My office computer runs IE and has a Google toolbar. The other day it downloaded a trial version of combined computing, in this case the computing was to be on behalf of the "Folding@Home Distributed Computing" I wonder if Google will be hacked.

Re:Wasn't cheating to be "impossible" ?

[ebbomega]

If anything, closing source opens you up to "cheats" because every time that an exploit/cheat comes up, you don't have OpenSource-support to fix it sooner rather than later.

Closing source isn't like sealing a tank. It's more like building a beaver-dam.

Re:This can't be that big of a problem

[terraformer]

Fair enough on the corruption point. I understand however, the position of the admins who are near the end of the project and have very few resources left. Although the overwhelming support they have received from the public for their work is a blessing, it has been a curse too. The more users they got, the more money they had to spend to support them (although cost per user has probably gone down). I would not be surprised that the whole project is being run by Grad students right now and the university would probably lend support for any big catastrophes should they occur.

They are probably unable to cope at this point, so near the end, to deal with it real time. There is nothing to prevent them from going in later to adjust and obviously, any published work based on the project will have to deal with the issue. As for the future, you have a point that the public at large may take exception with this and feel any future work is comprimised but people tend to have short memories.

I would imagine that the Seti@HomeII project will deal with this issue as they are going to need to distribute new software anyway. They could easily come up with a mechanism similar to that used by software publishers who tie their registration id to the hardware. This way the work units can't be transferred from machine to machine. I just can't see them pulling this off in the next few months.

Re:SETI Checking?

[phragle]

from the seti FAQ http://setifaq.org/faq.txt 2.4 I heard I was getting the same work unit as everyone else. Is the program wasting my time? Nope, because the only time you're giving it is time your computer would have wasted anyway. Yes, early in the program there were times when the same work units went out over and over, due to overloading of the SETI@home servers that were supposed to be making new ones to send out. (They didn't expect half a million people to sign up, and they don't have enough staff or computing power to keep up with it.) And since then, the same work units are still sent out to several people, for various reasons (for instance, more than half the people who signed up have never returned their work units, and probably dropped out) But new work units are being sent out too, so just leave your SETI@home program working and it'll take care of the details. Note: If workunits are sent out multiple times, they can be doublechecked by SETI@home.

Re:Wasn't cheating to be "impossible" ?

[anshil]

Closing the source does not help a bit. After all you give a binary to your "foe", thats enough. Look in example to Ultima Online, they encrypt the stream already in 10 layers or so, with constant changing keys, algorithmns and so on. But it is still beeing hacked, simple as that, you've a binary of the client, you can view the algorithmn on assembler basis, thats enough "source" code to hack anything assuming enough motivation and time.

Look at all the companies trying to hinder people copying with copy protection CD's, tongels and all that. Does it help? No it's all just a new challange for the hacker folk.

Ironcly

[isorox]

I'm researching seti for a final year comp sci project, and I've just handed in a draft about how its been secure, but how my distributed foobar will be open, and therfore more secure.

(dunno how to make it secure yet though)

Cheating is a big thing, as you can sell your work units on ebay!

500 units @ 25 euros [ebay.co.uk]
and http://cgi.ebay.co.uk/ws/eBayISAPI.dll?ViewItem&it em=2064169353 and
http://cgi.ebay.co.uk/ws/eBayISAPI.dll?ViewItem& it em=2064990327

Ramifications for other distributed projects?

[Sherloqq]

I wonder how this will affect other distributed projects, such as the cancer search.
Apparently any time there is a prize involved, people are willing to forgo their ethics
and the ulterior goals in favor of money. What would happen if this sort of cheating were
uncovered in the cancer project? Will it undermine its reputation and credibility, even
if only the stats were to have been sabotaged and not the results themselves? I'm sure
that people would start peeping "Well, we can't trust those results now, can we?" And all
those CPU cycles would have been wasted, after all.

Re:Ahem.

[IIRCAFAIKIANAL]

What happens if there really was something found, but due to the high rate of contamination that it was thought to be too good to be true and discarded. Consequences really need to be thought out before you start wrecking the hardwork of scientists and academics who are only doing a service for everyone's benefit.

Not that I disagree with you overall, but if they thought they found something but the results were contaminated, they would just reprocess them. Now, what we should worry about is something being overlooked...

They (SETI@Home) could fix this easily

[fudgefactor7]

Simply by refusing more than 4 WU a day per person. (6 hours for a 1Ghz PC to do one unit x 4 units = 24 hours.) Add to this if a single unit appears to have been submitted more than, say, 3 times, it will be "suspect" and resent out to be checked and you (the original submitter) will only get credit for it once it passes this second level.

Re:SETI Checking?

[Coplan]

Simple solution...

Seti should track what it hands out (and I'm sure it probably does). In fact, it should probably track to who it sends it (again, it probably does).

If Seti sends out 30 WUs (abroad), it should know that if it gets 200 back, a flag should be sent up. If seti sends a WU to Bob, but not to Gregg, and Gregg sends THAT WU back, the one returned from Gregg should be voided.

This is not about preventing competition. Screw that...Seti shouldn't be concerned about this issue relative to that. Seti's concern should be plain and simple -- it should be protecting the integrity of the data. 'Nuff Said.

Another Problem With Cheaters

[Tremblay99]

A while back, S@H was having so many bogus results sent in (and work units sent out to cheaters), Berkeley massively scaled back the bandwidth alloted to the project. The result was that people who didn't cheat and weren't compulsive users (people with caches / willing to retry their connections all day) couldn't get new work units. One of S@H's responses was to make the clients do more math, effectively slowing the clients down. The other was to close down some of the cheating loopholes.

It's unfortunate that the stats helped make the project so popular ... since they also made it a target for people needing to inflate their numbers at any cost.

Re:They (SETI@Home) could fix this easily

[fudgefactor7]

Ok, modify the above. Each SETI@Home install has a serial number, each computer has a different SN for it...then each computer can do no more than 4 WU a day. With that, you'd still be putting out the major numbers. (Nice going...!)

Re:They (SETI@Home) could fix this easily

[dfeist]

But my computers do 8... and they aren't the fastest you can get.
And additionally, this would do nothing to one of the points the article mentioned, where one unit is only processed once but submitted for different accounts.

SETI's a scam. Always was. So?

[Anonymous Coward]

SETI's a joke, a simple machine whose optimum output is funding.

They keep changing the rules: "If we do this, we'll find LIFE!" Then they don't find life. "Oh, wait, no, we'll do THIS -- and THEN we'll find LIFE!" Again, they don't find life. And so on, and so on.

The money fountain is based on the fact that you can't prove that there isn't life out there, somwhere. It's very hard to prove that something doesn't exist. Therefore, these witch doctors at SETI just keep on mixing new and different potions every year and charging the taxpayer an arm and a leg for it all.

What's worst is not the waste of money, but the violence done to the scientific method. Have you seen their calculations about the alleged "probability" of intelligent live existing somewhere else coincident with what passes for intelligent life on Earth? They've got these very serious-looking equations with variables and stuff, but the numbers they plug into the variables are all made up. They just pull numbers out of their asses! Who the hell knows how many Earth-like planets there are orbiting around G-type stars? NOBODY. We have exactly one (1) example to work from, and you can't generalize meaningfully from that. Who the hell knows how long the average radio-equipped civilization lasts before it blows itself up or transforms itself into energy beings and vanishes up its own etheric asshole? NOBODY. We have ONE example, which hasn't exploded or vanished yet, but who knows when or if it will? And what does that tell us about anything else? Nothing. If my dog gets hit by a car at age five, do I go and say, "Okay, that's how long dogs live: Five years. Now, given an arbitrarily assumed distribution of dogs on each of an arbitrarily assumed number of lawns in an arbitrarily assumed number of towns, we can calculate with meaningful precision that blah blah blah..."

No. Wrong. Dead wrong. You can't calculate squat from what we know about any of the stuff SETI is yapping about, because we know nothing about any of it. Making up an equation doesn't make it science. If you feed real data (we don't have any) into the equation and then compare the output to the real world phenomenon that it's supposed to model (about which we know nothing, in this case) and it matches up, then you know what you've got? You've got a hell of a lot more testing to do before you publish any conclusions, is what you've got, but at least you've got something meaningful. Nothing that SETI is doing is in any way falsifiable. The question they're asking isn't even clearly defined. It's not science. Period. It's an open-ended money pit.

Re:Wasn't cheating to be "impossible" ?

[bogado]

In fact this is a hard problem to solve, since you have to trust the computations made on the client side. Every security protocol must not trust the client! The solution in this case would be punishing the guilt.

My opinion is that each login should have a key, this key would sign all the packects received from this particular login. Now for every X packects received from any client, you resend one of them to another user, of there is a mismatch in the packet You then redo the calculation with your trusted code, and checkout witch is cheating and then ban this user.

Since cheating is for achieving higher pontuation, no one would like to be banned, since this would mean that one would have to restart their statisics. Groups could also be punished if one of their members is cheating making them also responsible for their components. This would help to police the network.

The key I proposed is for guaranty that a good user could not be sobotaged by other people sending packets in his name. Also one couls adopt a policy of sending more test packects to user with higher, more suspicious, rates of delivery.

Re:Wasn't cheating to be "impossible" ?

[ComputerSlicer23]

This system opens up the can of worms for a DOS. Basically, if a given user can overflow the request for a new public key, so no one can request one, because he keeps the machine that is storing them too busy. The other alternative, is "checking bad blocks" is on trusted code doesn't scale with the size of the project. Now cheaters can turn the "checking bad blocks" into a bottleneck by submitting all bad blocks immediatly for you to have to check. Eventually the back log on check the bad blocks will be too difficult.

They also address this in the article if the cheaters can manipulate the system enough to ensure they get the same block twice and send it in twice they win. Plus 99% of all blocks have the same answer: Nope, no interesting data here. That's it. So a cheater just has to send in "Nothing of interest here", for 100K blocks, then request a new public key and do that again. They could wipe out huge chunks of the key space because eventually they will get verified as correct.

When you give source to anyone to run on their machine, you can't ever trust the results.

Kirby

Take out the Game

[_KhlER3L]

If S@H didn't make it into a big race, people wouldn't be cheating. Give them a motivation, a simple numbers game, and they will, and have, to the detriment of the project.

Technical solutions such as adding hashes of this or encrypted that's will not tackle the root source of the problem: the game playing people themselves.

A solution I think might work would be to make WU statistics viewable only by the producer himself. Everybody wants to know what he or she has done, but compiling the data for an entire work group, much less all work groups, would be next to impossible. Without 'meaningful' ranking data, game players would have to find some other way to please themselves.

khl

Re:Wasn't cheating to be "impossible" ?

[ComputerSlicer23]

Okay, your right, I'd just gotten done reading another link from the posts, there is one from distributed.net that discussed all this, and actually was much more interesting then the original link. They talk about using a public key to sign data. Not that differs per individual, but even that is easy to abuse.

It's *MUCH* faster to generate bogus data, then it is to check it. I could generate thousands of work units in an hour. If I was a bad person, I'd sign up for a new name for every single work unit. Or only every 10-20 units. If I can turn them in faster then you can test and reject them, I'm winning. The DOS will actual work. Remember, they can't possibly afford to check 1 out of every million blocks of the data they are sending out, otherwise they wouldn't be doing it as a distributed computing project. I can DOS them if they attempt to run a "trusted" version of the binary locally. I'd whoop them really bad and generating bogus data. The attacker isn't going to play nice and put all their work units in under a single name if they are attempting to subvert the process.

I'm speaking from the perspective of an attacker who want's to subvert the process not rack up a big WU total. If I really wanted to rack up a huge work unit total, I'd take all my units under one name, and then submit them via 10 signed keys when they are done, so they all look like proper work units. Then they never check them locally, because they got verified by 10 different people as the same. How handy... If they have a set of "trusted" users that have to verify all the blocks, then all they should have the trusted people run the binaries, because everybody else will be throttled by the rate of the trusted ones.

In the end, they really can't check anything locally or only by trusted users, because locally and trusted users doesn't scale, that's why it's a distributed process. All the attacker has to do, is overrun the computing resources of the checker, and they win. It's not hard at all to pump to much data at them, because I don't need to do any real work to generate them, they have to do loads of work to check them. (Spoken like a man who use to grade tests.)...

Thanks,

Kirby