Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Status
The first post of this thread is a WikiPost and can be edited by anyone with the appropiate permissions. Your edits will be public.

imax2k2

macrumors regular
Feb 25, 2009
107
9
Hello everyone
Can someone please give me advise, i done all steps from post #1345 of vk2fro except of flashing new rom and have few questions:
1. When i dumped firmware from my mac and open it in UEFItool it shows unknown file system messages

Is it bad? or i can just ignore this ?

2. So i have downloaded from appstore "high sierra install.app" (10.13.5 version) and grab from it by "pacifist.app" NVMe driver from MBP114_0183_B00.fd. When i replace NVMe part in my bios i see different checksum - my is C0h instead of D5h. Data size is 25820

So is it bad or it's because of the updated firmwares in latest "high sierra install.app" ?

3. And finally is it necessary to update firmware of my MBR mid 2014 (with apple ssd) if i'm already updated to latest high sierra update (10.13.5) to get flawless workin of intel's 760p 1tb driver? I'm already bought sintech latest version adapter (black) and
going to buy new ssd in next week. Want to clarify all things before buy and flashing firmware

p.s. sorry for my english, hope someone will understand what i'm trying to say

You have to replace the body. And unless you’re having sleep/hibernation issues. I’d recommend not doing this. Any wrong step with make your MBP a palate weight.
 

imax2k2

macrumors regular
Feb 25, 2009
107
9
i'v done "replace as is" like in step by step guide
is it matter?



of course i understand it, just want to prepare all to not wasting time when i will and if i will get problems... =]

You have to replace from where the address, the whole parent has to be replaced.
 

alex_raa

macrumors newbie
Jun 2, 2018
18
7
Is the checksum same in the new file, the first screenshot is where the file hasn’t been merged into.

From my original dumped bios:
File GUID: 51116915-C34B-4D8E-86DB-6A70F2E60DAA
Type: 07h
Attributes: 40h
Full size: 288Bh (10379)
Header size: 18h (24)
Body size: 2873h (10355)
State: F8h
Header checksum: 73h
Data checksum: 7Fh


After replace:
File GUID: 51116915-C34B-4D8E-86DB-6A70F2E60DAA
Type: 07h
Attributes: 40h
Full size: 64DCh (25820)
Header size: 18h (24)
Body size: 64C4h (25796)
State: F8h
Header checksum: E6h
Data checksum: C0h
 

buchacho

macrumors newbie
Dec 16, 2008
19
1
I did an update (after using CCC) from 10.13.2 to 10.13.5 and couldn't successfully boot any more. I am hoping someone can clarify if the type of Sintech adapter is critical for a MBA early 2015 (i7). I am under the impression that it only matters for older models. I am using the small black one I bought a few months ago and just bought an SSD for it.
 
Last edited:

chrissnn

macrumors newbie
Jan 23, 2018
9
0
Got my first kernel panic today on my Mbp 2015 13" with Toshiba XG3:



Sun Jun 3 12:48:11 2018

*** Panic Report ***
panic(cpu 0 caller 0xffffff7f9d7d6f7b): nvme: " NVMe: Command timed-out and request found in the completion queue \n"@/BuildRoot/Library/Caches/com.apple.xbs/Sources/IONVMeFamily/IONVMeFamily-356.50.26/IONVMeController.cpp:5188
Backtrace (CPU 0), Frame : Return Address
0xffffff912a46bb50 : 0xffffff801a86e166
0xffffff912a46bba0 : 0xffffff801a996714
0xffffff912a46bbe0 : 0xffffff801a988a00
0xffffff912a46bc60 : 0xffffff801a820180
0xffffff912a46bc80 : 0xffffff801a86dbdc
0xffffff912a46bdb0 : 0xffffff801a86d99c
0xffffff912a46be10 : 0xffffff7f9d7d6f7b
0xffffff912a46be30 : 0xffffff801ae9f71c
0xffffff912a46bea0 : 0xffffff801ae9f646
0xffffff912a46bed0 : 0xffffff801a8a77e4
0xffffff912a46bf40 : 0xffffff801a8a7345
0xffffff912a46bfa0 : 0xffffff801a81f4f7
Kernel Extensions in backtrace:
com.apple.iokit.IONVMeFamily(2.1)[AAD9E232-4F00-3702-9310-C5ABB53A5B6F]@0xffffff7f9d7c3000->0xffffff7f9d801fff
dependency: com.apple.driver.AppleMobileFileIntegrity(1.0.5)[E56BF7DF-B38F-3193-9A02-9DB0BAC70D7A]@0xffffff7f9b7fd000
dependency: com.apple.iokit.IOPCIFamily(2.9)[580E0204-B37A-32BA-AC27-E8DBCA519B1F]@0xffffff7f9b094000
dependency: com.apple.driver.AppleEFINVRAM(2.1)[F35A52E2-CF80-3BA9-92B5-25EFE216094F]@0xffffff7f9b67a000
dependency: com.apple.iokit.IOStorageFamily(2.1)[F27A8A2A-6662-3608-83BD-415037509E01]@0xffffff7f9b246000
dependency: com.apple.iokit.IOReportFamily(31)[D2F2FBDF-4EE4-38BA-99F5-B699F886F413]@0xffffff7f9bc82000

