Android process injection and android Process

Android process injection and android Process

Download all code here: http://download.csdn.net/detail/a345017062/8133239

There are two exe files, and inj is an example of a C-layer process injection. Inj_dalvik is the Java injection I wrote.
C-layer process injection by directly pulling the master wash open source project (https://code.google.com/p/libandroidinjector)


Most of the basic services of Android are written in Java, but only in the C-layer injection. It is troublesome to directly access them. Therefore, you need to load a dex package at the remote end (the dex package under the/data/local/inj directory is written in the Code ). Loading dex requires the Context of the Dalvik virtual machine, that is, JNIEnv. This is a little troublesome. If you compile the source code directly, it will take a long time to build the Source Code compiling environment, finally, the Header file is pulled out from the source code, and the android_runtime and nativehelper are pulled out from the adb pull of my mobile phone (ZTE N5 4.1.2. so solves the issue of compilation and linking.
After loading dex on the C layer, you can call the main Java method to execute Java code. However, if you want to access system services, no Context is acceptable. Therefore, ActivityThread is called through reflection, get the Application.
My initial thought was to inject inj_dalvik into the system_server process, and then access all Android system services in it. But then I found two problems, dex cannot use a remote service proxy such as PackageManager when executing the system_server process. It can only use ServiceManager. getService ("package") directly obtains the PackageManagerService instance. In addition, it is found that services such as PackageManagerServer have frequent interface changes and version adaptation is troublesome. Therefore, we finally decided to inject a customer process whose user is system, such as com. android. settings. Then the entire process passes.
An unsolved problem is that a process like com. android. setting is not a system Daemon, nor a resident process. After code injection, we cannot survive forever. However, other processes such as/system/bin/surfaceflinger cannot load our Dex and Java code because they are C Programs and do not have AndroidRuntime at startup. Therefore, you can either secretly start the com. android. settings process in the background when you need to execute remote code, or fork a process with AndroidRuntime and register it in init. rc.


We look forward to your suggestions or solutions.
The score set during resource download is relatively high because I am too poor. If you do not score, follow the public account to contact me and I will send it to you.

Android Development

It is incorrect to use the SetOnClickListener of the button. First, you have not inherited the OnClickListener interface. Therefore, the click event you set for the button is actually an activity, and it is forcibly converted to OnClickListener, it's like someone else wants a door. You have to block a wall for someone else. Do you think that's right?
There are many methods
The simplest method is to inherit the OnClickListener interface. Remember that it is the OnClickListener interface under the View. view package.

How should I set a process to prevent being injected?

As long as you understand what is "injection" and how other processes are injected, you will know how to defend. The so-called injection means that the program puts its code into the address space of another process for execution to operate the process and obtain and modify process data. Put your code into the address space of another process, so that other processes can load their own DLL, or directly create remote threads in another process address space. Process injection methods include: (1) Modify HKEY_LOCAL_MACHINE \ Software \ Microsoft \ Windows NT \ CurrentVersion \ Windows \ AppInit_DLLs, and globally inject DLL to all processes using User32.dll; (2) message hook; (3) CreateRemoteThread; (4) Fake DLL. Defense (1): Use RD; Defense (2) and (3). Access Memory and hooks are matched in AD; protection (4) can use FD to a certain extent. White + Black is also (4), but there is no good way to prevent it (do not talk about the infinite pop-up stream ).
This is my idea, and I am not very familiar with how to prevent a process from being injected (armed with the Process). It can also be equivalent to blocking all program injections (removing the later program's arm). The application configuration is as follows: * ---- (all programs) custom rules: Allow all ----- (the program can do anything) excluded from the protected file/directory ----- (the program can only do this) select the process idea you want to protect for the blocked files/folders. If the rules are not written in this way, I don't know the Learning Mode I am still using. I plan to continue using them for a week.