General info:

On 2001.01.26, a new patch/hack for the v3.03 client appeared. It was released through the Ars Technica OpenForum. The ARS team distantiated itself from it.
The 3.03gti patch/hack doesn't do any actual signal processing. The complete calculation routines are skipped or stripped from the setiathome-3.03.i386-winnt-cmdline.exe client and an empty resultfile is created and sent back almost immediately. It generates a continuous download-upload-download-upload-... cycle; ad nauseum. In practice, workunits are clocked as fast as the connection to the servers at Berkeley allow. The workunit is considered 'done' and the account statistics are incremented as usual.

I have done a workunit with it on a standalone machine without connection to the net. The faulty result was not returned to SETI@home.
 

Screengrab:

A screengrab of the DOS output window:

Screengrab #1, the last line indicates a failed connection, the result was not returned.

 

Patch/hack output:

The content of the file 'result.sah' of the workunit from screengrab #1
(in yellow the values for the correctly processed wu; user_id/key withheld):

operation=send_result_get_user_stats
user_id=1#####6
user_key=6#######8
major_version=3
minor_version=3
platform=i386-winnt-cmdline
cpu_type=Intel Pentium
system=Windows 95: 4.10
id=2286b760        <-- id=50ca2af2
key0=33c462a6
key1=3eefcafe
end_request_header
type=result
task=seti
version=256
name=19no00ab.5433.20401.223570.125
user_id=1#####6
cpu_time=3.410000  <-- cpu_time=58488.240000 [ 3.41s vs. 16h14m48.24s ]
status=0
params_index=0
key2=38ea2c8a
key3=66632002
wu_key=63037ea6
end_header
data_type=encoded
data_class=0
splitter_version=0x0000
start_ra= 6.006
start_dec= 17.90
end_ra= 6.035
end_dec= 17.90
angle_range= 0.417
time_recorded= 2451868.74031 (Mon Nov 20 05:46:02 2000)
subband_center=1421224975.59
subband_base=1421220703.12
subband_sample_rate=9765.62
fft_len=2048
ifft_len=8
subband_number=125
receiver=ao1420
nsamples=1048576
tape_version=1.40
num_positions=22
coord0= 2451868.74031  6.006  17.90
coord1= 2451868.74037  6.007  17.90
coord2= 2451868.74043  6.008  17.90
coord3= 2451868.74049  6.010  17.90
coord4= 2451868.74054  6.011  17.90
coord5= 2451868.74060  6.013  17.90
coord6= 2451868.74066  6.014  17.90
coord7= 2451868.74072  6.015  17.90
coord8= 2451868.74078  6.017  17.90
coord9= 2451868.74083  6.018  17.90
coord10= 2451868.74089  6.020  17.90
coord11= 2451868.74095  6.021  17.90
coord12= 2451868.74101  6.022  17.90
coord13= 2451868.74106  6.024  17.90
coord14= 2451868.74112  6.025  17.90
coord15= 2451868.74118  6.027  17.90
coord16= 2451868.74124  6.028  17.90
coord17= 2451868.74130  6.029  17.90
coord18= 2451868.74135  6.031  17.90
coord19= 2451868.74141  6.032  17.90
coord20= 2451868.74147  6.033  17.90
coord21= 2451868.74153  6.035  17.90
end_seti_header
                   <-- result data... [ missing! ]

<ogh ncfft=11 cr=0.000000e+000 fl=64>
pulse: power=1.591622e+000 mean=3.894008e-003 period=1.815894e-001 ra= 6.016 dec= 17.90
 time= 2451868.74076 freq=1421226043.69 fft_len=64 chirp_rate=0.000000e+000 snr=6.693435e+000
 thresh=6.635407e+000 len_prof=27 prof=30413a0615131245392b3e16123f446a1d21fe0016211529374e3e
<ogt ncfft=11 cr=0.000000e+000 fl=64 cpu=222.620000>
<ogh ncfft=4433 cr=6.131539e+000 fl=131072>
spike: power=1.765574e+002 ra= 6.011 dec= 17.90 time= 2451868.74054 freq=1421227587.45
 fft_len=131072 chirp_rate=6.131539e+000
<ogt ncfft=4433 cr=6.131539e+000 fl=131072 cpu=8712.890000>
<ogh ncfft=4434 cr=6.133388e+000 fl=131072>
spike: power=1.874480e+002 ra= 6.011 dec= 17.90 time= 2451868.74054 freq=1421227587.38
 fft_len=131072 chirp_rate=6.133388e+000
<ogt ncfft=4434 cr=6.133388e+000 fl=131072 cpu=8714.540000>
<ogh ncfft=4435 cr=6.135236e+000 fl=131072>
spike: power=1.923232e+002 ra= 6.011 dec= 17.90 time= 2451868.74054 freq=1421227587.30
 fft_len=131072 chirp_rate=6.135236e+000
