Mac Pro 5.1 Rom / Firmware Backup Beschreibung und technischer Hintergrund

Soo.. inspiriert durch dieses Thema habe ich heute auch mal mein ROM gedumpt. Einfach mal so, will die Kiste ja noch ne Weile verwenden, davor nvreset mit 1x leisem und 3x lautem Gong.. soweit alles korrekt? Muss ich irgendwas tun, solange die Kiste gut läuft?

Habe den 5.1 nicht neu gekauft, weiß also nichts über das Vorleben. Windows hatte ich selbst nur mal kurz drauf und per DVD installiert, also vermutlich BIOS legacy mode.. möchte aber demnächst mal wieder zumindest Win7 auf ne separate SSD installieren.

Naja.. prinzipiell muss man sich glaube ich, sofern DUMP vorhanden, keine Sorgen machen ab jetzt. Dieser Chip ist/wäre an der Stelle ja auch einfach ausgelötet und ausgetauscht. Besser bei den Preisen für Backplanes auf ebay.. :ROFLMAO:
 
benmuetsch schrieb:
Soo.. inspiriert durch dieses Thema habe ich heute auch mal mein ROM gedumpt. Einfach mal so, will die Kiste ja noch ne Weile verwenden, davor nvreset mit 1x leisem und 3x lautem Gong.. soweit alles korrekt? Muss ich irgendwas tun, solange die Kiste gut läuft?

Habe den 5.1 nicht neu gekauft, weiß also nichts über das Vorleben. Windows hatte ich selbst nur mal kurz drauf und per DVD installiert, also vermutlich BIOS legacy mode.. möchte aber demnächst mal wieder zumindest Win7 auf ne separate SSD installieren.

Naja.. prinzipiell muss man sich glaube ich, sofern DUMP vorhanden, keine Sorgen machen ab jetzt. Dieser Chip ist/wäre an der Stelle ja auch einfach ausgelötet und ausgetauscht. Besser bei den Preisen für Backplanes auf ebay.. :ROFLMAO:
Zum Vergrößern anklicken....

Du kannst wie in #94 vorgeturnt mit UefiTool anschauen wieviel von den 64k im ersten Stream noch frei sind,

einen Binwalk Lauf machen

und meinem quick n dirty check https://gist.github.com/startergo/56d3770b7f78dd1591790c69753f846c durchlaufen lassen.


Generell muss man sagen dass die Firmware schon etwa 10 Jahre gelaufen ist, alle möglichen Systeme und Updates durchlaufen hat und es kein Nachteil wäre die Streams zu leeren.

Außerdem hat man bei einem Neuaufbau auch den neuesten BootLader von Apple, der wird nicht aktualisiert und ist auf dem Stand von dem Produktionsjahr des Mac Pro.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: ObsoleteMac und benmuetsch
@benmuetsch hatte gefragt:
Was meinst Du eigentlich mit "neuestem Bootloader" ? Dachte das wär alles in der BootROM Version drin (144.0.0.0)?


...
Nein, Apple Updated den Bootlader nicht, den Neuen gibts nur per Rekonstruktion.

Du kannst Dir das Rom wie als Betriebssystem vorstellen, mit Benutzerspeicher (nvram) und allen möglichen Treibern und Programmen. Der Bootlader kommt aber per Update keine Aktualisierung.

Warum? Vielleicht aus Sicherheitsgründen, ist das wichtigste Stückchen Firmware und wurde zum Beispiel zum Einlesen der Rettungsdisk benötigt, wenn der auch Upgedated wurde dann war's das dann.

Da die Methode beim Rekonstruieren sich völlig vom Update unterscheidet (komplettes, vorbereitetes Image einspielen) ist das weniger kritisch.
 
  • Gefällt mir
Reaktionen: benmuetsch
kleine Anleitung für das test_nvram Script:

1.) download Download ZIP
2.) im Terminal /usr/local/bin erzeugen, wenns schon da ist dann ists recht und gibt eine Fehlermeldung
Code: 
 mkdir /usr/local/bin
