cpan Date::Manip perl module on Darwin (not Darwin ports)
When attempting to install the Date::Manip perl module via cpan on Darwin it will probably give an error like:
<blockquote>
make: *** [test_dynamic] Error 255
/usr/bin/make test – NOT OK
Running make install
make test had returned bad status, won’t install without force</blockquote>
You are not really given much information, but if you attempt to build from source you will see a few dependencies are missing:
Test::Pod::Coverage and Test::Inter
Install these first via cpan:
cpan> install Test::Pod::Coverage
cpan> install Test::Inter
After that the cpan install of Date::Manip still did not work for me, but installing from source seemed to.
Download the Date::Manip source (make sure you have developer tools installed to build from source)
http://search.cpan.org/~sbeck/Date-Manip-6.11/lib/Date/Manip.pod
Building this module is a bit weird. Unpack it, and move into the directory. Then run the following to build and install:
perl Build.PL
./Build test
sudo ./Build install
source: http://faq.perl.org/perlfaq8.html#How_do_I_install_a_m
Cybercrime Technologies Philosophy
Cybercrime Technologies was founded on the principal that the level of competent, quality digital investigations should not be based on the budget of the practitioner. Because of this Cybercrime Technologies strives to produce solutions for digital forensic investigators that are:
* Low cost
* Easy to use
* Standards based
* Verifiable
Our initial focus is on digital forensic investigations conducted by Law Enforcement.
All software developed by Cybercrime Technologies will conform to the following standards:
* Low cost – In an effort to give investigators state-of-the-art tools without prohibitive cost, solutions developed by Cybercrime Technologies will conform to Open Source standards as far as applicable. Check the licensing details of each project for more information. Any solutions that require hardware will be thoroughly researched in an attempt to find the lowest cost while still maintaining the quality and standards necessary for law enforcement (in accordance with US and European standards).
* Easy to use – In an effort to minimize complicated, time-consuming tasks that may be prone to human error, the solutions provided by Cybercrime Technologies will be as automatic as possible. A focus will be in developing systems that require little-to-no interaction, or in other cases will help guide the investigator to relevant data, minimizing the time required for investigations.
* Standards based – Tools developed for investigations will attempt to adhere to internationally recognized standards of investigation, with a bias towards US and European requirements for digital evidence. An attempt will be made to strictly adhere to standards that are accepted worldwide.
* Verifiable – Software produced by Cybercrime Technologies will also be verified. Results of the verification process will be singleed along with the source code.
REAPER - Installable via self-extracting exe file
We have been looking into easier, more automatic ways for people to install and use REAPER products. Up to now we have mostly been focused on Linux-based distribution, but thanks to a new product we are tying out, All Image, we should be able to create a simple “installer” for Windows. The hope is that you plug in a USB device, double click the Installer icon, point it to the USB drive - and you have a working REAPER install. More to come!
RE: Read-Only Loopback to Physical Disk
A reader sent a very informative email in reply to this single about Read-Only Loopback Devices.
http://www.denisfrati.it/pdf/Linux_for_computer_forensic_investigators.pdf has the results of some research which was done into various “forensic” Linux boot CDs.
>For mounting a drive under Linux you have the
>standard ‘mount’ command. When mounting you can specify the -o ro
>option, which theoretically puts you in a safe read-only state… or
>does it? Does it always work? Does it stop everything?
It definitely does not always work. For example, partitions which use a journalling filesystem. The filesystem replays the journal on the disk (i.e. writes to the disk) even if “ro” is specified. For ext3, the “noload” option is supposed to prevent that happening. For XFS there is “norecovery” and for NTFS-3G there is “norecover”.
IMO that’s a terrible design decision; apart from the needlessly-differing option names, no writes at all should be done when “ro” is specified. (Maybe “forceload”/”forcerecovery” mount options could be used if the user for some reason does want to replay the journal and mount ro.)
It’s all too easy to forget and end up writing to the disk.
>Another option that I recently found was the ‘blockdev’ command. You can specify that the blockdev is ro even before mounting.
>blockdev –report
>blockdev –setro /dev/device
>But
>my professor brought up the point - these probably depend on the driver
>used. Maybe a driver for ntfs totally ignores the ro switch? I don’t
>totally agree that blockdev would be based on the driver, but how do
>you test whether the drive actually is in ro without writing? What if
>it fails?
Well, the filesystem code will (or should) go through the block layer, so using blockdev –setro should be effective. However, partitions don’t seem to inherit the read-only flag! In other words, if you have a hard disk /dev/sda with a single partition /dev/sda1, you can do
blockdev –setro /dev/sda
but if you then do
blockdev –getro /dev/sda1
you’ll notice that sda1’s read-only flag is not set! I haven’t verified yet whether sda1 can be written to in those circumstances.
That doesn’t of course prevent writes by the underlying driver (i.e. SCSI). You just have to trust that the underlying driver won’t do that. (But in theory a badly-written low-level driver might. E.g. to detect whether the medium is write-protected, the driver could read a sector and attempt to write it back.)
Any forensic Linux distribution should by default create all (disk) device nodes with the read-only flag set. That should provide another layer of confidence, in that the user must manually “blockdev –setrw /dev/name” before being able to write to the device. Apparently grml (in forensic mode) does that.
>Then the saving grace - loopback devices. Mount the partition as a file. You don’t need to worry about drivers, support, etc.
>To do this use losetup to create a loopback device:
>losetup -r /dev/loop1 /dev/hda1This creates a read-only loopback device pointing to /dev/hda1
>Then you can mount the loopback device (read-only if you are paranoid)
>mount -o ro /dev/loop1 /media/testThis mounts the loopback device loop1 at /media/test. You can then traverse the directory of /dev/hda1 just like it was mounted.
According to the PDF document I mentioned above, doing this:
mount -o ro,loop /dev/hda1 /media/test
should work in a similar way. (But to be sure, you’d need to check the source to see whether mount passes the “-r” option to losetup if ro and loop are specified…)
Ideally, anyone creating a forensic Linux distribution would test it when booting with disks which have “dirty” journals. Are there any hardware write-blocker products which will e.g. sound a buzzer when any write is attempted?
Thanks of the comments Mark!
REAPERlive Change Log - 7 Jan 2010
Change Log - 7 Jan 2010
REAPERlive
Major Revision
-Remove need for 2 drives.
-Temp remove OCFA processing.
-Add Ability to partition REAPERlive storage drive automatically on first run.
REAPERcontrol.sh v0.4 - 7/1/2010
-commented 2 drive serial numbers no serials required
-commented OCFA db password
-commented scripts running after REAPER_image
-added REAPER_partition.sh to first script to run
-checks same disk for created reaper partitions
-commented REAPERsys check
-changed REAPERevi partition to REAPERstore
-added color and pause to case name info (important info)
REAPER_detectDrive v0.4 - 7/1/2010
-commented “detect Drives” function - no longer needed
-changed detectREAPER to detect_forensic_disk
-added separate detect_suspect_disk function
REAPER_partition v0.1 - 7/1/2010
-automatically partitions REAPER USB drive with 1G SWAP and ext3 if partitions are not already created.
-REAPER_partition moved to first run position in REAPERcontrol
To Do:
REAPER_setENV needs updated to support the new single-drive structure.
REAPER_image must be checked for outdated code.
REAPER_cleanup needs to be re-implemented.
REAPERlive Major Revision in Progress
REAPERlive is being revamped. An effort to clean up and standardize a lot of the code is going on. This first part of the project will allow REAPERlive to:
1) Run on a single external hard-drive (rather than requiring 2)
2) No longer require the investigator have software-detectable serial numbers for their forensic drives (can now use very large flash drives, generic hard drives, etc.)
3) Automatically partition the drives during run-time (if not already partitioned)
4) Much improved automatic documentation
Other issues we are currently thinking about:
Bootable CD Rom support: How to securely detect the correct hard drive to store data?
Note: OCFA processing will be disabled until the imaging stage is back to stable. Check-out version 2 of the repository for the “original” REAPERlive code. The current version of REAPERdesktop is also now considered outdated, and should not be used until the new version is released.
Development Plan/Deliverables:
1) At different stages through this revamp REAPERlive will be released as an image (.img) file that can be written directly to a forensic hard drive. As long as you can image, you can run REAPER (no Debian box required!).
2) Soon after each image release of REAERlive, an updated REAPERdesktop iso will be released to automatically do all updated actions.