Does AOT still expose lots of .NET metadata?

[0x90CH]

I think that fewer people are interested in AOT in order to make reverse engineering their program more difficult (prevent usage of dnSpy etc), and I just discovered this blog post: https://blog.washi.dev/posts/recovering-nativeaot-metadata/, which states that AOT exposes a lot of .NET metadata. Is this still the case, or has it been fixed? With AOT, you assume you have a fully-fledged native program and not necessarily a ReadyToRun mix. At least that's the impression given in the docs for people who don't necessarily know exactly what's behind it.

[huoyaoyuan]

They are not "exposed". They are just present to organize the OOP type system to work.

I think that fewer people are interested in AOT in order to make reverse engineering their program more difficult

This is a side effect and never a goal.

Is this still the case, or has it been fixed?

There's nothing to fix. AOT is not designed as an obfuscator.

With AOT, you assume you have a fully-fledged native program and not necessarily a ReadyToRun mix.

The post is incorrect here. ReadyToRun was created from NativeAOT, although it went production earlier. The initial commit was dotnet/corert#5943 .

Because of the same origin, NativeAOT and ReadyToRun shares some auxiliary data structures.

[0x90CH]

If the goal wasn't to have a fully-fledged native program. What was the goal then?

[huoyaoyuan]

It is a fully-fledged native program. What do you mean here?

[0x90CH]

The blog assumes that it leaks .NET metadata. Data which wouldn't exist in a native program written in a native language. Is this a misunderstanding or am I missing something?

[huoyaoyuan]

The blog assumes that it leaks .NET metadata. Data which wouldn't exist in a native program written in a native language.

Such data exists for any type system present in runtime, including C++ vtable and RTTI information. Again, it's never a "leak". They are unavoidable to make things work.

[0x90CH]

Thank you for taking the time to explain this to me