BSD process name corresponding to current thread: kernel_task

Mac OS version:
17E202

Kernel version:
Darwin Kernel Version 17.5.0: Fri Apr 13 19:32:32 PDT 2018; root:xnu-4570.51.2~1/RELEASE_X86_64
Kernel UUID: 7134F18E-AAC2-3C5B-B2C4-ABB799B4B9DF
Kernel slide: 0x000000001a600000
Kernel text base: 0xffffff801a800000
__HIB text base: 0xffffff801a700000
System model name: MacBookPro12,1 (Mac-E43C1C25D4880AD6)

System uptime in nanoseconds: 54228511104
last loaded kext at 2137740312: com.apple.iokit.SCSITaskUserClient 404.30.2 (addr 0xffffff7f9d269000, size 45056)
loaded kexts:
com.apple.iokit.SCSITaskUserClient 404.30.2
com.apple.driver.AppleUSBStorageCoexistentDriver 439.50.6
com.apple.driver.AppleUSBCardReader 439.50.6
com.apple.iokit.IOBluetoothUSBDFU 6.0.5f3
com.apple.driver.AppleFileSystemDriver 3.0.1
com.apple.filesystems.hfs.kext 407.50.6
com.apple.AppleFSCompression.AppleFSCompressionTypeDataless 1.0.0d1
com.apple.BootCache 40
com.apple.AppleFSCompression.AppleFSCompressionTypeZlib 1.0.0
com.apple.driver.AppleTopCaseHIDEventDriver 133
com.apple.filesystems.apfs 748.51.0
com.apple.driver.AirPort.BrcmNIC 1240.29.1a7
com.apple.driver.AppleSmartBatteryManager 161.0.0
com.apple.driver.AppleACPIButtons 6.1
com.apple.driver.AppleRTC 2.0
com.apple.driver.AppleHPET 1.8
com.apple.driver.AppleSMBIOS 2.1
com.apple.driver.AppleACPIEC 6.1
com.apple.driver.AppleAPIC 1.7
com.apple.nke.applicationfirewall 183
com.apple.security.TMSafetyNet 8
com.apple.security.quarantine 3
com.apple.iokit.IOUSBMassStorageClass 4.0.4
com.apple.driver.usb.IOUSBHostHIDDevice 1.2
com.apple.driver.usb.cdc 5.0.0
com.apple.driver.usb.networking 5.0.0
com.apple.driver.usb.AppleUSBHostCompositeDevice 1.2
com.apple.filesystems.hfs.encodings.kext 1
com.apple.driver.AppleUSBMergeNub 900.4.1
com.apple.driver.AppleThunderboltDPInAdapter 5.5.3
com.apple.driver.AppleThunderboltDPAdapterFamily 5.5.3
com.apple.driver.AppleThunderboltPCIDownAdapter 2.1.3
com.apple.driver.AppleActuatorDriver 1404.4
com.apple.driver.AppleHIDKeyboard 205
com.apple.driver.AppleHSBluetoothDriver 133
com.apple.driver.IOBluetoothHIDDriver 6.0.5f3
com.apple.iokit.IOBluetoothFamily 6.0.5f3
com.apple.driver.AppleMultitouchDriver 1404.4
com.apple.driver.AppleInputDeviceSupport 1404.3
com.apple.driver.AppleXsanScheme 3
com.apple.driver.AppleHSSPIHIDDriver 53
com.apple.iokit.IONVMeFamily 2.1.0
com.apple.driver.AppleThunderboltNHI 4.7.2
com.apple.iokit.IOThunderboltFamily 6.7.8
com.apple.iokit.IO80211Family 1200.12.2
com.apple.driver.mDNSOffloadUserClient 1.0.1b8
com.apple.driver.corecapture 1.0.4
com.apple.driver.AppleHSSPISupport 53
com.apple.driver.AppleIntelLpssSpiController 3.0.60
com.apple.driver.AppleIntelLpssDmac 3.0.60
com.apple.driver.AppleIntelLpssGspi 3.0.60
com.apple.driver.AppleIntelLpssI2C 3.0.60
com.apple.driver.usb.AppleUSBXHCIPCI 1.2
com.apple.driver.usb.AppleUSBXHCI 1.2
com.apple.driver.usb.AppleUSBHostPacketFilter 1.0
com.apple.iokit.IOUSBFamily 900.4.1
com.apple.driver.AppleUSBHostMergeProperties 1.2
com.apple.driver.AppleEFINVRAM 2.1
com.apple.driver.AppleEFIRuntime 2.1
com.apple.iokit.IOHIDFamily 2.0.0
com.apple.iokit.IOSMBusFamily 1.1
com.apple.security.sandbox 300.0
com.apple.kext.AppleMatch 1.0.0d1
com.apple.driver.DiskImages 480.50.10
com.apple.driver.AppleFDEKeyStore 28.30
com.apple.driver.AppleEffaceableStorage 1.0
com.apple.driver.AppleKeyStore 2
com.apple.driver.AppleUSBTDM 439.50.6
com.apple.driver.AppleMobileFileIntegrity 1.0.5
com.apple.iokit.IOUSBMassStorageDriver 140.50.3
com.apple.iokit.IOSCSIBlockCommandsDevice 404.30.2
com.apple.iokit.IOSCSIArchitectureModelFamily 404.30.2
com.apple.iokit.IOStorageFamily 2.1
com.apple.driver.AppleCredentialManager 1.0
com.apple.driver.KernelRelayHost 1
com.apple.iokit.IOUSBHostFamily 1.2
com.apple.driver.usb.AppleUSBCommon 1.0
com.apple.driver.AppleBusPowerController 1.0
com.apple.driver.AppleSEPManager 1.0.1
com.apple.driver.IOSlaveProcessor 1
com.apple.iokit.IOReportFamily 31
com.apple.iokit.IOTimeSyncFamily 675.12
com.apple.iokit.IONetworkingFamily 3.4
com.apple.driver.AppleACPIPlatform 6.1
com.apple.driver.AppleSMC 3.1.9
com.apple.iokit.IOPCIFamily 2.9
com.apple.iokit.IOACPIFamily 1.4
com.apple.kec.pthread 1
com.apple.kec.Libm 1
com.apple.kec.corecrypto 1.0

