Hello,
After having implemented and successfully tested Ross Anderson's idea
to use the video output to synthesize a mediumwave AM signal, I
wondered if a similar effect could be obtained by using only the CPU,
since it was easy to correlate CPU activity with radio noise. I've
just written a quick C program that tries to force activity on the
memory bus in a repetitive pattern, with adjustable frequency. After
having fiddled with the timings for about one hour, I managed to
broadcast a test tune using my Pentium 120 running Linux, giving
extremely clear reception on FM band at about 87.5 Mhz (I have in no
way calculated or predicted this frequency).
Be warned that my understanding of radio waves is bad and incomplete,
and that I have no particular radio equipment, save a walkman and a
radio cassette player.
I found that it is possible to hear the test tune over the whole
"consumer" medium- and short-wave spectrum (530-1600 KHz, 2.3-22 MHz)
using the walkman, which has a digital synthesized PLL radio
(which is generally very sensitive to electrical noise), provided the
radio is held at a distance of less than two meters around the CPU,
which suggests that there are spectral components of CPU activity at
many frequencies dividing the clock frequency and at their harmonics
(which gives a very rich spectrum). The reception in the FM band is
much more clean, and it is possible to hear the test tune in the next
room (three to four meters).
I've found that accesses to the main memory create much more noise
that other CPU activity, which is readily understandable. As it is
not possible to disable CPU caches in user mode, the program allocates
a buffer of 1 megabyte, larger than the CPU caches, and fills it with
an arbitrary pattern for a number of cycles, then pauses for a number
of cycles. These numbers are supplied on the command line. There is an
evident correlation between the pitch of the tones generated and
the length of the cycles. However, the amplitude of the received
signal, although constant for one run, can vary significantly between
different runs. My guess is that this has to do with the physical
addresses of the memory pages allocated by the process.
I guess that with higher frequency processors and careful assembly
coding, it should be possible to do good broadcasting upto and
including the FM band. Unlike broadcasting done using an attached CRT
display, this broadcasting would be totally invisible and undetectable
to the user unless he is suspecting such an activity, and either
starts to investigate it or is a radio amateur having lots of
equipment (like a spectrum analyzer) which could give him hints about
weird CPU activity patterns (but it should be possible to use
spread-spectrum transmissions to hide them completely, altough
decoding SS is hard). However broadcasting done using the CPU and/or
system buses is much less powerful than broadcasting done using the
CRT display. But, since it is invisible, if one can get reasonably
close to the target computer, it might be possible to discretely
record the signals using a dissimulated received, for later
processing. Thus, I think that this threat is at least as serious as
hidden data transmissions via the CRT.
If you are too lazy to write your own and want my quicly hacked, slow,
dirty source code for CRT or CPU broadcasting (X11/Linux, DGA), e-mail
me and I'll make them available on the net.
Berke.
--
Berke Durak [EMAIL PROTECTED]
PGP 262i F203A409 44780515D0DC5FF1:BBE6C2EE0D1F56A1
GnuPG 1024D/15FAB6E4 2048g/64021883 E38EE35DCED067CEB949:FC77DAFA083A15FAB6E4
Kripto-TR http://gsu.linux.org.tr/kripto-tr/
