Also thought I’d add for reference that the first disc I tested was an official Beta 1 disc; the second disc was a Nightly.
As of those mysterious “scaps”. If they are FW images from ROM (SPI NOR flash), then most probably they are the same FW images as edk2 produces. Apple people are present on edk2. edk2 uses a so called Platform Initialization (PI) specification to implement UEFI. Unlike UEFI, PI is very messy imho. anyway, PI also uses PE files, so FW itself is a bunch of PE files. They are put into a flash oriented File System, Firmware File System (FFS), very minimalistic one. And that thing is put inside a so called Firmware Volume (FV). Volume 3 of PI describes it all and does well and laconically. This whole thing is pretty ascetic - no directories for example, but ironically, “files” consist of sections in which “real” files reside. The FW PE images for example. What I wanted to say, that you could try to confirm your guesses on what are those scap files. If it’s not encrypted of course. 
There is a lot of signatures (and GUIDs) inside, you can recognize easily, just looking at it in the hex viewer. For example, Firmware Volume Header has “_FVH” signature. “PE” signatures of PE images as well. Actually seeing these, one can then write the whole FV reader that would be able to show all the content of the FV. Every “file” has its header, and there are fields with different meanings, - types of what it is, for example. The same goes to “sections”. Let me show an excerpt from the C header file documenting this, file types:
/* File types */
#define EFI_FV_FILETYPE_RAW 0x01
#define EFI_FV_FILETYPE_FREEFORM 0x02
#define EFI_FV_FILETYPE_SECURITY_CORE 0x03
#define EFI_FV_FILETYPE_PEI_CORE 0x04
#define EFI_FV_FILETYPE_DXE_CORE 0x05
#define EFI_FV_FILETYPE_PEIM 0x06
#define EFI_FV_FILETYPE_DRIVER 0x07
#define EFI_FV_FILETYPE_COMBINED_PEIM_DRIVER 0x08
#define EFI_FV_FILETYPE_APPLICATION 0x09
#define EFI_FV_FILETYPE_SMM 0x0a
#define EFI_FV_FILETYPE_FIRMWARE_VOLUME_IMAGE 0x0b
#define EFI_FV_FILETYPE_COMBINED_SMM_DXE 0x0c
#define EFI_FV_FILETYPE_SMM_CORE 0x0d
#define EFI_FV_FILETYPE_OEM_MIN 0xc0
#define EFI_FV_FILETYPE_OEM_MAX 0xdf
#define EFI_FV_FILETYPE_DEBUG_MIN 0xe0
#define EFI_FV_FILETYPE_DEBUG_MAX 0xef
#define EFI_FV_FILETYPE_FFS_MIN 0xf0
#define EFI_FV_FILETYPE_FFS_MAX 0xff
#define EFI_FV_FILETYPW_FFS_PAD 0xf0Section types:
/* Encapsulation section Type values */
#define EFI_SECTION_COMPRESSION 0x01
#define EFI_SECTION_GUID_DEFINED 0x02
#define EFI_SECTION_DISPOSABLE 0x03
/* Leaf section Type values */
#define EFI_SECTION_PE32 0x10
#define EFI_SECTION_PIC 0x11
#define EFI_SECTION_TE 0x12
#define EFI_SECTION_DXE_DEPEX 0x13
#define EFI_SECTION_VERSION 0x14
#define EFI_SECTION_USER_INTERFACE 0x15
#define EFI_SECTION_COMPATIBILITY16 0x16
#define EFI_SECTION_FIRMWARE_VOLUME_IMAGE 0x17
#define EFI_SECTION_FREEFORM_SUBTYPE_GUID 0x18
#define EFI_SECTION_RAW 0x19
#define EFI_SECTION_PEI_DEPEX 0x1B
#define EFI_SECTION_SMM_DEPEX 0x1CFor example, the mentioned above Dxe is actually UEFI implementation roughly speaking. These files are put side by side in the FV. It’s a flat structure. So reading through it (programmatically I mean ), one may relatively easy not only confirm their guesses on what it is, but even - explore/extract its content.
But of course, it has nothing to do with how UEFI loads its payloads. Here, apple’s FW is either UEFI compliant or not. If the former, then nothing special should be there. FW processes load options that point to PE images, which are OS Loaders, they start and load their OS. Or do some unneeded chaining, transferring control elsewhere.
Even though I wouldn’t be surprised if Apple made it “differently”, turning into incompatible pile of mess, still I believe it’s UEFI compatible. Your problem has some other reasons.
1 Like
There could be a way to check this theory, I think.
1 Like
There probably is… but I’m not willing to try to flash the file and brick a MacBook to find out.
Thanks for the tips about the scap files, btw; sorry I left an essay earlier. I think this whole Mac and EFI thing touches a certain Mac-shaped tangent in my soul that’s causing me to take it more seriously than usual. 
There is a possibility to find out if these “scaps” are images of a file system or not. In Linux and also in macOS a file can be mounted just as it would be a partition:
mount -o loop <filename> /mnt
This command will try to determine the filesystem used by filename image and mount it into /mnt folder. You can also suggest its filesystem (expected fat32) by passing the option -t fat32. Linux also knows how to mount HFS+ (I don’t know if APFS also works).
Another option is to try to open such a file with some archiver application. They are known to “open” *.iso files and you can see and extract their contents.
Finally (but actually this would be the first action to try), you can guess whether the file contains a filesystem by compressing it. Usually flash images’ sizes match to partition size, but their content takes much less space. So these images contain a portion of meaningful information followed by zeros (or garbage). If the size of compressed file is much less then the size of uncompressed file, this usually is a good indication of a flash image contained in this file.
I think it is safe to ignore these scap files. They are indeed related to booting (they are a copy of the machine firmware), but they are not something you need to mess with.
As for UEFI, be careful with your look at the DVD. The DVD is an “anyboot” image, which means it shows itself as various things depending on how you look at it. It is both a DVD image with ISO9660 filesystem, and an MBR partition record with a BFS and a FAT32 EFI partition inside.
The EFI system partition is usually not directly accessible from the OS (at least Windows will hide it completely from the GUI, and Linux will apparently allow to mount it manually, but will not automount it like other partitions). And that’s the one partition you need to put files on when installing a new system, which makes this a little tricky, of course. Find the way to that partition and you can work out a way to install the EFI files for all your OS in a way that works. Possibly with rEFInd or some other similar tool to easily pick which one to start when you power on the machine.
This is PI. 
ironically, I didn’t know about this tool, lamer. 
I write (as a hobby) my own UEFI implementation for ARM/MIPS single board computers. Initially, I went this way and tried to follow PI spec. Then decided to do it my way - it’s too overdesigned. Still, I plan to support FV/FFS for devices where FW goes onto flash devices (SPI NOR flash).
This screenshot below is a big proud for me, because it was significant success - I was able to set PLLs (clocks), configure UART, and … SDRAM! :o Of course, consulting with resources on the Internet. And then add read from SD card. It’s MIPS machine, it was the first time when my code ran on bare metal without anything below it. traces of PI are seen on the output (this is printing into UART to the putty) - “SEC”, it’s the name for the very first phase of th FW. Then PEI, then DXE, then BDS. And “CFV” at the end is “Core Firmware Volume”. This board has bare NAND storage, in theory, FW should go there, but bare NANDs are well, too complex, so SD card so far. Now I’m trying to do the same for ARM boards to be able to finally test Boot Services, written but untested.
1 Like
To the Mac-and-Haiku fans following this project, I’m sorry I haven’t replied in a while; I’ve recently started a part-time job in the background, on top of the stuff I’m already trying to do, and haven’t had the time to really get into the Mac to solve this like I need to. I can assure the community once I can get around to testing my notebooks with Haiku again, I’ll get this little subproject back to life. So bear with me… 