Mac Pro 5.1 Rom / Firmware Backup Beschreibung und technischer Hintergrund

Macschrauber

Aktives Mitglied
Thread Starter
Mitglied seit
08.02.2014
Beiträge
6.763
Da ich immer wieder gebetsmühlenartig ein Rom Backup fordere hier eine Beschreibung des Vorgangs:


Backup des Roms (Firmware "Bios" des Mac Pros)

dieses Tool laden http://dosdude1.com/apps/ROMTool.zip

Password: rom

damit erstellt man eine Sicherung (Dump System Rom)


Ab 10.11 El Capitan ist es dazu notwendig rootless/sip vorübergehend auszuschalten

https://www.heise.de/mac-and-i/tipp...ection-SIP-in-macOS-deaktivieren-3946690.html



Erklärung warum:

Die Firmware des Mac Pros kann korrumpiert werden.

Der Bereich in der Firmware welcher für Systemspeicher benutzt wird ist nur 192 Kilobyte groß. Ein Teilbereich davon ist das was wir als nvram kennen und auch mit pram reset löschen können. Aber nicht die vollen 192 kb. Einen kleinen Teil dieses Bereiches kann man mit einem 3fachen NVRam reset löschen.

nvram = pram. pram ist ein historischer Begriff als das noch durch die Speicherbatterie gestützt wurde, hat sich als Begrifflichkeit festgesetzt und sich auch noch im Affengriff (alt-cmd-p-r) gehalten.

In diesem Bereich werden Speicherkonfigurationen, abgebrochene Installationen, Logs von Kernel Panics usw usw usw gespeichert.

Da der Bereich schnell voll wird kann es passieren dass er überfüllt wird. Ähnlich wie bei einem Betriebssystem dem der Massenspeicher ausgeht.


Zu allem Unglück speichert auch noch Windows im Uefi Mode fälschlicherweise Zertifikate in diesem knappen Bereich. Und das möglicherweise mehrmals. Windows sieht unser Efi als Uefi und behandelt es falsch.

Im schlimmsten Fall ist das Rom nicht mehr startfähig und muss durch Eingriff in die Hardware repariert werden. Ohne ein Backup des Roms ist das nicht möglich weil im Rom auch verschiedene Hardwarekennungen gespeichert werden. Das ist nicht nur die Seriennummer. Ohne gültige Hardwarekennungen funktionieren die Apple Dienste nicht mehr, der Mac verliert seine verifizierbare Identität.

Da für neuere Betriebssysteme Firmwareupdates notwendig sind kann dabei immer etwas schief gehen. Der SPI Flash Chip auf dem die Firmware gespeichert wird kann ausfallen, eine Firmware die nahezu voll war kann "überlaufen" - oder es kann durch Hard- oder Softwarestörung der Updatevorgang unterbrochen werden.

Besonders betroffen von diesen Firmware "bricks" sind 4.1er die zum 5.1er durch Upgrade geworden sind. Deren Firmware ist duch das Upgrade nicht so "sauber" wie echte 5.1er.

Dann wäre die Rettung den Chip auszulöten und extern mit dem Backup wieder zu programmieren - oder bei Ausfall des Chips persönlich einen neuen zu verwenden.

Wenn die Firmware komplett "verhunzt" ist dann besteht die Möglichkeit die Firmware aus dem Backup neu aufzubauen. Wie das funktioniert ist nicht öffentlich dokumentiert. Bei Bedarf kann ich helfen.
 
  • Gefällt mir
Reaktionen: tocotronaut, nonpareille8, lafranka und 9 andere

Macschrauber

Aktives Mitglied
Thread Starter
Mitglied seit
08.02.2014
Beiträge
6.763
-
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Indio

Indio

Aktives Mitglied
Mitglied seit
16.06.2004
Beiträge
1.385
@Macschrauber

die frage ist, was löscht es noch alles aus dem NVRAM?


zumindest ist bei mir nach dem reset eine neue XML dazu gekommen!


Screenshot 2020-04-13 at 18.11.49.jpg

und ein zurückflashen eines gespeicherten bootROM ohne XML ändert nichts - die bleiben !?!

überseh ich da etwas?
 
Zuletzt bearbeitet:

Macschrauber

Aktives Mitglied
Thread Starter
Mitglied seit
08.02.2014
Beiträge
6.763
hier stand dass OpenCore's nvram reset Zertifikate löschen kann.

