The Security Nerd

With photos of equipment and discussion of how it works:
http://blogs.techrepublic.com.com/security/?p=222&tag=nl.e036

Or just for statistics in some other line of work?

How would you like to get n-gram frequencies from Google's corpus? How would you like to have a training corpus of a trillion words?

Google Research has published them, on 6 DVDs. Announcement at http://googleresearch.blogspot.com/2006/08/all-our-n-gram-are-belong-to-you.html

Technical details of the 2004-2005 intercepts of Greek government officials's mobile phone calls. It was much more than just turning on the "lawful intercept" functions: the code turned off log files and used rootkit techniques.

via Rootsecure, Informatica review of programs designed to block software keyloggers. This isn't about detection and removal, as a typical antimalware package would do. These are programs that encrypt or hide keystreams so that any keylogger that gets installed sees nothing or sees a scrambled stream of keystrokes.

Interestingly, several products limit their scope to protecting keystrokes in web browsers.

The Iron Geek reviews PS/2 and USB keystroke loggers.

Since the days of the keystroke recorder that looks like an RF suppressor in the cable, there's been a new generation of USB devices that, with varying and sometimes configurable stealthiness, sit on the USB bus and record keyboard traffic as it goes by.

There's no real defense except for physical security.

If you know much about the physics of optical fiber, you know that there are ways to make light leak out without breaking the fiber.

That news is now widely known, since The Register has published an article about optical fiber eavesdropping with Exfo's FCD-10B coupler. I'm skeptical about the description of a "simple clip-on" device, given the amount of sheathing and armor on fiber lines, but Infoguard alleges that someone found an eavesdropping device on a Verizon fiber line in 2003.

Who's Infoguard? They sell encryption solutions for high-speed fiber.

Most forensics work these days involves shutting down a system and studying the hard disk in isolation. The problem is that if you're studying malware and it's on a critical system or is written by somebody clever, it might live entirely in RAM.

So the arms race continued with ways to copy live RAM onto an acquisition device. Which of course any self-respecting rootkit can subvert.

So the arms raced continued with proposals to build hardware RAM-acquisition boards which would go into a PCI slot and use DMA to read system RAM. Foolproof, right?

Unless the malware author is as smart as Joanna Rutkowska, who observed that DMA requests do not go through the same mechanisms as CPU RAM access does, that the difference is configurable, and that malware with driver-level access can

• Remap the DMA access from the acquisition card to be memory-mapped IO pointing back to the card, thus crashing the system that you couldn't afford to take down for study
• Redirect that memory-mapped IO to another PCI card and "cover" a set of addresses with unrelated bits in place of those the CPU sees
• Write to that other PCI card and control what the acquisition card sees.

This is beautiful work. It's theoretically detectable: it would take consummate artistry to change a block of RAM and have the result be internally and logically consistent.

If you are trying to prevent attacks like that, I don't see any way offhand. She studied AMD systems but there's no reason to think that others are less configurable.

Joanna Rutkowska presentation at BlackHat DC on defeating hardware-based rootkit detectors.

Michael Heyman, on a cryptography mailing list, points to a .

Ian Richards tested security-through-virtualization products, including deliberately infecting his machine with CoolWebSearch. As of midyear 2006, the best-performing of eight products was Greenborder.
See also a test commissioned by Greenborder.

There were some early and severe compatibility problems, for example with Nod32.