1

What is the format for .so native android files developed in Xamarin Mono droid? From this SO post it appears they are actually .NET IL binaries (not native machine code). However, this other SO post on Android NDK development appears to contradict this. In the apk file, there is a lib/armebi folder and a lib/x86 folder. Is it possible for .NET to be compiled to ARM format? If that is possible, it appears that x86 based .NET decompilers like ILSpy cannot handle ARM code too. Is there a better solution?

EDIT: I know Hopper and IDA Pro works with ARM mode, but we get assembly instead of .NET code.

Improve this question

1 Answer 1

Reset to default
5

If you're looking at a "normal" mono droid application (compiled with something like Xamarin) then you'll see some of these structures in the APK/ZIP'

/assemblies/Sikur.Monodroid.dll
/assemblies/Sikur.dll
/assemblies/Xamarin.Android.Support.v13.dll
/assemblies/Xamarin.Android.Support.v4.dll
/assemblies/Xamarin.Android.Support.v7.AppCompat.dll
/assemblies/Xamarin.Android.Support.v7.CardView.dll
/assemblies/Xamarin.Android.Support.v7.RecyclerView.dll
/assemblies/Xamarin.Mobile.dll
/assemblies/mscorlib.dll
/classes.dex
/lib
/lib/armeabi-v7a
/lib/armeabi-v7a/libmonodroid.so
/lib/armeabi-v7a/libmonosgen-2.0.so

File in the assemblies directory will be the Mono/.Net code and can be reversed using those normal tools.

classes.dex is a normal Android Dalvik executable file (dex) which can be reversed using the usual tools (baksmali, IDA Pro, etc) - though it should just be the stub loaded to start the Mono engine.

The files includes in lib/**/*.so are native shared libraries which are compiled into an ELF ARM file. These are normally going to the the monodroid engine (libmonodroid.so) and potentially other plugins that have been used by the developer. These would require ELF ARM capable disassemblers like Hopper, IDA Pro, r2, etc.

In the specific example above, the only non-Xamarin code would be located in Sikur.dll and Sikur.Monodroid.dll.

Improve this answer
2
  • sounds reasonable. but would it be confusing to look for the non-Xamarin code given that the dll file naming conventions are not required to follow the APK naming conventions. (like the DLL file containing the author's code may not be named in packages such as com.mycompany.MyApp as with the Java classes in classes.dex) Furthermore, there are a sizable number of third-party Xamarin extensions too.
    – Nederealm
    Oct 13, 2015 at 4:57
  • Correct, the dlls could be named anything, however they shouldn't be named as the "normal" framework files. So by just compiling a test application you should be able to see what is "normal" and was the new code being added is. The "Sikur.dll" was just an example.
    – diff
    Oct 13, 2015 at 16:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.