EFI Learning, Documentation and Toolkits: Find, post and discuss EFI related resources

This thread is for general reference information and advanced technical issues with the EFI toolkits available from the likes of Intel and the Tiancore project. MacEFIx86 toolkits and specific application goals should be discussed their respective threads.


Intel EFI online tutorial (highly recommended):
Using the EFI Shell: http://or1cedar.cps.intel.com/softwarecoll...sp?courseID=172

Intel EFI training videos (free registration required):
Introduction to EFI OS Loaders: http://or1cedar.cps.intel.com/softwarecoll...sp?courseID=169
Introduction to Programming in EFI: http://or1cedar.cps.intel.com/softwarecoll...sp?courseID=170
Introduction to the EFI Tookit: http://or1cedar.cps.intel.com/softwarecoll...sp?courseID=171

These seem to be the two most important EFI pages:
http://www.intel.com/technology/efi/
https://www.tianocore.org/

EFI application details:
Intel's EFI Presentations page: http://www.intel.com/technology/efi/efi.htm

Other EFI references:
Amit Singh's EFI overview (excellent): http://www.kernelthread.com/publications/firmware/
The Wikipedia EFI page: http://en.wikipedia.org/wiki/Extensible_Firmware_Interface
OSx86Project's EFI Wikipag: http://wiki.osx86project.org/wiki/index.php/EFI
OnMac.net's EFI Wikipage: http://wiki.onmac.net/index.php/Developers/EFI


EFI Toolkits

Intel EFI Application Toolkit: http://www.intel.com/technology/efi/toolkit_overview.htm

Intel EFI Sample Implementation: http://www.intel.com/technology/efi/main_sample.htm

TianoCore EFI Development Kit (EDK): https://edk.tianocore.org/

TianoCore EFI Shell: https://efi-shell.tianocore.org/

Welcome to the MacEFIx86 Project!

This thread is for the discussion of the MacEFIx86 Project's motivation and goals

EFI is the Extensible Firmware Interface that Intel has designed to replace BIOS. EFI is also the firmware system that Apple is using on all x86 Macintoshes. For more information on EFI and links to references see our EFI Learning, Documentation and Toolkits thread: http://forum.osx86project.org/index.php?showtopic=17917

The continued use of BIOS for OSx86 while Apple builds on EFI will likely result in a difficult series of technical problems for the OSx86 community. Furthermore, we wish to be able to use graphics drivers like Apple's ATI x1600 which require EFI environment. We also ultimately want to be able to use Macintosh firmware feartures like BootCamp, BootSelector and Target Disk Mode on our machines. In short, we want to build more perfect Macintosh clones by using EFI just like Apple. For more information, on why we should be working on EFI and also opposing arguments see our Why People Should Work On EFI thread: http://forum.osx86project.org/index.php?showtopic=13493

The MacEFIx86 Project has been formed to bring people together who are interested in moving beyond the limitations of the BIOS environment when running OSx86. We view this as a long term project that will be near the core of OSx86 community development effort. We have established three goals:

Extracting Apple's EFI firmware: http://forum.osx86project.org/index.php?showtopic=18011

Booting EFI OS's on a BIOS Platform: http://forum.osx86project.org/index.php?showtopic=17932

EFI Motherboards, Flashing and Native Booting: http://forum.osx86project.org/index.php?showtopic=17930




Join the MacEFIx86 Project, we can use everyone's help!

Aye! Welcome from Rogabean as well.

Bofors is getting the forum in line while I prepare the first release of the environment from which we are working.

Please excuse our dust.

We need more people as well. I will be posting soon with a list of people I need at the moment for this project.

Extracting Apple's EFI firmware: Omni got it and we want it

A sub-goal of this project is find a technique to abstract the EFI firmware from Intel Macintoshes in the form of .efi modules. Omni was able to get a copy of radeon.efi, so we know this is possible. Alternatively, Intel Macintosh EFI firmware is freely downloadable from Apple itself and it certainly is possible to unarchive it to the .efi modular form.

Some of Apple's EFI firmware: http://www.apple.com/downloads/macosx/appl...eupdate101.html

Wim's BIOS Page and forum has a lot of potentially useful information and knowledgeable people: http://www.wimsbios.com/