3.) im Terminal (bei "normalen" downloads Pfad und bei automatischem Auspacken von zip files)
Code: 
cp ~/downloads/56d3770b7f78dd1591790c69753f846c-de99df84cc85caf51d19ea106b4111e2e0bd2b27/test_nvram /usr/local/bin

fertig,

Beispiel:

Code: 
test_nvram ~/Desktop/Dump_5_1.bin
22 Memory Configs
0 xml
0 Microsoft Certificates
2 BluetoothActiveControllerInfos
 
  • Gefällt mir
Reaktionen: UnixCoon, Schalter 7 und Indio
Hallo,

ich habe versehentlich in den Bootcamp Tools der Systemsteuerung unter Windows 10 das Startvolume meines MP5.1(Flash von 4.1) geändert. Seitdem fährt BigSur via OpenCore nicht mehr hoch, sondern der Bildschirm bleibt schwarz. Ich kann über Drücken der ALT Taste nach dem Gong noch das silberne Startmenü aufrufen und dann EFI Boot auswählen, um dann den OpenCore Loader zu starten. Dann fährt BigSur hoch. Halte ich die ALT Taste nicht gedrückt bleibt der Bildschirm schwarz und nach einiger Zeit geht der Mac aus.

Wie kann ich diesen Boot Fehler beseitigen?

test_nvram gibt mir Folgendes aus:

19 Memory Configs
0 xml
6 Microsoft Certificates
2 BluetoothActiveControllerInfos

Danke, Dietmar
 
6 2 Microsoft Certificates

sauber :-o

die sollte man jetzt aber unbedingt rausbekommen, da scheint der Mac das Uefi Windows ungeschützt hochzufahren.


Es sind wahrscheinlich "nur" zwei Zertifikate. Mein Script schlägt auf den String "Microsoft Windows Secure Boot Variable Signer" an der pro Zertifikat 3 mal vorhanden ist. Werde das mal abändern. Wichtig ist natürlich dass es Alarm schlägt.
 
Zuletzt bearbeitet:
Heute beim Scannen ein Rom gefunden was 3 BluetoothInternalControllerInfos enthielt.

Also wieder einen Datenpunkt gefunden, der NVRam Fragmentierung indiziert.

Microsoft Zertifikate werden jetzt korrekt gezählt, die Zeichenkette "Microsoft Windows Secure Boot Variable Signer" kommt 3 mal pro Zertifikat vor.


Script wurde erweitert: https://gist.github.com/startergo/56d3770b7f78dd1591790c69753f846c
 
so schaut meins damit aus:

11 Memory Configs
0 xml
0 Microsoft Certificates
2 BluetoothActiveControllerInfos
2 BluetoothInternalControllerInfos


interessanterweise ist jetzt nicht einmal mehr 1 XML drin?
auch binwalk zeigt keine mehr an.

also ich glaub da sind noch viele unbekannte in einem ROM ; -)
 
so soll's sein.

Gerade im MP3,1 3 BluetoothActiveControllerInfos gefunden, triple bong, danach Null.
 
  • Gefällt mir
Reaktionen: Indio
Hallo,

ein bisher hoch interessantes Thema und die 6 Seiten sind für Mac Pro Novizen sehr lehrreich was die Installation von Windows 10 betrifft.

@Macschrauber, du hast auf den ersten Seiten Unterstützung für die Identifikation von eventuell korrumpierten EFI-Roms angeboten. Ich würde gern auf dieses Angebot zurück kommen. Aufgrund von Problemen mit der Boot-Camp-Software habe ich Windows mehrmals installiert und „natürlich“ ist dies teilweise aus Unwissenheit im UEFI Modus geschehen.

Mein Mac Pro ist ein 4.1er mit Udpate auf 5.1 und inzwischen die 144er FW-Version. Das Rom hab entsprechend der hier vorliegenden Anleitungen auch bereits gepumpt und extern gesichert.

Viele Grüße
Micha
 
Macschrauber schrieb:
Hab das vor einiger Zeit mit flashrom und grml2018-12 beschrieben,

