[Gammaray-interest] New plugin idea: Event inspector

[Christian Gagneraud]

On 19 September 2017 at 23:07, Milian Wolff <milian.wolff at kdab.com> wrote:
> On Dienstag, 19. September 2017 12:27:08 CEST Christian Gagneraud wrote:
>> On 19 September 2017 at 22:05, Milian Wolff <milian.wolff at kdab.com> wrote:
>> > On Dienstag, 19. September 2017 11:45:01 CEST Christian Gagneraud wrote:
>> >> On 19 September 2017 at 21:17, Milian Wolff <milian.wolff at kdab.com>
> wrote:
>> >> > On Dienstag, 19. September 2017 11:11:45 CEST Christian Gagneraud
> wrote:
>> >> >> On 19 September 2017 at 20:46, Milian Wolff <milian.wolff at kdab.com>
>> >
>> > wrote:
>> >> >> > On Dienstag, 19. September 2017 10:39:45 CEST Christian Gagneraud
>> >
>> > wrote:
>> >> >> >> On 19 September 2017 at 17:11, Christian Gagneraud
>> >> >> >> <chgans at gmail.com>
>> >> >
>> >> > wrote:
>> >> >> >> > On 18 September 2017 at 14:52, Christian Gagneraud
>> >> >> >> > <chgans at gmail.com>
>> >> >> >
>> >> >> > wrote:
>> >> >> >> >> On 18 September 2017 at 08:25, Milian Wolff
>> >> >> >> >> <milian.wolff at kdab.com>
>> >> >> >> >> wrote:
>> >> >> >> >> [...]
>> >> >> >> >>
>> >> >> >> >>>> I'm reading this right [1] now, it's called "Cheating the ELF
>> >> >> >> >>>> -
>> >> >> >> >>>> Subversive Dynamic Linking to Libraries".
>> >> >> >> >>>> AFAIU, he's talking about manipulation of the PLT of an ELF
>> >> >> >> >>>> image.
>> >> >> >> >>>> Which is, I think, what i would like to achieve: replace a
>> >> >> >> >>>> symbol
>> >> >> >> >>>> with
>> >> >> >> >>>> another one of my choice, and still be able to call the
>> >> >> >> >>>> original
>> >> >> >> >>>> symbol.
>> >> >> >> >>>> Now, this does not seem easy....
>> >> >> >> >>>
>> >> >> >> >>> You can have a look at the heaptrack injector code, which does
>> >> >> >> >>> just
>> >> >> >> >>> that.
>> >> >> >> >>
>> >> >> >> >> Yes, it is very interesting indeed, thanks for the pointer!
>> >> >> >> >
>> >> >> >> > Using this technique i was able to subsitute Qt's dynamic symbols
>> >> >> >> > (eg,
>> >> >> >> > qt_startup_hook) in a simple Qt application.
>> >> >> >> > And i now understand what this QtCore.dyn file is all about! ;)
>> >> >> >> >
>> >> >> >> > Using the Loadable program segment, i can as well wrap any Qt
>> >> >> >> > function
>> >> >> >> > used by the program (QObject::EventFilter, ...).
>> >> >> >>
>> >> >> >> Hi Milian,
>> >> >> >>
>> >> >> >> This makes me think that heaptrack doesn't track memory related
>> >> >> >> symbols directly imported by the program itself. It does track only
>> >> >> >> malloc/free made by loaded shared objects.... Am I missing
>> >> >> >> something?
>> >> >> >>
>> >> >> >> Due to
>> >> >> >> https://github.com/KDE/heaptrack/blob/master/src/track/heaptrack_in
>> >> >> >> jec
>> >> >> >> t.c
>> >> >> >> pp
>> >> >> >> #L269
>> >> >> >
>> >> >> > What is a "malloc/free symbol directly imported by the program
>> >> >> > itself"?
>> >> >>
>> >> >> I mean "all memory related symbols" that heaptrack needs to track to
>> >> >> be able to fulfill its job.
>> >> >>
>> >> >> Maybe i misunderstood the goal of heaptrack.
>> >> >>
>> >> >> I started with a copy/paste of your code (see [1] below about
>> >> >> copy/pasting open source code), and then added another if in the
>> >> >> "program header type" check , one that would - I think - capture
>> >> >> dynamic symbols in a non dynamic object such as an ELF program file.
>> >> >> Basically I have the feeling that one has to check for PT_LOAD as
>> >> >> well.
>> >> >> My dl_iterate_phdr always start with info->dlpi_name == "", and this
>> >> >> unnamed PT_LOAD program header contains dynamic symbols embedded into
>> >> >> the ELF program file itself.
>> >> >>
>> >> >> So if i understand correctly (and I might be wrong), heaptrack install
>> >> >> hooks only on dynamic symbols found in dynamic ELF object (SOlibs),
>> >> >> not on dynamic symbols found in "PT_LOAD"'able ELF objects such as
>> >> >> program files.
>> >> >
>> >> > Can you give an example of when that would apply? This is a serious
>> >> > question.
>> >>
>> >> Yes, thanks for asking, it was stimulating! ;)
>> >>
>> >> But the answer is unfortunately very simple:
>> >> I'm running the code in the host program not in an LD_PRELOAD object!
>> >> So i think that in my case dl_iterate_phdr gives me access to the
>> >> just-loaded ELF file: the executable, which can contains itself
>> >> contains dynamic symbols such as malloc or free like in:
>> >>
>> >> int main(int argc, charr **argv)
>> >> {
>> >>
>> >>    stuff = new Stuff()
>> >>    return 0;
>> >>
>> >> }
>> >>
>> >> The ELF program file have it's own dynamic symbol table too, this call
>> >> to "new" will point to a non-heaptrack-tracked symbols.
>> >>
>> >> Bummer i'm disappointed by my own answer! ;)
>> >
>> > I will have to write a unit test to check whether that is really happening
>> > or not. A quick look at a binary like the above in elf-dissector shows a
>> > .plt entry for _Znam at got which will eventually call malloc internally so
>> > I think that should work fine.
>>
>> I haven't come across "_Znam at got " yet, so i cannot comment.
>> But I will keep an eye, for sure! ;)
>>
>> What is this thing suppose to be/do? A across-shared-objects shared
>> symbol cache? Lol!
>
> https://reverseengineering.stackexchange.com/questions/1992/what-is-plt-got

Thanks for the link, there's more links to follow from there, some are
definitely very interesting indeed.

I have asked my question on the good old binutils mailing list:
https://sourceware.org/ml/binutils/2017-09/msg00205.html

We are not in the same situation, you are wrapping known symbol that
are always resolved dynamically.
I wan't to wrap symbols, that should actually be resolved either at
build or run time, and i don't know the symbol name in advance...

As explained in the binutils email, i didn't want to enforce how the
binary is build (that's a gammaray requirement), but i had to give up,
so now i'm looking into soft requirement on the final build-time
linking process... Basically the idea is to make the final elf
executable more friendly to the elf injector....

Well that's the idea, and so far i'm unlucky! :(

I wonder if it would be possible to use a mix of elf symbol injector
and vtable injector (maid up the name 20 minutes ago!)...

vtable are duplex communication channels, code in a shared library can
call code in the executable by simply manipulating object defined in
the very same shared library, and the magic is called vtable, so maybe
it's possible to patch vtables at run time!

Chris