Allerdings hat @Indio festgestellt dass bei ihn ein zweites Konfig File ins Nvram geschrieben wird.

Auch mit einem komplett leeren, neu aufgebauten Rom.

Das sollte nicht sein und kann man so noch nicht empfehlen bis das geklärt ist.

Deshalb wurden die Beiträge von mir gelöscht.
 
Zuletzt bearbeitet:

Macschrauber

Aktives Mitglied
Thread Starter
Mitglied seit
08.02.2014
Beiträge
6.763
@Macschrauber
ein zurückflashen eines gespeicherten bootROM ohne XML ändert nichts - die bleiben !?!

überseh ich da etwas?
Du kannst unmittelbar direkt, in der gleichen Minute ohne Neustart nach dem Flashen das Rom wieder mit RomTool auslesen, sollte das nicht 100% gleich sein dann ist mit Deinem Flash IC was nicht in Ordnung und es muss neu. Die eine XML wird wahrscheinlich beim Booten neu angelegt.

Hab Dir ein Rom neu gebaut, ganz ohne alles.
 

Macschrauber

Aktives Mitglied
Thread Starter
Mitglied seit
08.02.2014
Beiträge
6.763
Ich hab den Selbstversuch gemacht und ein 5.1 Rom geflasht was zwei Windows Uefi Zertifikate enthielt.

Nvram Reset mit OpenCore 0.57

Und es wurden die Zertifikate NICHT gelöscht

Code:
DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             UEFI PI Firmware Volume, volume size: 196608, header size: 1, revision: 0, Variable Storage, GUID: FFF12B8D-7696-4C8B-85A9-2747075B4F50
2022          0x7E6           Certificate in DER format (x509 v3), header length: 4, sequence length: 986
67558         0x107E6         Certificate in DER format (x509 v3), header length: 4, sequence length: 986
163863        0x28017         bzip2 compressed data, block size = 100k
 

Indio

Aktives Mitglied
Mitglied seit
16.06.2004
Beiträge
1.385
allerdings hat er nie wieder was darüber geschrieben und daher
denk ich eher das er sich geirrt hatte.
 

Macschrauber

Aktives Mitglied
Thread Starter
Mitglied seit
08.02.2014
Beiträge
6.763
naja, die Jungs haben ja auch alle Rom Backups (hint hint hint :) )
 
  • Gefällt mir
Reaktionen: Indio

Macschrauber

Aktives Mitglied
Thread Starter
Mitglied seit
08.02.2014
Beiträge
6.763
Wenn MacOS nicht mehr startet gibt es noch eine zweite Möglichkeit eines Rom Backups

Mit Linux bzw. Linux Stick / DVD)

(gerade getestet, Elementary OS und grml. Sicherlich auch noch etliche andere Distributionen)

Code:
sudo flashrom -p internal -r myrom.bin
der umgekehrte Weg des Schreibens einer "leeren" oder bereinigten Firmware sollte auch funktionieren.

Das könnte eine Rettung sein wenn MacOS nicht mehr startet.
 
  • Gefällt mir
Reaktionen: electricdawn und Indio

Macschrauber

Aktives Mitglied
Thread Starter
Mitglied seit
08.02.2014
Beiträge
6.763
Ich tu mich "als Windows Dau" immer schwer festzustellen ob das Ding jetzt in Bios/Legacy oder im Uefi mode läuft.
Ohne dass man Windows starten muss (und riskiert sich Zertifikate einzufangen) kann man feststellen was für eine Installation man auf der Platte / SSD hat:

Um herauszufinden, ob eue Windows-10 Installation das BIOS oder UEFI nutzt, macht ihr Folgendes:


  1. Navigiert zum Ordner \Windows\Panther
  2. Öffnet die Datei setupact.log mit einem Editor, zum Beispiel Text-Edit
  3. Drückt die Tastenkombination cmd + F, um den Suchen-Dialog zu starten.
  4. Tippt dort Detected Boot Environment ein und bestätigt mit der Eingabetaste.
  5. Hinter der gefundenen Textstelle in der Datei steht dann der Modus, in dem euer Windows läuft. Folgende Einträge sind möglich:
    • Callback_BootEnvironmentDetect: Detected boot environment: BIOS
    • Callback_BootEnvironmentDetect: Detected boot environment: EFI
Am Ende der Zeile seht ihr, welche Firmware-Schnittstelle auf eurem PC aktiv ist.


