Extracting raw data from an ELF .EXE file

[Michael Moroney]

I am dealing with some code being ported from VAX to I64 where much of the data (yes, data) is tables in the form of MACRO-32 macro calls that is assembled, and linked via $ LINK/SYSTEM=0/NOHEADER. The resulting "executable" is the raw binary data used by other programs. The data is complex tables which refer to each other which is why they are doing it that way.

On I64 I can link with /BASE=0 but there is no equivalent to /NOHEADER. The resulting executable has a 1 block ELF header, several blocks of raw data that matches the VAX .exe exactly, then several more blocks of ELF image info. I need to extract the raw binary data. I could just chop off block 1 and the last 5 blocks, but this is largely guessing. Is there some code that can tell me for certain that the program segment corresponding to the data starts at Block A and is B blocks long?

[Michael Moroney]

Attached is an $ ANALYZE/IMAGE of a typical data file. The data sizes range from between 3 and 16 blocks on the VAX.

[John Gillings]

Michael,

I'm not sure I understand how this image is used. Do the callers "activate" it? Is it just opened and read as a data file? Is it mapped somehow?

Can you modify your input or mapping routine to skip the ELF header if it's found? If not, maybe you need a post process program to trim off the header. Rather than just blindly chopping off the first block, I'd code something that does at least skeletal confirmation of the ELF header and finds the end of it) Can your I64 programs read the file linked on VAX?

Does it work on Alpha?

If I'm on completely the wrong track, perhaps you could post a very simple, cut down version of what you're doing - include both code to produce your decapitated image, and the consumer.

[Michael Moroney]

The image is just data, although it is mapped in via $CRMPSC rather than being read in via reads or $QIO.

The I64 does work with VAX-generated files. There is no Alpha version, customer is going from museum-quality VAXes straight to I64.

Current decapitation program is trivial: Get size in blocks of the .EXE. Read in (size-6) blocks starting at block 2 and write them to a new file. This works, but I know that someday there will be a new version of the linker that generates 2 block headers or 4 block trailers or something, which will cause things to break. I'd like to know just enough of the ELF image format to know where the raw data starts and its size in blocks.

[John Gillings]

Michael,

>The image is just data, although it is mapped in via $CRMPSC

Interesting! (and I thought I'd done some weird stuff with OpenVMS images ;-)

> I'd like to know just enough of the ELF
>image format to know where the raw data
>starts and its size in blocks.

Yes, you should definitely check the header is where you expect it to be.

One of the reasons OpenVMS engineering decided to change the image format was because ELF is a standard. As such the specification is freely available. A quick Google search found:

http://en.wikipedia.org/wiki/Executable_and_Linkable_Format

which contains many links to more detailed information. I'm sure you should be able to find what you need.

[Robert Gezelter]

Michael,

I cannot agree more with John. Reading, and then complying with the ELF specification (not what one happens to see, but the real specification) is important.

It is a fairly safe bet that the OpenVMS team will stay in compliance with the specification. This may, however, lead to the use of features that are not apparent from a casual analysis of an image.

Also, validating that an ELF file has the expected identification fields in the expected places would be an excellent idea.

- Bob Gezelter, http://www.rlgsc.com

[John Reagan · Accepted solution]

Go find/read my ELF presentations from previous Technical Bootcamps.

Basic approach:

- read the ELF header
- find the segment header table
- read the segment header #0
- find the segment in the file (offset 200, size 1FF4)

John

[Michael Moroney]

Thanks, all. I overlooked the fact that ELF is a standard, and the spec is widely available. I was having trouble finding it on the HP VMS doc website, never thought of ordinary web searches.

A little reading and I'll quickly code up a little program to do what I want.

As to:

>>The image is just data, although it is mapped in via $CRMPSC

>Interesting! (and I thought I'd done some weird stuff with OpenVMS images ;-)

Let me tell you, this is just the tip of the iceberg of weirdness with this project!

[Robert Brooks_1]

Let me tell you, this is just the tip of the iceberg of weirdness with this project!

--

You can't tease us like that . . . :-)

[John Reagan]

I have some small C examples for skimming through .OBJ and .EXE files looking for .note sections. Let me know if you want to see them as a starting point.

[Michael Moroney]

> You can't tease us like that . . . :-)

where do I start? I brought some of this code to VMS Engineering's Porting to Itanium seminar, and some of the VMS Engineers started reaching for crosses and garlic, or just hiding under their desks. Absolute addressing. Strange stack manipulation. Ponder these two macro-32 statements for a bit and you'll get an idea...


movzwl @#CMRTFP,fp

MOVW -6(SP),R0

[Michael Moroney]

John R:

So far I've been working with elf.c that comes with the gnv kit as a starting point. It parses object files for symbols. But more can't hurt.

[John Reagan]

The MOVW shouldn't be a problem, but moving into the FP is. That won't even work on Alpha by the way.

I've attached something that Hartmut wrote.

[John Gillings]

John R>The MOVW shouldn't be a problem

In the sense that it's unlikely to ACCVIO, true, but how can it return a predictable result? Anything above the current SP is volatile - it could be written at any time by an AST or other interrupt. I'd call it a timing bug waiting for a place to happen.

[Michael Moroney]

re: "In the sense that it's unlikely to ACCVIO, true, but how can it return a predictable result? Anything above the current SP is volatile - it could be written at any time by an AST or other interrupt. I'd call it a timing bug waiting for a place to happen."

Exactly. Try that code with ASTs enabled. (try finding that kind of bug!)

The FP instruction is an example of how twisted this code gets. They essentially invented their own stack frames/traceback stuff between routines, via JSB/RSB, ignoring all the useful stuff provided by CALLx/RET. Also note it's a 16 bit move with an absolute address.... Yes, the Itanium MACRO-32 compiler does not like that one bit, nor does it like all the other manipulation of the FP and SP..


John R, thanks for the code, it's easier to adapt than the other code.