Jump to content

-Archive- Macefix86 2006 -Archive-


bofors
 Share

443 posts in this topic

Recommended Posts

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.

 

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

 

:D

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

 

 

@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).

Link to comment
Share on other sites

  • 3 weeks later...
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.

Link to comment
Share on other sites

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

 

:thumbsdown_anim:

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 ?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

"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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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!!!!!

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
 Share

×
×
  • Create New...