Menu

#10 write blocker on x86 architecture

closed
guy
None
low
2017-10-16
2017-10-07
vincenzo
No

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.

1 Attachments

Discussion

  • guy

    guy - 2017-10-07
    • assigned_to: guy
    • Priority: high --> low
     
  • guy

    guy - 2017-10-07

    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
  • vincenzo

    vincenzo - 2017-10-08

    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.

    Autorun switched off: in which way you realize this step on your machines ?
    (Currently I use the kernel patch developed by Mikael Shuanov - Linux write blocker; https://github.com/msuhanov/Linux-write-blocker#linux-write-blocker)

    Automount switched off: in which way you realize this step on your machines ?
    (I think you use the mount command to switch off the automount; or what other ?)

    Hot plug the devices: this is the very important step - obviously there are not problem for usb devices; but can you tell me which interface you use to hot-plug a SATA hard drive (manufacturer and model ?)

    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

     
  • guy

    guy - 2017-10-08

    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
  • guy

    guy - 2017-10-16
    • status: open --> closed
     

Log in to post a comment.