I'm working on a .NET MAUI project targeting Android, and I noticed that the compiled library has a .dll.so format. After decompiling the generated AAB file, I observed that the library is in native code.
Given that the library is compiled to native code, does obfuscation still play a crucial role in securing the code? Are there specific considerations or best practices when it comes to obfuscating a .NET MAUI Android release project?
I want to ensure the security of my code but also understand whether the native compilation format (.dll.so) provides a certain level of protection inherently. Any insights or guidance on this matter would be greatly appreciated.
What I've Tried: I have reviewed the Android release build artifacts and verified that the compiled library is in the .dll.so format. Additionally, I've inspected the decompiled code to understand the level of obfuscation applied automatically by the native compilation.
Expectations: Considering the native compilation format (.dll.so), I would like to understand whether obfuscation is still a critical step for securing the code. I'm seeking insights into the effectiveness of native compilation in protecting intellectual property and preventing reverse engineering.
The answer to this Reverse Engineering question makes me think that the answer to your question is probably:
No, obfuscation is probably unnecessary.
Unless I have misunderstood something?
CORRECTION: Ah, it looks like the .dll.so files are only part of the story.
Inside the .APK there are also .blob files (multiple ones of these if you are building for native code). These .blob files are inside a folder called "assemblies". See: https://blog.dotnetframework.org/2022/10/03/extract-assemblies-blob-assemblies-manifest-from-xamarin-apk/
I'm still investigating, but it sounds like these .blob files may retain more information.