T480/s T480 (bzw. X270/T470/etc.): BIOS Advanced Menu (skyra1n) & me_cleaner

iks230

Well-known member
Themenstarter
Registriert
8 Dez. 2021
Beiträge
672
Ich hoffe mal bei der Forensuche kein Thema übersehen zu haben, was dies bereits behandelt.

Modfiziertes BIOS (erweiterte Optionen und ausgeschaltete Intel Management Engine) am Beispiel eines T480 (gleiche Patch-Datei lässt sich auch auf X270, T470, xx70 bzw. xx80 anwenden).

Ich konzentriere mich in der Anleitung auf einen CH341a als Programmer für den Chip. Alternativ kann auch ein Raspberry Pi verwendet werden (Links dazu weiter unter).

optional vorher anschauen bzw. durchlesen
benötigte Hard- und Software
  • zweiter Rechner mit Linux für flashrom (geht auch unter Mac mit Homebrew; Windows wohl eher schwierig)
  • CH341a (3,3 V-Version!) plus SOIC8-Clip und entsprechende Verkabelung / Adapter
Allgemeine Hinweise
  • BIOS-Passwörter entfernen und BIOS auf Werkeinstellungen zurücksetzen
  • BIOS mindestens zweimal auslesen und überprüfen, ob beide Dateien identisch sind (z. B. via Prüfsumme) und Sicherheitskope anfertigen
  • Akku entfernen bzw. internen Akku im BIOS deaktivieren
  • da das TPM betroffen sein kann: ggf. vorher das System entschlüsseln, wenn die Verschlüsselung auf TPM aufbaut
  • den Clip immer nur stromlos auf den Chip aufsetzen bzw. loslösen
  • viele CH341a liefern 5 V statt der geforderten 3,3 V (hier ein Fix oder auf die v1.6 ausweichen; Kauflinks weiter unten)
  • auslesen hat ca. zweieinhalb Minuten gedauert, zurückschreiben ca. viereinhalb Minuten
  • sollte irgendwas schiefgehen: Sicherheitskopie zurückflashen
BIOS Advanced Menu (bietet zum Beispiel Overclocking-Optionen)
  • BIOS auslesen
  • in der Patch-Datei die Patches, die nicht angewendet werden sollen, mit # auskommentieren
  • UEFIPatch plus Patch-Datei (z. B. xx70_xx80_patches_v7.txt) auf das ausgelesene BIOS anwenden
  • mit einem HEX-Editor den Wert 4C 4E 56 42 42 53 45 43 FB durch 4C 4E 56 42 42 53 45 43 FF ersetzen (z. B. Okteta)
  • modifiziertes BIOS zurückschreiben
Nachteil: TPM funktioniert nicht mehr, da das BIOS nicht mehr signiert ist bzw. TPM ist im Manufacturing (MFG) Mode (wobei manchmal Bitlocker doch noch zu gehen scheint; könnte aber ein Problem bei Windows 11 werden wegen TPM-Pflicht).

Beispiel Kommandozeilen-Befehle (mit einem CH341a):
Code:
sudo flashrom -p ch341a_spi -r bios1.bin # BIOS auslesen Nr. 1

sudo flashrom -p ch341a_spi -r bios2.bin # BIOS auslesen Nr. 2

sha512sum bios1.bin bios2.bin # sollte die gleiche Prüfsumme ergeben

diff bios1.bin bios2.bin # Alternative zu sha512sum: keine Ausgabe bedeutet "Dateien identisch"

nano xx70_xx80_patches_v7.txt # Patch-Datei bearbeiten bzw. Patches ggf. auskommentieren mit # (z. B. für X270)

./UEFIPatch bios1.bin xx70_xx80_patches_v7.txt -o bios_patched.bin # Patch anwenden

okteta bios_patched.bin # bios_patched.bin mit dem HEX-Editor bearbeiten

sudo flashrom -p ch341a_spi -w bios_patched.bin # BIOS zurückschreiben

Intel Management Engine abschalten
Beispiel Kommandozeilen-Befehle (mit einem CH341a):
Code:
sudo flashrom -p ch341a_spi -r bios1.bin # BIOS auslesen Nr. 1

sudo flashrom -p ch341a_spi -r bios2.bin # BIOS auslesen Nr. 2

sha512sum bios1.bin bios2.bin # sollte die gleiche Prüfsumme ergeben

diff bios1.bin bios2.bin # Alternative zu sha512sum: keine Ausgabe bedeutet "Dateien identisch"

./me_cleaner.py -s -O bios_ohne_me.bin bios1.bin

sudo flashrom -p ch341a_spi -w bios_ohne_me.bin # BIOS zurückschreiben

Links zu Raspberry Pi
Links, die mir weitergeholfen haben:
Beispiele für Terminal-Ausgaben:

