Xamarin-android: Xamarin Android: What does "Bundle assemblies into native code" really mean?

[alienwareone]

When this option is enabled, assemblies are bundled into a native shared library. This option keeps the code safe; it protects managed assemblies by embedding them in native binaries.

Note that the Bundle into Native Code option does not mean that the assemblies are compiled into native code. It is not possible to use AOT Compilation to compile assemblies into native code.

https://docs.microsoft.com/en-us/xamarin/android/deploy-test/release-prep/?tabs=windows#protect_app

I searched a lot about this topic but there seems a lot of confusion about what this option really does.

I tried to unpack the "libmonodroid_bundle_app.so" file with this project but it didn't work. https://github.com/AigioL/unpack.libmonodroid_bundle_app.so

I'm looking for basic obfuscation (renamed classes, methods, etc.) for my app.
It seems to me that this option compiles your assemblys to IL code, so your code could possibly be read.

So what can you see if you unpack the "libmonodroid_bundle_app.so" file (codewise)?

[dellis1972]

Personally if you want obfuscation I would not use bundle assemblies. As you mentioned all it does really is embed the IL into a native assembly. Also this feature is likely to be removed in the future.

I'm not sure if this still works but it might help https://devblogs.microsoft.com/xamarin/protecting-xamarin-apps-dotfuscator/.

[alienwareone]

Thanks for your answer @dellis1972

Unfortunately since I upgraded my project to AndroidX obfuscation doesn't work anymore, so I was looking for an alternative.

See:
https://github.com/xamarin/xamarin-android/issues/2120

