File Systems for Electronic Surveillance Devices?
An anonymous reader asks: "A friend recently discovered that her vehicle had been bugged by the police (for reasons I won't go into here). It seems the set-up had been wired into the car's electronics, so that whenever the car was going the microphones were recording the occupants' conversations. Unfortunately I didn't get to see everything she recovered, as she was a bit exuberant in her removal and disposal. However, I have been given a 20G Fujitsu notebook hard drive and some kind of audio processing chip from a manufacturer by the name of Topoint, and have been asked if I can examine the contents. You can read on to hear about my efforts so far, but I have several questions: If the surveillance device came from a vendor, what kind of file system might they use, and if - as I suspect - it is encrypted, do I have any options other than writing zeros over the drive and putting it to less controversial use?"
"Not knowing what to do with the audio chip, I focused on the notebook hard drive. I got an adapter, connected it as master on my desktop and booted up. After checking the BIOS to see if the drive was recognised (it was), I was presented with a full-screen simple line diagram showing the floppy drive slot, a floppy with an arrow in front of it and across the bottom, the F keys with the F1 key depressed. Hitting F1 with or without entering a disk resulted in 'Non-system disk error...' So much for the direct approach.
Next I set the drive as slave and booted Linux (Mandrake and then a few Live CDs), but the drive contents weren't recognised due to the lack of a partition table. So, I kept it as slave and ran a few forensic and data recovery tools in Windows: DFSee and tools from Mare Software and Runtime Software. I couldn't recognize the file system or recover anything from the drive with these, so I figure it isn't formatted with any of the standard FAT, FAT32, HPFS, NTFS, JFS, EXT2/3 or REISER file systems. I've kind of reached the limit of my abilities here, but my curiosity has been stoked.
Does anyone have any suggestions or comments - useful or otherwise? To anticipate a few in advance: Yes, listening devices might well run Linux. We're not in the US and are more interested in human rights than terrorism. My friend obviously knows most of what has been recorded, but wants to figure out how long the bug was in place."
Next I set the drive as slave and booted Linux (Mandrake and then a few Live CDs), but the drive contents weren't recognised due to the lack of a partition table. So, I kept it as slave and ran a few forensic and data recovery tools in Windows: DFSee and tools from Mare Software and Runtime Software. I couldn't recognize the file system or recover anything from the drive with these, so I figure it isn't formatted with any of the standard FAT, FAT32, HPFS, NTFS, JFS, EXT2/3 or REISER file systems. I've kind of reached the limit of my abilities here, but my curiosity has been stoked.
Does anyone have any suggestions or comments - useful or otherwise? To anticipate a few in advance: Yes, listening devices might well run Linux. We're not in the US and are more interested in human rights than terrorism. My friend obviously knows most of what has been recorded, but wants to figure out how long the bug was in place."
I would try grabbing the data off of the drive as an image, then "playing" the image as if it were one large audio file.
dd if=/dev/hdb of=/home/me/image
/home/me/image -- if disk was
/home/me/image|less and see if you notice anything special. If all your strings will be 4-letter random words, most probably it is encrypted and you are out of luck. Or maybe not, if they used something like XOR -- try building a hystogram of byte values distribution. If it is flat -- well, then you are screwed with a well-encrypted disk, and your best bet is to secretly ship the disk to a TLA of your country's adversary. ;-)
(assuming you have free 20G on your HDD)
Then try file
used just to dump data, you might as well see that it is a WAV file.
Then try strings
Paul B.
Forget reading the data.
Format the whole thing with fat32
Fill the entire drive with gay porn.
Reinstall in car.
Assuming the audio chip has a part number on it, try to get the datasheet from the manufacturer. See what format data it outputs, and perhaps the data on the hard drive is raw output from the audio chip. (If the audio chip's native format is 12 bit, 8k samples/sec, then that might be what's on the HD. If the audio chip supports some sort of audio compression, etc...)
/dev/hdb /dev/audio or something like that (I'm not a Linux guy)). If the HD was used just to dump raw wave data to, you'll hear something (possibly squeaky voices if it's the wrong format, but you'll be able to tell there's something there). Even if there's a filesystem of some sort that you can't interpret, that would just be noise at the beginning of the playback, before it got to the real audio.
A reasonable first step would be to try to take the entire contents of the drive and send it out your sound card... (dd
If it really is encrypted, then you'd have to do some sort of cryptanalysis, and I have no idea how to even begin cryptanalysis on audio data. At that point, I say open the HD up and scrape the platters until they're shiny silver instead of shiny brown.
First, if you encounter something like this in the future, don't try to boot from it. (It's always possible there could be code to detect an unauthorized machine and start deleting itself.)
Next, as another poster suggested, use dd to get a copy of the disk. Make a few copies while you're at it, and write them to DVDs, DLTs, or some other media.
Finally, do the processing. Here are some ideas:
Write all zeros to the drive, then put it back in the car. Drive around for set intervals of time (100 minutes, 200 minutes, etc.) then pull the data from the drive to see how much was filled up. (Hint: it's from the start of the drive to where the long string of zeros starts.) Try it with minimal noise, try it with talking, and try it with music.
Run 'file' or 'strings' on the image. Try catting it to your sound device. Plot the data in both 2D and 3D and look for any patterns. (Encrypted data shouldn't have any.)
Toppoint may build custom chips / build clone chips.
Any/all numbers on the chip would probably be more useful than the manufacturer's name.
Also, and perhaps a red herring, could the device in question be the product found here?
It is a GPS tracker with audio recording capability. It also happens to take 20G drives and uses a SOIC for control.
It may be a jump, but Toppoint could have been the board builder.
Well, considering you posted to Slashdot, I would assume that either you don't care if the authorities find out that their "bug" has been reappropriated, or perhaps you wish to blatenly rub that fact in their face? If your friend can be reasnoably certain that the bug did not capture any sensitive conversation (which I might guess is the case by her willingness to trust you with the drive rather than destrying it outright), then why not post a torrent? I'm sure plenty of amatuer and moonlight crypanalysists, file-system and audio engineers would love to check that data out. You can use "cat /dev/hdb | gzip > /image.gz" to pull the image off the drive, compress it, and dump it into a file which you could then release to the public.
Most filesystems store data at the lowest level in a more-or-less raw format on the disk for performance reasons. (on-the-fly compression or encryption is CPU intensive) Even something like ReiserFS would have chunks of recognizable (though perhaps out-of-order) raw audio file visible on the drive. Try feeding the output to your sound card. A good way to do this would be with "SoX" (Sound eXchange, an audio conversion tool for linux... "apt-get install sox"). SoX comes with "play" a command which basically just sends data to the sound card, and for raw data allows you to specify what format (8 bit or 16 bit? 22khz or 48khz?) it should play the audio at. Also if you suspect something other than 8 or 16 bit, try bitshifting the sample a couple times so that the first sample begins on a byte boundry.
Another useful tool is called "ent", which applies a number of entropy tests to a sample. True raw audio data should have only some entropy. Blank filesystem structure should have almost no entropy. Encrypted or very highly compressed data will appear to be almost entirely entropy. ("apt-get install ent" on Debian or Knoppix)
You could anylise the drive in chunks to see how much is filled with medium entropy (uncompressed audio), how much is high entropy (encrypted or compressed data) and how much has almost no entropy (empty space), and using this statistic in conjunction with any info you can find on the sample rate and number of bits from the chip, calculate how much audio is stored on the drive, and thus how long it has been installed.
I've seen that "line-drawing" before. It is probably just your BIOS telling you it can't find a boot sector on the drive. (which isn't terribly supprising) But if the people who made the device were particularily nefarious, it could be a fake splash screen which only *looks* like your BIOS, at which you must enter the secret code to proceed into the true playback application. (But that's almost too far-fetched to be a possibility. almost...) If you really wanted to eliminate that possablity, you would use hexedit (apt-get install hexedit) to look at the first sector for the magic number. it should be at the end of the sector (offset of 512k minus 4 I think), but I can't remember off the top of my head what the magic number is supposed to be for bootable i386 media. If the magic number is not there, that splash screen is just your BIOS. (Also a good way to check for stealth-boot-sector viruses. >:-} )
Anyway, good luck, and I hope you have firm legal ground to stand on where you are. Be careful. Angry Feds are not a pleasant thing.