BIOS auslesen:
Code:
$ sudo flashrom -p ch341a_spi -r bios1.bin
flashrom v1.2 on Linux 5.18.11-200.fc36.x86_64 (x86_64)
flashrom is free software, get the source code at https://flashrom.org

Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).
Found Winbond flash chip "W25Q128.V" (16384 kB, SPI) on ch341a_spi.
Reading flash... done.

Checksummen überprüfen:
Code:
$ sha512sum *
ebc50f6fbf58d4ff9f67a81487f18c1f[...] bios1.bin
ebc50f6fbf58d4ff9f67a81487f18c1f[...] bios2.bin

me_cleaner anwenden:
Code:
$ ./me_cleaner.py -s -O bios_ohne_me.bin bios1.bin
Full image detected
Found FPT header at 0x3010
Found 13 partition(s)
Found FTPR header: FTPR partition spans from 0x1000 to 0x130000
Found FTPR manifest at 0x1478
ME/TXE firmware version 11.8.92.4222 (generation 3)
Public key match: Intel ME, firmware versions 11.x.x.x
The HAP bit is NOT SET
Checking the FTPR RSA signature... VALID

mit me_cleaner den Status von ME auslesen:
Code:
$ ./me_cleaner.py -c bios_ohne_me.bin
Full image detected
Found FPT header at 0x3010
Found 13 partition(s)
Found FTPR header: FTPR partition spans from 0x1000 to 0x130000
Found FTPR manifest at 0x1478
ME/TXE firmware version 11.8.92.4222 (generation 3)
Public key match: Intel ME, firmware versions 11.x.x.x
The HAP bit is SET
Checking the FTPR RSA signature... VALID

BIOS zurückschreiben:
Code:
$ sudo flashrom -p ch341a_spi -w bios_ohne_me.bin
flashrom v1.2 on Linux 5.18.11-200.fc36.x86_64 (x86_64)
flashrom is free software, get the source code at https://flashrom.org

Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).
Found Winbond flash chip "W25Q128.V" (16384 kB, SPI) on ch341a_spi.
Reading old flash chip contents... done.
Erasing and writing flash chip... Erase/write done.
Verifying flash... VERIFIED.

BIOS patchen für Advanced Menu:
Code:
$ ./UEFIPatch bios1.bin xx70_xx80_patches_v7.txt -o bios_patched.bin
parseVolume: unknown file system FFF12B8D-7696-4C8B-A985-2747075B4F50
parseBios: one of volumes inside overlaps the end of data
parseFile: non-empty pad-file contents will be destroyed after volume modifications
patch: replaced 16 bytes at offset 3B60h 04320B483CC2E14ABB16A73FADDA475F -> 778B1D826D24964E8E103467D56AB1BA
patch: replaced 16 bytes at offset 118D0h 04320B483CC2E14ABB16A73FADDA475F -> 778B1D826D24964E8E103467D56AB1BA
patch: replaced 28 bytes at offset 6B80Ch 09072C1300000209072D1300000309072E1300000409072F13000005 -> 09072C1300001909072D1300001A09072E1300001B09072F1300001C
patch: replaced 58 bytes at offset 53B44h 00143100300030004D0068007A000000143100350030004D0068007A000000143200300030004D0068007A000000143200350030004D0068007A -> 00143100320035003000200020000000143100330030003000200020000000143100330035003000200020000000143100340030003000200020
patch: replaced 26 bytes at offset 69DDFh 0A821286A10B04001206A60B010016021206A60B020016022902 -> 0A821286A10B04001206A60B000016021206A60B000016022902
patch: replaced 11 bytes at offset 545h 0BC8394B040F8437020000 -> 0BC8394B04E93802000000
patch: replaced 5 bytes at offset 535h C8390B7516 -> C8390B7500
Image patched
 
Zuletzt bearbeitet:
Wie niedrig könnt ihr eure CPU undervolten? Und was für Cinebench R23 Werte bekommt ihr so?

Mein i7-8650U verträgt diese Werte ganz gut:

1729704898074.png

Cinebench R23 war auch meistens über 3700, je nach Randbedingung (z. B. Raumtemperatur / Länge des Tests).

Aber wie anderen bereits sagten: Was bei mir funktioniert, kann bei anderen direkt zum Absturz führen.
 
@iks230
Finde interessant das du Core / Cache um die Hälfte unterschiedlich hast. Hatte null Ahnung von der Materie und hab ein paar Guides von dem Author von Throttlestop gelesen und was ich so mitgenommen hab war das Core / Cache immer ein Wert-Paar sind. Genauso wie GPU undiGPU Unslice und alles andere zur dunklen Seite der Macht Instabilität führen würde.

Cool zu sehen was da scheinbar doch geht! Evtl. muss ich in die Richtung auch nochmal mehr experimentieren.

