In 1985, Wim van Eck published a paper which described how the state of a CRT monitor could be reproduced remotely based on the device’s electromagnetic radiation. Van Eck or TEMPEST devices, whatever you prefer to call them, aren’t just the secret sauce in your favorite science fiction, though for some reason there hasn’t been a lot of amateur or open source activity here. I’m not sure why, but I suspect as software radios become more affordable, people will start experimenting more in this space.
There are two open source Van Eck projects that I know of. The first, pictured above, is Erik Thiele’s Tempest for Eliza project. By drawing specific black and white patterns on your monitor, Tempest is able to generate audible signals in the AM range. You can use Tempest to play an mp3 file that you can tune in on your radio.
Tempest for Eliza is a fun demo, but what about being able to read someone’s monitor remotely?
There’s a second open source project, called EckBox, that claims to do just this. By piping the audio from a radio through an 8-bit analog to digital converter, EckBox claims to be able to read this data from a PC parallel port and reproduce the image of an 800×600 monitor. Looking at the code, it seems almost too simple to be true. Likewise, the project hasn’t been updated since June 2004 and there aren’t many references or screenshots or words of success floating around the net. Anyone with a parallel port and an ADC want to give this a shot and let us know how it works?
Tempest for Eliza – Link
EckBox – Link
Further Reading
Wim van Eck’s Paper (PDF) – Link
Compromising Emanations (Markus G. Kuhn, PDF) – Link
7 thoughts on “Van Eck phreaking”
Comments are closed.
ADVERTISEMENT
Join Make: Community Today
I’ve done this stuff for over a decade, so here goes.
This is only a 3DOF IMU, a 6DOF IMU would at this level contain MEMS rate gyros. In this case you are only getting relatively crude 3 axis linear acceleration. If the Wii is stationary you can get the tilt but not the compass bearing.
Also keep in mind with regard to integration that acceleration is a second derivative, so after you integrate twice the cumulative error increases proportional to time squared. Since acceleration is a relative measurement the error increases indefinitely.
This is why the Wii has a sensor bar to complement the accelerometer.
For further understanding of these issues Google Kalman Filter.
Rather than considering the WiiMote as a precision IMU consider it an inner ear when you have your eyes closed.
Check this:
“Why the (gyro) rate limitations?
The angular rate sensors that we’re using are limited to +/- 90 degrees per second. We’ve amplified them so that we can sense +/- 30 degrees per second very accurately, which should be fine for the pitch and roll axes during a stable hover. Forward flight should also not experience dynamics much faster than that. The yaw gyro may, so it should have its own scale factor.”
Via: http://autopilot.sourceforge.net/faq.html#how_do_accelerometers_work
Try to buy a low resolution gyro. (+-500 degrees for seconds is to much).
Interesting. You seem to be suggesting that gyro’s are not really required if some assumptions are made about the motion to be measured. A time eriod with no rotational motion or translational acceleration to find g. The jerk assumption isn’t so clear. Can you show us your equations?
Shoot. I just realized I didn’t link to the article. I’ve included it above, and there’s a wealth of info there.
bruceK: right, there are a lot of assumptions that need to be made. you need to know which way is up before motion occurs, the jerk which is perpendicular to gravity needs to be small, and you need to be able to assume that the device can’t be in constant linear motion.
From the article: “Then we can assume the time derivative of the force component which is perpendicular to our current estimate of the up direction is caused by the user rotating the controller only. This allows us to update our estimate of the up direction for the next time step.”
As monopole suggested, the cumulative error increases exponentially over time. This works with someone holding wiimote, though, because you can recalculate a correct “up” value regularly when g approximates 1 for a brief moment. Any motion that could cause a false reading (ie: moving down and to the side) could only be momentary, otherwise a person’s hand would be in the floor.
In terms of flying vehicles, the problem is much more difficult because it’s almost impossible to make all of these assumptions.
What I was thinking is that you might be able to get by with certain types of vehicles, such as an auto-balancing, counter rotating helicopter. The heli always centers itself to a roughly balanced position, so an accelerometer might be enough to take care of sub-second motion/rotation correction. Then you can use a GPS to receive position updates every second, which allows you to recalibrate and control for drift.