EOF
Model: MacBookPro12,1, BootROM MBP121.0171.B00, 2 processors, Intel Core i5, 2,7 GHz, 8 GB, SMC 2.28f7
Graphics: Intel Iris Graphics 6100, Intel Iris Graphics 6100, Built-In
Memory Module: BANK 0/DIMM0, 4 GB, DDR3, 1867 MHz, 0x02FE, 0x4544464132333241324D412D4A442D460000
Memory Module: BANK 1/DIMM0, 4 GB, DDR3, 1867 MHz, 0x02FE, 0x4544464132333241324D412D4A442D460000
AirPort: spairport_wireless_card_type_airport_extreme (0x14E4, 0x133), Broadcom BCM43xx 1.0 (7.77.37.29.1a7)
Bluetooth: Version 6.0.5f3, 3 services, 27 devices, 1 incoming serial ports
Network Service: Wi-Fi, AirPort, en0
USB Device: USB 3.0 Bus
USB Device: Internal Memory Card Reader
USB Device: Bluetooth USB Host Controller
Thunderbolt Bus: MacBook Pro, Apple Inc., 27.1
 

imax2k2

macrumors regular
Feb 25, 2009
107
9
It seems the issue for people with MBPs from Late 2013 and after, who are trying to update their boot rom, these macs don’t enter the firmware/programming update mode simply by pressing and holding Power button. Currently it is not known how these macs enter that mode. I just had this confirmed from dosdude1.
 

daniele_zing

macrumors newbie
Jan 25, 2018
17
5
Italy
Looks like with recent High Sierra update (10.13.5) the bootrom on my MacBook Pro retina 13 late 2013 has been updated to version MBP111.0146.B00.
Was there any improvement in the management of NVMe drives?
I have no way to check.
After my failure with an attempt to install a Toshiba XG3 I actually gave up my wish to install a NVMe drive , waiting for better times .... Have they arrived?
 

Earl Urley

macrumors 6502a
Nov 10, 2014
793
438
Well, the original High Sierra upgrade appears to be able to invoke the firmware update, someone may have to take it apart to see what it does; I'd imagine it's just setting an undocumented NVRAM bit that tells the machine to look for the firmware update in the proper location..
 

thierrybeginl

macrumors newbie
May 2, 2017
15
0
Hello peep,

