Trying to manipulate dynamic_cast

[Frederick Virchanza Gotham]

I intend to manipulate the functionality of 'dynamic_cast' on x86_64 with the GNU compiler 'g++'.

But first I need a solid understanding of how the v-table is laid out with RTTI and so forth. I searched and searched and searched the web but I can't get a simple explanation so I've decided to take the machine code for dynamic_cast and run it through a C decompiler. If I take the assembler for 'dynamic_cast' and run it through the IDA decompiler, it gives me the following:

void *_dynamic_cast(void ****p, const void *tiBase, const void *tiDerived, ptrdiff_t s2d)
{
if ( !p ) return nullptr;

void ****q = (void****)( p + p[0][-2] / 8u );

void **value = p[0][-1];

if ( q[0][-1] == value )
{
typedef void (*FuncPtr)(void **, ptrdiff_t, uint64_t, const void *, void ****, const void *, void ****) __attribute__((fastcall));

FuncPtr *const pf = static_cast<FuncPtr*>(*value);

pf[7u](value,s2d,6LL,tiDerived,q,tiBase,p);
}

return nullptr;
}

So the first thing I notice here is that this function always returns a null pointer -- but obviously that would be useless.

The only thing I can imagine here is that the function call "pf[7u](. . .)" is doing some sort of long jump return. Is that what's happening?

Also I imagine that "pf[7u]" is the address of a thunk.

My manipulation will involve writing a new thunk and setting "pf[7u]" to my new thunk.

[David Brown]

On 30/10/2022 02:00, Frederick Virchanza Gotham wrote:
>
> I intend to manipulate the functionality of 'dynamic_cast' on x86_64
> with the GNU compiler 'g++'.
>

I don't know what you are trying to do here, but it certainly sounds
like a bad idea...

> But first I need a solid understanding of how the v-table is laid out
> with RTTI and so forth. I searched and searched and searched the web
> but I can't get a simple explanation so I've decided to take the
> machine code for dynamic_cast and run it through a C decompiler. If I
> take the assembler for 'dynamic_cast' and run it through the IDA
> decompiler, it gives me the following:
>

Surely the obvious way to proceed is to download the gcc sources and
look at how dynamic_cast is actually implemented there? It seems crazy
to use a "decompiler" when the original source code is available. I am
not suggesting that the gcc sources are likely to be simple and clear in
this area, but they must surely be a better choice.

[Juha Nieminen]

Frederick Virchanza Gotham <cauldwel...@gmail.com> wrote:
> I intend to manipulate the functionality of 'dynamic_cast' on x86_64 with the GNU compiler 'g++'.

dynamic_cast is a rather complicated feature.

Most C++ programmers think of it as "just a downcast with a check to see
that the current object is actually of the derived type we are casting to".

However, it supports more than just casting from a base class type to a
derived class type with a validity check. You can have a very complicated
diamond inheritance scenario involving a dozen classes up and down the
inheritance tree (and even multiple diamond shapes within this tree), and
you can dynamic_cast between any two class types within that tree, and it
will work (ie. it will check if the object in question actually is of, or
inherits from, the target class type, and correctly calculates the pointer
offset for that particular type within the current object, no matter where
in the complex diamond inheritance hierarcy the source and target types may
be.) And yes, this does involve traveling inheritance hierarchies up and
down (possibly with some optimizations).

[Juha Nieminen]

Juha Nieminen <nos...@thanks.invalid> wrote:
> You can have a very complicated
> diamond inheritance scenario involving a dozen classes up and down the
> inheritance tree

Correction: Diamond inheritance, or even just multiple inheritance without
any diamonds. dynamic_cast will work correctly even if the source and
target class types have no common base class at all. (If there's a
class that inherits from both classes, directly or through a longer
chain of inheritances, dynamic_cast will find out if this is such an
object, even if the compiler does not see nor know about that class
that inherits from both at the point where you do the dynamic_cast.)

