[quote="chris2792]But what happens during the Boot Process ? Even if there is no partition mounted afterwards nobody knows if they really were never mounted for whatever reason.
If you know Linux, you know that the first process started is [i]init[/i]. From init, everything else is controlled by configuration scripts in the /etc/rc.d/init.d or /etc/init.d directory, plus configuration files in /etc and subdirectories. The boot process recognizes the devices (unless the device drivers have not been compiled into the kernel), but mounts the root device in read-only mode until init is run.
Linux has various AutoFS/automount processes, depending upon the flavor, but all of these are controlled by configuration files. It is simple to either turn off autofs or configure it to mount devices in read-only mode.
even if a question is not worded correctly (and I think my question was clear) that should not be reason a not to post a reply, that would make a forum worthless
Possibly, chris2792, but no all forums view it the way we (you+me+people here) do (and yes, it annoys me too, when that happens).
Have a look at the UnionFS and SquashFS specifications which all LiveCD distributions use. They should provide you with a possible answer with regards to the booting process.
There are cases where it is not possible to use a write blocker. In my last case I found that certain raid controllers makes use of the ATA Security feature to guarantee that the drives are not used with another controller.
Yes, there are such cases. Seriously, what would one do in such a case if the option of using a LiveCD distribution is not present?
And with regards to the Helix website's mention of Helix being a customised distribution of Ubuntu Linux, they've forgotten to update the FAQ with regards to the move to Ubuntu, I presume (it does say it is originally based on Knoppix). My bad, here, so sorry about the misunderstanding.
Cheers
DarkSYN
psu89, yes, according to this (http//
helix.e-fense.com/forums/viewtopic.php?f=14&t=709&p=2932) you are right in that they are mentioning that its based on the Ubuntu 8.04 kernel (not found anything to say what they based the rest of the GNU/Linux distribution on, exactly). Ticking off the kernel changes from the hints list of changes required (possibly).
Can anyone find some more specific information that suggests they have copied the rest of the Ubuntu 8.04 distribution?
Cheers
DarkSYN
I found this in their forum
Helix 2.0 is based on Ubuntu 8.04 with a 2.6.24 kernel
I didn't find any more specific info.
"@Beetle
When Helix has finished the Boot Process there are NO partitions mounted automatically, there is just an applet per partition created on the top bar. By klicking on that applet one can mount the respective partition (and in that case the partition is mounted read only) - so far so good.
But what happens during the Boot Process ? Even if there is no partition mounted afterwards nobody knows if they really were never mounted for whatever reason."
I was referring to the "auto" mounting when you right-click on the desktop icons in pre-2.0 or the little icons in the top bar. You don't type anything in at the root terminal.
If you want to see what is going on during the boot process you need to look at the start-up scripts.
As some have replied, you would have to review the init scripts as well as the source code for the modules/loaders they've modified for addtional write protection. This even includes the GNOME desktop GUI. I can see why they're apprehensive about completely detailing how they assure forensic soundness because they are currently building a "pro" version of their boot CD, which likely relies on the modifications they've made. They could either spend time writing/modifying code or they could waste time by turning this into a very detailed research project for some enterprising shmo to rip-off )
If you're concerned about the validity of forensic images created with Adepto, Linen, Air, dd, etc. etc., I suggest you find a disk and create an image with a proprietary vendor solution and one of the frequently used open source solutions previously mentioned. Compare their md5/sha1 hashes and get some sleep.
Hey guys, just catching up on the forums…
Jamie, do you have the email addresses that you tried to log in with? PM me, i'll help get you sorted.
With regards to the changes made, Drew made the changes to the CD. They are well documented in the forthcoming manual. I do not have a release date on the new manual, but rest assured it will be out soon.
I posted that question 3 weeks ago on the Helix Forums…
Count yourself lucky, I've tried twice to create an account and still can't get in!
Jamie
Jamie,
That is odd. We never saw your registration. We have a very strict registration policy to prevent spammers. You must register with a real email address and you will receive an email. You MUST click on the link in the email address to activate your account. A Board Admin MUST then confirm your account for it to be active. If neither of those happen than you will not have an account.
Also if a user has not logged into their account for more than a year the account will be removed.
If you or anyone else has problems with account creation feel free to let me know.
Drew
I have recently discovered that Helix3 2009R1 (as well as the latest Pro version) repairs corrupt ext3 filesystems during the boot process. Everyone can confirm this by searching for ext3 repair process in dmesg output or by checking hash values for the filesystem's block device using forensically sound distro (not DEFT - it repairs ext3 during the boot too).
There are other issues as well - Helix3 can automount some media read/write with HAL running (e.g. media in my internal card reader).
Re "Helix3 2009R1 repairs corrupt ext3 filesystems during the boot process"
After booting to this CD and running "blockdev –getro /dev/sdX " over all local HDD's it tells you that they are still set to RW. ( return code 0 = RW , return code 1 = RO )
Seems as the only forensic behaviour Helix does, is to automatically mount filesystems as RO.
So I would believe what you say RE the EXT3 repair occuring on bootup.
Thats dangerous as it may damage evidence.
Not so good from a forensic standpoint.
I would recommend using GRML for forensic acquisitions based on the fact that it sets all local storage block devices to RO mode using blockdev.
http//grml.org/
(make sure to boot into forensic mode)
For you to start acquisition you first need to set the destination block device device to RW and then mount it RW.
So is a lot harder to accidentally contaminate evidence using GRML.
One downside for most people is that GRML is mostly a command line oriented live CD.
You will need to know how to use the Linux command line.
An easier open source CD is Caine
http//
but it still doesn't set the blockdev for all storage devices to RO.
The official Guidance Software knoppix linen 6.14 boot CD still doesn't set the blockdev for all storage devices to RO.
(just tested it now)
The official Guidance Software Linen 6.14 CD using Helix1.9 (13.07.2007) boot CD also doesn't set the blockdev for all storage devices to RO.
(just tested it now)
So the safest option is to use GRML as it sets all block devices to RO by default.
Cheers
I have recently discovered that Helix3 2009R1 (as well as the latest Pro version) repairs corrupt ext3 filesystems during the boot process. Everyone can confirm this by searching for ext3 repair process in dmesg output or by checking hash values for the filesystem's block device using forensically sound distro (not DEFT - it repairs ext3 during the boot too).
There are other issues as well - Helix3 can automount some media read/write with HAL running (e.g. media in my internal card reader).
If no file systems are mounted or if file systems are mounted read only, why do you believe you need to set the physical drive to read only? (BTW, testing is always fantastic - you may find that using blkdev to set a drive read only actually fails to work though it may appear otherwise)
Cheers!
farmerdude