@Ambrosius ich würde eigentlich gar nicht ausschließen das man vom UEFI den EC beeinflussen kann. Du kannst ja auch den internen Akku hieraus deaktivieren und bei anderen Geräten z.b. einem HP-Laptop von mir kann man sehr gut den Akku aus dem UEFI in einem AC-Mode setzen wo er dann nur noch bis 80% läd. Bi einem naja jetzt wirds speziell Nova Custom NV41PZ von mir ist es völlig normal die Ladeschwellen in dem Coreboot-UEFI zu setzen das sie von 3mdeb programmieren haben lassen.

Also vermutlich hat der Embedded Controller Schnittstellen um diesen vom UEFI aus zu beinflussen. Von Linux aus kann ich es ja auch über die sys/class Werte und Vantage wird ja ähnlichen Zauber machen unter Windows.
 
Hab jemand noch das Problem das seit dem aktuellen Firmware Update welches man beim Microsoft Update bekommt die CPU auf 15w. Begrenzt wird? Habs jetzt an zwei T480 getestet, Pl1 steht auf 25w, Pl2 auf 30, Trotzdem zieht die Cpu nur kurz 28 und nach ein paar Sekunden nur noch 15W. Hab am Gerät nichts geändert ausser die neuen Updates über Windows Update installiert….
 
24H2? Hast du das mit einem Stresstest verifizieren können? Hast du mit nem Tool den Verbrauch gemessen oder an der Wand?
 
Ich benutze die aktuelle Windows 10 Version, und Ja ich konnte das natürlich verifizieren habs mit HWinfo ausgelesen.

Cinebench R23 mit 15 Watt= 3155 Punke
Cinebench R23 mit 25Watt = 4300 Punkte

Folgendes ist mir aufgefallen:

Wenn ich den Rechner Runterfahre und Neustarte bekomme ich wieder die volle Leistung.
Wenn ich aber nur einen Neustart durchführe Drosselt er direkt auf 15W ab.
 
Zuletzt bearbeitet:
Also aus der Changes in this Release Beschreibung geht davon nichts hervor https://download.lenovo.com/pccbbs/mobiles/n24uj39w.html für die Nutzer in diesem Thread macht die 1.52 ja doppelt keinen Sinn weil damit das Advanced-Menu nicht funktioniert was man hier ja möchte und zudem übers Windows-Update hierfür auch der völlig falsche Weg wäre.

Kannst ja einfach probieren @xjocker. Hier war ja kürzlich beschrieben wie der Weg zurück zur 1.51 geht und dann würd ich im Bios einstellen das man aus Windows nimmer flashen kann dann dürften auch die Windows-Nutzer sicher vor derartigen Zwangs-Updates sein.
 
@iks230
Ich weiß nicht ob das noch ein nenneswerter Nachteil für deinen hervorragenden Startpost wäre:

Das Advanced-Menu im UEFI taucht exakt an der Stelle auf wo du sonst Datum/Uhrzeit einstellen würdest, was du dann halt im UEFI nicht mehr kannst. Das Advanced-Menu überschreibt diesen zuvor vorhandenen Menüpunkt sozusagen.

Zumindest hab ich es nicht unter einem anderen Untermenü gefunden. Das wird bei unseren neuzeitlichen OS vermutlich nie ein Problem sein weil aj sowohl WIndows als auch LInux wie auch immer die RTC aktualisieren.

Ich weiß aber nicht ob es nicht evtl. eins werden könnte wenn alle Akkus beim Gerät leer waren + CMOS Battery und du versuchst ein neues OS zu installieren und die RTC plötzlich sagt hallo ich bin vom 01.01.1970 oder so.
 
Hallo,

mal eine Frage, da ich gerade das BIOS 1.52 auf eines meiner t480 bringen wollte: Geht das Deaktivieren der Management Engine mit me_cleaner dann noch? Das mit dem Advanced-Menu hatte ich bisher nicht genutzt, das wäre kein Problem.

Grüße, pepun.
 
@iks230
Ich weiß nicht ob das noch ein nenneswerter Nachteil für deinen hervorragenden Startpost wäre:

Das Advanced-Menu im UEFI taucht exakt an der Stelle auf wo du sonst Datum/Uhrzeit einstellen würdest, was du dann halt im UEFI nicht mehr kannst. Das Advanced-Menu überschreibt diesen zuvor vorhandenen Menüpunkt sozusagen.

Zumindest hab ich es nicht unter einem anderen Untermenü gefunden. Das wird bei unseren neuzeitlichen OS vermutlich nie ein Problem sein weil aj sowohl WIndows als auch LInux wie auch immer die RTC aktualisieren.

Ich weiß aber nicht ob es nicht evtl. eins werden könnte wenn alle Akkus beim Gerät leer waren + CMOS Battery und du versuchst ein neues OS zu installieren und die RTC plötzlich sagt hallo ich bin vom 01.01.1970 oder so.
Dafür kann man ne Efi shell laden und dann time / date updaten.
 
Hallo,

