Helix and external ...
 
Notifications
Clear all

Helix and external USB drives

12 Posts
7 Users
0 Likes
1,157 Views
jblakley
(@jblakley)
Posts: 110
Estimable Member
Topic starter
 

I'm trying to use helix to store images acquired from the live cd. When I try to mount the drive, it shows RW but I can't write to it. I've read other forums that say you can only read from ntfs partitions within knoppix. What do you guys do when using helix? Do you have drives that are specifically partitioned with ext3? I tried to format the usb drive with fat32 but windows won't even give me that option.

The command I use to mount is

sudo mount -t ntfs -o rw,noexec /dev/sda1 /media/usbext

Running mount without any arguments shows to be mounted as rw, and etc/mtab shows the same.

Thanks for all of your help!

John

 
Posted : 18/01/2008 9:16 pm
JonN
 JonN
(@jonn)
Posts: 73
Trusted Member
 

I've always used FAT32 drives to image to with Helix, and I'm sure I've used Helix to partition and format the drives, using fdisk and then mkfs.vfat with -F32 switch, if not Helix then any Linux box will do, or something like Partition Magic in Windows.

I don't actually know if Helix will write to NTFS drives, I've never tried, but from experience of using other Linux disks I've always defaulted to imaging to FAT32 because I know it works.

I know some people use ext3 formatted drives to image to, and profess them to be quicker - that may be the case, but as I always then transfer the images to a Windows server it would defeat any time savings in the lab.

 
Posted : 18/01/2008 9:34 pm
jblakley
(@jblakley)
Posts: 110
Estimable Member
Topic starter
 

Thanks for the quick reply! It's weird; I tried to delete the NTFS partition using fdisk under Helix, and it deletes all of them. I then created my ext3 partition, and it said that the disk would sync on next rebooted, so I rebooted. When I remounted the drive, it still shows as NTFS.

I didn't try the mkfs.vfat command yet, but I'll try that tonight.

Thanks JonN!

 
Posted : 18/01/2008 9:44 pm
(@bgrundy)
Posts: 70
Trusted Member
 

You could use ntfs-3g with Helix (it's on there). Google for it and read up a bit before doing so.

From a forensics perspective, writing to NTFS for acquisition is generally a BAD idea. Unless you've exhaustively tested it on your platfrom, I'd avoid using in a production environment. Even compared to VFAT on large images, it's pretty slow.

Format your thumbdrive Fat32 if you need to access from windows, or format EXT and use a Windows EXT driver (or software…again, check google).

My $.02

 
Posted : 18/01/2008 9:52 pm
jblakley
(@jblakley)
Posts: 110
Estimable Member
Topic starter
 

Well, this is just for dd to write to. I've booted a laptop up from Helix, mounted the local hdd as RO, and then mounted the external USB as rw. I was going to dd if=/dev/hda of=/dev/sda1/image.dd, and then open in Autopsy.

When you said "writing to NTFS for acquisition is generally a BAD idea", what do you suggest writing to? Should I expect to partition all of my storage drives to ext3?

Btw, this isn't for a "real" case. I've been asked by a client to see what data has been deleted, but it's not expected to go to court. I know that I can use other software, but I feel this is good practice. -)

 
Posted : 18/01/2008 9:57 pm
(@guyonright)
Posts: 4
New Member
 

To mount the NTFS volume as RW in Helix….From root shell or sudo
mount -t ntfs-3g /dev/hdx /media/hdx -o force

force is for forcing a mount when the volume was umounted improperly which that will be the case when using mkntfs to format it.

Jeff Hansen
Hansen & Levey Forensics
http//www.HLforensics.com

 
Posted : 28/01/2008 5:56 am
(@farmerdude)
Posts: 242
Estimable Member
 

ntfs-3g is what you will use for writing reliably to NTFS file systems from Linux that is mounted locally.

Alternatively, mount your destination via CIFS or SAMBA and blow your image across the network. This way you write to your NTFS destination but go through CIFS or SAMBA, and if you use a crossover cable and an intel gig pci Ethernet card it will be fast with no outside interference.

I think some thought should be given to the type of file system you store your image files on. Unfortunately many "just use" NTFS because they work in a Windows environment. I would give consideration to these areas when choosing the FS TYPE to store image files on
- how robust is the file system (can I include it in an LVM where I can grow or shrink as needed, simply by adding or removing a drive and changing the configuration file)
- how fast or slow is the file system, depending upon the type of files stored within it (large files vs small files)
- how fast (or slow) is the file system checker
- how accurate is the file system checker
- if I need cross-platform support, which are supported, and to what extent?

Just some thoughts …

farmerdude

 
Posted : 15/02/2008 7:17 pm
(@stud_rahul20)
Posts: 3
New Member
 

I've always used FAT32 drives to image to with Helix, and I'm sure I've used Helix to partition and format the drives, using fdisk and then mkfs.vfat with -F32 switch, if not Helix then any Linux box will do, or something like Partition Magic in Windows.

I don't actually know if Helix will write to NTFS drives, I've never tried, but from experience of using other Linux disks I've always defaulted to imaging to FAT32 because I know it works.

I know some people use ext3 formatted drives to image to, and profess them to be quicker - that may be the case, but as I always then transfer the images to a Windows server it would defeat any time savings in the lab.

Hello Jon,

I am new to this forum and I am currently conducting a forensic investigation of a hard drive. I am trying to use Helix for Imaging the hard drive. Currently I have not started doing any of the forensic processes. Hence, wanted your advice as to how to approach the investigation as it is part of a module.

If you can help me with a few questions that i have, it would be great.
- The procedres for imaging the hard drive.
- We go on the computer where we will be performing the imaging of the hard drive.
- Then do we mount the suspect's hard drive as read only?
- How to do that on Helix, then how to write block it?
- Once, we have write blocked the suspect's hard drive. Do we mount the imaging (forensically wiped) hard drive as RW?
- Please could you give me the codes on how to mount and write block drives in order to forensically image the suspect's hard drive by using Adepto.

 
Posted : 16/10/2009 2:39 pm
JonN
 JonN
(@jonn)
Posts: 73
Trusted Member
 

Hmm Ok,

The procedures for imaging the hard drive

You need to start with taking some basic details off the label - manufacturer, model number, serial number, size, LBA/CHS, manufactured date - along with details of the job, exhibit number etc.

- We go on the computer where we will be performing the imaging of the hard drive.
- Then do we mount the suspect's hard drive as read only?
- How to do that on Helix, then how to write block it?

I assume you mean connecting the suspect drive to another computer other than the suspect computer and booting the 'acquisition' machine with Helix? No problem with that. Helix won't do anything with it until you tell it (though I've heard there are some caveats here with ext2/3 drives being mounted by Ubuntu based forensic boot disks).
To simply acquire it, it doesn't need to be mounted as anything.
Write blocking - well that's why we're using a Linux forensic boot disk in the first place, we don't need one as the drive doesn't get mounted.

