20 August 1999: Add Berke Durak message with URLs.

18 August 1999

    Date: Wed, 18 Aug 1999 19:15:09 +0300 (EEST)
    From: Berke Durak <durakb@crit2.univ-montp2.fr>
    To: cypherpunks@toad.com
    Subject: Controlled CPU TEMPEST emanations

    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 durakb@crit2.univ-montp2.fr
    PGP 262i F203A409 44780515D0DC5FF1:BBE6C2EE0D1F56A1
    GnuPG 1024D/15FAB6E4 2048g/64021883 E38EE35DCED067CEB949:FC77DAFA083A15FAB6E4
    Kripto-TR http://gsu.linux.org.tr/kripto-tr/

    Date: Thu, 19 Aug 1999 20:47:41 +0300 (EEST)
    From: Berke Durak <durakb@crit2.univ-montp2.fr>
    To: cypherpunks@toad.com
    Subject: Sources for Controlled CPU TEMPEST Emanations

    Since a lot of people are requesting it, I'm making the sources
    available at:

    	http://altern.org/berke/tempest-cpu.tar.gz
    	http://altern.org/berke/tempest-crt.tar.gz
    	http://altern.org/berke/tempest-pci.tar.gz

    Please note that these sources are just quick hacks... I mean it.
    tempest-cpu broadcasts, on *my* P120 a nice tune on
    87.5FM. tempest-crt is somewhat cleaner and "transmits" 4-level
    FSK-modulated data on a specified AM frequency. I have not even
    checked if it is possible to demodulate it, but it is probably
    feasible. Since it is a quick hack it requires a 16-bit RGB
    display with specific byte ordering. tempest-pci is something
    I tried today based on suggestions I received; it tries to
    send data-dependent signals by indirectly using the PCI bus:
    it writes patterns of zeroes and ones synchronously to a file,
    which is expected to lie on an EIDE or SCSI harddisk connected
    via a PCI controller. Should these patterns be transmitted
    by block-mode 32-bit DMA to the disks, signals at the "sub"
    and "super" harmonics of the PCI clock should be detectable.
    So far I only managed to get weakly data-dependent buzzes on my
    radio. Again, I don't have radio equipment. So try this one out.
    You could also check the PCI (or whatever) bus with an oscilloscope.
    Although simple, I've tried to make this one minimally
    clean and usable.

    Thanks to all the people who sent me comments.
    --
    Berke Durak durakb@crit2.univ-montp2.fr
                    PGP 262i F203A409 44780515D0DC5FF1:BBE6C2EE0D1F56A1
                Kripto-TR http://gsu.linux.org.tr/kripto-tr/