Use this thread to discuss the possibility of extracting and examining the Apple EFI Firmware.

Specifically what we are in need of right now are the boot files being used to tell the system how to boot OS X. It is quite possible that Apple has reworked the EFI firmware to read HFS+ partitions, but that is unconfirmed.

We need to see how this puppy really works.

My first request of anyone would be to sit at the EFI shell prompt on the Intel mac and issue a drivers command and give me a listing of the output.

it will be more then one page... so drivers -b will break it up. for now I don't need the memory addresses, just the driver name and image name.

Saw this on some tech blog:

http://www.osxbook.com/book/bonus/chapter4/efiprogramming/

May be of use, or not, just thought I'd add it.

RF

Thanks, that is another EFI resource from Amit Singh, "EFI Programming on Mac OS X".

It is also useful to note that he has compiled his own EFI toolkits for both PPC and x86 OS X which are linked on that page.

I've managed to dump the output from the drivers command using the efi shell on my macbook pro 15", however, for some reason it truncates the output to an 80 column width, despite having run 'mode 180 47' before hand. output as follows, let me know if you need anything else. more than happy to experiment.

EDIT: Output attached to post as DriversDump.rtf

In order to get the -full- guid image names, here's the output from 'dh' for the device handles. these map to the start of the image names from the previous 'drivers' output:

EDIT: Output attached to post as HandlesDump.rtf

Hey Anomaly, thanks for posting your data. I put the dumps into attached text files so the thread is easier to read.

Is there anyway you could post some instructions on how to get into the EFI Shell on a Intel Mac?

We also trying to figure out how to save the loaded EFI drivers as .efi files, this is something you may be able to figure out with a little experimentation.

