While I don't know the specific details for LUKS, the way TPMs are usually used for disk encryption is that a key (typically used to decrypt or "unwrap" the master encryption key) is stored in the TPM and "sealed" to specific values in specific PCRs. TPMs let you specify a policy for when to unseal a key; in this case, the policy would be "don't unseal the key unless PCRs 0-5 (or even more) are <their current values>".
This means that the attacker can't simply figure out the expected hashes and then use them to decrypt the drive, because those values are useless by themselves. They need to actually be in the PCRs for the unseal policy to be satisfied. You can't write directly to the PCRs, or reset them (except as the system boots), either. You'd have to figure out the right input to take the PCR from whatever value it has to the one it expects. Assuming the hash algorithm used by the PCRs is strong against collisions and preimages, this is infeasible.
Of course, if you can control what gets hashed ("extended") into the PCRs from boot, then you can make them arrive at any value you want. Preventing this is the duty of the CRTM (Core Root of Trust Measurement), which is generated by hardware-enforced code (provided by the chipset vendor) that runs before anything else. This code measures the firmware (BIOS) of the system before executing it, extending all the code to be executed into PCR0 and the firmware configuration data into PCR1. The firmware itself measures the subsequent code-to-be-executed and extends that into suitable PCRs.
Because the CRTM is made using code that's integral to the chipset - possibly even integral to the CPU - an attacker can't replace it with something that lies about the measurement of the firmware. Because the firmware is measured, the attacker can't replace it with something that lies about the measurements of the boot metadata, etc. which means that the boot metadata can't be replaced with something that lies about the measurements of the bootloader, etc. The CRTM is - as its name implies - the root of a chain of trust; as long as the CRTM is what you expect (or the TPM's unseal function requires, per policy), you can be sure that each subsequent set of PCRs were extended legitimately and their values reflect the true hashes of the code that ran. Thus, if they are also the expected values, you can be sure that the boot code was not modified, such as to boot an alternative OS that will unseal the disk encryption key and then let you read the disk without having a valid login password.
As such, not only can an attacker not use the computed PCR4 value to decrypt the disk correctly, they can't even put it into PCR4 - not without having the wrong values in the lower PCRs - because the code that would extend the required sequence of values into PCR4 would itself have been extended into some lower PCR, and that code isn't normally there so the lower PCR would have an unexpected value and the TPM wouldn't unseal the key.
Mind, you do probably want to seal the key using more than just two PCRs. If you don't use PCR0, then modified firmware wouldn't be caught, and if your motherboard allows arbitrary (or buggy) firmware to be installed then the whole chain of trust would be broken. If you use PCR0 but not PCR2, then extensions to the firmware won't be checked, and those might override what data gets extended into PCR4 and PCR5.
For an example of which PCRs to use, consider BitLocker's default PCR policy when using the TPM on computers with native UEFI (search for "validation profile for native UEFI"): it checks PCRs 0 (CRTM, firmware code), 2 (firmware extension code), 4 (boot manager code from the UEFI system partition), and 11 (which Microsoft's boot code uses to store BitLocker access controls). This list is customizable; for example, if you want to prevent unsealing the key if the user changes any UEFI/BIOS settings at all, you might also check PCRs 1 and 3.
