Last edited:
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
MP 1,1-5,1 MP5,1: EFI Release vs BIOS Version vs BootBlock Version Reference Table:
- Thread starter tsialex
- Start date
- Sort by reaction score
EFI/BIOS/BootBlock table updated with MP51.0083.B00 that @Fangio, thx again, sent me today.
EFI/BIOS/BootBlock table updated with MP51.007F.B00, the original BootROM for the first produced mid-2010 Mac Pros.
The table is now missing just MP51.007F.B01 and MP51.007F.B02 to have all ever released mid-2010/mid-2012 BootROMs.
The table is now missing just MP51.007F.B01 and MP51.007F.B02 to have all ever released mid-2010/mid-2012 BootROMs.
EFI/BIOS/BootBlock table updated with BootBlock AAPLEFI1.88Z.0005.I00.1007141219 found in @angelsevov mid-2010 dump.
It's probably MP51.007F.B01, but I added just the BootBlock info. This one will be harder to track a full dump.
It's probably MP51.007F.B01, but I added just the BootBlock info. This one will be harder to track a full dump.
I'm checking my dump stash and I couldn't find a BootBlock with anything between AAPLEFI1.88Z.0005.I00.1007141219 and AAPLEFI1.88Z.0005.I00.1010071430, what probably would be MP51.007F.B01 and MP51.007F.B02.
I know that MP51.007F.B01 and MP51.007F.B02 exists, a table inside EfiUpdaterApp2.efi has these (see below), but it's probably BootROMs not used in the wild or used very briefly.
Maybe we will never have these dumps.
I know that MP51.007F.B01 and MP51.007F.B02 exists, a table inside EfiUpdaterApp2.efi has these (see below), but it's probably BootROMs not used in the wild or used very briefly.
| EFI Version: | BIOS Version: |
|---|---|
| MP51.007F.B00 | MP51.88Z.007F.B00.1008031144 |
| MP51.007F.B01 | MP51.88Z.007F.B01.1008231310 |
| MP51.007F.B02 | MP51.88Z.007F.B02.1009221128 |
Maybe we will never have these dumps.
Last edited:
Hi tsialex
How do I send you my dumped douple-cert firmware in order to get the intermediate files, and do you have time to help me with those - it seems you are spending an awful lot of time on all of the cMPs out there?
Sorry, I don't have time available for doing this anymore. I explained before on the thread what is needed to do a clean up, you can do it yourself.
[automerge]1574874409[/automerge]
If it's not one of the missing EFI versions of the first post, look at the table to see if yours is not there yet, no need to.
Last edited:
Re-issues of Mac Pro EFI Firmware Update 1.4 and Mac Pro EFI Firmware Update 1.5 from 2010 with the new certificates.
Last edited:
Mac Pro EFI Firmware Update 1.4
Post Date: Jan 18, 2010
![Screen Shot 2019-12-06 at 09.52.30.png]( "Screen Shot 2019-12-06 at 09.52.30.png")
Mac Pro EFI Firmware Update 1.5
Post Date: Oct 28, 2010
![Screen Shot 2019-12-06 at 09.56.18.png]( "Screen Shot 2019-12-06 at 09.56.18.png")
Post Date: Jan 18, 2010
Code:
$IBIOSI$ MP41.88Z.0081.B07.0910130729
Copyright (c) 2005-2009 Apple Inc. All rights reservedMac Pro EFI Firmware Update 1.5
Post Date: Oct 28, 2010
Code:
$IBIOSI$ MP51.88Z.007F.B03.1010071432Applied the same technique described with the 2nd post to reconstruct MM6,1 firmwares and it worked fine. MM6,1 generic image is a .scap one so you have a lot more steps to get to a binary image like the MP51.fd, but the method itself is sound and the reconstruction works fine.
Up to now, tested with MP4,1, MP5,1, MP6,1* and MM6,1*.
* generic Apple image is .scap encapsulated.
Up to now, tested with MP4,1, MP5,1, MP6,1* and MM6,1*.
* generic Apple image is .scap encapsulated.
Just re-read this entire thread again. This was a fun investigation that lead to this tutorial.
Just wondering if you ever did find a dump of the 2 missing releases?
Just wondering if you ever did find a dump of the 2 missing releases?
Not yet, both existed at one point in time since efiflasher has all the data that I wrote on the table already about those two, but efiflasher miss the BootBlock versions.
Maybe someday a replacement backplane sent to a corporation somewhere back in the day appears from a dusty box with one of the two missing releases. It's more a historical curiosity and the need to have the full info than anything useful, no one will ever use two EFI versions so old and full of bugs.
I was just re-reading "The Apple of Your EFI: Mac Firmware Security Research".
So you can force a firmware "downgrade" with the older or the same version of the firmware. If you use the firmware from the firmware update package it will only upgrade the non-nvram sections, but if you select the reconstructed firmware it will update everything just like the romtool, right?
So you can force a firmware "downgrade" with the older or the same version of the firmware. If you use the firmware from the firmware update package it will only upgrade the non-nvram sections, but if you select the reconstructed firmware it will update everything just like the romtool, right?
Apple removed the downgrade or refresh with the same version possibility with EFI flasher long ago, it's impossible since Thunderstrike.
ROMTool only writes a full image. flashrom can map areas in the same way efiflasher does. Back in the day I did a flashrom map and used for a long time before developing the reconstruction technique.
efiflasher flashes just the EFI firmware inside the BootROM. NVRAM volume, BootBlock and MLB sector are not touched.
Just sharing an excerpt of a totally boring NVRAM volume that really caught my eye today, a completely new BootBlock version!
I really wasn't expect to see that BootBlock version AAPLEFI1.88Z.0004.I00.0908061259. Looking at the dates, it's very likely that factory BootROM probably was B05 or B06, more likely the latter.
I'll add it to the first post.
Code:
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
240027 0x3A99B BIOS version: MP41.88Z.0081.B07.0910130729
764315 0xBA99B BIOS version: MP41.88Z.0081.B07.0910130729
1179688 0x120028 NVRAM start of the 1st VSS stream
1183321 0x120E59 NVRAM MemoryConfig type: (i)
1185687 0x121797 NVRAM SIP state, type: (w)
1186304 0x121A00 NVRAM MemoryConfig type: (g)
1188352 0x122200 NVRAM MemoryConfig type: (h)
1190400 0x122A00 NVRAM MemoryConfig type: (i)
1345189 0x1486A5 HardwareID Base_xx: 20
1345198 0x1486AE HardwareID 11-digits SSN: redactedE1C
1345215 0x1486BF HardwareID 3-digit HWC model: E1C
1416499 0x159D33 BIOS version: MP41.88Z.0081.B07.0910130729
4128867 0x3F0063 BootBlock version: AAPLEFI1.88Z.0004.I00.0908061259I really wasn't expect to see that BootBlock version AAPLEFI1.88Z.0004.I00.0908061259. Looking at the dates, it's very likely that factory BootROM probably was B05 or B06, more likely the latter.
I'll add it to the first post.
Hi tsialex. I'm so sorry to run into your thread. Recently, I've accidentally booted into windows. ( I'm not sure what damages I've made then)
I've been trying to search for topics and discussions, on how to look for signs whether the certs have been written only to nvram or not. but, I can only manage to go as far as installing Binwalk via homebrew. (please forgive me, I have low tech knowledge).
Can I ask you to point me into the right directions on how to and read up a little bit more? I'd wish to at least try to repair to what I've done wrong. I'm running a cMP 2009 (flashed to 5,1), High Sierra 10.13.6 and bootrom 144. (and also, it's rather odd that I couldn't find the PM button to message you privately)
I've been trying to search for topics and discussions, on how to look for signs whether the certs have been written only to nvram or not. but, I can only manage to go as far as installing Binwalk via homebrew. (please forgive me, I have low tech knowledge).
Can I ask you to point me into the right directions on how to and read up a little bit more? I'd wish to at least try to repair to what I've done wrong. I'm running a cMP 2009 (flashed to 5,1), High Sierra 10.13.6 and bootrom 144. (and also, it's rather odd that I couldn't find the PM button to message you privately)
While it's easy to confirm if your Mac Pro firmware have SecureBoot certificates inside the NVRAM volume, just run binwalk with your BootROM image dump and see if the output show any X.509 certificates inside, SecureBoot is just a red-herring.
The real problem is the NVRAM data/variables/entries not being erased anymore and the NVRAM volume part of the BootROM self destructing over the years. SecureBoot just makes this process much faster since the certificates/DBs/PKs occupy so much valuable space inside the NVRAM volume.
I've sent you a PM with instructions.
Last edited: