4

I've seen this question: Is it possible to determine if the BIOS has been modified between two points in time?

On my Linux PC, I've made a script that checks the MD5 hash of the boot partition to prevent evil maid attack. Also it check the infos of the SSD firmware and the BIOS.

For dumping the BIOS info I'm using dmidecode, to grab ROM size, version etc.

dmidecode --type bios| grep -E "Version|Release Date|Address|Runtime Size|ROM Size" > ./bios_info_orig.txt

I tried to dump the firmware with some tools like flashrom but with every reboot the MD5 check fails.

Yesterday, my PC prompted an UEFI update. I installed it and the script detected the changes only because the version number was changed, but the size was the same.

So my question is, there's a solution to this? dmidecode shows the size in mb, maybe there's some workaround that let me show the size on KB? If someone will flash something upon surely the size will change.

Improve this question
8
  • 2
    Monitoring state of UEFI/BIOS is one part of the job of a TPM. Have you considered using Bitlocker with TPM?
    – Robert
    May 24, 2022 at 10:15
  • 6
    This might be a personal challenge, but you are on the wrong end of the technology stack to make this work. You need to be closer to the BIOS, like the TPM is, to accomplish your goal.
    – schroeder ♦
    May 24, 2022 at 10:36
  • 1
    An hostile UEFI firmware would have the same version number as a proper one, so you have to dump the full firmware code (and trust you dumped the real one). The firmware dump should always be the size of the flash. Also if you can only flash signed UEFI images (depends on manufacturer), the potential attack is foiled that way...
    – Bruno Rohée
    May 24, 2022 at 11:08
  • 1
    You can compare the full dumps or their hashes, it doesn't make any difference as long as the hash is strong (so not MD5). But from the operating system you'll never be certain that you dumped the real BIOS or what someone who inserted himself earlier in the startup sequence wants you to believe is the BIOS. Have you read blog.invisiblethings.org/papers/2015/x86_harmful.pdf, it discusses the issues more in depth...
    – Bruno Rohée
    May 24, 2022 at 11:15
  • 2
    @billc.cn no need to send the TPM PCRs to an external host: simply seal a secret using TPM and the PCR your want to monitor: if, during a boot, you're not able to unseal your secret and read it back, then your PCRs has changed.
    – binarym
    May 25, 2022 at 11:06

1 Answer 1

Reset to default
1

Well. there's a tool called chipsec that can do it.

The problem is:

Warning Chipsec should only be used on test systems! It should not be installed/deployed on production end-user systems.

There are multiple reasons for that:

  1. Chipsec kernel drivers provide direct access to hardware resources to user-mode applications (for example, access to physical memory). When installed on production systems this could allow malware to access privileged hardware resources.

  2. The driver is distributed as source code. In order to load it on Operating System which requires kernel drivers to be signed (for example, 64 bit versions of Microsoft Windows 7 and higher), it is necessary to enable TestSigning (or equivalent) mode and sign the driver executable with test signature. Enabling TestSigning (or equivalent) mode turns off an important OS kernel protection and should not be done on production systems.

  3. Due to the nature of access to hardware, if any chipsec module issues incorrect access to hardware resources, Operating System can hang or panic.

Improve this answer
1
  • This is a poor answer. It says "use this tool!" but you don't say why, how it answers the question, or how it works. We try not to use products as answers to questions, but rather the approach that tools use.
    – schroeder ♦
    Jun 21, 2022 at 8:17

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .