(UEFI) Dell XPS 15z L511z modded BIOS - and HOWTO

[TimeWalker]

Uhm, guys I will try to catch up on this ME thing as I feel I fell behind pretty badly ..
I've seen (not actually read it, but just skimmed through rather) about overriding descriptor .. but I'm not aware where had I seen this ..
I guess I have some reading to do

Edit:
ah .. it was 6-series chipset datasheet.


And quoting Khenglish from techinferno here (thanks to kasar for the article):

Enabling the flash descriptor override is something that I don't know how to do, unless you have an HP laptop. On HP laptops there is a management mode that can be enabled by pressing "WIN+left_arrow+right_arrow" during POST (got this info from nando4). This management mode enables the flash descriptor override and the system will boot normally into windows, allowing the use of the Intel utility.

Which appears to be a total mystery cabinet then .. essentially this is a BIOS debug mode which I had mentioned when i was looking for a way to initiate recovery. Older DELL-propriotary bioses had this option.. I highly doubt Phoenix-Dell Tiano has this.

[jkbuha]

Interesting. Surely there must be another way to enable flash descriptor override? I mean if we can flash ME 7.x updates from Win64, surely there must be a way to flash variants??

Alternatively, we should be able to modify the base ME_firmware with a tool such as FITC or equivalent - we can flash this file easily, so all we need is a suitable editor to indicate which offset(s) to look for?

[TimeWalker]

Actually I take it back .. there may be some sort of debug mode 1547B4F3-3E8A-4FEF-81C8-328ED647AB1A :

