Need help bypassing ASRock BIOS Intel ME detection protection on J4105-ITX/J4105B-ITX/J4205-ITX/J3455M/J3455-ITX/J3455B-ITX/J3355M/J3355B-ITX/J3160DC-ITX/N3050M/Q1900M/Q1900B-ITX/D1800M/D1800B-ITX

[ASRockBiosProtection]

ASRock and a few other OEMs are using fake SPI region size to bypass ME region detection.

As discussed here:

https://www.win-raid.com/t840f39-ME-Analyzer-Intel-Engine-Firmware-Analysis-Tool-Discussion-12.html#msg30782

The problem with that images is the vendor made a mistake in last volume size, so it's free space crosses regions boundary, that's what that error message is all about. If you correct FvLength of the last volume manually to not cross the 0x6FEFFF, the file will be parsed normally.

The problem is that vendor don't see that volume free space is outside the BIOS region, but UEFITool sees that and complains about it. As a workaround, someone can add a routine to correct this last volume size automatically during parsing., or tell the vendor that they are doing their images a wrong way.

And here:

https://www.win-raid.com/t840f39-ME-Analyzer-Intel-Engine-Firmware-Analysis-Tool-Discussion-12.html#msg30786

I have found APL SPI from three different OEM and all their images are like that. Also, their SPI work at FIT whereas the fixed FD ones that I tried yesterday crash it. You certainly know what's what but this what I've seen so far:

This is the APL structure which differs depending on whether it's SPI or eMMC (No FD).

ASRock BIOSes can be downloaded here:

https://www.asrock.com/mb/Intel/J4205-ITX/index.us.asp?cat=Download&os=BIOS https://www.asrock.com/mb/Intel/J3455M/index.us.asp?cat=Download&os=BIOS https://www.asrock.com/mb/Intel/J3455-ITX/index.us.asp?cat=Download&os=BIOS https://www.asrock.com/mb/Intel/J3455B-ITX/index.us.asp?cat=Download&os=BIOS https://www.asrock.com/mb/Intel/J3355M/index.us.asp?cat=Download&os=BIOS https://www.asrock.com/mb/Intel/J3355B-ITX/index.us.asp?cat=Download&os=BIOS

When you run tools such as UBU/UEFItool on these BIOSes they report "Invalid UEFI volume", but these BIOSes support UEFI and the UEFI volume is in there, just can't be detected due to ASRock's protection.

When you run me_cleaner on these BIOSes you get:

python me_cleaner.py APLITX1.40

Full image detected The ME/TXE region in this image has been disabled

Is Intel ME really disabled on these boards? Or is me_cleaner reporting that because ASRock misaligned the regions in their BIOS?

[ASRockBiosProtection]

I've looked more into this and it looks like we might need IFWI support on APL SPI images.

https://github.com/LongSoft/UEFITool/issues/85

Uefi tool dont see me from bios like Apollo Lake chipset

There are two files for ApolloLake chipsets. The firts file doesnt look in Uefi tools Me region, cause I dont sure that the second file is work or have me region

https://github.com/LongSoft/UEFITool/issues/82

platomav commented Sep 3, 2017

Either way, APL has been out for a year now and every image I've seen uses IFWI. So it's worth adding that functionality to UEFITool.

When you run UEFI tools on these BIOSes you can't see the ME region even though they're in there.

Is me_cleaner having the same problem? Can me_cleaner add IFWI/APL support? At least tell newbies they're running me_cleaner on some APL/capsuled images and not a normal BIOS image or something, tell them what they need to do to extract the region and assemble it back to the image after cleaning.

Also it'll be helpful to let newbies know that some boards allow the BIOS to flash the cleaned image back without an external flasher, so newbies have a chance to download the latest BIOS, clean the ME from the file, and then flash it back without an external flasher and a month of research.

[ASRockBiosProtection]

MEAnalyzer supports APL/IFWI, can we have that in me_cleaner as well?

https://github.com/platomav/MEAnalyzer https://github.com/platomav/MEAnalyzer/blob/master/MEA.py

2691: #Used at APL/CNP/GLK IFWI 1.6 & 2.0 platforms
2692: #https://github.com/coreboot/coreboot/blob/master/util/cbfstool/ifwitool.c
2771: ("Type",          uint16_t),      # 0x00 dword at non APL IFWI 2.0 (?)
2772: ("Flags",         uint16_t),      # 0x02 Only at APL IFWI 2.0 (?)
2778: #It is probable that Flags field is relevant for APL (IFWI 2.0) platform only
2779: #At CNP (IFWI 1.6) and LKF (IFWI 1.7), Type is uint32_t and there are no Flags