mal eine Frage, da ich gerade das BIOS 1.52 auf eines meiner t480 bringen wollte: Geht das Deaktivieren der Management Engine mit me_cleaner dann noch? Das mit dem Advanced-Menu hatte ich bisher nicht genutzt, das wäre kein Problem.

Grüße, pepun.
Meines Wissens nach geht das nicht so ohne Weiteres. Da das Update noch recht neu ist, ist das noch quasi Neuland. Laut dem Changelog sind da einige CVEs geschlossen wurden, kann also gut sein dass da Bios Mods nochmal bissi was anpassen müssen. Wäre aber nicht das erste mal dass man sein Bios downgraden muss, um es erfolgreich patchen zu können, war bei 1vyrain auch Pflicht, beim Middleton weiss ich es gerade nicht.
 
Das Problem ist so ein bisschen die Abwägung ... ME deaktivieren und Version 1.51 vs. irgendwelche geschlossenen Lücken mit Version 1.52. Da mir aber nicht der ganze Änderungssatz der neuen Version nachvollziehbar ist (https://thinkpad-forum.de/posts/2406601/) , ist die Abwägung auch schwierig.

Am Ende werde ich es wohl mal in einer ruhigen Minute testen mit Flasher.
 
@pepun Ich hab deinen anderen Thread dazu gesehen und ich weiss genau was du meinst. Ich hab die spärlichen Details zu den CVEs auch gesehen, aber weiss auch nciht mehr wie du zum jetztigen Zeitpunkt. Deswegen bin ich erstmal davon ausgegangen, dass das so passt. Wenn du das mal testen willst und berichtest, würdest du allen natürlich einen großen Dienst erweisen. Wenn du vorher einfach ein Backup deines jetzigen funktionieren Dumps erstellst, kannst du es immer wieder zurückspielen, wenn dein T480 mit 1.52 nicht mehr booten will. Das im schlimmsten Fall, in einem weniger schlimmen Szenario kann ich mir dann nur vorstellen, dass die Intel ME wieder reaktiviert wird. Das kann ich mir aber nicht vorstellen, da im Changelog davon keine Erwähnung zu finden ist:

Version 1.52 (UEFI BIOS)

1.22 (ECP)



[Important updates]

- Enhancement to address security vulnerability,CVE-2024-29979, CVE-2024-29980.

- Enhancement to address security vulnerability,CVE-2024-24853.

- Enhancement to address security vulnerability,CVE-2023-45236, CVE-2023-45237.



[New functions or enhancements]

- Updated the Diagnostics module to version 04.35.000.

- Updated the CPU microcode.

(Note) Above update will show "Self-Healing BIOS backup progressing ... xx %"

message on screen during BIOS update process.



[Problem fixes]

Nothing
Ich vermute dass es der CPU Mircocode ist, der da irgendwas mit der alten Konfiguration bricht. Kenn mich aber mit den Delikatessen der Intel CPU Microcodes nicht gut genug aus. Wäre natürlich schön wenn man von Intel bissi Transparenz bekäme, was man da eigentlich updated...
 
Also ich glaube das driftet etwas ab und ist leider auch viel falsch:

Microcode-Update:
Das Microcode-Update der CPU wird mitnichten für das nicht mehr funktionieren des Advanced-Bios in der 1.52 verantwortlich sein.
Es besteht hier im Gegensatz zur Aussage von Ambrosius schon eine transparente Lage. Das Zeuch geht einfach über Github her und ist da in den Release-Notes weitestgehend dokumentiert. Nicht das "Normalos" wie wir da viel verstehen würden immer aber im großen und ganzen für Tech gut dokumentiert.


Ich muss kein Microcode-Update im Bios machen, sowohl Windows als auch LInux unterstützen Early-Loading.

CVE (Common Vulnerabilities and Exposures):

Die CVE kann man ebenso googlen da gibt es eine Datenbank wen das interessiert.


Wenn mich z.B. interessiert was ist denn diese CVE-2024-24853 aus dem 1.52er Update vom T480?


Incorrect behavior order in transition between executive monitor and SMI transfer monitor (STM) in some Intel(R) Processor may allow a privileged user to potentially enable escalation of privilege via local access.

Mitunter ist das CVE-Release auf dieser Seite arg zeitversetzt wie bei den Browser-Sicherheitslücken auch da man versucht erst eine große Anzahl an Systemen ins Update zu bekommen bevor man die Sicherheitslücke nennt.


TL;DR: Microcode-Updates und CVE sind weitestgehend gut dokumentiert und kein Geheimwissen., das Microcode-Update für ein nicht mehr funktionieren des Patches verantwortlich sind ist mit an Sicherheit grenzender Wahrscheinlichkeit nicht zutreffend. Die Behebung einer CVE im Phoenix-Bios könnte dafür eher wahrscheinlich sein. Sozusagen als Nebeneffekt.


Advanced-Menu
Lenovo verwendet hier ein Phoenix-Bios bei diesen Thinkpads. Wer schonmal z.B. ein China-Gerät z.B. miniPC mit Phoenix-Bios hatte sieht was da eigentlich an Optionen in einem Stock-Bios drin ist weil die es einfach offen lassen.. Das es bei den Thinkpads nicht so ist, beruht einfach auf der Entscheidung von Lenovo in deren Phoenix-Bios solch ein Menü nicht anzuzeigen weil der Nutzer zu viel kaputt machen kann. Es handelt sich also um eine spezielle Anpassung von Lenovo und der Schalter war halt bisher an einer Stelle es kann sein das durch Updates in dem Bios der Schalter jetzt wo anders ist oder anders funktioniert oder die Zugriffsmöglichkeit selbst als CVE klassifiziert war. Das Advanced-Menu kann jedes Stock-Phoenix-Bios das ist selbst keine CVE.


Intel-ME
Ja über was reden wir da eigentlich?
Tatsächlich wird das zu viel um es vernünftig zu erklären vielleicht wenig ganz einfach. Auf eurem Motherboard ist ein Chip, vielleicht auch mehrere Chips die beeinhalten zusammen mehrere Datenbereiche. Die Datenbereiche werden über den FlashDescriptor in ihrer Größe definiert, gleichzeitig ist der IFD auch der erste Bereich. Ein Bereich davon ist der ME-Bereich den es seit 2006 gibt. Dieser Bereich ist autark und kann seine eigenen Prozesse in der PCH oder in der CPU in eigenen Mikrocontrollern laufen lassen. Das sogar unabhängig davon ob euer PC an ist oder nicht solang er nur Strom hat.

Es ist u.a. für Management-Aufgaben und Fernwartung gedacht, viel ist dokumentiert, viel aber auch nicht.

Aluhutträger bezeichnen ME gemeinhin als Blackhole der Sicherheit und fürchten staatliche Akteure die mittels darin befindlichen für Sie bewusst gelassenen Lücken Zugang zu Daten von Geräten ihrer Ziele bekommen könnten. Wie später beschrieben ist zumindest auffällig dass auf Hardware von US-Nachrichtendiensten zumindest in dem Fall aus 2017 derartiges weitestgehend deaktiviert war. Die häufigen ME-Sicherheitslücken mögen ihnen recht geben. Erschwerend hierzu ist das durch die jeweiligen Mainboard-Hersteller also die OEM Anpassungen an ME Firmware vorgenommen werden können weshalb Intel selbst keine Sicherheitspatches hierfür ausliefert sondern an die Hersteller verweist. Mit Lenovo haben wir Glück die Release-History ist lang sieht man ja z.B: beim T480. Wenn man jetzt ein Produkt eines anderen Herstellers kauft kann es schon wieder anders aussehen. Es gibt dokumentierte Angriffsversuche verschiedenster Gruppen z.B. conti, vgl. https://www.golem.de/news/conti-ransomware-gruppe-arbeitet-an-exploit-fuer-intel-me-2206-165848.html


Das Wo:
Folgendes Bild hab ich von Coreboot ausgeliehen und stellt ein Lenovo Layout eines 8MB Chips aus der SandyBridge-Generation dar, das ist alles wesentlich komplizierter und mit jeder Generation immer noch komplizierter, der Bereich vom EmbeddedController ist am Beginn der Bios-Region hier nicht eingezeichnet:

Quelle: https://doc.coreboot.org/mainboard/lenovo/Sandy_Bridge_series.html

1730459496368.png



Wer in den 2000er Jahren BastardOperatorfromHell gelesen hat weiß um was es geht. Nein ernsthaft auch hier wieder zwei Dinge: Das Advanced-Menu bringt die Möglichkeit mit Intel-ME zu deaktivieren, wie auch immer das passiert. Ich weiß nicht ob und wie weit das Advanced-Menu dokumentiert ist müsste man sich anschauen. Vielleicht ist es auch nur eine Option wo die Bios Region aufhört sich als Schnittstelle zwischen Betriebssystem und EC zur ME zur Verfügung zu stellen und damit einfach denkt hey hier ist kein ME. Ich weiß es tatsächlich nicht.


Folgende von Heise vgl. https://www.heise.de/select/ct/2018/6/1520827829694087

Das Was:

Die ME steckt seit 2006 in jedem PC mit Intel-Prozessor. Der Mikrocontroller sitzt entweder im Chipsatz, den Intel Platform Controller Hub (PCH) nennt, oder bei System-on-Chip-(SoC-)Prozessoren wie Intel Atom im Prozessor selbst. Die ME-Firmware ist auf proprietäre Weise komprimiert und digital signiert, um sie vor Manipulationen zu schützen; sie liegt im selben SPI-Flash-Chip, der auch den Code des UEFI-BIOS speichert.

Warum "böse"?

Die ME ist nicht vollständig dokumentiert, die Firmware teilweise geheim. Daher ist der genaue Funktionsumfang unklar. Gleichzeitig läuft die ME jedoch unabhängig vom eigentlichen System und hat dabei Zugriff auf das gesamte RAM, sämtliche Schnittstellen und Bussysteme (PCI Express, USB, SATA, …), auch auf das Netzwerk. Ein unkontrollierbares System mit unklarem Funktionsumfang, das Zugriff auf sämtliche Daten hat, stellt ein potenzielles Sicherheitsrisiko dar, weil es Sicherheitslücken oder Hintertüren enthalten könnte.




Die "anerkannte" Methode um weitestgehend zu deaktivieren.
der ME-Cleaner, vgl. https://www.golem.de/news/firmware-...-aktueller-intel-plattformen-1906-141942.html


Grundlage:
Los gings 2016 / 2017 hiermit: https://web.archive.org/web/2021080...tsecurity.com/2017/08/disabling-intel-me.html

Tatsächlich hat diese Truppe von Sicherheitsforschern soweit mir bekannt durch Reverse-Engineering von ehemaliger US-Regierungs-Hardware eine in den Intel-Dokmentationen nicht enthaltene Einstellung gefunden mit der ein weiter Teil der Funktionen der Intel-Me durch das setzen des sog. HAP-Bit auf dieser Hardware deaktiviert war. Das wurde dann in den Intel-ME-Cleaner übernommen. Soweit ich weiß funktioniert das auch nur bis IntelME 11 Versionen. Der superintelligente Kopf hinter dem me_cleaner macht aktuell wohl auch seinen Doktor in irgendwelchen Todeswissenschaften weshalb da auch nix mehr kommt. Obs irgendwer forkt und ob das überhaupt für 12+x Versionen auch gehen wird mal sehen.


Vgl. https://github.com/corna/me_cleaner/wiki/me_cleaner-status

1730462064480.png

Borns hat das mal soweit auf deutsch zusammengfasst wer mag:



TL;DR: Intel-ME ist nicht grundsätzlich böse oder problembehaftet es lässt sich auch in der Intel-ME Version 11.x schon nicht mehr vollständig deaktivieren sondern lediglich Teilbereich davon. Was man jetzt halt hat ist das me-cleaner-Projekt vgl. https://github.com/corna/me_cleaner
Auch hier wieder sehr viel zu lesen, evtl. mitnehmen kann man https://github.com/corna/me_cleaner/wiki/How-does-it-work?

Zitat:

ME versions from 11.x (Skylake)

Starting from ME version 11 the internal structure of the partitions has changed substantially. The modules are now indexed in the CPD, the Code Partition Directory, where the partition manifest (the same partition manifest of the previous ME versions), the modules metadata and data are listed. To remove a module (uncompressed, Huffman or LZMA) it's sufficient to look for its offset in the CPD and remove the data from that offset to the following one.


Since there isn't a Huffman LLUT anymore (the Huffman-compressed data is now in a single stream, one for each module), the relocation of a partition is trivial, as it is sufficient to move the data and correct the offset in the FPT.


Das ist der Grund warum wir eben das soft disable nutzen was im Endeffekt nix anderes ist was man in dieser NSA-Hardware festgestellt hat (HAP-Bit) und vielleicht auch das ist was das Advanced-Menu setzt oder nicht.


Soft-disable​

With the -S/-s options, me_cleaner sets the HAP (for ME >= 11) or MeAltDisable (for ME < 11) bit, which ask Intel ME to disable itself after the hardware initialization.

Das sieht dann so aus wenn man deren Python-Skript auf ein ROM mit der Intel-Me Partition anwendet.

anton@CorebooT440p:~/t480/rom/patch/work$ /home/anton/t480/rom/patch/me_cleaner/./me_cleaner.py -s -O bios_removed_me.bin bios1.bin
Full image detected
The ME/TXE region goes from 0x3000 to 0x700000
Found FPT header at 0x3010
Found 11 partition(s)
Found FTPR header: FTPR partition spans from 0x1000 to 0xa8000
Found FTPR manifest at 0x1478
ME/TXE firmware version 11.8.92.4222
Public key match: Intel ME, firmware versions 11.x.x.x
The HAP bit is NOT SET
Setting the HAP bit in PCHSTRP0 to disable Intel ME...

Checking the FTPR RSA signature... VALID
Done! Good luck!
anton@CorebooT440p:~/t480/rom/patch/work$

Genaugenommen machen wir ja mit "-s" schon die kleinstmöglichste Veränderung weil ja iks230 auch schon negative Erfahrungen hatte mit -S wie er im Startpost schreibt.

You should try first with -S (code removal + HAP/AltMeDisable bit) and, if it doesn't work, fallback to no arguments (code removal only) and, as last chance, -s (HAP/AltMeDisable bit only).

Sprich Stufenprogramm von groß nach klein, damit setzen wir nur das Bit löschen keinen Code.


TL;DR: Der Bios Version 1.52 ist höchstwahrscheinlich völlig egal ob du die INTEL-ME mittels ME_Cleaner über Soft-Disable HAP-Bit setzen in "weitestgehend" deaktiviert schickst. Das sind unabhängig voneinander laufende Konstrukte.



Leider ist das alles sehr viel zu lesen und zu denken wenn man da etwas Einblick bekommen will und es steht eigentlich auch nirgendwo alles weshalb man massiv in der Gegend rum springt. Leider² sieht es im AMD-Bereich nicht besser aus, bei denen heißt das vergleichbare Konstrukt PSP. Nur ist da noch viel weniger dokumentiert oder bekannt. Möglichkeiten da etwas zu umgehen gibt es m.W. nicht.

Der Ansatz von Coreboot ist z.B. meist / häufig die ME-Region zu verkleinern nachdem zuvor mittels ME-Cleaner der Inhalt reduziert wurde geht das. Dann wird dieser Eingangs erwähnte IFD Bereich verändert und man hat dann den gewonnen Platz aus dem ME-Bereich als zusätzlichen Bereich für den eigenen Payload.
 
Zuletzt bearbeitet:
Hallo,

mal eine Frage, da ich gerade das BIOS 1.52 auf eines meiner t480 bringen wollte: Geht das Deaktivieren der Management Engine mit me_cleaner dann noch? Das mit dem Advanced-Menu hatte ich bisher nicht genutzt, das wäre kein Problem.

Grüße, pepun.

Ich kann zumindest sagen, dass das Update auf die aktuellste BIOS-Version nichts reaktiviert hat. Sieht also noch so aus wie dort (also die Ausgabe in der PowerShell und die Ansicht im BIOS):



Ansonsten gilt soweit ich weiß das, was @KNARZ dort beschreibt, also BIOS, ME etc. liegen un verschiedenen Bereichen und daher überlebt die Abschaltung auch ein Update:

 
@iks230

Meine Internet-Streifzüge haben was interessantes herausgefischt.


Soweit so gut es ist ein X1 Carbon Gen6 (hier funktionieren die xx80 Patches d.h. gleiches Phoenix-Bios gleiche Struktur)

Bis auf das ich gar nicht verstehe warum sich der Herr so sehr über xdci freut stelle ich folgendes fest:

Er macht eigentlich was ziemlich cooles, er patcht das Advanced-Menu rein (bis hier nichts neues). Dann setzt er über die dortige Option sein XDCI stellt dann im Vergleich zum Dump vom Original-Bios fest was sich dadurch im NVRAM seines MOD-Bios ändert und übernimmt dann nur die Änderung im NVRAM in sein Original-Bios Dump und hat also sozusagen den entsprechenden Wert oder Option freigeschaltet ohne das Bios als solches zu verändern und umgeht damit den zerbrochenen Bootguard&TPM im MFG-Mode.


Ich bin leider nicht in der Lage nachzuvollziehen wie er das umsetzt aber das hier ist so der interessante Passus:

1730635994507.png


TL;DR: Wenn man verstehen würde wie das funktioniert könnte man also Wert ändern ohne Nachteile man müsste halt immer doppelt arbeiten sprich advanced - ändern - geänderte byte sequence feststellen - geänderte byte sequence zurückins original schreiben - flashen - profit.
 
Jupp das ist alles bekannt. Wenn man nur eine ganz bestimmte Sachen ändern möchte dann kann man das so quasi machen bzw. einfacher ist einen Dump der Variable mittels EFI Shell zu machen, den zu bearbeiten (Checksumme nicht vergessen) und dann zu importieren. Das ganz Thema nennt sch IFR (extractor) damit kann man sich anhand der Binary des Bios-Menü-Abschnitts (Advanced ist so ein Abschnitt) die Settings anzeigen lassen. Anhand des Varstores und der Question bzw. dem Offset und des Werts kann man dann die Position (meist ein eigenes Byte) der gewünschten Funktion im Varstore ermitteln und dann anpassen. Ganz oft wird bei diesen Sachen auf ein Tool bzw. veränderten Grub_loader verwiesen und nennt sich "setup_var" bzw. var2 usw. usw. damit kann man dann die die NVData / VarStore am Offset mit dem gewünschten Value beschreiben. Das funktioniert aber scheinbar nicht bei th ThinkPad Phoenix Bios, eher Ideapads (Insyde Bios)

MIt xDCI kann man Intel CPUs auf 'nem recht niedrigem level debuggen. Viel mehr Ahnung hab ich von der Thematik bei Intel jedoch nicht.
 
Ohmann KNARZ das klingt sehr interessant ich weiß leider noch null wie das umsetzbar wäre aber möchte mich massiv einlesen. Ich häng irgendwo in der Theorie fest und wir vergleichen sinnlos dumps und dann werden doch wieder andere EFIVARS allein schon beim Boot random geändert und wir versenken masiv Zeit in was das nicht funktioniert :D.

In unserem Fall ist ja praktisch immer das gleiche Zeuch interessant:

Hackintosh Builds:
1730646836769.png

Undervolting:

1730646864276.png
Grafiken entnommen von hier: https://tylernguyen.github.io/x1c6-hackintosh/BIOS/settings-for-modded-BIOS/
 
Zuletzt bearbeitet:
Das beste und eigentlich auch einzige All-In-One Tool ist das hier:

Darin kannste den Dump genauer anschauen. Funktioniert eigenltich gut mit ThinkPads, da ich ihm auch paar Error Reports geschickt habe. ;)

