Dear Guy, today i'm writing to you for two questions, the second one very hard to accept for me.
The first question: is it possible with Guymager image a single drive partition instead of the whole drive ? if so, in which way ?
The second one: Please, help me !!! This question regards the topic of write blockers (in particular the software write blockers).
Please, let me show you my doubts. I hope you can definitively solve my problem.
I start from a your phrase you wrote me in a previous email: "we don't use write blockers in our lab but have properly configured Linux machines instead" (date: 24-ago-2017 8.19).
Please, can you tell me precisely in which a way you properly configured Linux machines in your lab and if are you so sure that the writing block works effectively ?
Now, I'll try to explein the sense of this question: can you demonstrate that a BIOS/UEFI not write implicitly, that is without an explicit command from a user, to a suspect drive attached to a computer ?
As you well know the boot sequence of an x86 workstation can be sintesized into three steps:
1. BIOS/UEFI micro-code is executed from the ROM Manager chip inside the motherboard that gives the control to the BOOT Manager.
2. A BOOT Manager (like GRUB) is then performed
executing, but using a BIOS interrupt or a UEFI call to interact with a drive,
3. The KERNEL (of an operating system) is executed using native disk access.
My doubts, infact, are in beetwen the step 1 and 2.
We certainly know that the the GRUB, by design, has to be indipendent from the BIOS/UEFI.
However (if I'm not wronging "for legacy problems ???") the GRUB and the BIOS can communicates each other, by means of interrupts (for example INT H 13).
Please, can you give a look at the picture i attached.
CONCLUSION: Nobody can be sure that, attaching a usb suspect drive to a PC, the data on the usb stick are not implicitily changed (I repeat,implicitly, that is, without an explicit command from the forenser analist).
QUESTION: in which a way you have configured your machines ? Probably could be usefull use CPU with a different architecture (no x86) to realize a write blocker ?
Please, I apologize with you for this long question. I hope you can help me to clarify my doubts.
I hope to hear you soon.
Best Regards.
Vincenzo Di Salvo.
Hello Vicenzo,
Answer 1: Yes, you do so by clicking on "Devices / Add sepcial device". Unfortunately, the Qt selection dialog does not show the devices. You have to enter the partition manually, for instance /dev/sda2. The "special device" will then show up in Guymager's device list and you can acquire it like any other device.
Answer 2: We generally use Ubuntu and have automount and autorun switched off. We do not boot with the suspect devices attached, but boot the imager first and then hot plug the devices that need to be acquired.
In case we use the suspect PC itself for acquiring the image, we first unplug the devices, boot from USB stick or DVD and then hot plug the devices.
Sometimes this is not possible: For example with laptops that must be imaged quickly but are difficult to open or if the SSD chips are soldered directly onto the motherboard. Well, in that case a write blocker wouldn't help neither.
So, in short: We avoid BOOT/BIOS/EFI problems by connecting suspect devices after Linux has taken over control.
Ok, but can we be really really really sure that nothing never ever can happen? No! There could be a hacker finding some Linux vulnerability, for example in the partition table decoder and then, by using some very "strange" partition table, he could be able to exploit that vulnerability. Who knows...
Ah, so we better use write blockers - they must be safe because it's hardware, isn't it? LOL, no! What are write blockers? In old ATA/IDE times, there was in deed a write signal that could be blocked by hardware. That probably was safe. With SATA, everything is software now - i.e. some firmware that might have its own vulnerabilities. There is no such thing as a hardware write blocker for today's interfaces.
BTW: A suspect hacker could also modifiy the HDD's firmware. The drive could destroy its own data if it detects that it's connected to a different PC.
And: There's something much simplier than UEFI/BIOS/Firmware/whatever hacking to prevent others from accessing your data. It's called encryption.
Conclusion: If you can sleep better with write blockers then buy some and use them. I won't because I can't really see an advantage, only many disadvantages.
Best greetings
Guy
Last edit: guy 2017-11-21
Hello Guy,
Thanks for your reply. It is very important the scenario depicted by you, in particular the fact that today everything is software.
So, please, help me to arrange one of my machine like one in your labs. I use Ubuntu 16.04 O.S.
(I use bold style to put in evidence your reply; then my questions follow).
Answer 2: We generally use Ubuntu and have automount and autorun switched off. We do not boot with the suspect devices attached, but boot the imager first and then hot plug the devices that need to be acquired.
In case we use the suspect PC itself for acquiring the image, we first unplug the devices, boot from USB stick or DVD and then hot plug the devices.
Ok. This step is clear for me and I agree with you.
So, in short: We avoid BOOT/BIOS/EFI problems by connecting suspect devices after Linux has taken over control.
OK !!!!
I hope to hear you soon.
Best greetings.
Guy
Automount in Ubuntu (with Unity or Gnome, also with XFCE in XUbuntu) can be switched off with dconf-editor (install it with
apt-get install dconf-editor
if you've not already done so). You must launch it as the user that you use for imaging (so, usually not root, but the user that you choose when logging in after booting).You then navigate in the tree to "org.gnome.desktop.media-handling" where you find "automount" and "automount-open" which you switch off both and "autorun-never" which you switch on.
Concerning the SATA interface: Since many years already, all motherboards are able to do automounting. We always buy MBs with many SATA ports so that we can image at least 6 devices in parallel. No need for special controllers.
Try this as well: Open a shell and enter
tail -f /var/log/syslog
Then hot-plug an SATA drive. You now can follow in the syslog output how the device is being recognised and assigned its /dev/sd<x> in the file tree.
The sequence for connecting the SATA device (first power, then data or the reverse) doesn't matter.
Guy
Last edit: guy 2017-10-08