I am ready to buy an SSD for my late 2013 A1398. When I see Toshiba XG5 (4 or 3), I only find TLC and I prefer SLC because it last way longer. Does it exists?? Or should I go with evo 960?

I want to install bootcamp also. I don't care about hibernating, i will just shut down the comp.

Thanks!
 

HBP

macrumors member
Aug 22, 2006
67
0
Looks like with recent High Sierra update (10.13.5) the bootrom on my MacBook Pro retina 13 late 2013 has been updated to version MBP111.0146.B00.
Was there any improvement in the management of NVMe drives?
I have no way to check.
After my failure with an attempt to install a Toshiba XG3 I actually gave up my wish to install a NVMe drive , waiting for better times .... Have they arrived?

What was the bootrom in 10.13.4?
Didn’t realize there was a change when I upgraded this AM.

I’m currently restoring to a 960evo with long black sintech in my mid-2014 MBP
It was detected as an internal drive when booting to a USB installer

Lets see how it goes
 

imax2k2

macrumors regular
Feb 25, 2009
107
9
What was the bootrom in 10.13.4?
Didn’t realize there was a change when I upgraded this AM.

I’m currently restoring to a 960evo with long black sintech in my mid-2014 MBP
It was detected as an internal drive when booting to a USB installer

Lets see how it goes

Was this different from your past experience?
 

terraphantm

macrumors 68040
Jun 27, 2009
3,816
670
Pennsylvania
Well, the original High Sierra upgrade appears to be able to invoke the firmware update, someone may have to take it apart to see what it does; I'd imagine it's just setting an undocumented NVRAM bit that tells the machine to look for the firmware update in the proper location..
I think what happens is when the firmware is "blessed" and stored in the EFI partition, the stock firmware loads it, does some quick verification (signature check, checksum, version check) and then flashes. Seems to reject downgrades and sidegrades, and also rejects modified scap files.

External programmers might be the only way on newer macbooks. There were some vulnerabilities in old EFI versions that let you flash from the OS, but looks like Apple fixed those.
 
  • Like
Reactions: Cmd+Q

vk2fro

macrumors member
Apr 29, 2015
99
51
Sydney, Australia
It would appear that I am having the same problems as everybody else, not being able to flash the boot rom. I wish to apologise to everyone for getting their hopes up. it turnes out that comparing the CRC32's of the two roms (pre flash dump and post "flash" upgrade is not sufficient to be able to determine the process worked. The crc32's of the original unflashed dump can change, due to bits changing inside the EFI, for example by changing the computers volume or brightness. Thus the crc32 check is not sufficient to verify the flash procedure work - dumping after flashing and checking for the modifications will work.

And guess what, I ended up apon dumping with the same old stock rom as before - the flash procedure had not worked. So once again sorry for jumping to conclusions - the edited roms will work, we just need to some how get them into the bootrom! (either by software or using a hardware programmer)

Further research has revealed that the rom is locked for read only (and by that I mean flashing, not changing of parameters such as volume etc) early on in the boot process, another way would be to attack it from a hardware programmer in a similar fashion to the malicious code contained in devices that carry the Thunderstrike payload, which work over thunderbolt ports. This would also bypass the downgrade/sidegrade checks performed by the system. Of course this would be a lot of effort to do the same thing as using an SPI programmer - you'd need to develop and test a piece of hardware (or modify something) that connects to thunderbolt to deliver the payload (in this case, a modified bootrom).

I think our best line of attack is to see how the firmware upgrade process works in the OS installer, and attack that so we can enable firmware writing - it should not be too difficult to "falsify" the version number in the bootrom so it can be tricked into upgrading itself with the new patched rom.
 
Last edited:

Cmd+Q

macrumors member
Apr 23, 2018
57
75
I think what happens is when the firmware is "blessed" and stored in the EFI partition, the stock firmware loads it, does some quick verification (signature check, checksum, version check) and then flashes. Seems to reject downgrades and sidegrades, and also rejects modified scap files.

This matches exactly my experience and tests today - based on the behavior described in this paper. And I cannot seem the find the mechanism that places the machine into firmware programming mode: presumably only when in EFI and with internal, stock SSD.
 

vk2fro

macrumors member
Apr 29, 2015
99
51
Sydney, Australia
Part of the reason the flash procedure is designed to work from the internal storage only is that this is a rudimentry sort of defence against attack vectors that exploit the use of external usb devices/thunderbolt devices from uploading malicious code or otherwise tampering with the rom. Good in one way, but a nuisance in our case as we WANT to flash a modified rom.

