[116703] in Cypherpunks

home help back first fref pref prev next nref lref last post

Re: Controlled CPU TEMPEST emanations

daemon@ATHENA.MIT.EDU (ANTGamez@aol.com)
Wed Aug 18 17:13:24 1999

From: ANTGamez@aol.com
Message-ID: <88ce8a76.24ec738d@aol.com>
Date: Wed, 18 Aug 1999 16:37:33 EDT
To: cypherpunks@toad.com, durakb@crit2.univ-montp2.fr
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Reply-To: ANTGamez@aol.com

This is interesting, If someone has the talent/time/patience to write one 
that could broadcast the first amendment, please e-mail a copy of it to me. 
But I did I have a real question, would it be possible to actually broadcast 
a voice by a CPU?

In a message dated 8/18/99 3:22:08 PM US Eastern Standard Time, 
durakb@crit2.univ-montp2.fr writes:

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


home help back first fref pref prev next nref lref last post