Modifying ELF files

[Patrick Mahan]

> On Thu, 8 Apr 2010, Patrick Mahan wrote:
> 
> >
> > In my job, we are producing applications and KLM's for our product
> > that require them to be signed so that our installer will recognize
> > and validate our images.
> >
> > The signature is stored in each app as
> >
> > unsigned char signature[40] __attribute__((section(".compsign")));
> >
> > What I need to do is open the file for writing, locate the ".compsign"
> > section and stuff in the signature, write it out and close the file.
> > (simple ELF manipulation)
> >
> > An 'ls -l' shows the following:
> >
> > % ls compklm.ko
> > -rw-r--r--  1 pmahan  pmahan  125296 Apr  6 22:50 
> > /home/pmahan/temp/compklm.ko
> >
> > When I try to run my program
> > ./signfile --signature=A203239897C8EB360D1EB2C84E8E77B16E5B7C9A compklm.ko
> > open: Text file busy
> >
> > Googling and looking at the kernel sources, it seems that it detects
> > this file contains 'shared text', that is, it is an executable file
> > and does not allow me to open it for writing.
> 
> My understanding was that ETXTBSY occurs when you attempt to open for 
> writing a file which is actually being executed, i.e. is mapped into some 
> process.  I'm not aware that open(2) actually looks at the file itself to 
> see if it is an executable; that would be very surprising to me.
> 
> What does "fstat -m compklm.ko" say?
>

% fstat -m compklm.ko
USER     CMD          PID   FD MOUNT      INUM MODE         SZ|DV R/W NAME
% 
 
> What happens if you "cp compklm.ko foo.ko" and try to sign foo.ko?  You 
> should then be able to do "mv foo.ko compklm.ko"; if compklm.ko is 
> in fact mapped into some process, it will continue to use the original 
> version, which will be kept around (invisibly) until all mappings go away. 
> This is what compilers, install(8), etc, normally do.
> 
> Does your signfile program do anything with the target file before 
> open(..., O_RDWR)?
>

I've just found my problem.  We have a wrapper program that basically handles
parsing command line options and is suppose to adjust the argv[] array so
that it only contains the remaining non-option targets starting at index zero.
So I am doing 'open(argv[0], O_RDWR, 0)' expecting it to be the .ko file.
Turns out it was not operating as described (whipping post to be erected later);
so argv[0] actually pointed at the operating program, not the first target past
the cmd line options. *-)

Mystery solved.

Thanks,

Patrick