Utility to change "image file identification"?

[David R. Lennon]

Hi,

   Does anyone know of a program or a way of changing or patching the "image file identification", i.e.. the program version number string that is set by the linker identification keyword, in an existing image file?? I am specifically looking for something that would work under Itanium OpenVMS, which, as I understand it, is a bit more complicated since it is embedded in the ELF image format, however it would ideal if it could work under Alpha, as well. 

   The problem I am trying to solve is that I have a large collection of .EXE files that I'd really like to not re-link (or can't) and the developers didn't conform to the standard of putting the version number in this field, so automated tools built on analyze/image can't retrieve an accurate version number. I'd like to update these "in place". The SET IMAGE command looked promising but this does not seem to be a field it supports changing. I can put in an enhancement request to HP but I was hoping for a solution this century.

  Thanks in advance for any help.

- Dave

[John Gillings]

Dave,

  When you say "didn't conform to the standard" do you mean they specified something, but not what you want, or that it's undefined or null? If there's something there which is at least the correct string length, you may be able to fix it using PATCH/ABSOLUTE (this is a one-off isn't it?). Worst case pad it with blanks. Changing the string length might get a bit ugly. 

  Most likely your approach will need to be completely different between Alpha and Itanium.

  Maybe you can appease your automated tools with dummy images containing the correct string, visible only to the analysis utility via a search list? (without knowing more about your environment...)

[John Gillings]

FWIW, playing around on Alpha, Isuccessfully changed the image file identification on a copy of ZIP.EXE.

 I found the ident string at offset 0F0 in the header as a counted ASCII string. The original value was ZIP 3.0 (with a count byte of 7). There were 2 empty longwords to the next field (looks like the linker ident, also as a counted string). That meant I was able to patch the ident string up to 15 characters. Here's a transcript:

Before

        Image Identification Information

                image name: "ZIP"
                image file identification: "ZIP 3.0"
                image file build identification: ""
                link date/time: 26-FEB-2009 21:51:20.33
                linker identification: "A13-03"


$ patch/absolute zip.exe


  OpenVMS PATCH Version T8.2-001

%PATCH-I-NOGBL, some or all global symbols not accessible
%PATCH-I-NOLCL, image does not contain local symbols
PATCH>examine 0f0:0100
000000F0:  50495A07   ! Count byte 7, text ZIP
000000F4:  302E3320   ! text <sp>3.0
000000F8:  00000000   ! empty
000000FC:  00000000   ! empty
00000100:  33314106   ! start of 6 byte linker ident string

PATCH>dep/byte 0f0=0f
old:    000000F0:  07
new:    000000F0:  0F
PATCH>dep/ascii .+1='ZIP'
old:    000000F1:  'ZIP '
new:    000000F1:  'ZIP'
PATCH>dep/ascii .+3=' NEW'
old:    000000F4:  '3.0'
new:    000000F4:  ' NEW'
PATCH>dep/ascii .+4=' V3.'
old:    000000F8:  ''
new:    000000F8:  ' V3.'
PATCH>dep/ascii .+4='1415'
old:    000000FC:  ''
new:    000000FC:  '1415'
PATCH>update
%PATCH-I-WRTFIL, updating image file DISK1:[GILLINGS]ZIP.EXE;4


After

        Image Identification Information

                image name: "ZIP"
                image file identification: "ZIP NEW V3.1415"
                image file build identification: ""
                link date/time: 26-FEB-2009 21:51:20.33
                linker identification: "A13-03"

I'm not sure if the 0F0 is constant for all images (though a quick look at several images looks like it is). Assuming that's the case it's fairly simple to generate patch scripts, at least on Alpha. When I get a chance I'll see if I can figure out how it works on Itanium

[H.Becker]

As far as I know, the only public documentation on the image format - either Alpha or Integrity - is in starlet and lib. For C header files look for ei* in sys$lib_c.tlb and elf* in sys$starlet_c.tlb. The image file identification is not at a fixed offset, not even for Alpha.  You probably need a combination of analyze/image and dump/page to determine the offset on Alpha. For Integrity analyze/image prints offsets. Then use your favorite patch utility. (But you can use EDIT/TPU to search for a given string and replace it - and reset the file attributes after TPU wrote a new version of the file.) But you can (or ask others to) write a simple C program to do the work, with code for both formats. It shouldn't be that difficult and expensive. 

[John Gillings]

Thanks to Hartmut's clue, I found EIHD$L_IMGIDOFF=24 so the longword at offset 24 in the image header is an offset to the image ident area (EIHI$). That block contains major and minor IDs, link time, image name, image ID and linker ID. The Image ID is a counted string at EIHI$T_IMGID=56 within the block. Maximum length of the field (including the size byte) is EIHI$S_LINKID=16

So here's a DCL procedure to find the image ident string of an image:

$ f=F$PARSE(p1,"SYS$DISK:[].EXE")
$ lf=""
$ SET NOON
$ EIHD$L_IMGIDOFF=24     ! Location of offset to ImageID
$ EIHI$T_IMGID=56
$ ByteSize=8
$ LongSize=32
$ Loop: ff=F$SEARCH(f)
$ IF ff.NES."".AND.ff.NES.lf
$ THEN
$   lf=ff
$   OPEN/READ img 'ff'
$     READ img head          ! Get image header
$   CLOSE img
$     ! Calculate byte offset to Image Ident string
$   idoff=F$CVUI(EIHD$L_IMGIDOFF*ByteSize,LongSize,head)+EIHI$T_IMGID
$   len=F$CVUI(idoff*ByteSize,ByteSize,head)  ! Read Length byte
$   IdStr=F$EXTRACT(idoff+1,len,head)         ! Extract ident string
$   WRITE SYS$OUTPUT "''ff' ''IdStr'"
$   GOTO Loop
$ ENDIF
$ EXIT

I get sensible answers for all the images I've tried it on. Including everything in SYS$SYSTEM, SYS$SHARE and SYS$LOADABLE_IMAGES.

I found documentation describing the (Alpha) image header in section 28.1.4 in the IDSM V1.5

The above DCL could be used to generate a PATCH script to hack the ident string of an image.

[John McL]

I think you didn't even need to use PATCH on an Alpha.  The .EXE file is fixed length 512 byte records, so just open the .EXE like a normal file, read the first record/block, modify the field, WRITE/UPDATE/SYMBOL the record, then close the file.  Or, if you wanted to play safe, write the modified record to a new file and copy the rest of the initial file there too.  Of course you'll need to first identify the location of the

I wonder if Itanium .EXE's can be processed in a similar fashion. I've got a vague recollection that there's a checksum at the end of each section of the ELF, but hopefully I'm wrong.

[H.Becker]

>>> that there's a checksum at the end of each section of the ELF
 
No, there isn't. As we all know, the ELF is quite different from the VAX/Alpha image format. The "image file identification" is in the note section. The location of this section is described in the section header table. The location of this table is described in the ELF header. This header is at the beginning of the file. The good thing here is, that the linker developer almost always wrote sections and the section header table starting at disk blocks - an implementation detail which can change any time. So it is doable, even in DCL but it is more work. 

Although output parsing is not recommended the most effective way in DCL would be to parse the output of analyze/image/section=note to calculate the file offset. At least for me, writing a small program to do this is much easier. But I didn't receive any request , so far :-)

[David R. Lennon]

Thanks for everyone's input.

H.Becker - sure, what can I do to request/bribe you to write a program? Could the program be able to "modify" the field, not just display it?

I found a program that looks like it is similar to the SET IMAGE command, I wonder if that could be modified to do this easier than writing one from scratch?

http://vouters.dyndns.org/tima/OpenVMS-IA64-THREADCP_rewritten_for_Itanium.html

Thanks,

Dave

[H.Becker]

>>> I found a program that looks like it is similar to the SET IMAGE command, I wonder if that could be modified to do this easier than writing one from scratch?

I can't comment on this one, the html page is not available for me. But changing thread related flags is changing DT_VMS_LINKFLAGS in the dynamic table and that is a little bit different. But for a start ... There is probably more available on the net.

You are very likely looking for something like

$ mc []imgid main.exe

imgid: 'V1.0'

$ mc []imgid main.exe "V1.0.8.8" 

imgid: 'V1.0'

new imgid too long, supply a string with length < 8

$ mc []imgid main.exe "V1.0.8"

imgid: 'V1.0'

new imgid: 'V1.0.8'

$ mc []imgid main.exe         

imgid: 'V1.0.8'

$

Fresh out of the compiler, the bits are still wet. Unfortunately I can't test/analyze the generated image, because this ran on Alpha and I don't have access to an Integrity. 

The note's entry for imgid has a max size, a multiple of 8, depending on what is already there. The string is zero-terminated and the terminator counts.

Regarding the bribe and how you can get this, send me a mail, or what they call here a private message. And let me know where you want to run the tool, VMS-Alpha/Integrity (or X86/Linux. No, no Win32 code!)

[Ph Vouters · Accepted solution]

David,

For the imgid Alpha source code, be in touch with H. Becker. For the imgid Itanium code, refer to:

http://vouters.dyndns.org/tima/OpenVMS-IA64-Changing_the_image_identitication_of_an_executable.html

Yours truly,

Philippe