Man muss sich dann mal alles genauer anschauen und reinfuchsen. Hier aber schon mal ein gewisser Schnellstart. Es kann aber auch sein das ich etwas falsch liege. Bei mir ist das jetzt schon paar Jahre her das ich mich sehr intensiv damit beschäftigt habe.

Pseudo-denk-workflow:
- Abfrage finden dessen Wert ich ändern möchte
- Checken in welcher Variable der Wert gespeichert wird (SaSetup)
- Offset der Variable bearbeiten, speichern, einspielen



Beispiel für DVMT bei einem T480s Dump in relevanten Auszügen:

efivarstore varid = 0x0002,
attribute = 0x00000007,
name = SaSetup,
guid = 72C5E28C-7783-43A1-8767-FAD73FCCAFA4;

...

suppressif
ideqval 0x0002 == 32;
oneof
varid = 0x0002,
/*varoffset = 0x00DF*/
questionid = 0x0357,
prompt = STRING_TOKEN(STR_0x126C) /*DVMT Pre-Allocated*/,
help = STRING_TOKEN(STR_0x127F) /*Select DVMT 5.0 Pre-Allocated (Fixed) Graphics Memory size used by the Internal Graphics Device.*/,
flags = 0x0010,
maximum = 0x254,
minimum = 0x0,
default value = cond(ideqvallist 0x0002 == 115 116 ? 0 : 0), defaultstore = 0x0000,
option text = STRING_TOKEN(STR_0x126D) /*0M*/, value = 0, flags = 0x00;
option text = STRING_TOKEN(STR_0x126E) /*32M*/, value = 1, flags = 0x00;
option text = STRING_TOKEN(STR_0x126F) /*64M*/, value = 2, flags = 0x00;
option text = STRING_TOKEN(STR_0x1270) /*4M*/, value = 240, flags = 0x00;
option text = STRING_TOKEN(STR_0x1271) /*8M*/, value = 241, flags = 0x00;
option text = STRING_TOKEN(STR_0x1272) /*12M*/, value = 242, flags = 0x00;
option text = STRING_TOKEN(STR_0x1273) /*16M*/, value = 243, flags = 0x00;
option text = STRING_TOKEN(STR_0x1274) /*20M*/, value = 244, flags = 0x00;
option text = STRING_TOKEN(STR_0x1275) /*24M*/, value = 245, flags = 0x00;
option text = STRING_TOKEN(STR_0x1276) /*28M*/, value = 246, flags = 0x00;
option text = STRING_TOKEN(STR_0x1277) /*32M/F7*/, value = 247, flags = 0x00;
option text = STRING_TOKEN(STR_0x1278) /*36M*/, value = 248, flags = 0x00;
option text = STRING_TOKEN(STR_0x1279) /*40M*/, value = 249, flags = 0x00;
option text = STRING_TOKEN(STR_0x127A) /*44M*/, value = 250, flags = 0x00;
option text = STRING_TOKEN(STR_0x127B) /*48M*/, value = 251, flags = 0x00;
option text = STRING_TOKEN(STR_0x127C) /*52M*/, value = 252, flags = 0x00;
option text = STRING_TOKEN(STR_0x127D) /*56M*/, value = 253, flags = 0x00;
option text = STRING_TOKEN(STR_0x127E) /*60M*/, value = 254, flags = 0x00;
endoneof;
endif;

---


1730652284884.png


Es hilft wenn man sich die langen Texte in Notepad kopiert. Andere Tools (IFR Extractor usw) machen etwas schönere Darstellungen, aber dazu muss man mit dem UefiTool auch erst wieder die richtie EFI Datei aus dem Dump extrahieren, da kann man kein Dump reinladen. So ist das einfacher.

Ehrlich gesagt einfach viel mit dem Tool herumspielen und irgendwann versteht man die Zusammenhänge.
 
Herzlichen Dank für den Einblick, das scheint ein längerfristiges Projekt zu werden bei dem die Backplate vom T480 besser nen Reißverschluss hat :D.
 
Keiner zwingt dich die zu verschrauben... oder mehr als eine zu nutzen ^^
Alternativ ein EM100Pro ^^
 
  • ok1.de
  • ok2.de
  • thinkstore24.de
  • Preiswerte-IT - Gebrauchte Lenovo Notebooks kaufen

Werbung

Zurück
Oben