grml 2020 bzw die neuere Flashrom Version braucht eine andere Beschreibung des Programmers Internal


nochmal angepasst:

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)

Vorher muss ich bei einem Read-Only System eine Fat Partition oder einen Stick mounten damit ich überhaupt irgendwo hin schreiben kann.

Da Linux in Minimalconfig mit HFS oder gar APFS nichts anfangen kann empfiehlt sich eine EFI Partition.


Code: 
sudo flashrom -p internal:laptop=this_is_not_a_laptop -r /mnt/mymountpoint/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.
Zum Vergrößern anklicken....



------>
zitier mich mal selber,
heute (weil ich an diesem Standort nicht meine WerkzeugPlatte habe) und für die Wissenschaft einen Mac Pro 4.1 in einen 5.1 verwandelt mit Linux Stick.

Lesen wie in #86,
Schreiben auch, beim 4.1 versucht Flashrom den Flash zu erkennen was da auch gelingt. Beim 5.1 wird man den Flash IC Typ angeben müssen.

Schreibschutz des Flash muss wie üblich durch langes Einschalter Drücken aufgehoben werden.


Flash Rom with grml.jpg
 
Nachdem ich durch einen anderen User auf die Idee gekommen bin die DirectHW.kext von RomTool durch OpenCore zu laden ist es möglich mit der Flashrom Version die in RomTool steckt das Rom zu Dumpen wenn RomTool das selbst nicht schafft.


Dazu Romtool anklicken und Paketinhalt zeigen,

DirectHW.kext in /efi/efi/oc/kexts/ kopieren,
die Flashrom Version benutzen die in RomTool steckt.



Code: 
./flashrom097r1711 -p internal -r test.bin
flashrom v0.9.7-r1711 on Darwin 18.7.0 (x86_64)
flashrom is free software, get the source code at http://www.flashrom.org

Calibrating delay loop... OK.
Mapping low megabyte at 0x0000000000000400, unaligned size 0xffc00.
Mapping low megabyte, 0xffc00 bytes at unaligned 0x0000000000000400.
sh: dmidecode: command not found
dmidecode execution unsuccessful - continuing without DMI info
Found chipset "Intel 631xESB/632xESB/3100". Enabling flash write... OK.
Found ST flash chip "M50FW016" (2048 kB, FWH) at physical address 0xffe00000.
===
This flash part has status UNTESTED for operations: PROBE READ ERASE WRITE
The test status of this chip may have been updated in the latest development
version of flashrom. If you are running the latest development version,
please email a report to flashrom@flashrom.org if any of the above operations
work correctly for you with this flash part. Please include the flashrom
output with the additional -V option for all operations you tested (-V, -Vr,
-VE, -Vw), and mention which mainboard or programmer you tested.
Please mention your board in the subject line. Thanks for your help!
Cannot unlock sector @ 0x0
UNLOCK FAILED!
Reading flash... done.

DirectHW.kext laden geht in OpenCore über dieses Kernel Setting in OC:

Code: 
           <dict>
                <key>Arch</key>
                <string>x86_64</string>
                <key>BundlePath</key>
                <string>DirectHW.kext</string>
                <key>Comment</key>
                <string>For Romtool etc</string>
                <key>Enabled</key>
                <true/>
                <key>ExecutablePath</key>
                <string>Contents/MacOS/DirectHW</string>
                <key>MaxKernel</key>
                <string></string>
                <key>MinKernel</key>
                <string>18.0.0</string>
                <key>PlistPath</key>
                <string>Contents/Info.plist</string>
            </dict>
 
  • Gefällt mir
Reaktionen: Indio
Hallo!

In Vorbereitung einer OpenCore Installation habe ich heute mal mein ROM gedumped cMP5,1. Ich habe hier noch keine Angabe gefunden, ab welcher Größe des Dumps man sich Sorgen bzgl. des Speicherplatzes auf dem EEPROm machen muss. Meiner hat 4.194.304 Byte.

