442 replies to this topic

[sbeehre]

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.

[Kiko]

sbeehre, on Jul 28 2006, 06:36 AM, said:

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 ?

[Urbz]

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.

[Kiko]

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.

[sbeehre]

found this on the Intel site

http://www.intel.com...and_Example.htm

http://www.intel.com...ice_handles.htm

[Urbz]

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?

[Superhai]

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.

[Urbz]

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

[Superhai]

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.

[Urbz]

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

[bofors]

Urby3, on Jul 28 2006, 03:33 PM, said:

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

I think Omni is still incommunicado

[sbeehre]

would this perl script help? it looks like it converts hex to bin

http://www.cpan.org/...in-1999.0302.pl

or what about this one

http://www.onembeddi...intelhex_en.htm

[bofors]

I am somewhat baffled by this conversion issue.   I mean, these files are binary in any state, so we are just talking about text encodings, right?

I guess can understand decoding memory dumped as text to a console back to binary, is that what this about?

It seems like there should be a way to dump it directly to a file to just avoid the issue.

[Superhai]

Obviously can you hex dump memory, you save it as a binary file, nothing else. I can't see the point of saving in ascii. But a memory dump is not what i would want, it would be better to have the actual .efi driver files.

[Urbz]

Superhai, on Jul 28 2006, 09:31 PM, said:

Obviously can you hex dump memory, you save it as a binary file, nothing else. I can't see the point of saving in ascii. But a memory dump is not what i would want, it would be better to have the actual .efi driver files.

Then what do you propose we do to get to that file? Have you already done all this?

[sbeehre]

Superhai, on Jul 29 2006, 01:31 PM, said:

it would be better to have the actual .efi driver files.

That is exactly what we are trying to do.... we are trying to dump efi drivers from memory to a file so we can try loading them in the EFI environment.

[bofors]

Simon, I think he means more directly, like perhaps extracting them from the firmware file itself, as opposed to a memory dump.

[sbeehre]

aah ok that would be good to but maybe a bit harder wouldnt it?

[bofors]

If the .efi files are simply concatenated into Apple's .fd firmware file, it could be very simple.

Again, this seems do-able because we (Rogabean) know(s) how to generate .fd files from .efi:

http://forum.insanel...mp;#entry118315

All we are talking about is reversing the process, which is something the EFI Framework should obiviously provide for.

[Urbz]

by doind it that way, i would not even know where to start.
I am not a programmer or a coder and have limited knowledge of c++.
I do not know what to do with an fd file: how would you reverse engineer it? How would you split it open and view it's contents?

On a slightly happier note, anomaly256 has provided me with instructions on how to save output to a txt file instead of to the screen. I'll post back in a few minutes.

[update]

Alright: Here's everything.
drivers.txt is what i used to select which module i was going to concern myself with. I chose handle 87: the hfsplus.efi one.
The i used dh 87 to find out where it lay in the ram, and dh before that just to make sure 87 was the correct handle, and it was.
Finally, i did dmem to output just the memory address of handle 87.

All the files are attached. Notice that dmem_of_dh_87.txt has both hex (on the left) and ASCII (on the right).
That's what i've been talking about!
Now maybe we can (somehow) take all this and turn it into another type of file? I don't know how, though.

Also, anomaly had this to say about the text files:
"Note however that the format of this text file is UTF-16, and therefore it won't display properly in TextEdit or notepad, gedit under gnome however opens it fine (once you enable the utf-16 character set)."
I can confirm they are viewable in textedit.

Hope this helps in some way,

Urby

Attached Files

•  drivers.txt   6.19K   93 downloads
•  dh.txt   18.55K   55 downloads
•  dh_87.txt   1.09K   54 downloads
•  dmem_of_dh_87.txt   186.44K   77 downloads