-
|
Currently ELFIO succeeds in parsing the header of a memory-mapped ELF dump file, but fails to parse other elements of the ELF file that are present also in memory such as segment headers and For some of these structures no changes in parsing code need to be made since fields in the header point to them even in memory (segment headers, for example). For others (symbols, for example), different parsing logic is needed so I suggest adding a flag to |
Beta Was this translation helpful? Give feedback.
Replies: 10 comments 4 replies
-
|
I am not sure what you call “memory-mapped ELF dump file”. An ELF file loaded to memory has limited amount of information available. Even file sections names are not available due to the lack of string tables. Basically, in common case which includes bare metal images, only segment data payload is accessible. You still may use ELFIO library for parsing original file and dump memory by following virtual memory locations. |
Beta Was this translation helpful? Give feedback.
-
|
@serge1 What I mean by “memory-mapped ELF dump file” is reading from the /proc/PID/mem of a process the segments that contain the loaded ELF file and writing them into a new file - a dump of the loaded ELF file. As for the lack of information - you are right. There's less information to recover in memory-mapped ELFs. But there's still some interesting data to get such as the header, the segment headers and their content, the In |
Beta Was this translation helpful? Give feedback.
-
|
The idea of dump file processing sounds interesting. Would you please advise which tool can I use to produce an example of such file? Edit: I have managed to produce the dump by using 'gcore' utility |
Beta Was this translation helpful? Give feedback.
-
|
Here's a short python script I found here. It dumps all the used parts of a process memory. This is a little extensive since all we need is the mapping of the process exe file (the first mapped file shown in `/proc/PID/maps), so it needs a little editing in order to extract only the relevant parts. |
Beta Was this translation helpful? Give feedback.
-
|
My attempt to implement this request is located at branch 'translate_offset'. Specifically the commit b527ea9. It is able to take the translation table located in /proc/pid/maps and use it to access ELF file components located in memory. For example, for /usr/bin/base file I got the following: Reading afterwards from /proc/pid/mem gives: vs. the content located in the original ELF file: Segment data is also looks in sync. For example: vs. the same segment data in the file: So, nothing interesting so far. I am stuck with the section header content. While the file contains: corresponding information is not available in memory: So, without section header information, no interesting data can be retrieved from memory. Please let me know if I am missing something essential, but, I didn't find any info that cannot be taken from the original ELF file. I stuck with the section header and didn't continue implementation of the similar translation mechanism for segments |
Beta Was this translation helpful? Give feedback.
-
|
As a wrote earlier, the header and the segment headers (and their data, of course) are present and intact in memory. Sections are only relevant in the original file and so their headers are not loaded into memory (explaining their absence from your dump). There is no "new" data (relative to the file on disk) that I'm aware of that might interest you in a dump of a process. My interest in this type of parsing originates from scenarios when I want to compare the data found in memory with the data present in the file on disk, so the data that can be extracted (headers etc) is not new but interesting to me anyway. This might also be useful when investigating a core dump of a failed process |
Beta Was this translation helpful? Give feedback.
-
|
I am moving the issue to "Discussions" |
Beta Was this translation helpful? Give feedback.
-
|
I have implemented address translation for segments too. It looks better than sections. You need to provide program arguments like: For example: or Is that what you have in mind? Please note - it is different from processing of a core dump. The core dump looks like a regular ELF file. Just a note: I found it convinient to compare segments' data by using 'proc_mem' vs. 'elfdump' examples |
Beta Was this translation helpful? Give feedback.
-
|
That's actually exactly what I had in mind! It works really well, too. The address translation mechanism you added inside the If getting the segment headers is so easy, why can't the parser also find the location of the symbols? There must be something pointing to their location seems the dynamic linker knows how to use them. EDIT: as for the use of the address translator and the processing of the file in /proc/PID/mem, I think it might be easier reading the relevant parts of the mem file and putting them directly into an |
Beta Was this translation helpful? Give feedback.
-
Symbol information is located in a section. The section header is not accessible. I guess a dynamic linker used the information from corresponding sections, but didn't map it to memory, or, even didn't uploaded it.
Do you propose to create a customized class derived from |
Beta Was this translation helpful? Give feedback.
-
|
I meant appending the data read from the mem file to an I guess the data |
Beta Was this translation helpful? Give feedback.
-
I am going to merge the branch to the main one.
Thank you for the initial idea of /proc/mem parsing and participating in this discussion! |
Beta Was this translation helpful? Give feedback.
-
|
To finish the discussion, I'd like to let you know that the implementation has been merged to the main branch and branch 'translate_offset' has been removed. The order and meaning of the address translation table has been modified, so, be careful in case you already have some examples |
Beta Was this translation helpful? Give feedback.
-
|
Ok, I'll make sure it doesn't break my code. Thank you! |
Beta Was this translation helpful? Give feedback.
I have implemented address translation for segments too. It looks better than sections.
Please give a try to 'proc_mem' example located in 'translate_offset' branch.
You need to provide program arguments like:
For example:
or
Is that what you have in mind?
Please note - it is different from processing of a core dump. The core dump looks like a regular ELF file.
Just a note: I found it convinient to compare segments' data by using 'proc_mem' vs. 'elfdump' examples