Also Dell somehow is able to update the ME region .. meaning they have to compromise descriptor to allow flashing the region (I've read on Intel® vPro™ Technology). Digging through the rom fw now .. lets see if the firmware is actually in there.

---

P.S. Actually I feel retarded .. we had PFlash.efi at our hands all along .. the C8AB0F4E-26FE-40F1-9579-EA8D30D503A4 1.06 Mb file that is extracted from the BIOS1.WHP along with the main bios capsule IS the PFlash.efi application ..


Notice the update descriptor region ...
So what i'm implying is maybe during the recovery phase when the capsule is sideloaded from an external media the override flag is actually set to descriptor...

[TimeWalker]

Lets see what your guys' new version has different from my stock one:

Code:

C:\DRIVERS\WIN\ME>MEInfoWin.exe Intel(R) MEInfo Version: 7.1.10.1065 Copyright(C) 2005 - 2011, Intel Corporation. All rights reserved. PMXUtil: Error during PMX Call: PMxDrv!MAPPHYS - Bad Input Parameters GBE Region does not exist. Intel(R) ME code versions: BIOS Version: A13 MEBx Version: 0.0.0.0 Gbe Version: Unknown VendorID: 8086 PCH Version: 600005 FW Version: 7.0.4.1197 UNS Version: 7.1.50.1172 LMS Version: 7.1.50.1172 MEI Driver Version: 7.1.21.1134 Wireless Hardware Version: Not Available Wireless Driver Version: Not Available FW Capabilities: 16784480 Intel(R) Anti-Theft Technology - PRESENT/ENABLED Intel(R) Capability Licensing Service - PRESENT/ENABLED Protect Audio Video Path - PRESENT/ENABLED Level III Manageability Upgrade State: Not Upgradable CPU Upgrade State: Upgrade Capable Cryptography Support: Disabled Last ME reset reason: Power up Local FWUpdate: Enabled BIOS and GbE Config Lock: Unknown Host Read Access to ME: Disabled Host Write Access to ME: Disabled SPI Flash ID #1: EF4016 SPI Flash ID VSCC #1: 20052005 SPI Flash BIOS VSCC: 20052005 BIOS boot State: Post Boot OEM Id: 00000000-0000-0000-0000-000000000000 OEM Tag: 0x00000000

Here is the tool: https://dl.dropbox.com/u/2573233/ME.rar

[jkbuha]

Here's mine:

Code:

C:\Temp\ME>MEInfoWin.exe Intel(R) MEInfo Version: 7.1.10.1065 Copyright(C) 2005 - 2011, Intel Corporation. All rights reserved. PMXUtil: Error during PMX Call: PMxDrv!MAPPHYS - Bad Input Parameters GBE Region does not exist. Intel(R) ME code versions: BIOS Version: A12 MEBx Version: 0.0.0.0 Gbe Version: Unknown VendorID: 8086 PCH Version: 600005 FW Version: 7.1.52.1176 UNS Version: 8.1.10.1300 LMS Version: 8.1.10.1300 MEI Driver Version: 8.1.10.1275 Wireless Hardware Version: Not Available Wireless Driver Version: Not Available FW Capabilities: 17833024 Intel(R) Capability Licensing Service - PRESENT/ENABLED Protect Audio Video Path - PRESENT/ENABLED Intel(R) ME Dynamic Application Loader - PRESENT/ENABLED Level III Manageability Upgrade State: Not Upgradable CPU Upgrade State: Upgrade Capable Cryptography Support: Disabled Last ME reset reason: Power up Local FWUpdate: Enabled BIOS and GbE Config Lock: Unknown Host Read Access to ME: Disabled Host Write Access to ME: Disabled SPI Flash ID #1: C22016 SPI Flash ID VSCC #1: 20052005 SPI Flash BIOS VSCC: 20052005 BIOS boot State: Post Boot OEM Id: 00000000-0000-0000-0000-000000000000 OEM Tag: 0x00000000

So practically the same. Note that Host Read/Write access is Disabled, which explains why fptw(64).exe -d or -f gives an error.

[TimeWalker]

Yeah, nothing is really that different. Firmware features is different due to the different series of our laptops.
I wonder what are these manufacturing mode levels though and where is the Fn+X is supposed to be pressed... any thoughts? I tried pressing it at post and then launching the ME Info again.. Host still showed up as being R/W Disabled.

I've stumbled upon this ..

Hello,
I have a Dell Precision M6300 laptop, I replaced the motherboard and when I power on it gives the Dell splash screen and error message "manufacturing mode level 40" then the screen goes blank. the video is only there for at most 1,5 seconds. I had to take a picture with my camera phone to get that much information. Anybody got any suggextions?

I did find this suggestion just now:
"Hold down the function key and start tapping X before the message comes up"

On some desktop boards (if not all of them actually) the descriptor override is set by a jumper..

[jkbuha]

On our machines holding Fn launches the ePSU dialog so it is most likely another key sequence (same as the problem I have with launching recovery)

[kasar]

oops, srry for the delay.

one of my hard disks died and I had a massive data loss (over 600 Gb dataloss). I am restoring backups and DLding some stuff again.

used MEInfoWin64.exe instead MEInfoWin.exe

Code:

C:\Users\kasar>"C:\BIOS MOD\A12 PROJECT\modded menus\ME test\Tools\System Tools\ MEInfo\Windows64\MEInfoWin64.exe" Intel(R) MEInfo Version: 8.1.10.1286 Copyright(C) 2005 - 2012, Intel Corporation. All rights reserved. Error 1002: Failed to retrieve Intel (R) ME FW Version GBE Region does not exist. Intel(R) ME code versions: BIOS Version: A12 MEBx Version: 0.0.0.0000 Gbe Version: Unknown VendorID: 8086 PCH Version: 5 FW Version: 7.1.52.1176 UNS Version: 8.1.10.1300 LMS Version: 8.1.10.1300 MEI Driver Version: 8.1.10.1275 Wireless Hardware Version: 2.5.68 Wireless Driver Version: 14.1.1.3 FW Capabilities: 0x01101C40 Intel(R) Capability Licensing Service - PRESENT/ENABLED Protect Audio Video Path - PRESENT/ENABLED Intel(R) Dynamic Application Loader - PRESENT/ENABLED Error 8203: Unexpected result in command response (Get CLS Allowed Feature Info) Cryptography Support: Disabled Last ME reset reason: Power up Local FWUpdate: Enabled BIOS Config Lock: Enabled Host Read Access to ME: Disabled Host Write Access to ME: Disabled SPI Flash ID #1: EF4016 SPI Flash ID VSCC #1: 20052005 SPI Flash BIOS VSCC: 20052005 BIOS boot State: Post Boot OEM Id: 00000000-0000-0000-0000-000000000000 Capability Licensing Service: Enabled Error 8203: Unexpected result in command response (Get CLS Allowed Feature Info) Error 8203: Unexpected result in command response (Get CLS Allowed Feature Info) Error 8203: Unexpected result in command response (Get CLS Allowed Feature Info) OEM Tag: 0x00000000 Localized Language: Unknown Independent Firmware Recovery: Disabled

so as for the moment, we are trying to unlock the descriptor settings, right?

[jkbuha]

Interesting kasar - your CPU doesn't appear to have upgrade capabilities. Maybe it's because it's an i3?

Ok guys - let's crack out our tools to see how we can remove the bios config lock and enable r/w access to ME...

[TimeWalker]

Mine is an i3 as well.. I guess it's because he used a newer version of the software so the result is different.

This extract from flashrom's documentation was an interesting read:

= Accesses beyond region bounds in descriptor mode =
Intel's flash image tool will always expand the last region so that it covers
the whole flash chip, but some boards ship with a different configuration.
It seems that in descriptor mode all addresses outside the used regions can not
be accessed whatsoever. This is not specified anywhere publicly as far as we
could tell. flashrom does not handle this explicitly yet. It will just fail
when trying to touch an address outside of any region.
See also http://www.flashrom.org/pipermail/flashr...07606.html

= (Un)locking the ME region =
If the ME region is locked by the FRAP register in descriptor mode, the host
software is not allowed to read or write any address inside that region.
Although the chipset datasheets specify that "[t]he contents of this register
are that of the Flash Descriptor" [PANTHER], this is not entirely true.
The firmware has to fill at least some of the registers involved. It is not
known when they become read-only or any other details, but there is at least
one HM67-based board, that provides an user-changeable setting in the firmware
user interface to enable ME region updates that lead to a FRAP content that is
not equal to the descriptor region bits [NC9B].

There are different ways to unlock access:

- A pin strap: Flash Descriptor Security Override Strap (as indicated by the
Flash Descriptor Override Pin Strap Status (FDOPSS) in HSFS. That pin is
probably not accessible to end users on consumer boards (every Intel doc i
have seen stresses that this is for debugging in manufacturing only and
should not be available for end users).
The ME indicates this in bits [19:16] (Operation Mode) in the HFS register of
the HECI/MEI PCI device by setting them to 4 (SECOVR_JMPR) [MODE_CTRL].

- Intel Management Engine BIOS Extension (MEBx) Disable
This option may be available to end users on some boards usually accessible
by hitting ctrl+p after BIOS POST. Quote: "'Disabling' the Intel ME does not
really disable it: it causes the Intel ME code to be halted at an early stage
of the Intel ME's booting so that the system has no traffic originating from
the Intel ME on any of the buses." [MEBX] The ME indicates this in
bits [19:16] (Operation Mode) in the HFS register of the HECI/MEI PCI device
by setting them to 3 (Soft Temporary Disable) [MODE_CTRL].

- Previous to Ibex Peak/5 Series chipsets removing the DIMM from slot (or
channel?) #0 disables the ME completely, which may give the host access to
the ME region.

- HMRFPO (Host ME Region Flash Protection Override) Enable MEI command
This is the most interesting one because it allows to temporarily disable
the ME region protection by software. The ME indicates this in bits [19:16]
(Operation Mode) in the HFS register of the HECI/MEI PCI device by setting
them to 5 (SECOVER_MEI_MSG) [MODE_CTRL].

== MEI/HECI ==
Communication between the host software and the different services provided by
the ME is done via a packet-based protocol that uses MMIO transfers to one or
more virtual PCI devices. Upon this layer there exist various services that can
be used to read out hardware management values (e.g. temperatures, fan speeds
etc.). The lower levels of that protocol are well documented:
The locations/offsets of the PCI MMIO registers are noted in the chipset
datasheets. The actually communication is documented in a whitepaper [DCMI] and
an outdated as well as a current Linux kernel implementation (currently in
staging/ exist [KERNEL]. There exists a patch that re-implements this in user
space (as part of flashrom).

== Problems ==
The problem is that only very few higher level protocols are documented publicly,
especially the bunch of messages that contain the HMRFPO commands is probably
well protected and only documented in ME-specific docs and the BIOS writer's
guides. We are aware of a few leaked documents though that give us a few hints
about it, but nothing substantial regarding its implementation.

The documents are somewhat contradicting each other in various points which
might be due to factual changes in process of time or due to the different
capabilities of the ME firmwares, example:

Intel's Flash Programming Tool (FPT) "automatically stops ME writing to SPI
ME Region, to prevent both writing at the same time, causing data corruption." [ME8]

"FPT is not HMRFPO-capable, so needs [the help of the FDOPS pin] HDA_SDO if
used to update the ME Region." [SPS]

When looking at the various ME firmware editions (and different chipsets), things
get very unclear. Some docs say that HMRFPO needs to be sent before End-of-POST
(EOP), others say that the ME region can be updated in the field or that some
vendor tools use it for updates. This needs to be investigated further before
drawing any conclusion.

[PANTHER] Intel 7 Series Chipset Family Platform Controller Hub (PCH) Datasheet
Document Number: 326776, April 2012, page 857
[NC9B] Jetway NC9B flashrom v0.9.5.2-r1517 log with ME region unlocked.
NB: "FRAP 0e0f" vs. "FLMSTR1 0a0b".
http://paste.flashrom.org/view.php?id=1215
[MODE_CTRL] Client Platform Enabling Tour: Platform Software
Document Number: 439167, Revision 1.2, page 52
[MEBX] Intel Management Engine BIOS Extension (MEBX) User's Guide
Revision 1.2, Section 3.1 and 3.5
[DCMI] DCMI Host Interface Specification
Revision 1.0
[KERNEL] http://git.kernel.org/?p=linux/kernel/gi...ei;hb=HEAD
[SPI_PROG] Ibex Peak SPI Programming Guide
Document Number: 403598, Revision 1.3, page 79
[ME8] Manufacturing with Intel Management Engine (ME) Firmware 8.X on Intel 7 Series
Revision 2.0, page 59
[SPS] Manufacturing with Intel Management Engine (ME) on Intel C600 Series Chipset 1
for Romley Server 2 Platforms using Server Platform Services (SPS) Firmware
Revision 2.2, page 51

If it's a mystery for these guys .. we are kind of screwed going down this route..