Date: Thu, 08 Apr 2010 10:22:26 -0700 From: Patrick Mahan <mahan@mahan.org> To: Nate Eldredge <nate@thatsmathematics.com> Cc: freebsd-hackers@freebsd.org Subject: Re: Modifying ELF files Message-ID: <201004081726.o38HQp8O084761@ns.mahan.org> In-Reply-To: <Pine.GSO.4.64.1004080806540.5432@zeno.ucsd.edu> References: <4BBDE58A.9050502@mahan.org> <Pine.GSO.4.64.1004080806540.5432@zeno.ucsd.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201004081726.o38HQp8O084761>