It means that GUID-defined section has a GUID that indicates a specific compression type, so the actual body of the file is in fact decompressed data.
This is not a limitation of UEFITool, this is a design decision. A lot of people will try to extract body of GUID-defined section and then insert it as FFS file body, and this can never be done properly, unless the user is a pro. Need the compressed body - strip all headers from FFS file, because you clearly know what you are doing.

Does anyone know how, or can point me to a little info/guide on correcting this issue when modifying BIOS - warning from EUFITool - checkProtectedRanges: BG-protected ranges hash mismatch, opened image may refuse to boot

I corrected the FIT table already in this BIOS, fixing microcode locations and Bootguard key manifest and key policy locations, but am unable to figure out the above issue. Hopefully it's possible!
Original image does not show this. I've seen it be OK before, but usually in those instances the bootguard key manifest and policy locations weren't setup in FIT, at least I don't remember having to correct those before and BIOS was OK.
I checked the ME Region, and OEM Public key hash is all zero's, so maybe it's not fully configured and this can be safely ignored?

BIOS In question here - https://www.supermicro.com/products/moth...0/X11DPi-NT.cfm
I updated two microcodes via GUID extraction and hex edit, then corrected it all the FIT table.

There's no way to correct it without having vendor's private key to ri-sign the modified firmware. If the system doesn't have BootGuard enabled, just do nothing.

Thanks @CodeRush I thought I've read you say that sometime in the past, but I couldn't find the right post. Does that mean I was correct, in thinking that is ME settings do not have OEM Public key hash value set then it's not really enabled anyway?

Thanks, I asked the user and he said he doesn't use bootguard, but I guess that maybe still doesn't mean this issue will be OK solely based on him not using it.
Good thing though, he has flash programmer so recovery is no problem!

@plutomaniac, while it's not a 100% working indicator of disabled SB, it's mostly true because no sane vendor will provide and update image that has mismatched BG configuration and will probably refuse to work because of that (depends on BG setup, actually). So, if you see a valid OEM hash in ME config, and the same hash can be found on BootGuard tab of UEFITool NE, this indicate a correct BG setup. If ME doesn't have an OEM PK hash or has a different one, the most probable outcome is that it's not enabled.

However to be 100% sure and get away from heuristics, MEInfo provides all the required BG-related information, so if you see BG tab populated and stuff marked in red/yellow/cyan in UEFITool NE, it's better to ask for MEInfo output before trying to modify anything.

Thanks @CodeRush - I do see red/yellow/cyan in the modified and original BIOS. I'll have the user get me an MEInfo report, will it be obvious from that if BG is enabled vs what we're already discussing only partially setup?

@Lost_N_BIOS, it's obvious from MEInfo output, as it clearly indicates Measured Boot (TPM-based BootGuard mode) and Verified Boot (ME RoT-based BootGuard mode) as enabled or disabled. If any of those is Enabled, any changes in BIOS region may lead to brick.

Thanks, I will wait for meinfo output then before giving BIOS to user to test. He has programmer to recover, but if I know it's going to be a brick no matter what then no point in sending over a modified BIOS even if it's done.

@CodeRush & plutomaniac (I guess that's a good way to catch your eye? )

Measured Boot and Verified Boot enabled at ME level, but not at FPF side, does this indicate bootguard not active and I can edit something inside cyan region of BIOS? Thanks!

And while your looking, something I thought to ask other day, when I do find this is active on some system, editing still will fail if user has flash programmer too correct, nothing matters/can't be edited?