leicht angepasst, Quelle: https://www.giga.de/downloads/windo...et-ihr-heraus-welche-pc-schnittstelle-laeuft/
 
  • Gefällt mir
Reaktionen: Indio und SirVikon

Macschrauber

Aktives Mitglied
Thread Starter
Mitglied seit
08.02.2014
Beiträge
6.763
Ein Hinweis auf ein fragmentiertes NVRam Modul ist eine hohe Anzahl an Memory configs.

Wenn es mal über 20 werden wird es kritisch.

Ich habe gebrickte Roms ausgelötet mit 28 (!) MemoryConfigs. Diese Rechner starteten nicht mehr, waren tot, kein Efi done, kein Gong.

Hab mal ein kleines Shell Script gebastelt was in einem Rom Dump die MemoryConfigs zählt.

in /usr/local/bin mit dem Namen MemoryConfigs gespeichert und mit chmod 755 als Ausführbar gesetzt kann es vom Terminal wie jedes andere Kommando benutzt werden

Code:
#!/bin/bash

#usage: MemoryConfigs MyRom.bin

# to make executable from Terminal:
# chmod 755 MemoryConfigs
# cp MemoryConfigs /usr/local/bin

MemoryConfigs=$(xxd -p "$1" | tr -d '\n' | grep -o '8c4d0065006d006f007200790043006f006e0066' | wc -l)
echo $MemoryConfigs' Memory Configs'
exit 0

Beispiel:

Code:
mp31:~ macschrauber$ MemoryConfigs 144.bin
17 Memory Configs
mp31:~ macschrauber$

Zertifikate und die Installer Logs (IASInstallPhaseList.xml) sieht man mit Binwalk
 
  • Gefällt mir
Reaktionen: DL8LAQ, Indio, Proinnsias und eine weitere Person

Macschrauber

Aktives Mitglied
Thread Starter
Mitglied seit
08.02.2014
Beiträge
6.763
ok, angestoßen durch den Thread #1

habe ich ein wenig mit dem Erstellen eines USB Sticks für Windows 10 experimentiert.

Wollte feststellen ob ein Uefi gebooteter Windows 10 Stick eine csm/legacy/bios Installation oder Reparatur durchführen kann.

Das blosse Booten des Sticks hat mir schon das erste Zertifikat beschert. Ich war mutig weil das Rom des Testrechners neu aufgebaut war und ich logischerweise ein Backup hatte.

In Englisch weil ich es nicht noch mal texten möchte, das Wichtigste ist schon erklärt:

I fiddled a bit with creating a Windows Installer Thumb drive.
Knowing the risks, starting with a backed up and cleaned Firmware.

used uunetbootin and Win10_2004 iso

just booted the USB thumb drive, started installation until I have seen my drives and stopped it.

and I got a Certificate:

Code:
DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
24468         0x5F94          Certificate in DER format (x509 v3), header length: 4, sequence length: 986
49011         0xBF73          XML document, version: "1.0"
163863        0x28017         bzip2 compressed data, block size = 100k
xml was for booting into recovery to set csrutil disable for dumping the rom.

re-flashing the backup got the Certificate away, of course.

so, people, everyone should have a rom backup, you can't clean the Certificate of the nvram stream the easy way with nvram resets, just with re-flashing the backup.
 

Indio

Aktives Mitglied
Mitglied seit
16.06.2004
Beiträge
1.385
hätt ich dir vorher auch schon sagen können ;- )
es wird eben schon beim booten des sticks das bootROM quasi zerschossen
ohne das man irgendwas installiert hat.
und soviel ich weis kann man mit dem stick auch keine legacy installation durchführen.
 

Macschrauber

Aktives Mitglied
Thread Starter
Mitglied seit
08.02.2014
Beiträge
6.763
Zerschossen ist ein wenig extrem ausgedrückt. Es muss nicht gleich einen Brick geben. Aber es kann der erste Schritt sein.

Die Zertifikate brauchen so viel Platz dass die nächsten Dinge die ins Rom geschrieben werden das Rom fragmentieren können.

Muss nicht aber kann...
 

Elebato

