Android-Xamarin primary break

klaus.feng (25)in #android-xamarin • 6 years ago (edited)

When doing APK analysis will inevitably encounter some non native development models, such as H5, Mono and so on, to solve the APK principle development mode actually added and cracked shell like APK, is nothing more than to find its core code (or the former than the latter is much simpler). This time, I met a APK developed by Xamarin. I first learned about this Xamarin. It is nothing more than a APP development framework based on Mono, which contains many Android Framework API for you.

DEX decompile

Almost all classes, as shown above, have static code block + string format code + Native method. I found a lot of code that I didn't find useful, but I felt like I was either shell or I never met.

It is decided that something in the DEX file is useless, so what is in the SO file? Whether it is a shell or other, there will be a corresponding SO to deal with, so to see what the familiar files in the Lib directory, can help me to further understand the APK.

Lib directory

There is no libdexhelper.so in the Lib directory that looks very eyesore, but there are two more interesting files, libmonodroid.so and libmonosgen.so, and these two files are the engine files of Xamarin.

After knowing that APK is the Xamarin framework, go to the assemblies directory to find its core code, and find a lot of DLL files here, which are compiled by the C# source code. There are many tools to decompile these files, such as ILSpy,.NET Reflector and dotpeek, etc. (personal recommendation ILSpy).

DLL file

Next is to analyze the decompile code. We can see that the decomcompiling degree of C# is almost the same as that of the source code, so it is easy to analyze. Looking for where you want to modify (modify IL code only needs to add a plug-in to your recompiling tool is good -Reflexil), a lot of small game break, change gold coins, blood volume and what is easy. I need to let traffic go through my proxy server for a more convenient study of its communication protocol, so I need to modify its certificate check code.

Modify IL

Find the checkout place, then change the returned false to true, and change the ldc.i4.0 to ldc.i4.1 through reflexil. Next is saving, replacing source files, packing and signing.

Pay attention to several problems when packing

The first problem is packing, generally repackaging my habit of choosing apktool B to repackage, but here because some bug can not pack apktool, after thinking of other ways, instead of replacing the DLL file, and this resource is not compiled with AAPT, so I can choose to unzip the APK file, and then replace the APK file, and then replace it, and then replace the APK file, and then replace it, then replace the APK file, and then replace the AAPT file, and then replace it, then replace the AAPT file, then replace the APK file, then replace the AAPT file, then replace the AAPT file, then replace the AAPT file, then replace the AAPT file, then replace the AAPT file, then replace the APK file, then replace the AAPT file, then replace the AAPT file, then replace the AAPT file, then replace the AAPT file, then replace the AAPT file, then replace the APK file, then replace the AAPT file, then replace the AAPT file, then replace the Change the DLL file, finally in the compression back on the OK, in fact, all add or delete not to be compiled files can be used in this way, such as the resources under the assets directory, compiled DEX, compiled SO;

The second problem is the file compression problem, when I replace DLL, when the folder is compressed, you need to choose some resources to not be compressed, or the late operation will be reported wrong. For this APK, all the files under the assemblies directory should not be compressed;

The third problem is the APK byte alignment problem, which is mainly on the Google store application packaging, and I need to cut the compressed APK through the zipalign tool

Android SDK contains a "zipalign" tool, which can optimize packaged applications. Run zipalign on your application, making interaction between Android and application more efficient at runtime. Therefore, this way can make the application and the whole system run faster.
This tool is in the SDK directory, and the command is

Android/sdk/build-tools/25.0.0/zipalign -v -p 4 in.apk out.apk.

The fourth problem is the signature, and then it is done with the apksigner tool in SDK, which requires a signature file that can be generated in the Android Studio, and the signature command is:

Android/sdk/build-tools/25.0.0/apksigner sign --ks releasekeystore.jks --out out.apk in.apk.

Finally, the system agent is installed on the mobile phone, and it is found that its traffic has not yet come to my proxy server. Why? The certificate check is changed.

Suppose there are several possibilities. The first possibility is that its protocol is not http/https, but the analysis of C# code shows that many URL is HTTPS protocol, break. The second possibility is that it does not take the flow of the system agent, by observing the traffic on my proxy server, it does not catch the APP traffic, but this APP can run normally, continue.

So why don't you take the system agent? The first possibility is that it sets the agent to NO_PROXY, so that the agent is forced to fail.

NO_PROXY

Go back to the C# code and find that the HTTP library it uses is FLURL, and it is found that it does not set the proxy property of the FLURL, so that it makes sense that it will not go without the agent. Further analysis, FLURL is implemented by C# and acts on the.NET program, so it is conjectured that the library should not take into account the system agent on the Android phone at the beginning of the design (I did not dig the Xamarin to the agent), so it would not take the initiative to obtain the system agent on the Android. And getting the system proxy addresses on the Android platform is generally done in this way (hostKey is "http.proxyHost" in the graph, and portKey as "http.proxyPort"):

Android6.0 gets the system agent address

So how can we make FLURL's proxy automatically configured as Android's system agent? You can change the code of FLURL, compile and replace the flurl.dll file in APK. When I thought about this method, I gave up. After many twists and turns, the last thing is to force HTTP traffic to my proxy server by means of ProxyDroid, a tool on Android.

Looking back again, there are many ways to achieve the above function, for example, HOOK. Mono is a JIT run mode, so that we can load a DLL file by Hook Mono, replace a specific DLL (when DLL changes are larger), or offset to a byte in patch DLL (DLL changes hours) by file migration.

Mono is an open source project, and there are many online analysis. I'll briefly summarize some functions involved in the DLL loading process here.

1.mono_assembly_open opens the DLL file

2.mono_assembly_load_from_full loads DLL files into memory.

mono_assembly_open&&mono_assembly_load_from_full