Macschrauber
Aktives Mitglied
Thread Starter
- Dabei seit
- 08.02.2014
- Beiträge
- 13.558
- Reaktionspunkte
- 9.501
Würde mich auch interessieren, warte ein paar Tage, hab ein MBR-Mint im 3.1, das kann ich mal testen.
Mac Pro 5.1 Rom / Firmware Backup Beschreibung und technischer Hintergrund
LuckyOldMan
Aktives Mitglied
- Dabei seit
- 28.11.2015
- Beiträge
- 4.802
- Reaktionspunkte
- 2.998
Kein Problem. Habe es bis heute ausgehalten - dann ist da noch mehr Platz.
P. S.:
@Macschrauber
Habe gerade nochmal nachgeschaut: es ist doch der 5,1, in dem Linux Mint steckt. Und es ist in MBR/Ext4 angelegt.
Bei der Vielzahl von OS kann man schon mal durcheinander kommen.
Zuletzt bearbeitet:
Macschrauber
Aktives Mitglied
Thread Starter
- Dabei seit
- 08.02.2014
- Beiträge
- 13.558
- Reaktionspunkte
- 9.501
Dumper Update 4-2-2024
Diesmal endlich die GUI etwas ansehnlicher gemacht. Ist wesentlich mehr Aufwand wie es ausschaut und stand ziemlich hinten an.
Ein Dialog, ein Analysebildschirm mit Scrollen und passenden Font.
Funktioniert ab Mac Os 10.10, unter 10.9 gibt's den alten Dialog, Mavericks und die Systeme davor unterstützen nicht die Techniken, die genutzt werden.
Im Hintergrund wurde noch mehr Logging betrieben, die ESP Tools überarbeitet und Rechteprobleme auf Shares aufgefangen.
https://www.dropbox.com/s/t5k7j4gxj8n9pj2/Download Macschrauber's CMP Rom Dump.zip?dl=1
Diesmal endlich die GUI etwas ansehnlicher gemacht. Ist wesentlich mehr Aufwand wie es ausschaut und stand ziemlich hinten an.
Ein Dialog, ein Analysebildschirm mit Scrollen und passenden Font.
Funktioniert ab Mac Os 10.10, unter 10.9 gibt's den alten Dialog, Mavericks und die Systeme davor unterstützen nicht die Techniken, die genutzt werden.
Im Hintergrund wurde noch mehr Logging betrieben, die ESP Tools überarbeitet und Rechteprobleme auf Shares aufgefangen.
https://www.dropbox.com/s/t5k7j4gxj8n9pj2/Download Macschrauber's CMP Rom Dump.zip?dl=1
Macschrauber
Aktives Mitglied
Thread Starter
- Dabei seit
- 08.02.2014
- Beiträge
- 13.558
- Reaktionspunkte
- 9.501
Kein Problem. Habe es bis heute ausgehalten - dann ist da noch mehr Platz.
P. S.:
@Macschrauber
Habe gerade nochmal nachgeschaut: es ist doch der 5,1, in dem Linux Mint steckt. Und es ist in MBR/Ext4 angelegt.
Bei der Vielzahl von OS kann man schon mal durcheinander kommen.
Gehört hier eigentlich nicht genau rein, aber ich habs mal kurz angeschaut:
Die Mac Firmware sieht die Helferpartition von den MBR Linux Versionen als Windows. Da gibt's auch kein Label, auch kein disk icon file wird ausgelesen. Geht also nicht.
Um das schön zu steuern würde ich RefindPlus empfehlen. Das kann eine oder mehrere Instanzen von OpenCore laden, Linux, Windows (auch UEFI mit NVRAM Schutz), usw usw. https://github.com/dakanji/RefindPlus
edit: damit es ein wenig rein passt: Mit Linux Mint 20.2 konnte ich mit Flashrom ein firmware dump des 5.1 machen.
LuckyOldMan
Aktives Mitglied
- Dabei seit
- 28.11.2015
- Beiträge
- 4.802
- Reaktionspunkte
- 2.998
Ok - erledigt.
Kaskadierende BLs sind eher nicht mein Fall. Dann muss ich bei ALT halt genauer zielen.
Macschrauber
Aktives Mitglied
Thread Starter
- Dabei seit
- 08.02.2014
- Beiträge
- 13.558
- Reaktionspunkte
- 9.501
Dumper Update 10-2-2024
-> Ein Fehler hat sich in 4-2-2024 eingeschlichen der das Starten unter 10.7 bis 10.9 des Dumpers verhinderte.
-> Die Label ESP Tools konnten eine UEFI Windows ESP nicht benennen. Ist gefixt.
-> Unter alten Systemen (10.7-10.9) liefen einige ESP Tools nicht, das ist soweit möglich gefixt.
-> Der Preboot Fixer bekam einen Hinweis wenn ein eher unwahrscheinlicher Fehler gefunden wurde. Mir hat es die plists in System/CoreServices einer Monterey Installation mit Ventura plists überschrieben. Das hat der Dumper gemeldet, kann es aber aus technischen Gründen nicht beheben. Aufgrund der Logik und des Ursprungsfehler hat der Fixer das Überschreiben dieser plists vorgeschlagen, was falsch gewesen wäre. Jetzt gibt's eine extra Warnung dass das eigentlich nicht sein kann.
Zumindest das Aufzeigen dieses Fehlers ist sinnvoll. (Monterey neu überinstallieren hat geholfen).
-> Eine technisch ungültige Seriennummer wird gemeldet.
-> Das VorhandenSein einer McFiver wird gemeldet wenn man eine EnableGop Firmware flasht, hier gibt es Kompatibilitätsprobleme mit McFiver und OpenCore.
https://www.dropbox.com/s/t5k7j4gxj8n9pj2/Download Macschrauber's CMP Rom Dump.zip?dl=1
-> Ein Fehler hat sich in 4-2-2024 eingeschlichen der das Starten unter 10.7 bis 10.9 des Dumpers verhinderte.
-> Die Label ESP Tools konnten eine UEFI Windows ESP nicht benennen. Ist gefixt.
-> Unter alten Systemen (10.7-10.9) liefen einige ESP Tools nicht, das ist soweit möglich gefixt.
-> Der Preboot Fixer bekam einen Hinweis wenn ein eher unwahrscheinlicher Fehler gefunden wurde. Mir hat es die plists in System/CoreServices einer Monterey Installation mit Ventura plists überschrieben. Das hat der Dumper gemeldet, kann es aber aus technischen Gründen nicht beheben. Aufgrund der Logik und des Ursprungsfehler hat der Fixer das Überschreiben dieser plists vorgeschlagen, was falsch gewesen wäre. Jetzt gibt's eine extra Warnung dass das eigentlich nicht sein kann.
Zumindest das Aufzeigen dieses Fehlers ist sinnvoll. (Monterey neu überinstallieren hat geholfen).
-> Eine technisch ungültige Seriennummer wird gemeldet.
-> Das VorhandenSein einer McFiver wird gemeldet wenn man eine EnableGop Firmware flasht, hier gibt es Kompatibilitätsprobleme mit McFiver und OpenCore.
https://www.dropbox.com/s/t5k7j4gxj8n9pj2/Download Macschrauber's CMP Rom Dump.zip?dl=1
tiftich
Mitglied
- Dabei seit
- 23.01.2019
- Beiträge
- 68
- Reaktionspunkte
- 5
Hallo zusammen,
grundsätzliche Frage: Ich möchte gelegentlich mein freundlicherweise von Macschrauber im letzten Jahr erstelltes Rebuild erneut in meinen MacPro5,1 flashen – als "PRam Reset Deluxe", wie es Macschrauber genannt hat, diesmal gleich mit EnableGop 1.4.
Das einzige, was mir beim Flashen immer noch ein mulmiges Gefühl bereitet, ist ein ROM-Chip mit möglicherweise defekten Zellen oder sowas.
Gibt es nicht irgendeine Möglichkeit, den Chip vor dem Flashen zu testen? Ein in der Vergangenheit erfolgreich erfolgter Flash wird nicht als Validierung reichen, nehme ich an, vor allem nicht für alle Zeiten…
Vielen Dank im voraus!
grundsätzliche Frage: Ich möchte gelegentlich mein freundlicherweise von Macschrauber im letzten Jahr erstelltes Rebuild erneut in meinen MacPro5,1 flashen – als "PRam Reset Deluxe", wie es Macschrauber genannt hat, diesmal gleich mit EnableGop 1.4.
Das einzige, was mir beim Flashen immer noch ein mulmiges Gefühl bereitet, ist ein ROM-Chip mit möglicherweise defekten Zellen oder sowas.
Gibt es nicht irgendeine Möglichkeit, den Chip vor dem Flashen zu testen? Ein in der Vergangenheit erfolgreich erfolgter Flash wird nicht als Validierung reichen, nehme ich an, vor allem nicht für alle Zeiten…
Vielen Dank im voraus!
Macschrauber
Aktives Mitglied
Thread Starter
- Dabei seit
- 08.02.2014
- Beiträge
- 13.558
- Reaktionspunkte
- 9.501
Interessante Frage. Eigentlich übervorsichtig, aber schauen wir mal das Thema theoretisch an:
Einen Dump ziehen ist ein Test ob Zellen gekippt sind. Da in der Mac Firmware fast schon fetischartig CRC32 Checksummen sind wird ein defekter SPI Chip sich schnell mit Checksummen Fehler melden.
Dann kannst Du mehrere Dumps hintereinander ziehen und vergleichen, die sollten immer 100% identisch sein.
im Terminal
shasum "dumpfilename.bin" gibt dir eine Prüfsumme aus, das wiederholst du mit mehreren Dumps.Dann kannst du mit einem Hex Editor deiner Wahl, oder falls du keinen installieren willst mit
xxd dumpfilename.bin den Dump anschauen. Leere Zellen haben den Wert 0xff, im hexdump mit FF zu sehen. Wenn solche "FF Wände" mitten drin Ausreißer haben ist was faul.Aaaaaaber:
Wenn der Flash defekt wäre dann hättest du es wahrscheinlich an einem nicht mehr startenden Mac Pro bemerkt.
Und: Die Zellen die nach dem "NVRAM Reset deLuxe" neu geschrieben werden sind im NVRAM Bereich, die sowieso nach jeder NVRAM Änderung und nach jedem Neustart beschrieben werden. So ist so ein Flash auch nur unwesentlich gefährlicher als die regelmäßige Garbage Collection. Oder die erzwungene mit mehrfach NVRAM Reset.
Weil die Firmware die beiden NVRAM Streams immer auf die gleichen Zellen schreibt.
Flashrom schreibt nur die Blöcke neu die geändert wurden. Wenn ich eine Firmware neu flashe und der Inhalt des SPI Chips unterscheidet sich nur durch das NVRAM, dann wird nur der Block neu geschrieben, der im NVRAM Bereich ist. Weil das der einzige Block ist der verändert wurde.
Und selbst wenn nach einem Upgrade alles neu geschrieben wurde sind diese Zellen im Mac Pro Leben nur ein paar mal geschrieben worden. Jeweils bei einem Firmware Update.
Wenn EnableGOP dazu kommt wird vieles neu geschrieben, weil sich ein Bereich im hinteren Drittel verschiebt. Ein echter Test mit leer machen und neu schreiben ist so nicht möglich. Du müsstest für einen vollständigen Test auch jeden Wert zwischen 0x00 und 0xff schreiben.
Der SPI Chip wird ja vom Mac benötigt und kann nicht mal eben für einen Test ausgeklinkt werden.
Ok, da wir theoretisieren, könnte ich theoretisch den SPI Chip im laufenden System mit Werten zwischen 0 und FF beschreiben, das wären 256 Flash Vorgänge. Die Cochones hab ich noch nicht gehabt
Sollte die Kiste in dem Moment abschmieren oder der Strom ausfallen darf ich löten.Ich habe bis jetzt nur Chips gehabt die im NVRAM Bereich defekt waren, einen Aussetzer in dem Bereich wo die anderen Firmware Bestandteile sind hatte ich noch nicht.
Zuletzt bearbeitet:
tiftich
Mitglied
- Dabei seit
- 23.01.2019
- Beiträge
- 68
- Reaktionspunkte
- 5
OK. Und praktisch…?
Gibt ohne Auslöten keine Testmöglichkeit, schon gar nicht, wenn mit einer gepatchten FW geflasht wird?
Einfach machen, solange der Strom nicht ausfällt
?
Macschrauber
Aktives Mitglied
Thread Starter
- Dabei seit
- 08.02.2014
- Beiträge
- 13.558
- Reaktionspunkte
- 9.501
Das gleiche Dilemma hast du bei jedem Apple Firmware Upgrade. Und dort keinerlei Kontrolle, was passiert.OK. Und praktisch…?
Gibt ohne Auslöten keine Testmöglichkeit, schon gar nicht, wenn mit einer gepatchten FW geflasht wird?
Einfach machen, solange der Strom nicht ausfällt
Der Dumper zieht die Kopie des alten Stands,
Analysiert das zu flashende File,
flasht mit Verify von Flashrom,
Liest nochmals aus, vergleicht nochmals und analysiert ein zweites Mal.
Sollte eine Zelle instabil sein, und hier sind wir wieder in der Theorie, dann könntest du auch mehrmals flashen bis es funktioniert. Die Firmware wird erst beim Neustart oder Wecken aus Full Sleep benutzt.
Fazit: ein gewöhnliches Firmware Upgrade beim MacOs upgraden ist deutlich kritischer. Ohne Risiko ist beides nicht.
Der Strom sollte nicht ausfallen und die Kiste nicht abschmieren.
Der eigentliche Flash Vorgang dauert btw ca. 10 Sekunden, der Rest ist Verifizierung und Überprüfen.
tiftich
Mitglied
- Dabei seit
- 23.01.2019
- Beiträge
- 68
- Reaktionspunkte
- 5
Vielen Dank für die Erläuterungen. Ich wollte es mal angehen und damit beginnen, dass ich ein "test a rom dump file" über Deinen leeren Rebuild vom letzten Jahr habe laufen lassen. Habe bisher nur "Flash" und "Backup" in ROMDump benutzt. Ist es normal, dass man beim "Test" nur 1 Logfile bekommt, was dann so aussieht [SNs ersetzt]?
Die fett markierten Zeilen sind mir aufgefallen. Users/.../Library/Application Support/Macschrauber/DirectHW.kext war vorhanden.
Außerdem endete der Test im ProgrammGUI folgendermaßen:
Das Logfile in "Downloads" ist zwar da, aber der "Stopp" Button reagiert nicht (1 Minute gewartet), es geht nur im Hauptfenster ein "Quit". Soll das so sein?
Code:
21.02.2024_11-43-07> permissions check ok, -60007
21.02.2024_11-43-08> The Dumper: 10-2-2024, System Version: 10.14.6 (Mojave)
21.02.2024_11-43-08> OpenCore: none, OCLP-Version: 1.3.0%00
21.02.2024_11-43-08> Available Python Versions: 2.7
21.02.2024_11-43-08> CPU: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz, 16 cores
21.02.2024_11-43-08> paths:
21.02.2024_11-43-08> RomDump.app//Contents/Resources/flashrom12 ok
21.02.2024_11-43-08> RomDump.app//Contents/Resources/flashrom097r1711 ok
21.02.2024_11-43-08> RomDump.app/Contents/Resources/DirectHW.kext ok
21.02.2024_11-43-08> RomDump.app/Contents/Resources/test_nvram ok
21.02.2024_11-43-08> RomDump.app//Contents/Resources/macserial ok
21.02.2024_11-43-08> RomDump.app//Contents/Resources/libusb for ch341/in -usr-local-opt-libftdi0-lib-/libftdi.1.dylib ok
21.02.2024_11-43-08> RomDump.app//Contents/Resources/libusb for ch341/in usr-local-lib-/libusb-0.1.4.dylib ok
21.02.2024_11-43-08> RomDump.app//Contents/Resources/libusb for ch341/in usr-local-lib-/libusb-1.0.0.dylib ok
21.02.2024_11-43-08> RomDump.app//Contents/Resources/gfxutil ok
21.02.2024_11-43-08> RomDump.app//Contents/Resources/gfxutil180b ok
21.02.2024_11-43-08> RomDump.app//Contents/Resources/UEFIExtract ok
21.02.2024_11-43-08> RomDump.app//Contents/Resources/findhex ok
21.02.2024_11-43-08> RomDump.app//Contents/Resources/findhexp3 ok
21.02.2024_11-43-08> RomDump.app//Contents/Resources/displayTextView.scptd ok
21.02.2024_11-43-08> RomDump.app//Contents/Resources/mouseinfo1010 ok
21.02.2024_11-43-08> RomDump.app//Contents/Resources/Scripts/main_dialog.scpt ok
21.02.2024_11-43-08> (progress) running eficheck...
21.02.2024_11-43-08> (progress) running eficheck...error
21.02.2024_11-43-09> error eficheck: ReadBinaryFromKernel: No matching services found. Either this system is not supported by eficheck, or you need to re-load the kext
IntegrityCheck: couldn't get EFI contents from kext
21.02.2024_11-43-09> (progress) Probing Flashrom
21.02.2024_11-43-09> (progress) flashrom v0.9.7-r1711 on Darwin 18.7.0 (x86_64)
21.02.2024_11-43-09> (progress) Searching for ch341a_spi programmer USB IDs:
21.02.2024_11-43-10> (progress) internal boot rom mode
21.02.2024_11-43-11> Title: Macschrauber's Rom Dump 10-2-2024
21.02.2024_11-43-11> Firmware from system_profiler: 144.0.0.0.0
21.02.2024_11-43-11> (progress) Checking SMC Version: 1.39f11
21.02.2024_11-43-11> masked serial: [Seriennummer]
21.02.2024_11-43-11> 4 characters hwc: [Seriennummer letzte 4)
21.02.2024_11-43-11> 3 characters hwc: [Seriennummer letzte 3)
21.02.2024_11-43-11> Mac Model: Mac Pro 2010
21.02.2024_11-43-12> (U)EFI version: 1.10 (0a000100)
21.02.2024_11-43-12> fetch_encrypted_password: 1 Der Befehl wurde mit einem Ergebnis ungleich Null beendet.
21.02.2024_11-43-18> get_screen_resolution: mouseinfo gave: 1600 x 1200 under cursor
21.02.2024_11-43-18> <test a rom dump> selected
21.02.2024_11-43-23> (progress) analysing
[Seriennummer] rebuilt.bin
21.02.2024_11-43-23> (analyse): '/Users/../Desktop/[Seriennummer] rebuilt.bin'
21.02.2024_11-43-23> with arguments: -showbathealth -nocondensedfont
21.02.2024_11-43-26> 4 characters hwc: [Seriennummer letzte 4)
21.02.2024_11-43-27> 3 characters hwc: [Seriennummer letzte 3)
21.02.2024_11-43-27> text width for dialog: 63
21.02.2024_11-43-27> scrollable_dialog: x=800 y=241 x_max=1600 y_max=880 x_calculated=548
21.02.2024_11-43-27> (check_for_serious_damage): called for [Seriennummer] rebuilt.bin
21.02.2024_11-43-27> (check_for_serious_damage): firmware_version_from_file: 144.0.0.0.0
21.02.2024_11-43-27> 4 characters hwc: [Seriennummer letzte 4)
21.02.2024_11-43-27> 3 characters hwc: [Seriennummer letzte 3)
21.02.2024_11-43-27> (check_for_serious_damage): model from serial: Mac Pro 2010
21.02.2024_11-51-41
> <quit> selected in main dialog
21.02.2024_11-51-41> to undload_direct_hw: no unload, was not loaded by the DumperAußerdem endete der Test im ProgrammGUI folgendermaßen:
Das Logfile in "Downloads" ist zwar da, aber der "Stopp" Button reagiert nicht (1 Minute gewartet), es geht nur im Hauptfenster ein "Quit". Soll das so sein?
Zuletzt bearbeitet von einem Moderator:
Macschrauber
Aktives Mitglied
Thread Starter
- Dabei seit
- 08.02.2014
- Beiträge
- 13.558
- Reaktionspunkte
- 9.501
Den Stopp Button hätte ich gerne weg, aber das ist eine eingebaute AppleScript Funktion die nicht veränderbar ist - und noch nie so richtig funktioniert hat. Auch kann man den "leeren" Progress Dialog nicht verschwinden lassen. Ärgerliche und halbherzige Umsetzung von Apple.
Aber ohne Progress bar ists noch blöder.
Du solltest bei test a rom dump file den Dialog bekommen wo er anzeigt dass das eine "never booted rebuilt firmware" ist.
Wenn der nicht kommt dann stimmt was nicht bei dir im Ablauf, das diskutieren wir aber nicht im Thread um ihn nicht unnötig aufzublasen.
Hast ne Unterhaltung..
Lade auch mal die neue Version, 20-2-2024 ist aktuell. Ich hab da was umgestellt, vielleicht ists n blöder Fehler.
Aber ohne Progress bar ists noch blöder.
Du solltest bei test a rom dump file den Dialog bekommen wo er anzeigt dass das eine "never booted rebuilt firmware" ist.
Wenn der nicht kommt dann stimmt was nicht bei dir im Ablauf, das diskutieren wir aber nicht im Thread um ihn nicht unnötig aufzublasen.
Hast ne Unterhaltung..
Lade auch mal die neue Version, 20-2-2024 ist aktuell. Ich hab da was umgestellt, vielleicht ists n blöder Fehler.
Macschrauber
Aktives Mitglied
Thread Starter
- Dabei seit
- 08.02.2014
- Beiträge
- 13.558
- Reaktionspunkte
- 9.501
21.02.2024_11-43-09> error eficheck: ReadBinaryFromKernel: No matching services found. Either this system is not supported by eficheck, or you need to re-load the kext
> eficheck läuft auf dem Mac Pro 4,1/5,1 nicht, deshalb die Fehlermeldung
21.02.2024_11-43-12> fetch_encrypted_password: 1 Der Befehl wurde mit einem Ergebnis ungleich Null beendet.
> Es wurde keine Datei mit admin Passwort vom Nutzer angelegt. Muss auch nicht, ist halt bequemer wenn man viel testet.
21.02.2024_11-51-41> to undload_direct_hw: no unload, was not loaded by the Dumper
>DirectHW.kext wurde nicht geladen weil kein Dump gezogen oder geschrieben wurde, also ist auch kein Entladen dieser kext nötig.
> eficheck läuft auf dem Mac Pro 4,1/5,1 nicht, deshalb die Fehlermeldung
21.02.2024_11-43-12> fetch_encrypted_password: 1 Der Befehl wurde mit einem Ergebnis ungleich Null beendet.
> Es wurde keine Datei mit admin Passwort vom Nutzer angelegt. Muss auch nicht, ist halt bequemer wenn man viel testet.
21.02.2024_11-51-41> to undload_direct_hw: no unload, was not loaded by the Dumper
>DirectHW.kext wurde nicht geladen weil kein Dump gezogen oder geschrieben wurde, also ist auch kein Entladen dieser kext nötig.
tiftich
Mitglied
- Dabei seit
- 23.01.2019
- Beiträge
- 68
- Reaktionspunkte
- 5
Macschrauber
Aktives Mitglied
Thread Starter
- Dabei seit
- 08.02.2014
- Beiträge
- 13.558
- Reaktionspunkte
- 9.501
Macschrauber
Aktives Mitglied
Thread Starter
- Dabei seit
- 08.02.2014
- Beiträge
- 13.558
- Reaktionspunkte
- 9.501
Zur Info: wir sind dran den Fehler aufzuspüren, warum an seinem Mac Pro der Dialog nicht läuft.
Edit: die Schrift Courier New hat gefehlt. Das externe Script für den Scrollbaren Dialog rauscht dann durch und meldet keinen Fehler. Bin davon ausgegangen dass es Fehler meldet, dann kommt der einfache Dialog als Ersatz.
Nicht gut, da müssen noch Prüfungen rein. Da merkt man mal wieder dass man beim Coden an alles denken muss…
Danke an @tiftich für‘s Motzen
Edit: die Schrift Courier New hat gefehlt. Das externe Script für den Scrollbaren Dialog rauscht dann durch und meldet keinen Fehler. Bin davon ausgegangen dass es Fehler meldet, dann kommt der einfache Dialog als Ersatz.
Nicht gut, da müssen noch Prüfungen rein. Da merkt man mal wieder dass man beim Coden an alles denken muss…
Danke an @tiftich für‘s Motzen
Zuletzt bearbeitet:
Macschrauber
Aktives Mitglied
Thread Starter
- Dabei seit
- 08.02.2014
- Beiträge
- 13.558
- Reaktionspunkte
- 9.501
Update vom 2-3-2024
Fixes:
- Wenn der Font Courier New gefehlt hat wurde kein Dialog ausgegeben, gefixt, benutzt alternative Fonts wenn Courier New entfernt wurde.
- Formatierung der VSS1/VSS2 Variablen, wenn >10
- Falsche NVRAM Variablen Checksummen für Type80 Firmwares (>2012) wurden nicht gemeldet.
- Ein Tool im Hintergrund (findhex) wurde in C umgeschrieben um die Developer Command Line Tools für Python3 nicht zu benötigen. Hängt mit der automatischen Erkennung der Bereiche unbekannter FIrmwares zusammen.
https://www.dropbox.com/s/t5k7j4gxj8n9pj2/Download Macschrauber's CMP Rom Dump.zip?dl=1
Fixes:
- Wenn der Font Courier New gefehlt hat wurde kein Dialog ausgegeben, gefixt, benutzt alternative Fonts wenn Courier New entfernt wurde.
- Formatierung der VSS1/VSS2 Variablen, wenn >10
- Falsche NVRAM Variablen Checksummen für Type80 Firmwares (>2012) wurden nicht gemeldet.
- Ein Tool im Hintergrund (findhex) wurde in C umgeschrieben um die Developer Command Line Tools für Python3 nicht zu benötigen. Hängt mit der automatischen Erkennung der Bereiche unbekannter FIrmwares zusammen.
https://www.dropbox.com/s/t5k7j4gxj8n9pj2/Download Macschrauber's CMP Rom Dump.zip?dl=1
Macschrauber
Aktives Mitglied
Thread Starter
- Dabei seit
- 08.02.2014
- Beiträge
- 13.558
- Reaktionspunkte
- 9.501
Update vom 10-3-2024
--03-03-2024 OpenCore Version wird dargestellt wenn OC während dem Dumpen läuft
--04-03-2024 Einige Kosmetik in den Logs und Darstellung der Pfade
--05-03-2024 Macserial und der Dumper hatte eine falsche Hardware ID für ein MBP113: HWC G3QD war als MBP115 in der Liste. Den Fehler habe ich gemeldet und wurde auch in OpenCore gefixt.
--08-03-2024 MP41 / MP51 Backplane Typ und Generation wird angezeigt
--09-03-2024 Meldung wenn die Firmware nicht schreibgeschützt ist bei nicht Mac Pro / Xserves. Da gab es einen bösen Bug im Zusammenhang mit dem Ruhezustand bei den Rechnern die keinen Hardware Schreibschutz haben.
Ein neuer Fehler hat sich eingeschlichen seit der Version 2-3-2024;
--10-03-2024 Der Dumper brach mit einem Scriptfehler ab wenn die Größe eines zu testenden Files nicht kompatibel war. Ist gefixt.
https://www.dropbox.com/s/t5k7j4gxj8n9pj2/Download Macschrauber's CMP Rom Dump.zip?dl=1
--03-03-2024 OpenCore Version wird dargestellt wenn OC während dem Dumpen läuft
--04-03-2024 Einige Kosmetik in den Logs und Darstellung der Pfade
--05-03-2024 Macserial und der Dumper hatte eine falsche Hardware ID für ein MBP113: HWC G3QD war als MBP115 in der Liste. Den Fehler habe ich gemeldet und wurde auch in OpenCore gefixt.
--08-03-2024 MP41 / MP51 Backplane Typ und Generation wird angezeigt
--09-03-2024 Meldung wenn die Firmware nicht schreibgeschützt ist bei nicht Mac Pro / Xserves. Da gab es einen bösen Bug im Zusammenhang mit dem Ruhezustand bei den Rechnern die keinen Hardware Schreibschutz haben.
Ein neuer Fehler hat sich eingeschlichen seit der Version 2-3-2024;
--10-03-2024 Der Dumper brach mit einem Scriptfehler ab wenn die Größe eines zu testenden Files nicht kompatibel war. Ist gefixt.
https://www.dropbox.com/s/t5k7j4gxj8n9pj2/Download Macschrauber's CMP Rom Dump.zip?dl=1
Macschrauber
Aktives Mitglied
Thread Starter
- Dabei seit
- 08.02.2014
- Beiträge
- 13.558
- Reaktionspunkte
- 9.501
Der Dumper ist auf Github:
https://github.com/Macschrauber/Macschrauber-s-Rom-Dump
https://github.com/Macschrauber/Macschrauber-s-Rom-Dump
Macschrauber
Aktives Mitglied
Thread Starter
- Dabei seit
- 08.02.2014
- Beiträge
- 13.558
- Reaktionspunkte
- 9.501
Update vom 22-3-2024
-> Analyse der von eficheck erstellten .dump-Dateien, um sie ohne Benutzerdaten (Fsys-Stream) an Apple zu senden.
Mein Mac Mini 7,1 erstellt eine 6-MB-Datei. Ich bräuchte weitere Beispiele für andere Größen.
-> Der Stopp-Knopf des Fortschrittsfensters funktioniert jetzt im Dumper und den meisten anderen Tools.
-> Überarbeitung eines Handlers zur Verarbeitung von sudo-cli-Toolaufrufen für präzisere Protokollierung.
-> Hinzufügen von "<download from github>" zu den Downloadern.
Außerdem Fehlerkorrektur im Tool "<Is damaged fix>" aufgrund eines Tippfehlers in einem Versionskommentar.
https://github.com/Macschrauber/Macschrauber-s-Rom-Dump
-> Analyse der von eficheck erstellten .dump-Dateien, um sie ohne Benutzerdaten (Fsys-Stream) an Apple zu senden.
Mein Mac Mini 7,1 erstellt eine 6-MB-Datei. Ich bräuchte weitere Beispiele für andere Größen.
-> Der Stopp-Knopf des Fortschrittsfensters funktioniert jetzt im Dumper und den meisten anderen Tools.
-> Überarbeitung eines Handlers zur Verarbeitung von sudo-cli-Toolaufrufen für präzisere Protokollierung.
-> Hinzufügen von "<download from github>" zu den Downloadern.
Außerdem Fehlerkorrektur im Tool "<Is damaged fix>" aufgrund eines Tippfehlers in einem Versionskommentar.
https://github.com/Macschrauber/Macschrauber-s-Rom-Dump