- White Papers Digital Intelligence Linux Review April 9, 2004 Providing a linux focused review of the Digital Intelligence Firefly and Ultrablock IDE products. Overview Digital Intelligence (http://www.digitalintel.com) provides Firewire IDE/SATA/SCSI drive adaptor technology that allows end users to connect standard drives via ieee1394 connections. We are reviewing two of the currently available devices, the Firefly and Ultrablock product. Digital Intelligence was kind enough to supply us with an Ultrablock IDE for this testing. The Firefly(s) used were part of our existing equipment. Devices Digital Intelligence Firefly Read-Only ("Firefly RO") Digital Intelligence Firefly Read-Write ("Firefly RW") Digital Intelligence Ultrablock IDE ("Ultradock IDE") Features Firefly (RO/RW) The Firefly is DI's earlier firewire to IDE bridge product. It directly connects to the IDE port of most existing hard drives (IDE Drives > 1024 Megs on average) and provides direct read-only or read write access based on the firmware version purchased. Ultrablock The Ultrablock is DI's latest Firewire/USB to IDE bridge product. It requires an external IDE cable and 12v Molex, however it sports Firewire 800 (ieee1394b), Firewire 400 (ieee1394a), and USB 2.0 (USB MINI-B, 5-pin) connection ports. Objectives We determined it would be best to test these adaptors based on the following criteria: Compatibility Do they work with default vendor kernels (Redhat, Fedora)? What modules are required? Does hotplugging work? Physical Review Have the devices been built with quality in mind? Is it difficult to troubleshoot problems? Accuracy Do the devices handle typical imaging operations Do the devices block write actions? Compatibility Review of the native linux compatibility for both the Firefly and Ultrablock devices. To test compatilbility with the most recent 2.4.x series kernel branch, we used the stock Fedora/Redhat kernel, as well as a customized 2.4.24 kernel with hotplugging support. Our test workstation was a mini-itx Travala C136 from Casetronic using the ieee1394 6-pin interface. It is important to note that although the Ultrablock does possess 1394a (Firewire 800) ports, we were unable to readily test these as there was a lack of local vendor support for the cables and device adaptors required. It is also important to explain here, that multiple times during our tests we had drives refuse to respond, disconnect, or fail to load. After multiple hours of testing it was determined that the FW cable orginally supplied with the Firefly units was faulty. Digital Intelligence was more than happy to supply a replacement cable when requested. We found their technical support and sales staff very helpful and knowledgeable. This does bring up some of the more important rules regarding troubleshooting equipment. Check every link in the chain, including the cables. The first kernel tested was the stock RedHat/Fedora Kernel (2.4.22-ntpl-etc). We followed the requirements outlined in the README document provided with the Firefly devices and connected the devices individually and daisy-chained. Firefly devices attached via Firewire Ultrablock device attached via Firewire Ultrablock device attached via USB 2.0 The README document provided with the Firefly devices is quite detailed, and we recommend you take the time to read it prior to using the devices. Some of the more important considerations are as follows: * Make sure the drive is set as "single" or "master w/out slave". * Most drives will work fine, however some hard drives under 1 Gig may not be recognized. * Drives will not be recognized immediately. There is often a 1-2 second pause before the firmware generates a module load command. Results Using the Firefly and Ultrablock devices under linux requires a minimum an understanding of kernel modules, accessing linux devices, and a basic understanding of the linux firewire/scsi subsystem. Using a stock linux kernel, you will be forced to load specific modules related to the firewire storage devices, in particular, sbp2 and possibly sd_mod. Sbp2 is the firewire storage driver used to connect a storage device (hard drive/cdrom) via firewire. Sbp2 creates a SCSI device, sdx, where x is a letter(a,b,c,etc) dependent on the number of devices on the workstation. Under the stock kernel, sbp2 is not enabled by hotplug, the linux autoload subsystem, therefore you must load the module manually through a modprobe call. * /sbin/modprobe sbp2 Even though a new SCSI device has been added via sbp2, the SCSI subsytem does not have any information about the new drive(s). You will need to either add this information manually to the /proc/scsi system, or use the rescan_scsi_bus.sh script available here, to populate the /proc/scsi enteries. At this point a call to "cat /proc/partitions" will still not show the new devices. You must access the drive(s) in order to populate the partitions listing. The easiest way to do this is through "sfdisk -l", which lists all the paritions on the device called. * /sbin/sfdisk -l /dev/sdx To summarize, the following list outlines the process of using a Firefly or Ultrablock under the stock Fedora/Redhat kernel. Stock Fedora Kernel/Redhat Kernel 2.4.22 Directions for use: Install and connect all the Firefly devices Load the appropriate modules * /sbin/modprobe sbp2 Scan the proc filesystem for new SCSI Devices # /usr/bin/rescan_scsi_bus.sh Update information in /proc/partitions # /sbin/sfdisk -l /dev/sdx # Repeat above as neccessary for each device (sda,sdb,etc) Use as normal device (/dev/sda1,etc) Unload device when finished # /sbin/rmmod sbp2 Remove the SCSI device listings # /usr/bin/rescan_scsi_bus.sh While the devices worked properly under the 2.4 stock kernels supplied by most vendors, they are not hotplugged automatically as they would be under the 2.6 kernel. In order to enable hotplugging support for Firewire SCSI devices a special patch must be applied to the 2.4.x series kernel. This patch along with instructions for use is available here. In addition to lack of hotplugging support, many stock kernels do not have native support for the NASA Enhanced Loopback device. More information on this device is available here. This device allows you to mount a disk image and read individual partitions as if you were reading a physical disk. The patches provided by NASA are for the 2.4.20 kernel series, however, we adapted those patches to the 2.4.24 series and have made them available here. These patches should function properly, however if you have questions or comments, let me know. Using the modified kernel you are no longer required to manually probe the sbp2 driver, rescan the scsi bus, or access the parition table through sfdisk. All these actions are wrapped up in the hotplugging patches listed above. To summarize, the following list outlines the process of using a Firefly or Ultrablock under the 2.4.24 kernel with hotplugging support. Modified 2.4.24 Hotplug/Enhanced Loopback kernel, directions for use: Install and connect all the Firefly devices Correct Modules automatically loaded by hotplug + Device information added to SCSI device table, no need to rescan_scsi_bus.sh Drive parition tables should be read automatically Use as normal device (/dev/sdx,etc) Unload device when finished + /sbin/rmmod sbp2 Remove the SCSI device listings + Device listings (/dev/sdx) removed automatically by hotplug Firefly Physical Review The Firefly is a largely inclusive unit, possessing a female IDE port as well as two Firewire ports, it requires very little in additional cables. This inclusive construction makes the device very portable, in fact it's small dimensions (<3") and light-weight contruction make it very appealing to the portable imaging market. However, you may want to consider developing a specialized Male to Female IDE cable as there are drives which do not properly line up to the female IDE port provided. Device Quality While the device is small and extremely portable, care must be taken during the attach and detach steps. The plastic casing can begin to separate if an excessive amount of force is needed to remove the Firefly for a hard drive. If this does happen it can be rather disconcerting, however they do pop back together very easily. The Power adaptor, provided if you purchase the power supply kit with your Firefly, is a very basic dual molex cable. As with most molex connectors, the pins can be very tight for the first few usages, however DO NOT pull on the wiring, as the molex connector can become detached. Alternatively, if you plan on using the firefly inside a workstation, then no external power supply is needed, as the workstation molex's can be used. Ultrablock Physical Review In sharp contrast to the Firefly, the Ultrablock requires external cables. It possess a male IDE port and male 12v Molex connector, both of which require the use of external cables to attach them to a drive. In addition, the Ultradock sports a set of indicator lights, which provide information about both the attached drive, host adapter, and read only/read write status. These indicator lights may not sound like much, however they are excellent in assisting the troubleshooting process. For example, should you forget to set your drive as "master/single" the ATA Drive indicator light will fail to light, quickly indicating your mistake. Also, as soon as you remove the sbp2 module, the host adaptor light will turn off, indicating the host is no long accessing the Ultradock. Device Quality In contrast to the Firefly, the Ultrablock has a much more sturdy contruction, built from what looks to be a industrial electronics project box, it is easily four times the size of a Firefly device, and provide three times the number of available connections. The Read Only/Read Write switches are covered by a pop out panel on the bottom of the device. Removing this panel to access the dip switches is a one way operation, the panel is held in by two small pieces of plastic which must be cut out in order to access the switches. This did cause us some concern. While it is unlikely the device could be jarred sufficiently to accidentally switch to Read Write mode, we recommend you always verify the Write Blocker Indicator light prior to using the Ultradock in a Read Only environment. Power Adaptor connector One of the few areas of frustration with the Ultrablock is the change in power supplies. While there is clearly a .5 milliamp of difference between the Firefly and Ultradock supplies, it is also clear that the pinouts have changed between each power supply. All told, some upgrading to Ultradocks will want to replace their power supply or power the device by a 12v Molex power. Accuracy Testing the Ultrablock and Firefly for accuary and functionality. Finally, in order to complete our review of the Ultrablock and Firefly devices we attached them to one of our linux workstations and stepped through the forensic process. Each device was tested and any failures are reported below. Sterilize Acquire Authenticate Sterilize In order to ensure our target hard drive was clear of all previous images and data, we attached it to the Read/Write Firefly first and used "dd" to overwrite the drive with data from /dev/zero. FIREFLY RW [root@silentpower mshannon]# dd if=/dev/zero of=/dev/sda bs=1024 dd: writing `/dev/sda': No space left on device 39082681+0 records in 39082680+0 records out FIREFLY RO (Not Tested) ULTRADOCK (Not Tested) Upon completion of the "dd" process, we initialized a filesystem on the target drive, we chose ext2 as there was no need for ext3's journal capabilities, nor the relative inflexibility of a filesystem such as ReiserFS or xfs. Ext2 allows large file sizes and is recognized natively by most default kernels. FIREFLY RW [root@silentpower mshannon]# /sbin/fdisk /dev/sda (e.g., DOS FDISK, OS/2 FDISK) Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite) Command (m for help): p Disk /dev/sda: 40.0 GB, 40020664320 bytes 64 heads, 32 sectors/track, 38166 cylinders Units = cylinders of 2048 * 512 = 1048576 bytes Device Boot Start End Blocks Id System Command (m for help): n Command action e extended p primary partition (1-4) p Partition number (1-4): 1 First cylinder (1-38166, default 1): Using default value 1 Last cylinder or +size or +sizeM or +sizeK (1-38166, default 38166): Using default value 38166 Disk /dev/sda: 40.0 GB, 40020664320 bytes 64 heads, 32 sectors/track, 38166 cylinders Units = cylinders of 2048 * 512 = 1048576 bytes Device Boot Start End Blocks Id System /dev/sda1 1 38166 39081968 83 Linux Command (m for help):w The partition table has been altered! Calling ioctl() to re-read partition table. Syncing disks. [root@silentpower mshannon]# /sbin/mkfs -t ext2 /dev/sda1 mke2fs 1.34 (25-Jul-2003) Filesystem label= OS type: Linux Block size=4096 (log=2) Fragment size=4096 (log=2) 4889248 inodes, 9770492 blocks 488524 blocks (5.00%) reserved for the super user First data block=0 299 block groups 32768 blocks per group, 32768 fragments per group 16352 inodes per group Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000, 7962624 Writing inode tables: done Writing superblocks and filesystem accounting information: done This filesystem will be automatically checked every 21 mounts or 180 days, whichever comes first. Use tune2fs -c or -i to override. [root@silentpower mshannon]# mount /dev/sda1 /mnt/fwrw -t ext2 At this point the target drive is now ready to receive a evidentiary image. FIREFLY RO (Not Tested) ULTRADOCK (Not Tested) Acquire Prior to beginning the imaging process, we typically obtain a md5 hash for the evidence drive and partition(s). This allows us to quickly authenticate the image with the original. We attached our evidence drive to both the read-only Firefly and Ultrablock, and used md5sum to obtain the hash. Following the completed md5sum we used dcfldd, available here, to create an image of both the whole drive and parition. Hashing and imaging results were the same for both the Firefly and Ultradock. FIREFLY RO [root@silentpower mshannon]# md5sum /dev/sdb c588f5461259d9f111b893a3b09b789b /dev/sdb [root@silentpower mshannon]# m5sum /dev/sdb1 082bf383ad1b85d470c1baeb6db092db /dev/sdb1 Imaging the entire drive (for use with the eloop driver) [root@silentpower mshannon]# dcfldd if=/dev/sdb of=/mnt/fwrw/suspect-name-case-num-date-fwro-drv.img bs=1024 2496768 blocks (1219Mb) written. 2496876+0 records in 2496876+0 records out Imaging individual parition(s) [root@silentpower mshannon]# dcfldd if=/dev/sdb1 of=/mnt/fwrw/suspect-name-case-num-paritionnum-date-fwro-drv.img bs=1024 1245696 blocks (1217Mb) written. 1245856+0 records in 1245856+0 records out ULTRADOCK [root@silentpower mshannon]# md5sum /dev/sdb c588f5461259d9f111b893a3b09b789b /dev/sdb [root@silentpower mshannon]# m5sum /dev/sdb1 082bf383ad1b85d470c1baeb6db092db /dev/sdb1 Imaging the entire drive (for use with the eloop driver) [root@silentpower mshannon]# dcfldd if=/dev/sdb of=/mnt/fwrw/suspect-name-case-num-date-ud-drv.img bs=1024 2496768 blocks (1219Mb) written. 2496876+0 records in 2496876+0 records out Imaging individual parition(s) [root@silentpower mshannon]# dcfldd if=/dev/sdb1 of=/mnt/fwrw/suspect-name-case-num-paritionnum-date-ud-drv.img bs=1024 1245696 blocks (1217Mb) written. 1245856+0 records in 1245856+0 records out Authentication Lastly the md5sum values will give us a clear indication as to whether the drive(s) performed as expected. FIREFLY RO [root@silentpower mshannon]# md5sum /mnt/fwrw/ suspect-name-case-num-date-fwro-drv.img c588f5461259d9f111b893a3b09b789b [root@silentpower mshannon]# m5sum /mnt/fwrw/ suspect-name-case-num-paritionnum-date-fwro-drv.img 082bf383ad1b85d470c1baeb6db092db ULTRADOCK [root@silentpower mshannon]# md5sum /mnt/fwrw/ suspect-name-case-num-date-ud-drv.img c588f5461259d9f111b893a3b09b789b [root@silentpower mshannon]# m5sum /mnt/fwrw/ suspect-name-case-num-paritionnum-date-ud-drv.img 082bf383ad1b85d470c1baeb6db092db Resulting md5 hashes are identical, both devices worked as anticipated. Lastly, an attempt was made to write to the evidence drive using both the Ultrablock and Firefly RO. [root@silentpower external]# mount /dev/sdb1 /mnt/external [root@silentpower external]# touch /mnt/external/TEST-RW.TEST [root@silentpower external]# No errors given, file not written to disk. MD5 hashes remain the same. Write blocking functioning properly. Testing Results Summary of test results for both the Firefly and Ultrablock devices. We were very pleased with the results of both the Firefly and Ultrablock products. All tests were completed successfully with no failures. Both products expertly handled all requirements placed on them. Overall Results Both the Firefly and Ultrablock products are well designed, built, and executed products. First and foremost we recommend them as a part of any linux forensics solution. However, we feel that for those outfitting new portable or stationary linux forensics environments the Ultradock offers the largest array of features with support for USB 2.0, ieee1394a, and ieee1394b, in additional to the useful indicator lights. In contrast, those already using the Firefly devices are most likely best off to pass on upgrading until their existing Firefly devices are no longer functional or they have migrated to a ieee1394b (Firewire 800) architecture. In conclusion, both products over a very cost effective and forensically sound means to access IDE devices via firewire. Both products are well supported by the linux kernel and linux ieee1394 group, and would make a good addition to any forensic toolkit. All devices reviewed above are available from Digital Intelligence at www.digitalintel.com. About the Author: Matthew Shannon has over five years of professional information security experience in private industry, including KPMG LLP, ExxonMobil, and United Technologies. Mr. Shannon has been the lead investigator on numerous computer forensics engagements, including intellectual property theft and employment law. Mr. Shannon graduated cum laude from The University of Florida in Decision and Information Sciences (BSBA) in 1999. He is an accomplished speaker having presented at the DEFCON 11 Information Security Conference in Las Vegas, Nevada. He is a member in good standing of ISSA. In addition, Matthew holds numerous professional information technology certifications, and has been a contributor to multiple open source information security projects including "The Sleuthkit" and "The Honeynet Project". About Agile Risk Management LLC: Agile Risk Management, LLC is a premium provider of information security consulting services, committed to providing business value with uncompromised integrity. Agile specializes in delivering consulting services not motivated or influenced by vendor products or relationships. Agile provides services that afford reasonable protection for the information assets of our clients in accordance with their business needs. Agile service offerings include: Digital Forensics and Litigation Support Security Assessments Security Program Development Crisis Management Business Continuity Planning