its trivial to get to the EFI shell with reFit (http://refit.sf.net) I still can't get their EFIAppLoader.efi to write the current firmware out from there. I'm thinking its going to be easier to extract the bin files. I decided to work on something else for the weekend (convertmake) I'll come back to this in a week or so when i feel up to unpacking PE binaries.

Glad to help anyone else who wants to try tho

-manch

Here is a relate page at Intel: http://www.intel.com/technology/efi/help/m...ice_handles.htm

The rEFIt Project is another resoure: http://refit.sourceforge.net/



Apparently, it also provides easy EFI Shell access on Intel Macs.

So what exactly are we doing here?
Are we emulating EFI or are we hacking the Mobo firmware to enable it.

Yes, we are working on emulating EFI on BIOS boards.



Sort of, we are also interested in flashing Apple's EFI firmware on to Intel EFI boards.

As manchmod said, I'm using rEFIt to run the efi shell (aswell as other things). I've been pretty busy at work lately, a deadline for our current project is getting close so I haven't had much free time to play around with efi. However I have some free time coming up soon and will gladly devote my time to trying to pull this stuff apart

I'll post anything I find here.

One thing in particular I would like to pull out of the firmware is the ATI 'vbios' driver that bootcamp uses so I can preload it for enabling 3d acceleration when booting using elilo instead of having to boot standard lilo through bootcamp and losing the framebuffer support

Ok i did not know that this project existed. For the past few months i have been hacking my mobo firmware to try and enable the EFI chipp that is already onboard (All boards that use the Intel 945 chipset support EFI).

The only problem is that no mobo maker wants to enbale it

I think that it would be much more useful to work on enabling this EFI chip instead of trying to emulate it. I do not think the BIOS will be able to Emulate it properly, and i also think taht it would take much more time to emulate it as we would have to initiate the Emualtion before booting an OS.

I was also thinking (and hoping) that the mobo manufacturers would release an udae to support EFI (i dont know why this would happen, maybe a petition of sorts (but that is just stupid, no?))

I think that the EFI specification has much larger room for low-level drivers. BIOS chips are purdy small.

Isnt the point of EFI to get away from 1985 technological limitations in Bios?

Sorry i didnt read above, yes i know taht we want to flash apples EFI onto intel boards. This is a very good idea. but if we had to do so we would still haver to enable the EFI from the ground up. instead of having a CD environment.

I think there is mass confusion on the issue of "enabling" EFI. In short, EFI is not "disabled" on Intel's boards, but rather the normal EFI firmware emulates BIOS.

well than would it be possible to stop it emualting BIOS and start emulating itself. or does it already do that?

Yes, that is one of the main goals for this project. We are interested in using Apple's flashing EFI firmware onto Intel EFI boards to do this. Intel also regular (not BIOS emulating) EFI firmware that will eventualy be released (perhaps when Vista supports EFI), so we could and probably will work with that too.

Great, looking forward to your assistance.

hi guys. i just read this. i thought it was important so here it is:

"And just by coincidence," Brookwood remarked, "the fact that their system relies on EFI, and no commodity Intel hardware at the motherboard level supports EFI, means that you can't start their stuff on a commodity board." In other words, Apple might not need fancy code to determine for Mac OS X to determine whether an attempt is being made to launch it in a non-Macintosh system. It could simply try tripping a BIOS interrupt - what developers call an "INT 13h." If it works...then OS X could easily halt itself.

We had been wondering for quirte a while whether a certain implementation of Intel's long-awaited Trusted Platform Module, known as LaGrande Technology (LT), would be making its premiere in the new Macs. Such a system, with its well-buried cryptographic keys, could make it easier for Apple to protect its intellectual property - both its operating system and the media components a user may download from iTunes. But we know that the 945 chipset does not carry LT. If it is the 945 that's running the Macs, this means that TPM won't play a role in 32-bit iMac and MacBook Pro architecture, at least for the next six months or so. If Apple truly does have something unique to hide beneath the lid of its new systems, this apparently isn't it.

hope you guys are on the rigth path.

best luck

That is from an article at TG Daily posted in January: http://www.tgdaily.com/2006/01/12/how_diff...tel-based_macs/

Not that this has much to do with EFI, but I had thought some form of LaGrande Technology was being used to secure OSx86. We know for sure that Apple is using encrypted binaries which were being decoded by the TPM chip, but perhaps the memory was not protected because LaGrande was fully operational and that is how Maxxuss was able to get the decrypted files needed.

is up to "AppleEFIRuntime" and his "plugin" "AppleEFINVRAM"

where will look for System/Library/CoreServices/boot.efi with "partition" UUID

set as "resource" (see IOKit reference of "publishResource(name, object)" )boot.efi = osx install UUID , stored at NVRAM in mac eeprom

depend's on bunch of "*.efi" modules

bofors.

so you think it is important to get a board thats has both tpm and efi?
i know yours has but there are other efi (intel) boards that only have efi. in order to get things going in the future, the most compatible board should have both?

thx

Whether a board has a TPM chip or not should be irrelevant here. This is because Apple's signs its TPM chips with its secret "endorsement key", TPM boards that you can buy are not encoded with that key.

EFI boards might make a difference in the future, after this project can flash them. But for now, EFI should not be a primary factor in choosing which board to buy.

Hey guys, Im not wanting to be annoying or anything, but thios board has been dead for like a couple days. What is happening?

Well I can't speak for anyone else, but real life has kept me barely able to breathe as of late. That's the reason for my absence... Hopefully it will all calm down soon so I can get back to working on this.

@bofors
Got impatient, reading all the questions from others that say "but what if" "I don't think" "isn't EFI illegal in Botswana", etc, etc. So bought a 945GNTLKR, knowing full well it's old tech. I'm gonna dink with all the things that come to mind.

Hopefully some others will do similar. After all, it's not like there's any personal health risks involved - just a piece of soon-to-be-antique hardware.

You seem to have a handle on what EFI is/can do, I'll try to add feedback as things progress.

BTW, both the Intel and Tianocore toolkits are full featured/fully working, just need people to get a better handle on how to use them is all.

I don't know what advantage will really be served putting a Apple firmware onto an Intel board, but that will be first order of business over here. It can't possibly work better than the Intel firmware (Apple power management comes to mind).

What about buying a Appleboard as a repairpart and go from there?!

Well, i dont hink Apple repair boards are very cheap, also it would just be the same as having a working iMac wouldnt it?

I'm thinking more like going for the upcoming Mac Pro board. And from there you could use cheaper stuff to build your own box. But as you say, it's probobly really expensive and I think it's a bit hard to get your hands on the Mac-boards.

Well thanks for your idea, it might be an option for some pepole

if apple make mistake and post leopard kernel sources for PPC ie darwin xnu, won't need any "EFI" loaders, cracks, flashing or sort of

the think is much more simple

yeah, hahah, that what was what i had thought of then dismissed quickly. That would be an even better option

oh that kind of better.... eheheheheehehe

More bonus content from Amit Singh's new OSX book...specifically stuff about the firmware, BIOS, and EFI.

http://www.osxbook.com/book/bonus/chapter4/firmware/

Ditto: http://www.osxbook.com/book/bonus/chapter4/efiprogramming/

EDIT: Simon, I moved this into the "correct" thread. ~bofors

Alright here is how you dump Apple's efi modules from memory! thanks to Omni

The way to dump all and any EFI modules from the Apple firmware is to use the dh command. With dh you can find the memory location of each module image, the memory can then be dumped using dmem, and subsequently converted back to raw form for use on the sample Intel floppy.

Umm, i forgot to ask thsi in the other thread, but hiow will we convert it to module form again? Dont we need some sort of script ?

This is GREAT!!!!!!!
i'm working with the dh command now...
how exactly do i do it?

With some instructions, i could get everything for tomorow!

By the way, i mean specifics. I am able to view the memory mappings of a handle of my choosing, but there are so many that i'm not sure which to use, and even when they display in dmem, how can i dump them somewhere else but the screen?

also, say i choose a handle 81, there is a reference to a pdbfilename and i was wondering how to access that file.

I have personally never used dh but i think i read about it while looking fo rways to dump the modules, its on the apple website under debuugers think.
It has more specific info there too if that is what you want.

found this on the Intel site

http://www.intel.com/technology/efi/help/m...and_Example.htm

http://www.intel.com/technology/efi/help/m...ice_handles.htm

Ive been playing with all this for a while.
It consists of using the drivers command to list the handles of all the drivers, and there are the EFI modules!

Pick the handle you want, and use the dh *# OF HANDLE* command and get all the memory info.

What i cant grasp is precisely which address to start from and how many bytes to display, as well as how to turn that into a file.

Any ideas?

[EDIT] I HAVE FIGURED OUT THE CORRECT MEMORY ALLOCATIONS FOR ANY GIVEN HANDLE!!!!!!!!

Let's take the example of hfsplus.efi. Handle 87 on my iMac (drivers command told me so!).
i did "dh 87" and then got all the memory addresses. This module lies between the values imagebase. To see all the hex code, type "dmem ***STARTING IMAGEBASE*** ***IMAGESIZE VALUE***

do not convert anything from hex to decimal.

now i need to translate all this hex code into a usable raw format.

once again, any ideas?

PDB files are usually configuration files for MS Visual programs, and as visual c++ are probably the software apple uses to make the efi modules. At least until they make their own software for xcode to compile efi files.

"By default, when you build projects generated by the Visual Workbench, the compiler switch /Fd is used to rename the .PDB file to <project>.PDB. Therefore, you will have only one .PDB file for the entire project. "

Taken from support.microsoft.com/kb/121366/.

Doesn't it mean that this file is indeed what we're after?

[update] it may or may not be a pdb file. It is whatever file the driver itself is.
dh 87 brings up information, one line of which is
"PdbFileName...: c:\buildtools\fware\m38main.proj\projectfiles\sandbox\Platform\IntelMpg\M38\Release\IA32\HfsPlus.pdb"
Looking at it now, it must point to an original file when the driver was created, therefore to a file deep within apple. It isn't a local file.

My next goal stands: convert the hex or ASCII from a textfile (print to a file?) into a usable format, whatever that is.

PDB files are not very important. The best thing would be to get the actual .c files (which also are deep down in a building in cupertino). I have tried to run the omnis radeon.efi file, but it don't. Maybe it is because of the legacy bios in behind.

You have to find the files starting with MZ.

You're missing my point: the actual file's origin is unknown.
It is probably not a pdb file. It may be anything.
It isn't as easy as extracting the file.
I need to identify where the module (whatever it is) is in the ram and extract either the ASCII or Hex code from those memory allocations, and then i will have raw code. From there, we would have to compile (i'm assuming) a solid file and try out different file extensions to see which is correct.

This is my theory, but with all the work i've been doing, there is a little science to back it up!

The next work to be done: FIND OMNI!!!!!