[ThePlexus]

I ran into this problem, but it seems like its nearly a year old and likely in the "parked/wontfix" category.

ifdtool (coreboot/util/ifdtool from coreboot) has the ability to set the HAP bit for Gemini Lake BIOS. Dump with your SPI reader, run ifdtool on the BIOS with the -M 1 switch and flash back.

Yes it wont read properly in me_cleaner to remove the blobs, but it will set the HAP bit and both me_cleaner and ifdtool can validate this, despite the new partition format

$ flashrom --programmer cha341a_spi -r bios.bin --SNIP

$ me_cleaner/me_cleaner.py -c bios.bin Full image detected The ME region in this image has already been disabled The HAP bit is NOT SET Checking the FTPR RSA signature... Traceback (most recent call last): --SNIP

$ coreboot/util/ifdtool/ifdtool -d bios.bin | grep HAP HAP bit is not set

$ coreboot/util/ifdtool/ifdtool -M 1 bios.bin Setting the HAP bit to disable Intel ME... Writing the new image to bios.bin.new

$ coreboot/util/ifdtool/ifdtool -d bios.bin.new | grep HAP HAP bit is set

$ me_cleaner/me_cleaner.py -c bios.bin.new Full image detected The ME region in this image has already been disabled the HAP bit is SET Checking the FTPR RSA signature... Traceback (most recent call last): --SNIP

ASrock Gemini Lake motherboards also have an interesting TXE1 jumper which, when shorted, seems to have some effect on the BIOS <> TXE communication. The BIOS will see the TXE firmware as "N/A" though Im yet to research if this setting can be used day to day.

https://www.asrock.com/support/BIOSIG.asp?cat=Windows10

install a jumper cap on the TXE1 header. ....

--- SNIP

Enter the BIOS setup and refer to the following path to ensure the TXE FW version is “N/A”. Path: Advanced → Chipset Configuration → TXE FW version

[derpeter]

@shamen123 i used, as you mentioned here, ifd tool to set the HAP bit and also get the same outputs as you. Sadly after flashing it the board (J3445-ITX) isnt booting anymore, no Video output no disk activity. I tried flashing back and forth the modified and the unmodified version to make sure it is not an flash issue. Flashing back the unmodified version works. Any hints what else i could try to make the modified bios work?

[ThePlexus]

not sure on the J3445 as I dont have one, this method worked perfectly on the j4105. is there a "TXE" jumper on the board anywhere? some asroc boards have that and it will disable ME when shorted. if not, im not sure what else to suggest

[derpeter]

At least not populated with a jumper or mentioned in the manual. I will need to disassemble the box again to look if there is something marked on the board. As our boards look very similar from the layout, can you tel me where it is on yours? Is there any way to figure out why its not booting? Some serial output or something like this?

[ThePlexus]

no its not mentioned in the manual on mine either. its marked on the PCB on mine, you can see it directly above the "ROHS" marker, next to DDR bank A1 as "TXE1"

https://www.asrock.com/mb/Intel/J4105B-ITX/

select 2nd pic, zoom into ROHS symbol, look for two pronged jumper spot (above ROHS symbol, to the direct left of the top clip on the A1 DDR bank)

However, that does not mean its on every board. ultimately, what I suggested was a workaround for my specific board, based on the lack of support in me_cleaner for the new style partitions of gemini lake. the ideal path would be for these bios partitions to be supported in me_cleaner.

[derpeter]

ok, I checked the whole board and can find any TXE1 marking. Looks like i need to wait for support in me_cleaner or an explanation why the image with HAP bit is not starting. thanks for your answers.

[ThePlexus]

FYI as an update to this, I have upgraded my UEFI firmware to vendor issued version 1.30 on the J4105b-ITX board for various microcode fixes. For ME neuter attempts, I used the ifdtool method as I mentioned above. This did set the HAP bit - as with previous versions of ASRock UEFI firmware. I also used ifdtool to lock the ME regions from change.

However, I have noticed the following changes;

1. POST time at boot is significantly lengthened. Around 70 seconds for POST from cold start.
2. Soft reboot and physical reboot button do not work any more. The system does reboot - but gets into UEFI stage 99, beeps like normal POST then locks up solid and goes nowhere else.

YMMV.