| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 35 |
| Nodes: | 6 (1 / 5) |
| Uptime: | 19:09:11 |
| Calls: | 321 |
| Calls today: | 1 |
| Files: | 957 |
| Messages: | 82,383 |
Right. It seems to boil down to:
You can't interpose a syscall.
I.e., so if a library function calls the syscall directly (rather than
going through the Glibc wrapper), you can't interpose it. This is, of course, as it should be.
Am 18.01.25 um 01:42 schrieb Kenny McCormack:
Right. It seems to boil down to:
You can't interpose a syscall.
I.e., so if a library function calls the syscall directly (rather
than going through the Glibc wrapper), you can't interpose it. This
is, of course, as it should be.
Hmm, it may be related to optimizations. Assuming the openat call is
inlined in another compilation unit there is no option to change this
at link time.
System call can mean two things:
1) The actual transfer to the kernel, via an instruction such as SYSCALL
(x86) or SVC (Arm). This is what appears in strace.
2) The function in the C library that contains this instruction.
Normally the distinction is irrelevant, but here it matters.
You cant interpose a syscall, is only true for sense 1. That
instruction is somewhere the middle of a function and the interposition >technique hes using relies on runtime symbol resolution rules, so it
doesnt apply to sense-1 syscalls.
What you are calling "sense #2" (i.e., the "glibc wrapper" that is provided for most (not all) syscalls) is just another function and can, of course,
be interposed.
Am 19.01.25 um 18:12 schrieb Kenny McCormack:
What you are calling "sense #2" (i.e., the "glibc wrapper" that is provided >> for most (not all) syscalls) is just another function and can, of course,
be interposed.
Not necessarily.
The header files might contain information that tells the compiler to
inline the wrapper when possible. In this case it won't succeed either.
In article <vmjq8b$2clu1$1@gwaiyur.mb-net.net>,
Marcel Mueller <news.5.maazl@spamgourmet.org> wrote:
Not necessarily.
The header files might contain information that tells the compiler to
inline the wrapper when possible. In this case it won't succeed either.
In that case, it's not a wrapper, now is it?
We're just arguing over definitions at this point.
Am 19.01.25 um 18:12 schrieb Kenny McCormack:
What you are calling "sense #2" (i.e., the "glibc wrapper" that is provided >> for most (not all) syscalls) is just another function and can, of course,
be interposed.
Not necessarily.
The header files might contain information that tells the compiler to
inline the wrapper when possible. In this case it won't succeed
either.
Marcel Mueller <news.5.maazl@spamgourmet.org> writes:
Am 18.01.25 um 01:42 schrieb Kenny McCormack:
Right. It seems to boil down to:
You can't interpose a syscall.
I.e., so if a library function calls the syscall directly (rather
than going through the Glibc wrapper), you can't interpose it. This
is, of course, as it should be.
Hmm, it may be related to optimizations. Assuming the openat call is
inlined in another compilation unit there is no option to change this
at link time.
Inlining and compiler optimization aren’t relevant here.
“System call” can mean two things:
1) The actual transfer to the kernel, via an instruction such as SYSCALL
(x86) or SVC (Arm). This is what appears in strace.
On a slight tangent, does anyone know of a good
reference for how to use the ptrace() call on
Linux? The man page is somewhat obtuse.
Muttley@dastardlyhq.org wrote:
On a slight tangent, does anyone know of a good
reference for how to use the ptrace() call on
Linux? The man page is somewhat obtuse.
Just guessing, but I can only think of reading
gdb source code.
In article <vmlmkp$36kmo$1@dont-email.me>,
Kalevi Kolttonen <kalevi@kolttonen.fi> wrote:
Muttley@dastardlyhq.org wrote:
On a slight tangent, does anyone know of a good
reference for how to use the ptrace() call on
Linux? The man page is somewhat obtuse.
Just guessing, but I can only think of reading
gdb source code.
Or strace.
Context is Linux (and only Linux).
Over the years, I have written many "interposers" - that is, a shared
library loaded with LD_PRELOAD that hooks some system or library call
(e.g., "read"). The interposer usually ends up calling the "real"
function, then doing something special either before or after the call.
Context is Linux (and only Linux).
Over the years, I have written many "interposers" - that is, a shared
library loaded with LD_PRELOAD that hooks some system or library call
(e.g., "read"). The interposer usually ends up calling the "real"
function, then doing something special either before or after the
call.
Generally, it all works fine - or at least, it did - until they
started having "strong symbols" (I think that's the right term).
Anyway, some number of years back, I noticed that it became kind of
hit and miss as to whether or not you could get your hooked version of
the function to be called. Generally, it seemed, the more "low level"
the function, the less likely it was that the interposer would work.
So, I am wondering, is there a fix for this? I'm assuming that
somebody decided that interposers were evil and thus, they came up
with this as a way to foil us, but there should be fix to the fix, so
to speak. Is there?
Note: I am not showing code at the moment, because I'd like (if
possible) a simple "Yes, it can be done" or "No, they got you" type
answer. If there is sufficient interest, I can post code in a
followup.
Generally, it all works fine - or at least, it did - until they
started having "strong symbols" (I think that's the right term).
I think you mean STB_WEAK vs STB_GLOBAL, in the naming used in Glibc and
the ELF spec.
I can interpose both weak and global symbols from Debians Glibc 2.39
without doing anything unusual.
Yes, it can be done....
Something that tripped me up: a program shows a call to openat() in...
strace output, so one tries to interpose openat(). But in fact the
program is calling the Glibc open() function, which calls the openat() >syscall.
However I think from your other post that you've already considered this >possibility.
In article <vmeibp$33sam$1@news.xmission.com>,
Kenny McCormack <gazelle@shell.xmission.com> wrote:
Context is Linux (and only Linux).
Over the years, I have written many "interposers" - that is, a shared >>library loaded with LD_PRELOAD that hooks some system or library call >>(e.g., "read"). The interposer usually ends up calling the "real" >>function, then doing something special either before or after the call.
Also, wanted to state that the function I am trying to hook is "openat".
"open" I can hook, but "openat" doesn't work. I think most programs just call "open", which eventually ends up calling "openat", so that (hooking "open") works. But some programs call "openat" directly, and that doesn't work.
And, also, just to clarify, the whole point of this is to modify the
behavior of a program without the bother of re-compiling it.