Jump to content

-Archive- Macefix86 2006 -Archive-


bofors
 Share

443 posts in this topic

Recommended Posts

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.insanelymac.com/index.php?sho...mp;#entry118315

 

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

Link to comment
Share on other sites

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

drivers.txt

dh.txt

dh_87.txt

dmem_of_dh_87.txt

Link to comment
Share on other sites

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?

The actual programming to do this would be very simple, again if the .efi files are merely concatenated. It is the reverse engineering that is the real issue, figuring out how the .efi files are packed into the .fd file, specifically, where each one starts and ends. The .fd file could include some kind of table which holds this information or the .efi files could delimited by special code sequences.

 

We can get back to the .fd file approach later, you almost got it the other way.

Link to comment
Share on other sites

[update]

I chose handle 87: the hfsplus.efi one.

 

Good choice, it is easy to test if that one works.

 

Finally, i did dmem to output just the memory address of handle 87.

 

Great, that should be your .efi file then, right?

 

 

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.

 

The ASCII is just a translations of the hex code. For example your hex starts with "4D 5A", that corresponds to "M" and "Z" in ASCII. I think you are a little confused here, just ignore the ASCII for now, it good for revealing clues and such for reverse engineering.

 

All we are interested in is the hex code. It looks like you opened up the hex code in a hex editor to get "dmem_of_dh_87.txt". So I think you already have it. It is just the raw "dmem to output" file.

Link to comment
Share on other sites

Yeah that pretty much sums it up.

Sorry about the ASCII confusion...i guess i just haven't been explaining myself very well!

So yeah, there we have the hex code for hfsplus.efi.

 

Basically, now we need to take the code and turn it back into an efi file.

I don't have that microsoft compiler...

 

I was thinking maybe the intel hex format could help us in some way?

I haven't dont enough research...

anyone have some efi driver modules from like the tianocore implementation?

 

is there some sort of translator out there to convert the hex code to like the intel hex format? I know that with a real hex file, we could convert it to a binary file, which i THINK we can compile to an efi file...

 

If anyone wants to contribute, the first thing you could do (apart from looking for answer to the next objective) would be to delete everything else in the dmem_of_dh_87.txt except for the actual hex code... like everything around it, including the memory address to the left and text to the right.

I think that would be more usable than what we currently have. Any way to automate this?

Link to comment
Share on other sites

If anyone wants to contribute, the first thing you could do (apart from looking for answer to the next objective) would be to delete everything else in the dmem_of_dh_87.txt except for the actual hex code... like everything around it, including the memory address to the left and text to the right.

I think that would be more usable than what we currently have. Any way to automate this?

 

maybe we could write a small c application to remove the first 2 spaces of each line in the file and write it out to a new file.

Link to comment
Share on other sites

maybe we could write a small c application to remove the first 2 spaces of each line in the file and write it out to a new file.

 

Actually, since the lines are 79 characters long, we would have to remove 1-12, then all the spaces between hex pairs, that dash in the middle, and then the whole 2 spaces after the last hex pair and all the ASCII after that.

 

 

I wonder if dmem has additional paramters where it dumps only hex and not ascii.

 

I don't think so. I'll check again, but it doesn't look like it.

 

I'm currently working with a hex program just to analyse the text and compare it to exe and efi files. So far so good...

Link to comment
Share on other sites

Actually, since the lines are 79 characters long, we would have to remove 1-12, then all the spaces between hex pairs, that dash in the middle, and then the whole 2 spaces after the last hex pair and all the ASCII after that.

I don't think so. I'll check again, but it doesn't look like it.

 

I'm currently working with a hex program just to analyse the text and compare it to exe and efi files. So far so good...

 

I think there has to be a way to just dump the raw hex without the additional {censored}.

Link to comment
Share on other sites

I'm working with a few programs...

the best seems to be FlexHEX for windows.

If we can get it all without the additional {censored}, we should have no problems just importing the text file to this program and tell it that the text it contains is hex data.

Then, we have to make sure it recognizes separators (not sure precisely how that works, still testing).

 

The script wont be necessary. I should be able to just export the newly created hex file, rename it as efi and there's the hfsplus module.

 

Again, nothing is certain, but i have strong evidence to back this up. I'm also gonna try working with some spreadsheets to import and export the text file, perhaps getting the "{censored}" out that way. There must be a way to manipulate the text file and kill all but what we want.

 

Stay posted.

Link to comment
Share on other sites

I'm also gonna try working with some spreadsheets to import and export the text file, perhaps getting the "{censored}" out that way. There must be a way to manipulate the text file and kill all but what we want.

I think it would much easier to just write program like dmem that dumps it raw. I mean, this would like a 10 line program in C.

Link to comment
Share on other sites

Well then we need someone that is capable of that...

I unfortunately am not there in my c++ studies yet, so can be of no help.

 

However, give me a few hours and i'll surely find another way of doing it.

It won't be the most accommodating method, but it will be the easiest for me.

 

If anyone is up to it, go right ahead. Hell, i'm sure applescript can be used for something like this...

Link to comment
Share on other sites

no, all i need to do is put together a hex file from this text file, save it as efi and hope for the best!

 

Everyone cross your fingers!

Link to comment
Share on other sites

Urby3, have you looked at the "hexedit" EFI command:

 

hexedit

 

hexedit [[-f]FileName|[-d DiskName Offset Size]|[-m Offset Size]]

 

-f - Open file to edit

-d - Open disk block to edit

DiskName - Editing disk's name (for example fs0)

Offset - Starting block's No. (beginning from 0)

Size - Number of blocks that to be edited

-m - Open memory region to edit

Offset - Starting offset of memory region (beginning from 0)

Size - Size of memory region that to be edited

 

This command allows a file, block device, or memory region to be edited. The region being edited

is displayed as hexadecimal bytes, and the contents can be modified and saved. The following

example shows typical output for help on this command.

 

http://www.intel.com/software/products/col...ll_cmnd_1_1.pdf

 

EDIT: I actually think that this will have the same result as "dmem".

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
 Share

×
×
  • Create New...