Außerdem habe ich bei mir ähnliche Phänomene wie bei Gerd gefunden:

Bildschirmfoto 2021-04-05 um 21.17.14.png

Ansonsten habe ich keine XML Dateien, scheinbar keine Zertifikate:

Code: 
memoryconfigs cMP51.bin
16 Memory Configs

binwalk cMP51.bin     

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0                   0x0                 UEFI PI Firmware Volume, volume size: 524288, header size: 1, revision: 0, EFI Firmware File System
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
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
1064960       0x104000        UEFI PI Firmware Volume, volume size: 49152, header size: 1, revision: 0
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
1130496       0x114000        UEFI PI Firmware Volume, volume size: 49152, header size: 1, revision: 0
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
1343511       0x148017        bzip2 compressed data, block size = 100k
1376256       0x150000        UEFI PI Firmware Volume, volume size: 2686976, header size: 1, revision: 0, EFI Firmware File System
4063232       0x3E0000        UEFI PI Firmware Volume, volume size: 65536, header size: 1, revision: 0
4128768       0x3F0000        UEFI PI Firmware Volume, volume size: 65536, header size: 0, revision: 0, Apple Boot Volume

BluetoothActiveControllerInfos cMP51.bin             
2 BluetoothActiveControllerInfos

Muss ich mir da Sorgen machen oder irgendetwas bereinigen?

@Macschrauber Wie erstellst Du die Ausgabe der Memory Configs im nvram Volume? Ist das eine Funktion von binwalk? Welche Parameter muss man dafür eingeben?
 
Das Romfile selbst kann nicht größer werden als der Chip.

Es geht um die Größe des nvram VSS Streams for dem Stream der die Hardwaredefinitionen enthält.

Die zusätzlichen Binwalk Angaben (in „“) sind selbsterstellte Signaturen.

Auf den ersten Blick kein schlimmes Problem, aber die große Lücke im Nvram sollte man näher prüfen.

Hast ne Unterhaltung.
 
Macschrauber schrieb:
Das Romfile selbst kann nicht größer werden als der Chip.
Zum Vergrößern anklicken....
Vielleicht habe ich mich etwas unklar ausgedrückt. Mein Romfile hat 4.194.304 Byte. Ist noch genügend Platz auf dem Chip für die nächsten 10 Jahre? :D
 
Nein, der Chip hat kein einziges Byte mehr.

Die Streams im Chip haben eine feste Größe, 64kbyte genauer für den genutzen ersten nvram Stream.

Wenn der zu voll ist wird der aufgeräumt, ähnlich der garbage collection bei SSDs.

Dieser Vorgang kann aber Amok laufen, zum Beispiel durch einen Absturz während einem Schreibvorgang im nvram.

Oder durch Settings die nicht von der Firmware berücksichtigt werden.

Prominentes Beispiel sind die Zertifikate durch Uefi Windows.

Mir ist selbst durch OpenCore Experimente das nvram vollgelaufen bis nichts mehr ging.

Deshalb ist es gut vor dem Einsatz von OpenCore ein möglichst sauberes Rom/Nvram zu haben. Manche empfehlen sogar alle 3 Monate ein sauberes Rom zu flashen.
 
Servus, ich habe mal das ROM von meinem Mac Pro 4.1/5.1 mit dem ROMTool gesichert und mit Binwalk ausgelesen, nun mach ich mir sorgen das sehr viele UEFI eintrage in der ROM sind und da ich mir sehr sicher bin das ich nie eine UEFI Installation mit Windows gemacht habe sondern immer Legacy, gehe ich mal stark davon aus das mein Vorgänger von dem ich den Mac Pro gekauft habe das gemacht hat oder was ganz anderes ich weiß es nicht. Nun meine eigentliche Frage muss ich mir jetzt Gedanken machen das ich ein Brick bekomme?
 

Anhänge

  • Bildschirmfoto 2021-04-08 um 00.45.04.png
    Bildschirmfoto 2021-04-08 um 00.45.04.png
    609,3 KB · Aufrufe: 56
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben Unten