Building FIVES Porndetect Image and Video
Installation of FIVES Porndetect was relatively painless on Debian Squeeze (Lenny is a bit of a pain).
First get the F_PORNDETECT.doc from the FIVES portal. Their documentation is pretty good. I am just adding extras that I come across while installing.
Requires:
iulib - Follow gsbabil’s single here for all the deps. If you are in Squeeze autoconf is newer that specified, you will have to run aclocal before ./build.
The genAM.py patch was required for both Lenny and Squeeze. Download it into the same dir, and apply it with ‘patch -p0 < genAM.py.patch’
After that iulib should build/install - you then just need to copy vidio/vidio.h and imglib/iulib.h to /usr/local/include/
I am building from the FIVES ‘everything.tar.gz’ - so extract it and go into the porndetect dir
All the packages in the document (.doc) seemed to work for me except ‘imagemagick++9-dev’ which was ‘libmagick++-dev’ in INSTALL.txt.
After that you should just be able to ‘make’ in porndetect, and it works - you will have three executables in the ‘build’ directory. The command line –help for them is lacking, but the documentation on the FIVES portal makes up for it (and no manual).
I will talk about usage in another single, but now on to building video:
For video, it has a lot of the same deps. We just need some video processing libs - see the README in the porndetect-video - it lists all the packages needed. All packages were available from the squeeze repository with no issues (not so with lenny).
I was able to build with no issues, and after had to executables in build: porndetect-video and vis-scores.
Both of the following require a global.makeinfo file that does not come in the everything package. I am waiting to hear from the group about compiling the modules standalone. Check back later.
F_SSEMATCH requires:
afflib and libewf2
Both installed from source with no problems based on the packages previously installed.
F_FDAE module, standalone. This module is for face and age detection.
First we need OpenCV which is available on Squeeze as libcv-dev, and also libsvm-dev which is for machine learning.
Forensic Image and Video Extraction Support (FIVES) Project
While working with the Open Computer Forensics Architecture (OCFA), I came across the Forensic Image and Video Extraction Support (FIVES) project. At the time, REAPER was in the proof of concept stage, and I was thinking more about automated imaging and verification than image and video processing, but with interest in REAPER Preview, image and video detection became more important. Eventually, the developer of Automated Network Triage (ANT) reminded me of FIVES. Taking a closer look, they have some tools, such as face detection and age estimation (using OpenCV) that was exactly what I was looking for. What makes the project even better is the fact that each of the tools are modules that can be plugged into OCFA. I am working on giving REAPER preview a smaller memory footprint, integrating some of the new Sleuth Kit features, and will definitely be trying out some of the FIVES tools.
Debian Live X Only
Looking for a lighter way to run REAPER Preview, we are looking into an X only kiosk-type implementation, al la:
http://jadoba.net/kiosks/firefox/
Also looking at a lighter httpd - thinking Cherokee
http://www.cherokee-project.com/
Also looking at the speed of the Google Chrome OS start up. I wonder if we can be that fast?
Installing a Eucalyptus Cloud with Debian Squeeze
When trying to install Eucalyptus on Debian, the newest version seemed to be packaged for Squeeze. I tried this directly on Lenny, but it did not work. I have never had luck trying to upgrade from Lenny to Squeeze. I suggest a new install rather than upgrading. Squeeze (testing) can be found here: http://www.debian.org/devel/debian-installer/
Just completed the install with Squeeze RC1 with no problems.
Eucalyptus hosts its own repository for Squeeze, which makes everything much, much easier. Also the documentation is pretty good, so this part will mostly be links.
<ul>
<li>Install the front-end cloud controller and any nodes (nodes can be added later)</li>
<li> Next I suggest installing Euca2ools at the same time since you will need them anyway</li>
<li> Restart the hosts</li>
<li> Go to the first time setup to designate the front-end and join nodes to the pool</li>
<li> You should have logged into the front-end to see the first-time settings and change the admin password. Make sure you downloaded your credentials onto the front-end machine, and you have sources the key info file.</li>
<li> Now you will need an image. I suggest going to the repository and selecting one yourself to start out with.</li>
<li> Once you have an image, then add it to Eucalyptus</li>
<li> Make sure the service is running on the nodes: /etc/init.d/eucalyptus-nc start</li>
<li> See this documentation section 4 for a quick start for an instance</li></ul>
That should pretty much do it without any fancy configuration options (such as elastic IPs).
Converting Parallels Disks to Raw on OS X
Update: See the forensic focus article: http://articles.forensicfocus.com/2012/07/05/parallels-hard-drive-image-converting-for-analysis/
Update: I have had problems with this method leading to corruption / being unreliable. Backup all your data before you attempt this.
We do quite a bit with parallels, and commonly want to copy a virtual disk for analysis. If you come across a machine with parallels disks, how do you copy a usable image file out? Parallels is set to use expanding disks by default, which are apparently compressed. Digfor talks about finding parallels on a Windows machine, and how to convert the disk. I will just cover the process on OS X (very similar).
Edit (7-12): An easier and faster way is to use ‘qemu-img’. I might try to create a how-to on it in the future, but it is pretty straightforward.Essentially we want to locate the .hds file. In Mac the image is usually in the .pvm package (unless location was manually specified).
<ul>Right click on the .pvm file, and click "Show Package Contents".</li>Move the .hds file to the .pvm directory</li>Rename the .hds file to OS.hdd (OS can be whatever is meaningful to you)</li>Open 'Applications/Parallels/Parallels Image Tool'</li>Choose the new disk image "OS.hdd"</li>Choose "Convert to plain disk"</li><ul>Note: This will expand the disk to its "true" size. Make sure your drive is big enough</li></ul>The converted disk is once again called OS.0.{###}.hds</li>The resulting file is now raw</li></ul>
img_stat ~/Documents/Parallels/Windows\ Server\ 2003.pvm/Windows\ Server\ 2003.hdd/Windows\ Server\ 2003.hdd.0.\{5fbaabe3-6958-40ff-92a7-860e329aab41\}.hds
IMAGE FILE INFORMATION
--------------------------------------------
Image Type: raw
Size in bytes: 8590675968Note: You can also use Parallels Image Tool to split and combine the image file - though dd gives you more options.
Profile Based Digital Forensic Preview
The newest build of REAPER Preview (officially Alpha 2) includes quite a few changes, but one that I am especially excited about is Profile Based Preivew. First I will describe the new REAPER Preview process:
REAPER Preview is designed to be highly-automatic preview. When REAPER Preview starts an ‘autorun’ profile is detected. Any file type filters, hash databases, and keyword lists that an investigator always wants to search for, are automatically scanned. These lists, obviously, need to be pre-set by by an experienced investigator for items that ALWAYS need to be scanned for. This profile should be extremely generic.
While the automatic profile is running in the background, the investigator can choose a specific pre-created profile. A specific profile could be, for example, exploitation, hacking, financial, etc. Each of these profiles would have specific hashes, keywords and preferred file types to search for. By creating a profile you not only control what is automatically searched for, but what and how found items are displayed. For example, in an exploitation case hashes and images might be the most important, where music files may not be relevant. You can choose to remove music as a display option, forcing the first responder to focus on images/hashes (since that is all they have access to). The scanning is automatic so they do not need to do anything except click the link of the profile they would like to view.
I often hear that generic keyword lists make no sense. To my knowledge there has not been a study linking keyword lists to profiling machines. I know investigators that have certain keyword lists in their heads for certain types of cases… why not use these to attempt to profile a system? I do, however, see the need for manual keyword searching since static keyword lists would not include names, etc. Because of this each profile also supports manual keyword searching against file names and full disk.
Essentially REAPER Preview is a tiered system, from highly-generic (autorun profile), to case-type specific (pre-set profiles), to incident specific (manual searching). I believe these three layers of abstraction can help an investigator quickly dig deeply into a system while not missing important information that might be more general.
I welcome you to try REAPER Preview yourself - it can be downloaded from the REAPER Forensics project page: http://sourceforge.net/projects/reaperforensics/
Any and all feedback is most welcome! Want to see a specific feature? Found a problem? Let me know!