Mitglied
Mitglied seit
03.04.2017
Beiträge
804
Wenn die Firmware komplett "verhunzt" ist dann besteht die Möglichkeit die Firmware aus dem Backup neu aufzubauen. Wie das funktioniert ist nicht öffentlich dokumentiert. Bei Bedarf kann ich helfen.
@Macschrauber, auf das Angebot würde ich gerne zurückkommen. Ich habe unsere beiden auf 5,1 geflashten Mac Pro 4,1 mittlerweile mit SSDs für Windows ausgerüstet und dabei Windows 10 auch endlich neu im Legacy Mode installiert. Der vorherige EFI-Install bei beiden stammte noch aus Windows 7 und wurde dann leider auch nach Windows 10 mitgeschleppt.

Naja, sieht man dann auch mit binwalk; beim Mac Pro meiner Frau sieht es entsprechend aus:

Code:
DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             UEFI PI Firmware Volume, volume size: 524288, header size: 1, revision: 0, EFI Firmware File System, GUID: 7A9354D9-0468-444A-CE81-0BF617D890DF
24972         0x618C          CRC32 polynomial table, little endian
35787         0x8BCB          mcrypt 2.2 encrypted data, algorithm: blowfish-448, mode: CBC, keymode: 8bit
524288        0x80000         UEFI PI Firmware Volume, volume size: 524288, header size: 1, revision: 0, EFI Firmware File System, GUID: 7A9354D9-0468-444A-CE81-0BF617D890DF
549260        0x8618C         CRC32 polynomial table, little endian
560075        0x88BCB         mcrypt 2.2 encrypted data, algorithm: blowfish-448, mode: CBC, keymode: 8bit
1048576       0x100000        UEFI PI Firmware Volume, volume size: 16384, header size: 1, revision: 0, EFI Firmware File System, GUID: 7A9354D9-0468-444A-CE81-0BF617D890DF
1064960       0x104000        UEFI PI Firmware Volume, volume size: 49152, header size: 1, revision: 0, GUID: 153D2197-29BD-44DC-59AC-887F70E41A6B
1065216       0x104100        Intel x86 or x64 microcode, sig 0x000106a5, pf_mask 0x03, 2018-05-11, rev 0x001d, size 12288
1077504       0x107100        Intel x86 or x64 microcode, sig 0x000206c0, pf_mask 0x13, 2009-08-20, rev 0x-ffea, size 8192
1085696       0x109100        Intel x86 or x64 microcode, sig 0x000206c2, pf_mask 0x03, 2018-05-08, rev 0x001f, size 11264
1114112       0x110000        UEFI PI Firmware Volume, volume size: 16384, header size: 1, revision: 0, EFI Firmware File System, GUID: 7A9354D9-0468-444A-CE81-0BF617D890DF
1130496       0x114000        UEFI PI Firmware Volume, volume size: 49152, header size: 1, revision: 0, GUID: 153D2197-29BD-44DC-59AC-887F70E41A6B
1130752       0x114100        Intel x86 or x64 microcode, sig 0x000106a5, pf_mask 0x03, 2018-05-11, rev 0x001d, size 12288
1143040       0x117100        Intel x86 or x64 microcode, sig 0x000206c0, pf_mask 0x13, 2009-08-20, rev 0x-ffea, size 8192
1151232       0x119100        Intel x86 or x64 microcode, sig 0x000206c2, pf_mask 0x03, 2018-05-08, rev 0x001f, size 11264
1179648       0x120000        UEFI PI Firmware Volume, volume size: 196608, header size: 1, revision: 0, Variable Storage, GUID: FFF12B8D-7696-4C8B-85A9-2747075B4F50
1184585       0x121349        Certificate in DER format (x509 v3), header length: 4, sequence length: 986
1250121       0x131349        Certificate in DER format (x509 v3), header length: 4, sequence length: 986
1343538       0x148032        bzip2 compressed data, block size = 100k
1376256       0x150000        UEFI PI Firmware Volume, volume size: 2686976, header size: 1, revision: 0, EFI Firmware File System, GUID: 7A9354D9-0468-444A-CE81-0BF617D890DF
4063232       0x3E0000        UEFI PI Firmware Volume, volume size: 65536, header size: 1, revision: 0, GUID: E3B980A9-5FE3-48E5-929B-2798385A9027
4128768       0x3F0000        UEFI PI Firmware Volume, volume size: 65536, header size: 0, revision: 0, Apple Boot Volume, GUID: 04ADEEAD-61FF-4D31-BAB6-64F8BF901F5A
Für Unterstützung beim Restaurieren der Firmware wäre ich sehr dankbar, wenn das möglich sein sollte.
 
  • Wow
Reaktionen: Indio
Oben