- Once, we have write blocked the suspect's hard drive. Do we mount the imaging (forensically wiped) hard drive as RW?
- Please could you give me the codes on how to mount and write block drives in order to forensically image the suspect's hard drive by using Adepto.

When you connect your imaging drive, Helix will show you it but not mount it. I'm not sure if there is a way in the GUI to mount it read/write, I've always made a habit of doing it from the terminal.

You'll need a mount point first in either /mnt or /media (depends on preference or habit, but I don't think it makes much difference) e.g mkdir /mnt/usb

You need to know which is the suspect drive and which is your imaging drive, this is important as you are going to mount one of them read/write and you don't want it to be the suspect drive. You can work it out (hopefully) from the output of the command 'fdisk -l'

So pick which one is your imaging drive and use the 'mount' command to mount it read/write, which is the default - e.g. mount /dev/sdc /mnt/usb - so mounting the physical device to whatever mount point you created or chose.

You should be good to go now, fire up Adepto and work through the screens, I always find it easier to type in the mount point rather than try to navigate to it.

If you are going to work from terminal, pick the 'Root Terminal' in Forensics and IR, otherwise you'll forever be typing 'sudo'

If you need more information about the specific commands and any switches you can add - Google is your friend, to be confident with using Linux commands it helps to know what the full potential of eatch command with the various switches is. There's also the 'man' pages at the terminal - e.g type 'man mount' and it will give you a help file

Other than that, best of luck, I'm no Linux guru so if I've got anything wrong or missed anything maybe someone else with more knowledge will correct or add the information. The above works for me and has done on many occasions now.

That enough for you? Good, now don't come back until you've got it right!! D

 
Posted : 16/10/2009 5:38 pm
(@stud_rahul20)
Posts: 3
New Member
 

Hello Jon.

Thank you very much for you prompt and very helpful response.

I have started my research and what I am understanding now is as follows
- Take photographs and Label everything and then I take out the hard disk of the suspected computer from it's computer
- Boot the suspected computer without its hard disk and take photographs of the BIOS of suspected computer.
- Then take the hard disk to another computer where i will be performing the acquisition.
- I can either add an internal forensically wiped hard disk and then boot it with Helix or use an external forensically wiped hard disk
- When i go on Helix, I go on the Terminal from Forensics & IR tab
- I mount the imaging forensically wiped hard disk as RW
by using the command

wipe -k /dev/sdb (Forensically wipe the hard disk where I will be storing the image again)

mount -t captive-ntfs -o rw /dev/sdb /mnt/sdb

mount -t ntfs-3g /dev/sdb /media/sdb -o force

or depending where the source of hard drive is and change the sdb accordingly

- Then I go on Adepto and fill in the details etc. then I select the suspected hard drive (it may be sdb or sdd etc.)
Device to acquire - Suspected hard drive
Destination point - Imaging forensically wiped hard drive.

I am facing two issues
1. The suspected hard drive is aroound 40GB, and I have been having errors writing more than 4GB on FAT32 forensically wiped hard disk.

Should I wipe the imaging hard disk as FAT32 then go on Partition Maker on Helix and change the partition to NTFS and then mount it as NTFS-3g which is the writable format of NTFS?
Will I be able to image the 40GB suspected hard disk on FAT 32 forensically wiped 80GB hard disk?

Sorry to bother u so much, but thank you very much for being so supportive.

 
Posted : 23/10/2009 5:31 pm
Page 1 / 2
Share: