Fuji FinePix digital camera with USB cable.
Computer forensics is the science of extracting information from computers in support of the investigation of crime or other malicious activity.
Except.... It isn't really a science, not in the same sense that forensic chemistry, forensic biology, and so on are based on an underlying science. What is called "computer forensics" today is a collection of ad-hoc techniques done in a legally responsible way.
|
Fuji FinePix digital camera with USB cable. |
|
|
recoverjpeg is a very nice tool that solves the data recovery problem you are most likely to encounter. Get it from rfc1149.net or from freshmeat.net.
If your camera works as a USB mass storage device, you can simply find its device name (it will appear as if it were a SCSI or SATA disk, use fdisk -l to figure out its name). Then you can image the camera's memory into a file, and extract images from there:
$ cd $ dd if=/dev/sdb of=camera-image $ recoverjpeg camera-image
Or you could simply recover the JPEG image files directly, there is no real need to save an image of the camera's memory:
$ cd $ recoverjpeg /dev/sdb
If, on the other hand, your camera uses the Picture Transfer Protocol, or PTP, then as far as I know you will have to put the memory card into a reader so it appears as a USB mass storage device. I don't think there's an easy way of using the PTP interface to directly access or copy the memory via the command line, but then on Unix there are commands to do pretty much anything fairly easily.
See my page on using digital cameras with Unix for more on PTP and accessing and controlling digital cameras with gphoto2.
File system forks, called Alternate Data Streams (ADS) by Microsoft, contain metadata associated with a file system object. Apple included this in their Hierarchical File System (HFS) to store things like the icon to be used by the Finder or the menus and dialog boxes used by the application itself.
Many tools have ignored ADS — for example the command line utilities on Mac OS X versions before 10.4 ("Tiger") and the Windows Explorer graphical interface and the command line dir tool. Vista's dir has an option to also list ADS objects, use:
c:\> dir /r
Of course, you have to suspect that an ADS is lurking there before you are going to use that /r option.
Alternate Data Stream creation is very simple:
c:\> cd \ c:\> mkdir test c:\> cd test c:\test> copy \picture1.jpg . c:\test> copy \picture2.jpg . c:\test> type \windows\system32\notepad.exe > picture1.jpg:secret.exe c:\test> type \sensitive.txt > picture2.jpg:scandal.txt c:\test> dir
At this point you will just see files picture1.jpg and picture2.jpg. The dir utility cannot find or show you these Alternate Data Streams associated with them (except the dir starting with Vista, and then only if you specifically ask it to). The only thing you can notice with dir is that if you run it before and after the two type commands, the amount of free space on the disk will have decreased slightly, by the sum of the sizes of notepad.exe and sensitive.txt.
However, as a proof of concept you can execute the program hidden as an ADS of picture1.jpg with this:
c:\> start picture1.jpg:secret.exe
You have to run the executable program with start because the command shell does not notice the ADS. You can also edit the text hidden as an ADS of picture2.jpg with this:
c:\> notepad picture2.jpg:scandal.txt
Some malware scanners and forensic analysis tools are now aware of ADS data and look for it, but many such tools do not notice it. As you might imagine, ADS provides a hiding place for users of malware and other inappropriate data and programs.
The Encrypting File System (EFS) is an extension to NTFS, providing encryption of files in a way that is transparent to the user and applications.
Each user has an RSA public/private key pair, the private key is the master key leading to encryption and decryption of all their EFS files. This key pair is stored in the Local Security Authority (LSA) Secrets area of the Windows Registry. The key pair is encrypted using the user's password as a symmetric key, and the resulting ciphertext stored in the LSA Secrets. When the user logs in, the login password is used to decrypt that key pair and provide it to the login session.
A file can be marked for encryption, individually or by inheriting that characteristic from its directory. Each file marked for encryption has a randomly generated File Encryption Key (FEK). That key is used with a symmetric cipher (originally DES, AES starting with XP SP1) to encrypt the file. The ciphertext is stored in the file itself, or the data fork in ADS terminology (see above for forks and ADS). The randomly generated FEK is then encrypted using the user's RSA public key, and the resulting ciphertext stored in the $EFS ADS, which may be called the Data Decryption Field (DDF). To be careful about all this, a Recovery Agent should have already been set up on the system with its own RSA key pair, so that the operating system has access to a Recovery Agent Certificate containing the Recovery Agent's public key. The FEK is also encrypted using the Recovery Agent's public key, and the resulting ciphertext stored as the Data Recovery Field (DRF). In Windows 2000, you must have a recovery agent and be default it is the local administrator. Windows XP and later has no requirement for a recovery agent and there is none defined by default.
+---------+ +---------+
| | +-----+ | |
|cleartext|--->| AES |----------------------------->|encrypted|
| file | +-----+ | file |
+---------+ ^ | |
^ | +-----+ +---------+
| +------->| RSA |------+ +---------+
| | +-----+ | |$EFS ADS |
User selects | ^ +-------------->DRF |
encryption | | | |
for this file | Recovery Agent's +-------------->DDF |
| public key, | +---------+
| if available |
| | \----v----/
System generates | +-----+ | |
random FEK ------+------->| RSA |------+ |
+-----+ Stored in the
^ file system
|
+-----------+ private key
|Registry | |
|+-------+ | |
|| LSA | | +-------+ RSA key
||Secrets|----->|decrypt|---> pair
|+-------+ | +-------+
| | ^
+-----------+ |
user's password
|
user at +-------+
the ------->| login |
keyboard +-------+
When the legitimate user wants to decrypt the file and access the data, their login session has access to their RSA key pair, and so the DDF field can be decrypted to yield the FEK, and the FEK used to decrypt the file itself.
If a Recovery Agent has been set up, that entity has an RSA key pair that allows them to decrypt the DRF to yield the FEK, and thereby decrypt the file.
But let's say that no Recovery Agent has been set up (remember that only Windows 2000 requires one!), the users' RSA private keys have not been backed up offline or within Active Directory (and honestly, how often is that done carefully and correctly?), and the user has forgotten their password. If you reset the password, that RSA key pair has been lost — the new password certainly cannot be used to decrypt it. The result is that all the user's EFS encrypted files have been lost.
Be very careful — EFS can lead to complete data loss if not used carefully.
EFS does not really provide security. This isn't just me complaining — Microsoft's own documentation admits that EFS only provides security if Windows is the only operating system in the world. EFS leaves cleartext copies of all the files on the disk, in the assumption that no one will ever have access to the media other than through the controls of their operating system.
From http://technet.microsoft.com/en-us/sysinternals/bb897443.aspx:
Even when you encrypt files with Win2K's Encrypting File System (EFS), a file's original unencrypted file data is left on the disk after a new encrypted version of the file is created.
The only way to ensure that deleted files, as well as files that you encrypt with EFS, are safe from recovery is to use a secure delete application.
From http://technet.microsoft.com/en-us/magazine/dd334519.aspx:
However, an attacker with direct access to the disk can still recover the file's contents until it has been overwritten by another file — which might never happen. Similarly, files that have been EFS-encrypted leave behind the unencrypted contents of the file on the disk.
With the SDelete tool, which you can download for free, you can overwrite the contents of free space on your disk to prevent deleted or encrypted files from being recovered.
From http://technet.microsoft.com/en-us/sysinternals/bb897443.aspx:
However, object reuse does not dictate that the space that a file occupies before it is deleted be zeroed. This is because Windows NT/2K is designed with the assumption that the operating system controls access to system resources. However, when the operating system is not active it is possible to use raw disk editors and recovery tools to view and recover data that the operating system has deallocated. Even when you encrypt files with Win2K's Encrypting File System (EFS), a file's original unencrypted file data is left on the disk after a new encrypted version of the file is created.
The only way to ensure that deleted files, as well as files that you encrypt with EFS, are safe from recovery is to use a secure delete application. Secure delete applications overwrite a deleted file's on-disk data using techiques that are shown to make disk data unrecoverable, even using recovery technology that can read patterns in magnetic media that reveal weakly deleted files. SDelete (Secure Delete) is such an application.
If you have enabled Volume Shadow Copy, the original data cannot be securely deleted. See this web page for details.
|
|
|
|||||||||
|
|||||||||
|
| © Bob Cromwell Sep 2010. Created with /bin/vi and ImageMagick, hosted on OpenBSD with Apache. Root password available here, privacy policy here. |