<ogt ncfft=4435 cr=6.135236e+000 fl=131072 cpu=8716.240000>
<ogh ncfft=4436 cr=6.137084e+000 fl=131072>
spike: power=1.900498e+002 ra= 6.011 dec= 17.90 time= 2451868.74054 freq=1421227587.23
 fft_len=131072 chirp_rate=6.137084e+000
<ogt ncfft=4436 cr=6.137084e+000 fl=131072 cpu=8717.890000>
<ogh ncfft=4438 cr=6.138933e+000 fl=131072>
spike: power=1.804196e+002 ra= 6.011 dec= 17.90 time= 2451868.74054 freq=1421227587.15
 fft_len=131072 chirp_rate=6.138933e+000
<ogt ncfft=4438 cr=6.138933e+000 fl=131072 cpu=8720.690000>
<ogh ncfft=6609 cr=9.146474e+000 fl=65536>
spike: power=8.911810e+001 ra= 6.012 dec= 17.90 time= 2451868.74058 freq=1421225180.32
 fft_len=65536 chirp_rate=9.146474e+000
<ogt ncfft=6609 cr=9.146474e+000 fl=65536 cpu=12235.100000>
<ogh ncfft=7065 cr=9.780517e+000 fl=131072>
spike: power=1.943693e+002 ra= 6.007 dec= 17.90 time= 2451868.74039 freq=1421222717.68
 fft_len=131072 chirp_rate=9.780517e+000
<ogt ncfft=7065 cr=9.780517e+000 fl=131072 cpu=12975.160000>
<ogh ncfft=7069 cr=9.786062e+000 fl=131072>
spike: power=2.011509e+002 ra= 6.007 dec= 17.90 time= 2451868.74039 freq=1421222717.61
 fft_len=131072 chirp_rate=9.786062e+000
<ogt ncfft=7069 cr=9.786062e+000 fl=131072 cpu=12981.210000>
<ogh ncfft=21627 cr=-8.100212e+000 fl=131072>
spike: power=1.790229e+002 ra= 6.007 dec= 17.90 time= 2451868.74039 freq=1421226632.14
 fft_len=131072 chirp_rate=-8.100212e+000
<ogt ncfft=21627 cr=-8.100212e+000 fl=131072 cpu=40026.520000>

SETI@home statement:

Posting in the seti newsgroups by Eric Korpela of the SETI@home team at Berkeley.

|      Subject: The patch (semi-official response).
|         Date: 31 Jan 2001 02:23:00 GMT
|         From: korpela@ellie.ssl.berkeley.edu (Eric J. Korpela)
| Organization: Cal Berkeley-- Space Sciences Lab
|   Newsgroups: sci.astro.seti, alt.sci.seti

Sorry about letting the lack of response from most of the SETI@home 
team posters.  I'm sure you can understand that we've been a bit
busy.  Thank you, Lawrence Kirby, for helping everyone keep a little
perspective.

Yes, the patch does exist, and yes, it does what is claimed.  It
requests a workunit and uploads a blank result a few seconds later.
Unfortunately we had become complacent against this type of attack
following the release of the version 2 clients.  We are no longer 
complacent, and are watching carefully for users using this patch.  
Most make themselves pretty obvious.

The damage to the completeness of the science database appears to be
minimal.  Lawrence is correct that it is unlikely that the same workunit 
would be sent to two different cheaters.  There is also an additional 
effect that Lawrence didn't mention.  Workunits are not deleted 
immediately after a second result is returned.  The deletion occurs only
when the splitters have filled up the available disk space, and then the 
deletions are in fairly small chunks.  Since we're constrained by the 
data rate at the telescope (and we don't run the splitters any faster 
than that), the net effect of a million bogus results returned quickly 
is that the average number of times a workunit is sent goes up to 
compensate.   It's not enough to fully prevent any loss, but it helps.  

We're investigating ways to prevent type of hack from working in the future on
both the server and client side.  Some of the options people here have 
mentioned are being invertigated.  We'll try solving the problem in the
server first.  Because of the architecture it's a whole lot easier to prevent
the phony results from ending up in the database than it is to prevent cheaters
from getting credit for the phonies.  

Another option would be to no longer give credit for null results.  We expect
that many users would rebel against that, and stop processing any workunits
that don't find a signal in the first 5 minutes.

Some of the options presented here would greatly exceed our database processing
capacity to implement.  They would certainly work, they're just not feasable in
our current setup.  Others would require that we increase our workunit storage
by a factor of 8 or so.  If we had that much disk space around it would 
get used in the science database....

If we're not able to solve the problem in the server, expect a Windows
commandline 3.04.  I've come up with a method of prevent the null result
problem that would make the patch job more difficult.  Of course there's
no way of making the patch job impossible.

At any rate, the damage isn't too bad, and we're working on a solution...

Eric

Back to the general news archive...