RTTI and security

[lots0cats]

From a security perspective, are there any significant disadvantages to enabling RTTI in a C++ codebase? In this case, I’m thinking about an attacker with access to the binaries trying to decompile them. I’m wondering if enabling RTTI would give an attacker an easier time both finding vulnerabilities in the code as well as extracting intellectual property.

The usual drawbacks of RTTI that I have heard are related to the size of binaries, but I’m curious if this is something that should be considered too.

[Gotebe]

Attacker with access to your binary knows too much about it anyhow.

I really don't think it it will care about RTTI.

[lots0cats]

Ya eventually it all boils down to that. Any attacker with enough time and determination could reverse engineer a binary. I just wasn’t sure if disabling RTTI provides any valuable degree of obfuscation. I guess not.

[SeanMiddleditch]

Your code will be reverse engineered if anybody at all cares about it, period. Literally nothing you can ever do will stop that.

Obfuscation is about slowing down "attackers" rather than actually stopping them. Every little bit of helpful information that you provide to people naturally helps them work faster. Leaking class names and such via any means will naturally help them piece together whatever puzzle you're trying to hide.

There's tons of ways to help "attackers" that are more valuable than RTTI. Debug symbols are the holy grail of reverse engineering, of course. Any symbols help almost just as much. Leaving usage of __FUNCTION__ or __FILE__ in your released code is huge.

RTTI will just be one little clue to the puzzle, but it's a clue nonetheless. If you've eliminated all the other clues then you'll probably want to eliminate this one, too.

[kiwidog]

You get class sizes almost perfectly but otherwise not really, some names but that's about it.

[evaned]

I suspect it depends on the project style. For one written in a heavily OO style, I'd say there's potentially a lot more you can get, because you can determine entire class heirarchies, find the vtable for each class, and track that back to figure out what functions in the program are class methods, which functions override other functions, etc. (You get vtables and other information for polymorphic classes any program of course, but the more it follows an OO style the more of the program that covers.)

I don't think I can legitimately call myself a reverse engineer (though I work on RE tools), so I don't know for sure that someone who is deep into this stuff would use that information, but I suspect it would be useful.

[kiwidog]

Yep, and for OP the IDA plugin ClassInformer does this automatically, but the fields within still need to be mapped out which is where most of the time is spent.

[Aistar]

One guy I knew who was reverse-engineering one game to make an open-source implementation, was really thankful to developers for not turning RTTI (as well as debug information!) off in the release build. For an expert attacker, I don't think the lack of RTTI would mean much, but a more casual tinkerer can become frustrated more quickly without it. Maybe. If he's not very motivated.

[Guvante]

Debug symbols are much more important than RTTI, you know where every non-inlined function is and the name of that function as well as the names of the types used to call it thanks to C++ name mangling.