exec at offset != 0

[Stephane G. Titard]

Hi
I would like to be able to simulate an exec but starting at byte N in a
file
(without creating a temporary file which is exec'ed later)
I understand there are security implications, but is it doable? what
about exec´ing
in memory
Actually it is similar in spirit to a dynamic load of library (shl_open,
dl_open etc...).
so my feeling is that it could be hacked...


I want to build something similar to an auto-installer

wrapper
--------
prog
archive
--------
l ib 1
lib 2
---------

the trick is here that nothing forbids putting any kind of data after a
well-formed
executable.

wrapper is executed, knows how to position itself
on prog which is "exec'ed" loads archive extracts libn and loads it
etc...
(similar in spirit to par files in perl)

any pointer, any sample code
thanks

stephan

[Casper H.S. Dik]

"Stephane G. Titard" <sgt19@tid.es> writes:

>no. imagine a have /bin/echo. I copy it to /tmp/echo
>and I append /bin/echo to /tmp/echo. /tmp/echo runs perfectly
>now from C can I exec the second /bin/echo which is at offset length(/bin/echo)
>exec(2) family is bound to a physical file, right?

>of course the exec family does not permit this, but maybe some hack similar
>to dynamic loading could work... definitely would not be portable
>(dlopen type of things isn't either)

No, you cannot; programs generally are not relocatable and require a fixed
location in memory. So if you're unwilling to change the executable you
must make your "loader" relocatable and then load the new executable
and the dynamic linker in memory much like the kernel does
and hand control to them.


When you copy a second executable after your first executable, you should
keep in mind that the second executable will not be loaded in memory by
the kernel; it will only load the ELF sections that need to be loaded
of the first executable. You'll either need to embed the executable in your
data segment or read (map) it from a file.

Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

[Shaun Clowes]

"Stephane G. Titard" <sgt19@tid.es> wrote in message
news:3F20F478.260454BF@tid.es...

>
> Shaun Clowes wrote:
>

> > Unfortunately it doesn't look like you simply want to exec from a

different

> > offset, but rather you want to be able to exec a completely independant
> > executable that is embedded in another.

>
> no. imagine a have /bin/echo. I copy it to /tmp/echo
> and I append /bin/echo to /tmp/echo. /tmp/echo runs perfectly
> now from C can I exec the second /bin/echo which is at offset

length(/bin/echo)

> exec(2) family is bound to a physical file, right?

As Casper pointed out separately, this won't work because the two copies of
echo both expect to be at overlapping places in virtual memory when
executed.

When I've done this I've used a stub that was deliberately located at a
strange place in memory (e.g 0xb0000000) which would hopefully never overlap
with a standard executables memory regions.

There are actually a number of other issues, particularly in invoking the
dynamic linker correctly.

Cheers,
Shaun

[Stephane G. Titard]

"Casper H.S. Dik" wrote:

> "Stephane G. Titard" <sgt19@tid.es> writes:
>

> >no. imagine a have /bin/echo. I copy it to /tmp/echo
> >and I append /bin/echo to /tmp/echo. /tmp/echo runs perfectly
> >now from C can I exec the second /bin/echo which is at offset length(/bin/echo)
> >exec(2) family is bound to a physical file, right?

>

> >of course the exec family does not permit this, but maybe some hack similar
> >to dynamic loading could work... definitely would not be portable
> >(dlopen type of things isn't either)

>
> No, you cannot; programs generally are not relocatable and require a fixed
> location in memory. So if you're unwilling to change the executable you
> must make your "loader" relocatable and then load the new executable
> and the dynamic linker in memory much like the kernel does
> and hand control to them.
>
> When you copy a second executable after your first executable, you should
> keep in mind that the second executable will not be loaded in memory by
> the kernel; it will only load the ELF sections that need to be loaded
> of the first executable.

Yes. I am aware of this. This why is asked "can I exec at offset !=0" maybe
i did not express myself sufficiently clearly.
I have one file: prog1 + prog2. From prog3 I want to exec prog2 = exec at offset
length(prog1). Prog3 can actully be prog1.

Thanks to all. I will check upx and ELFcrypt.
I'd like something that works on Linux, Cygwin, HP-UX and Solaris.
stephan

> You'll either need to embed the executable in your
> data segment or read (map) it from a file.
>
> Casper
> --
> Expressed in this posting are my opinions. They are in no way related
> to opinions held by my employer, Sun Microsystems.
> Statements on Sun products included here are not gospel and may
> be fiction rather than truth.

[Shaun Clowes]

"Stephane G. Titard" <sgt19@tid.es> wrote in message
news:3F24EFD0.BB92C7FC@tid.es...

> "Casper H.S. Dik" wrote:

> > When you copy a second executable after your first executable, you

should

> > keep in mind that the second executable will not be loaded in memory by
> > the kernel; it will only load the ELF sections that need to be loaded
> > of the first executable.

>
> Yes. I am aware of this. This why is asked "can I exec at offset !=0"

maybe

> i did not express myself sufficiently clearly.
> I have one file: prog1 + prog2. From prog3 I want to exec prog2 = exec at

offset

> length(prog1). Prog3 can actully be prog1.

The bit you're missing is that there is no 'exec offset'. When you exec a
file, the kernel reads the executable and maps the code and data segments to
_fixed_, _compile time_ decided locations in memory that are specified in
the file's meta data (in general, though it is possible to compile
relocatable executables and all executables are relocatable on AIX at
least). Even if you could exec at an 'offset' into the file, the kernel
would still read the executables meta data (from that offset) and try to map
the executable over already used pages, clobbering your code.

> I'd like something that works on Linux, Cygwin, HP-UX and Solaris.

Cygwin will actually just be PE (Portable Executable), there are plenty of
windows encryptors and packers you could look at for examples. Linux and
Solaris are quite possible, HP-UX will be hard. Certainly you're looking at
significant development effort for all of them.

Cheers,
Shaun

[Dmitry Karasik]

Hi Shaun!

On 29 Jul 03 at 00:15, "Shaun" (Shaun Clowes) wrote:

>> first executable, you

Shaun> should

>> > keep in mind that the second executable will not be loaded in memory

>> by > the kernel; it will only load the ELF sections that need to be
>> loaded > of the first executable.
>>
>> Yes. I am aware of this. This why is asked "can I exec at offset !=0"

Shaun> maybe

>> i did not express myself sufficiently clearly. I have one file: prog1
>> + prog2. From prog3 I want to exec prog2 = exec at

Shaun> offset

>> length(prog1). Prog3 can actully be prog1.

Thinking about executable loading scheme, where kernel is doing direct
mmap() to the file, I thought on reverse, what can one do to make a portion
of memory to look like a file to the kernel? Just theoretically, OP can
create a file with native OS file system inside, which can be then
mounted, and any executable file on that synthetic FS can be directly
executed without copying.

This solution is really hacky even without minding the multiplatformness,
as it throws all dangers of security risks of non-root mounts, but my
point is that mounting an archive file is indeed a portable scheme.
It wouldn't work for win32 straight away, but one can always write a
pseudo-device driver a-la Norton Ghost, which does exactly the thing.

--
Sincerely,
Dmitry

--- [url]www.karasik.eu.org[/url] ---

Life ain't fair, but the root password helps.
- BOFH