As everybody knows, piracy becomes a very serious issue on Android.
Does Mono for Android provide code obfuscation when compiling to native code?
Mono for Android does not provide this functionality, however you can still use a third-party tool for obfuscation. As Mono for Android produces CIL assemblies that are JITed by the Mono runtime on the Android device you need to obfuscate these .NET assemblies. Therefore tools like the Android obfuscator Proguard will not help you. The below .NET obfuscators have been reported to work with Mono for Android.
Xenocode Postbuild
CryptoObfuscator
If you use Xenocode Postbuild then make sure you disable "metadata reduction" so that Class names remain valid in Java.
Update
Xamarin.Android allows you to package APK files without the need for the compiled .NET DLLs. This means you do not need to apply obfuscation from a .NET point of view. I can extract my release APK file and find that only the classes.dex file and the .so library files are included. To enable this tick the box "Embed assemblies in native code" (this may only be available for Enterprise subscribers).
Related
So I have an android game which is using unity, and I looked for scripts inside dll and know exactly what should I change in C# code, I mean I reverse engineered this app almost completely. What should I do next? Complile it? But how?
You can use use AAPT (Android Asset Packaging Tool) to decompile-recompile apks.
For more information how to use it, below references are given:
http://elinux.org/Android_aapt
What is aapt(Android Asset Packaging Tool) & How it works?
ReverseEngineering
Hope you can't do that with Proguard Obfuscation limit.! Especially, for Android applications which is written by Android Studio.
I mean, if one app compiled(for android studio f.g), Progaurd will do the Obfuscation and you can't even see the right codes.
Is the .so files generated by Xamarin Monodroid (libmonodroid.so and libmonosgen-2.0.so) managed code or native code? From this SO post it appears they are actually .NET IL binaries (not native machine code). An answer even suggested the Xamarin.Android binaries is JIT'ed and can be opened in any .NET decompiler. However, this doesn't seem to work with dotPeak or ILSpy based on my investigation.
However, this other post on another SE site appears to contradict this. It should be noted that they are referring to Android NDK in general.
So, should the native library be opened on a .NET decompiler or dissembler such as Hopper and IDA Pro (giving you assembly code)?
Those files, libmonodroid.so and libmonosgen-2.0.so are native libraries and are the core libs of Mono and Xamarin.Android, these of course are based upon the ABI/ARCH types that you are supporting within your APP.
Xamarin.Android application packages have the same structure and layout as normal Android packages, with the following additions:
The application assemblies (containing IL) are stored uncompressed within the assemblies folder.
Native libraries containing the Mono runtime are also included and provide a parallel runtime to the Android Runtime (ART) and the bridge to talk from/to MONO <-> ART.
In Xamarin.Android 5.1 and above, you have the option to AOT your assemblies like Xamarin.iOS does always due to Apple's requirement of no JIT/dynimically generated code on iOS. This option for Android is defined in the Packaging Properties and by default is false. So for assemblies that have been AOT'd, machine code based on ABI/ARCH type has been generated and replaced the APPs C# IL.
This is my first experience to build an APK for native code in android.when I build APK as we do in android for java code it consists of only Java code ,functionality that implemented in c/c++ not reflected in build when I install apk on device.
Please guide me on the same !!!
You can use Android-NDK
Android NDK
The NDK is a toolset that allows you to implement parts of your app using native-code languages such as C and C++. For certain types of apps, this can be helpful so that you may reuse existing code libraries written in these languages and possibly increased performance.
I can cross-compile any C/C++ application, statically link it Linux libraries and run it on Android. What was the need of an Android-ndk then? Android-ndk limits us to bionic which has a small subset of gnu libc. Isn't it a better idea to straightaway cross-compile applications and run them through Android shell? Is there any limitation to cross-compiling that I can't see? This URL : Can Linux apps be run in Android? answers my question to some extent but eventually leaves me confused and without clarity.
I think this is enough for Android-NDK
The Android NDK is a companion tool to the Android SDK that lets you build performance-critical portions of your apps in native code. It provides headers and libraries that allow you to build activities, handle user input, use hardware sensors, access application resources, and more, when programming in C or C++. If you write native code, your applications are still packaged into an .apk file and they still run inside of a virtual machine on the device. The fundamental Android application model does not change.
The NDK provides:
A set of tools and build files used to generate native code libraries
from C and C++ sources
A way to embed the corresponding native libraries into an application
package file (.apk) that can be deployed on Android devices
A set of native system headers and libraries that will be supported
in all future versions of the Android platform, starting from Android
1.5. Applications that use native activities must be run on Android 2.3 or later.
This thing you can not find in other cross-compilation with arm toolchain..
As mentioned in the link http://developer.android.com/sdk/ndk/index.html NDK is a companion for App development folk to create performance sensitive native code. NDK exposes some of the native implementation of Android which could not be found in the general Linux environments. Some of them include the Android/Bitmap, Android/nativeWindow etc. Using these Android natives applcation can speed up CPU intensive processes like some compression or decompression of images.
Even though the externally cross-compiled executables may run in the Android there no guarantee that versions of the standard library implementaions are the same. NDK provides a easier and Android compatible toolchain and other resources, using which is much easier to application developers than having to find a compatible cross-compiler for their usecase.
Our development team just (mostly) finished an Android app using MonoDroid in Visual Studio. Because it has to do with banking, we wanted to try to obfuscate it in order to add some security against anyone trying to decompile it. Initially, I figured I could just use ProGuard, but there doesn't seem to be a project.properties file that I can edit in Visual Studio. Can anyone shine some glorious helping light on this subject and tell me if it is possible to use ProGuard with Mono and my newbishness is just clouding my vision?
(Another developer tried to use Dotfuscator -since we couldn't immediately find a way to use ProGuard- but it failed with numerous errors; the Mono runtime seems to give it issues.)
The Mono for Android toolchain doesn't have any support for running proguard at the moment.
However, with one broad exception, the lack of proguard support is largely moot. Proguard only runs on Java bytecode. The Mono for Android architecture has the Mono runtime running in the process; .NET CIL is not "compiled" into Java bytecode, the CIL is JITed by Mono. The only Java code running around is for Android Callable Wrappers, which allow Java/Android to call into managed code.
Thus the only thing proguard will protect in a Mono for Android app is the generated Android Callable Wrappers, which largely consists of a bunch of native method declarations. There won't be any business logic to decompile in the Android Callable Wrappers.
Instead, the CIL assemblies are stored uncompressed in the .apk file. The assemblies in turn can be decompiled to obtain all your business logic. The solution here is to obfuscate the assemblies before embedding them into the .apk. There are reports that Xenocode's Postbuild 2010 can be used, though I don't know any of the details on how to hook this up.
The exception mentioned above relates to any custom Java code included in the build proces via the AndroidJavaSource and AndroidJavaLibrary Build actions, which would be used to include such things as the AdMob library. For this scenario we should add proguard support to the build process, though I have no ETA on when proguard support will be added.