Apple Mac firmware. Layout, Data Space and Variables.

Apple Mac's firmware almost corresponds to the Intel specification for Flash Images. Almost, because that Bios Region is used as data storage for OS specific values, EFI-password, EFI and/or ME applications (some executables if to be fair) and other Apple specific data.
Apple ROMs contain 3 regions: Flash Descriptor, ME Region, BIOS Region. Sizes and offsets defined in Flash Descriptor and can be detected by utilities such as 'flashrom' during a flash chip reading or FITS. FITS however can not read the data within the BIOS and ME regions, but can build a map-file with sizes and offsets for all regions.

BIOS Region inside ROM file can be divided on 2 parts. The first portion is a BIOS itself, the second - Apple specific data.

Line of separation can be found at a 32-bytes sequence:

00000000000000000000000000000000
8D2BF1FF96768B4CA9852747075B4F50

Offset is depended from model or chipset used in model. Can little migrate, but always follows after BIOS code.

Apple specific block contain as minimum 3 independent parts.

1. Machine configuration, bootloader configuration, OS relative configuration such as audio volume, Wi-Fi networks, Bluetooth devices configuration (keyboard and mouse) etc. Also block with machine serial number and model number definition.
2. EFI-password block
3. Block with EFI/ME applications. This area does not discovered fully, so any suggestions are welcome.

The Variables inside Apple specific data block.



Every variable's record within ROM-file corresponds to EFI Variable Services Feature. Variable namespaces are identified by GUIDs, and variables are key/value pairs. At the storage (inside ROM-lise) variables are can be identified by formula:

[Descriptor 0x10 bytes][GUID 0x10 bytes][key/value pair, size defined by descriptor]

Where,
Descriptor: The first 2 bytes = 'AA55'. Next 2 bytes = 7F00 or 7C00 or 7D00 and likely be interpreted as state of a variable's record. According to my observations only '7F00'-state vars appear in EFI environment. (EFI shell 'dmpstore' command used for analyze)
Next 4 bytes seems used as 'variable record format' key. In ROMs which I parse it is a sequence '07000000' or '07000080'.
Next 4 bytes is a length of a key. And next 4 bytes is a value's length. Both are little endian 32-bit digits.

GUID: 16 bytes. Should be read by formula:
[4 bytes as little endian 32-bit unsigned][2 bytes as little endian 16-bit unsigned][2 bytes as little endian 16-bit unsigned][6 bytes as sequence]

Key/Value pair:
Sizes for key and value defined in the Descriptor. Storing format is depended on data in a second 4 bytes of Descriptor.
If it '07000000' then key/value data follows immediately after GUID. If it '07000080' you need skip 4 bytes after GUID and read data as defined in the Descriptor.

Answer on question: What inside? It is a main conclusion, I think.
I'll write another article about password area, how password stored and how to determine is set or not. This info should be enough to implement an application for cleaning dumps taken from a chip.

SSH,perl and lot of dumps will enough. Or I should to receive archive... Anyway, I believe that 'universal-way' exist.

Yep... need check my approach. I wrote script which makes search for password area, password records and create offsets map.
As fact, data in ROM file can slide and when we found offset for one EMC different offset on other EMC will necessarily be. So, I have to use 'relative orientation' theory in script... It almost done. 2/3 of plan.

Initial version of 'rom_scanner' script.
Script do scan of a file as command line argument. Performs checking of Intel Flash Image signature for Series 6,7,8 chipsets, makes a search for 'Apple Specific' area and password area, calculates offsets, makes checking of matching data from file to known stamps. For each found 'password' record parsing will performed.




An example:

I run it with EMC2555,EMC2428,EMC2554,EMC2745,EMC2881.
Still there a Rom file of EMC2395 model is not a Series 6+ model, and rom of my MBP 2008 year of production... Script found the first variable, that is surprising.

Is it some kind of wire with a SOIC clip? I bought today rapsberry pi. As I can see it is a must have device.

I bought PI to find better way. It will pity if because a stupid mistake machine will turn into brick and I can not fix it. I just must be ready for in-circuit operations.
Also I bought it for fun... let it turn on/off a tea makers...

You are a programmer correct?

I never thought about it. My main job is the networks and I love UNIX. I can write some code... but I call it as 'shit-script' because code itself little lame as I think.
I was spent much time with C language study, unsuccessful. I can read and little change foreign code but I can't write own from scratch. And for my job this skill does not needed. Perl, Shell and PHP was always enough. Actually code-writting is less interesting for me than analysis and logic inventing. I like search solutions.

Interesting info: http://code.coreboot.org/svn/flashrom/trunk/Documentation/mysteries_intel.txt

Citation:

Intel's flash image tool will always expand the last region so that it covers the whole flash chip, but some boards ship with a different configuration. It seems that in descriptor mode all addresses outside the used regions can not be accessed whatsoever. This is not specified anywhere publicly as far as we could tell. flashrom does not handle this explicitly yet. It will just fail when trying to touch an address outside of any region.

It may means that 'Apple Specific' area is not a part of the BIOS region and can be locked by ME. While we don't know how ME handle its blocks on the flash it should be as warning. All of this should be checked of course.

P.S. This info applicable for 'flashrom -p internal...' process only.

The problem as I can see is that space on the flash after BIOS is a 'BIOS Region' formally only. Stupid situation... Intel permits to divide a flash between different software such as 'Apple Specific' data, ME storage... etc BUT it does not have a manner to control it. It is very good, because we can read and may be write almost any part of flash. When I tried to parse Descriptor Region I only found offsets for beginning each region but not end. I found offsets for SPI lockdowns, but they are formally again, just addresses list, no more. The question is: What internal programmer can do? Can it write to locked down areas if 'force' was said?
However... problem. If password area is locked by ME as opened file or mounted filesystem for example, we cannot do correctly patch for area. Who ME handle it?
ah... I am in problem too... I can't explain... not have enough knowledge of English. Sorry...
My idea for now is attempt to patch the password area with clean records taken from clean dumps. I have both types of password area and can detect records type (my script does it) When I receive Raps PI, I will try patch ROM on my iMac with 'flashrom' and internal board programmer i.e. 'flashrom -p internal' and will use layout option where offset of password area will be defined, so 'flashrom' will erase and write the password area only and nothing else. It is experiment. And 3 expected results:
1. 'flashrom' just die on write attempt and do nothing
2. 'flashrom' writes area but after restart area will corrupted
3. 'flashrom' writes area successful and we will have 'Software' for password clean up.

ok don't know if this is what you where looking for but i removed a mx25l6406e from a macbook air and read and dumped flash with my Jtag-nt which is blazing fast it took less than a minute and i modded it to remove efi lock and when i was about to load it back i noticed it was 16mb so i changed the settings of the jtag-nt to read 8mb flash and dumped again and verified removed the efi lock again and load it back. ok after that i compared both dumps and i saw the bytes from the extra 8mb of the 16mb dump were not empty it had extra data.