Symbols were found but are not matching the assembly
   bei Mono.Cecil.ModuleDefinition.ReadSymbols(ISymbolReader reader, Boolean throwIfSymbolsAreNotMaching)
   bei Mono.Cecil.ModuleReader.ReadSymbols(ModuleDefinition module, ReaderParameters parameters)
   bei Mono.Cecil.ModuleReader.CreateModule(Image image, ReaderParameters parameters)
   bei Mono.Cecil.ModuleDefinition.ReadModule(String fileName, ReaderParameters parameters)
   bei Xamarin.AndroidX.Migration.CecilMigrator.Migrate(String source, String destination)
   bei Xamarin.AndroidX.Migration.CecilMigrator.Migrate(IEnumerable`1 assemblies)
   bei Xamarin.AndroidX.Migration.BuildTasks.CecilfyFiles.Execute()

[simon10says]

I'm also getting very confused about this, especially since XF4.5, several serious, showstopper, regression bugs (like xamarin/Xamarin.Forms#9900 and xamarin/AndroidX#64) has surfaced and Xamarin members have since strongly demote the use of BundleAssemblies

My decision to use BundleAssemblies was based on this, to:

1. Provide at least some protection by embedding managed assemblies into native binaries
2. Strip away the assemblies folders in my apk which the dlls could be so easily peek using dotPeek in plain text code
3. Decrease the size of my apk (and yes, I know I can use app bundle)

So ... now ... with Xamarin members questioning us why use BundleAssemblies and demoting the use, and reading back the doc as stated above, what is the guideline now? Without BundleAssemblies, how does the code get the protection with BundleAssemblies (I know it's not 100% foolproof, but at least there is a layer of protection)? Is there anything else about BundleAssemblies which led Xamarin members surprise why we are using it?

Would really appreciate some detail rather than suggesting that it might be removed in .Net 5 which is some time away

[nhdanh]

I'm also getting very confused about this, especially since XF4.5, several serious, showstopper, regression bugs (like xamarin/Xamarin.Forms#9900 and xamarin/AndroidX#64) has surfaced and Xamarin members have since strongly demote the use of BundleAssemblies

My decision to use BundleAssemblies was based on this, to:

1. Provide at least some protection by embedding managed assemblies into native binaries
2. Strip away the assemblies folders in my apk which the dlls could be so easily peek using dotPeek in plain text code
3. Decrease the size of my apk (and yes, I know I can use app bundle)

So ... now ... with Xamarin members questioning us why use BundleAssemblies and demoting the use, and reading back the doc as stated above, what is the guideline now? Without BundleAssemblies, how does the code get the protection with BundleAssemblies (I know it's not 100% foolproof, but at least there is a layer of protection)? Is there anything else about BundleAssemblies which led Xamarin members surprise why we are using it?

Would really appreciate some detail rather than suggesting that it might be removed in .Net 5 which is some time away

Good, I agree with you

[pulmuone]

I'm also getting very confused about this, especially since XF4.5, several serious, showstopper, regression bugs (like xamarin/Xamarin.Forms#9900 and xamarin/AndroidX#64) has surfaced and Xamarin members have since strongly demote the use of BundleAssemblies

My decision to use BundleAssemblies was based on this, to:

1. Provide at least some protection by embedding managed assemblies into native binaries
2. Strip away the assemblies folders in my apk which the dlls could be so easily peek using dotPeek in plain text code
3. Decrease the size of my apk (and yes, I know I can use app bundle)

So ... now ... with Xamarin members questioning us why use BundleAssemblies and demoting the use, and reading back the doc as stated above, what is the guideline now? Without BundleAssemblies, how does the code get the protection with BundleAssemblies (I know it's not 100% foolproof, but at least there is a layer of protection)? Is there anything else about BundleAssemblies which led Xamarin members surprise why we are using it?

Would really appreciate some detail rather than suggesting that it might be removed in .Net 5 which is some time away

Good, I agree with you.

[nhdanh]

any new when XF 4.6 was release. I still get error on XF 4.6

[jonpryor]

What does "Bundle assemblies into native code" really mean?

It means "take all of the assemblies, and instead of leaving them uncompressed as assemblies/*.dll within the .apk, gzip compress them into a libmonodroid_bundle_app.so file, using mkbundle to generate the code.

So what can you see if you unpack the "libmonodroid_bundle_app.so" file (codewise)?

All of the assemblies/*.dll files that are required for the app to run.

The assemblies themselves are unchanged (aside from linking/etc.).

This is "some" protection, to be fair, but it's not much.

[jonpryor]

I have updated the Bundle Assemblies into Native Code documentation, which now reads:

This allows assemblies to be compressed, permitting smaller .apk files. Assembly compression also confers a minimal form of obfuscation; such obfuscation should not be relied upon.

[jonpryor]

Commit d236af54538ef1fe62d0125798cdde78e46dcd8e provides a different take on "minimal levels of obfuscation": it does not obfuscate, but it does:

1. Compress assemblies, and
2. Prefix compressed assemblies with a non-IL header.

As such, tools like ildasm won't be able to read them as-is. It is an "obscuration."

It is not a security solution. It's a way to get smaller .apk files without the startup overheads involved in $(BundleAssemblies)=True, while also avoiding the Xamarin.AndroidX.AppCompat.Resources.dll issue in xamarin/AndroidX#64.

[EDMIStephen]

Commit d236af5 provides a _different_ take on "minimal levels of obfuscation": _it does not obfuscate_, but it does:

1. Compress assemblies, and
2. Prefix compressed assemblies with a non-IL header.

As such, tools like ildasm won't be able to read them as-is. It is _an_ "obscuration."

_It is not a security solution._ It's a way to get smaller .apk files without the startup overheads involved in $(BundleAssemblies)=True, while also avoiding the Xamarin.AndroidX.AppCompat.Resources.dll issue in xamarin/AndroidX#64.

Someone might want to get in touch with the VS team to update their gui.

[simon10says]

Hi @jonpryor , I don't have much knowledge on this aspect and hope you could shine some light. When you said:

So what can you see if you unpack the "libmonodroid_bundle_app.so" file (codewise)?

All of the assemblies/*.dll files that are required for the app to run.

Do you mean I could simply unzip libmonodroid_bundle_app.so and I could retrieve all the assemblies/*.dll?

I tried it and all I see is:

I tried opening up most of the files inside and they are all in binary. And from my shallow knowledge on this, my understanding is that you could go a step further to reverse-engineer to machine code. So, how to unpack libmonodroid_bundle_app.so to get to the assemblies/*.dll files?

[EDMIStephen]

Hi @jonpryor , I don't have much knowledge on this aspect and hope you could shine some light. When you said:

So what can you see if you unpack the "libmonodroid_bundle_app.so" file (codewise)?

All of the assemblies/*.dll files that are required for the app to run.

Do you mean I could simply unzip libmonodroid_bundle_app.so and I could retrieve all the assemblies/*.dll?

I tried it and all I see is:

I tried opening up most of the files inside and they are all in binary. And from my shallow knowledge on this, my understanding is that you could go a step further to reverse-engineer to machine code. So, how to unpack libmonodroid_bundle_app.so to get to the assemblies/*.dll files?

https://github.com/tjg1/mono_unbundle

[EmilAlipiev]

you can see this SO post. App Bundles does same thing as Bundle into native assemblies.

https://stackoverflow.com/questions/62293367/xamarin-android-app-bundle-with-bundle-into-native-assemblies-increases-size-b

[simon10says]

@EDMIStephen , thanks for the link. I'll need more time to test it out; but a quick look at it, it seems easy to reverse-engineer libmonodroid_bundle_app.so to get the dlls.

My initial understanding of this is all wrong; I thought BundleAssemblies will compile the code into native code.

I've re-read this Xamarin Doc. Some sections in the doc has changed even the date at the very top still is at 2018. There is this line that says:

Note that the Bundle into Native Code option does not mean that the assemblies are compiled into native code. It is not possible to use AOT Compilation to compile assemblies into native code.

So, there is never a way in Xamarin to compile and pack apk in native code. Also to take note is that r8 or ProGuard does not do any obfuscation (in Xamarin).

So ... it seems like the only way to protect Xamarin app is with obfuscation. And now I understand why Xamarin members have been diminishing the usefulness of <BundleAssemblies>. But still ... with <BundleAssemblies>, I can eliminate those novice hacker.

Finally, any best practices to follow to make it harder against reverse-engineering (just in the area of Xamarin)? Is there an option to compile into native code instead of generating the dlls?

[simon10says]

@EmilAlipiev , thanks for the link to the SO post. I'll bring my further discussion in the SO post

[tranb3r]

@simon10says
Yes, in xamarin, you can compile the .net code into native code, it's what AOT does.
However, the apk will always contain the original dlls (I believe this is needed for reflection), either in the assembly folder or bundled into a .so lib (which is smaller in size than the assembly folder, and is in a way some very basic obfuscation since you'll need a tool to unbundle it).
r8 or proguard does not modify .net code, but it does actually obfuscate the java code in xamarin apps.
For more obfuscation of .net code, you can use any .net obfuscation tool (dotfuscator, babel obfuscator...).

[nexxuno]

Let me add an important detail: if you use hybrid AOT the code is stripped away from the .Net assemblies leaving only method stubs neede for relfection, thus achieving very good obfuscation.

[tranb3r]

Let me add an important detail: if you use hybrid AOT the code is stripped away from the .Net assemblies leaving only method stubs neede for relfection, thus achieving very good obfuscation.

@nexxuno I didn't know that. Thanks for the tip, I'll definitely look into it :)

[simon10says]

@tranb3r , yes ... that's my understanding too. What I meant was finding a mean to compile into native code and does away the dlls that could be so easily reverse-engineered.

@nexxuno , it seems like using hybrid AOT does not stripped away code from the assemblies. I came upon this fresh post. I've also verified it with the following configuration and it does not strip away the code from the assemblies:

<AotAssemblies>true</AotAssemblies>
<AndroidAotMode>hybrid</AndroidAotMode>
<BundleAssemblies>false</BundleAssemblies>
<EmbedAssembliesIntoApk>true</EmbedAssembliesIntoApk>
<AndroidLinkMode>Full</AndroidLinkMode>
<AndroidLinkTool>r8</AndroidLinkTool>
<AndroidDexTool>d8</AndroidDexTool>

This is my test project - App2.zip

[nexxuno]

At the moment I can't test if it stopped working, like stated in your link. What I remember is that I used hybrid aot plus llvm and it was working.

[simon10says]

https://github.com/xamarin/xamarin-android/issues/4818#issue-638517771

pfff ... this is getting so tiring and frustrating to get it right

[EDMIStephen]

#4818 (comment)

pfff ... this is getting so tiring and frustrating to get it right

Yeah. I am having no luck with Hybrid AOT. It doesn't seem to be doing what it says it should.

[EDMIStephen]

g, like stated in your link. What I remember is that I used hybrid aot plus llvm and it was working.

Are you able to post which version of VS etc you are using. I am on the latest of everything and tried preview too and it isn't working.

In the other bug you mentioned it was not working for you.
https://github.com/xamarin/xamarin-android/issues/4115#issuecomment-609436070

[nexxuno]

I need to check my continous integration settings but I can't right now. For some time it wasn't working as in "it was crashing at startup" but it was definetly stripping.

Ottieni Outlook per Androidhttps://aka.ms/ghei36

---

From: EDMIStephen [e-mail]
Sent: Wednesday, June 17, 2020 11:31:01 PM
To: xamarin/xamarin-android [e-mail]
Cc: Paolo Ferrazza [e-mail]; Mention [e-mail]
Subject: Re: [xamarin/xamarin-android] Xamarin Android: What does "Bundle assemblies into native code" really mean? (#4527)

g, like stated in your link. What I remember is that I used hybrid aot plus llvm and it was working.

Are you able to post which version of VS etc you are using. I am on the latest of everything and tried preview too and it isn't working.

In the other bug you mentioned it was not working for you.

4115 (comment)https://eur06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fxamarin%2Fxamarin-android%2Fissues%2F4115%23issuecomment-609436070&data=02%7C01%7C%7Cb06374c2f83f48b9c1aa08d81305bc1a%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637280262631207620&sdata=fWFn6AouxfK0u9Z3D1jonFipI%2Ft9PLerYM7XktVh87g%3D&reserved=0

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://eur06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fxamarin%2Fxamarin-android%2Fissues%2F4527%23issuecomment-645635711&data=02%7C01%7C%7Cb06374c2f83f48b9c1aa08d81305bc1a%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637280262631207620&sdata=u%2FpH%2BGk2oPhASlTXWEZ5%2BF%2FZxhfOtVkAvJoAnrn9C%2Fc%3D&reserved=0, or unsubscribehttps://eur06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FADWECAEN56FYRHJYQ4G2FLDRXEYZLANCNFSM4MCIWVSA&data=02%7C01%7C%7Cb06374c2f83f48b9c1aa08d81305bc1a%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637280262631217614&sdata=NSgaU3O%2BLbxcZTBT2%2FB0JsowSVv6u%2FnJB9A4FkNCTK8%3D&reserved=0.