[Frederick Virchanza Gotham]

I ended up writing a function to disable 'dynamic_class' at runtime for any given polymorphic class.

I put together a quiz question about it up on the 'Codewars' website, you can see it here:

https://www.codewars.com/kata/635d489c3c8a10004abfd46b

[Öö Tiib]

Suggestion to copy-paste parts of standard library or compiler implementation
code is bad. Authors of such use and define names reserved to implementation
but if programmers use those in their code then the behaviour of resulting
program is undefined if it compiles. That is not just pedantry, outcome can
actually behave in rather confusing manner.

On any case use spellchecker on texts you publish ... for example it is spelled
"plagiarism" not "plagarism".

[Frederick Virchanza Gotham]

On Tuesday, November 1, 2022 at 2:24:32 PM UTC, Öö Tiib wrote:

> Suggestion to copy-paste parts of standard library or compiler implementation
> code is bad. Authors of such use and define names reserved to implementation
> but if programmers use those in their code then the behaviour of resulting
> program is undefined if it compiles. That is not just pedantry, outcome can
> actually behave in rather confusing manner.

The Standard says that identifiers containing a double underscore are reserved. The Standard also tells all about integer promotion, and lots of other stuff too such as an array decaying to a pointer to its first element. The people taking the quiz are expected to be fairly familiar with the Standard, and they can read it while taking the quiz.

> On any case use spellchecker on texts you publish ... for example it is spelled
> "plagiarism" not "plagarism".

I am strongly adverse to spelling standardisation as it curbs creativity. For example if I'm in a happy mood, I will spell 'sheep' with an I instead of an E, as follows:
"Today I am so happi, not to be following everyone in the crowd like a mindless shiip, and instead to inject my creativitii into my spelling"

During the festive season I use camel case. I had one lecturer in college who could do mirror writing.

[Öö Tiib]

On Thursday, 3 November 2022 at 01:12:23 UTC+2, Frederick Virchanza Gotham wrote:
> On Tuesday, November 1, 2022 at 2:24:32 PM UTC, Öö Tiib wrote:
>
> > Suggestion to copy-paste parts of standard library or compiler implementation
> > code is bad. Authors of such use and define names reserved to implementation
> > but if programmers use those in their code then the behaviour of resulting
> > program is undefined if it compiles. That is not just pedantry, outcome can
> > actually behave in rather confusing manner.
>
> The Standard says that identifiers containing a double underscore are reserved. The Standard also tells all about integer promotion, and lots of other stuff too such as an array decaying to a pointer to its first element. The people taking the quiz are expected to be fairly familiar with the Standard, and they can read it while taking the quiz.

Still to copy-paste that code is bad idea regardless of deepness of
knowledge of standard and years of experience with C++.

> > On any case use spellchecker on texts you publish ... for example it is spelled
> > "plagiarism" not "plagarism".
>
> I am strongly adverse to spelling standardisation as it curbs creativity. For example if I'm in a happy mood, I will spell 'sheep' with an I instead of an E, as follows:
> "Today I am so happi, not to be following everyone in the crowd like a mindless shiip, and instead to inject my creativitii into my spelling"
>
> During the festive season I use camel case. I had one lecturer in college who could do mirror writing.

Of course it is OK, if your goal is not to express thoughts and to make a
point but just to produce immature sheep noises. But it is not innovative
as 95% of internet content seems to be such animal noises expressed in
more or less defective human grammar.

[Chris M. Thomasson]

On 10/30/2022 2:09 AM, David Brown wrote:
> On 30/10/2022 02:00, Frederick Virchanza Gotham wrote:
>>
>> I intend to manipulate the functionality of 'dynamic_cast' on x86_64
>> with the GNU compiler 'g++'.
>>
>
> I don't know what you are trying to do here, but it certainly sounds
> like a bad idea...

[...]

Nasal demons are having a party right now!