I have worked out a simple solution to bypass the protection but it involves opening the computer and a soldering iron along with a 100k resistor - we bypass the write enable / write protect line going to the SPI chip, by tying it to ground or Vcc using the resistor - which ever logic level enables flash mode, flash it with dosdude1's software, then return control of the write enable line to the logic board. I am looking for the paper I read on the Thunderstrike 2 exploit I read a few days ago - it goes in depth on how the flash protection works, and how we might be able to use the paper to learn how to temporarily bypass the protection. It was very in depth, and went down to what the pins on the SPI flash chip actually did. AFAIK the resistor could theorectically be left in place indefinatly so we could continue to flash modified roms to these models, or removed easily by untacking one end, then untacking the other. Personally I would remove the resistor once your done to restore the security agains firmware worms and other malicious code that could easily brick the machine.

The whole reason for this is not many people are really going to want to buy an SPI flashing device just for one or two jobs nor wait for it to arrive on the slow boat from China (the cheaper ones that are capable of doing the work are all shipped out of China). However a soldering iron is cheap, available almost everywhere, and most people who pull apart computers to do maintainence or upgrades, would know how to use one. Now that dosdude1 has provided the software to flash the rom, and gilles_polysoft has provided the processs for modifying the rom the only thing standing in our way is the way the logic board protects against malicious code rewriting parts or all of the firmware chip. Newcomers to soldering would obviously be well advised to practice on some dead circuits first to get a feel for the skill, before attacking an soic8 device, but its an easy skill to pick up - there are plenty of video tutorials on youtube to teach you. if you're still too scared to do it, you could always take the machine to a friend you trust who has done xbox or other console hackery - the process is similar to adding a very simple mod-chip.

Before my trying any of this I need to do more research and begin with removing my firmware password and temporarily uninstalling my copy of Orbicule Undercover, just in case it gets in the way of flashing the firmware.

If the resistor trick doesn't work, we'll just have to concede that loading a hacked firmware will not be possible with software along with a 5 c part, and can only be accomplished with a SPI programming tool. These are cheap too, just take a while to arrive, but better than pulling your hair out wondering why the hacked firmware won't take, and less invasive than soldering to the chip inside the notebook.

edit: apologies for any poor spelling - at home sick today but brain going lightspeed + 10 as usual :). Since I am not well and my hands very shaky at the moment I cannot perform the resistor trick yet - and I'd like to do more research on wether my speculated process will work at all - in theory it should. The trick could possibly be performed with an SOIC8 clip with the resistor attached at the other end, but that would make it kind of difficult to then flip the computer over to boot it and load dosdude1's software. Once again apologies if I am not making a lot of sense, I am not well and this is speculation only, but it should work.

TL;DR : it may be possible to trick / jump start the firmware to always be in flash mode with a resistor, but doing so opens up the computer to firmware exploits by malicious code. An SOIC clip with the resistor elimenates the need for any other tools like a soldering iron.

Has anyone attempted to use the "efiupdater" program with our hacked roms and the --force-update switch?

edit 2: on further research it looks like the only easy way to write to the rom chip is with a raspberry pi and a clip for now. A raspberry pi is also a handy thing to have around - I have 1 here but it does not belong to me so I won't tinker with it, but they're basically a little linux computer which one can use to program the flash. They are often used when the owner of the computer has forgotten their icloud or firmware password to get around it, but also can be used for flashing the chip.
 
Last edited:
  • Like
Reactions: nephron8

Cmd+Q

macrumors member
Apr 23, 2018
57
75
Has anyone attempted to use the "efiupdater" program with our hacked roms and the --force-update switch?

Yes, the output is the same as “bless” with the modified UEFI capsule (SCAP). EFIUPDATER (per the paper referenced above) seems to be picking the SCAP/FD files from a directory based on MacBook model and detected EFI ROM versions. Force-update in EFIUPDATER correctly picks up the modified SCAP (in my case, 0146 to Modified 0146 on a MBP11,1): I can see the SCAP file being copied to the EFI paritition and the NVRAM variables for boot changing, but it is not actually flashing the ROM upon boot - neither with the NVMe drive nor the stock SSD. There is probably some checksum/signature check that will need to be defeated, and that check is not in “bless” or “efiupdater”.

I had high hopes that 0146 on MBP11,1 introduces proper NVMe support (the DXE section did change between 0145 and 0146).
 

Earl Urley

macrumors 6502a
Nov 10, 2014
793
438
Just updated a 13-inch MacBook Pro Late 2015 from 10.13.4 to 10.13.5, using the combo update..

looks like the BootROM was updated from MBP121.0175.B00 to MBP121.0176.B00.

If someone were to tell me what to look for, I could report on whether or not the NVMe driver was patched/updated or not..
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.