SIMILE Widgets: Timeline and Timeplot Mac OSx Install
Looking around I just found the SIMILE project. I have been messing around with TSK’s fls and looking into log2timeline and think SIMILE widgets might be useful. I am singleing the install instructions here for future reference. The test machine is Mac OS X 10.5.8.
Ant is already installed on OS X, but if you want the newest version:
Download JUnit from here
Download Apache Ant from here
JUnit will be a .jar file. Move it into “/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/lib/ext”ant --version # Demonstrate builtin version
cd ~/Downloads # Let's get into your downloads folder.
tar -xvzf apache-ant-1.8.1-bin.tar.gz # Extract the folder
sudo mkdir -p /usr/local # Ensure that /usr/local exists
sudo cp -rf apache-ant-1.8.1-bin /usr/local/apache-ant # Copy it into /usr/local
# Add the new version of Ant to current terminal session
export PATH=/usr/local/apache-ant/bin:"$PATH"
# Add the new version of Ant to future terminal sessions
echo 'export PATH=/usr/local/apache-ant/bin:"$PATH"' >> ~/.profile
# Demonstrate new version of ant
ant --version
http://stackoverflow.com/questions/3222804/how-can-i-install-apache-ant-on-mac-os-x
Make a working directory for timeline/timeplot:mkdir ~/Documents/Timelinescd ~/Documents/Timelines
Get timeline/timeplot from svn - really only need the trunk:svn checkout http://simile-widgets.googlecode.com/svn/timelinesvn checkout http://simile-widgets.googlecode.com/svn/timeplot
Now in both the working directories if you have JRE installed (default in Mac) then you can enter the trunk directory and type ./run
This will start a jetty webserver and you can access the time lines from a browser at address: http://127.0.0.1:9999/timeline (or timeplot) depending on which one you want to view.
The index.html file is in /src/webapp.
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.