How do you spawn a shell after exploit?

[naikel]

I've tried execpl, system, even executing chmod(const char *pathname, mode_t mode) in the code but nothing seems to work.

I do get getuid() == 0, but I can't do anything with that privilege.

EDIT: My device does NOT have /system/bin/run-as with setuid and I have seen NO device that has it set.

[ghost]

@Manouchehri im gonna keep trying to dirtycow in adbd... i need to find path that it writable by run-as (root) and by shell

[Manouchehri]

It doesn't need to be writable, dirtycow only needs read access.

[ghost]

@Manouchehri i mean writable by shell and readable by run-as (root)

[Manouchehri]

It doesn't need to be writable by either.

[ghost]

i need to upload you adbd somewhere with shell that run-as-root can read it. lol that is what i mean

[Manouchehri]

/system/vendor/pittpatt/models/recognition/face.face.y0-y0-71-N-tree_7-wmd.bin

Found with find /system -size +350k.

[NTT123]

I'm currently able to run arbitrary code under the init process. The idea is to modify the signal handler function of init using dirtycow from root user.

Is that possible to disable SELinux from the init process?

[naikel]

Look at this, from app_process32, setcon to system_server, shell through tcp_socket:

> id
uid=0(root) gid=0(root) groups=0(root) context=u:r:system_server:s0
> insmod ./dma_test.ko
> lsmod
Module                  Size  Used by
dma_test               13157  0
wlan                 3711716  0
touchx                 20406  0
>

If we can insmod, can we do something?

EDIT: From the run-as context this wasn't possible to me, but can do it easily through the system_server context.

[chaosmaster]

@Manouchehri I tried overwriting adbd which just kills adb untill reboot. I have compiled one myself with modifications to keep it from dropping priviledges. My version is larger then the original adbd which could be the problem. I can't use your version either since I need arm64. Could you build an arm64-version which is less than 462840 bytes? (I wasn't able to)

@naikel this looks promissing, care to share the code? As for the insmod take a look at my module https://github.com/chaosmaster/ford_selinux_permissive to set selinux to permissive (I wrote it for the Amazon Fire, maybe we can modify it)

[naikel]

@chaosmaster it's a modification of the recowvery-app_process64 using some code from XDA to spawn a shell using TCP sockets and lsh as a shell ( https://github.com/brenns10/lsh )

Here it is: http://pastebin.com/3eU1eVYa

Keep in mind you need to modify NDK to be able to compile these things. That is pulling libselinux.so and libcutils.so from your phone, and getting the include files you are missing from the Android source and putting them in the right platform directory in your NDK.

[ghost]

@naikel does it works? how was you able to compile recowvery-ap_process64? i put the selinux and cutils in the includre folder and kee getting getcon setcon errors.

[naikel]

Don't forget to modify your Android.mk with:

LOCAL_LDLIBS := -llog -lselinux -lcutils

And pull libselinux.so and libcutils.so from your device since the NDK won't have them.

[ghost]

how do l make android.mk compile just for my Arch? ohhh im missing libselinux.so and libcutils.so .

[refi64]

@christianrodher

libselinux.so and libcutils.so

scrolls up to post by @naikel

And pull libselinux.so and libcutils.so from your device since the NDK won't have them.

[ghost]

ya... that shell give full temp root?

[naikel]

@christianrodher yes but your phone GUI will be non-reponsive while you have root until you reboot (black screen and no buttons will work).

[ghost]

yea... but you can remout and install su and then reboot right? so thats perfect.

[naikel]

@christianrodher No, hehehe. We haven't found a solution yet. We are still doing baby steps. We are not able to remount or to write any file to any location in the file system.

But disabling SELinux will be a BIG step.

[jfranchetto]

@naikel Which header file did you use for selinux? I keep getting errors on missing getcon/setcon even though they are in the header I have. I've just put the headers in folders within the directory that holds the app_process code but I've had no luck building it

[naikel]

@jfranchetto are you getting compiling errors or linking errors? Are you linking to libselinux.so and libcutils.so? Have you pulled those two files from your device and put them in your toolchain? Read my posts about it.

[rhcp011235]

Why just fork this and push the changes which makes this work to another git? Or put in pull requests for this to build and work? Much easier than all this

[naikel]

Because there are just trivial changes in the files. The big change is in the NDK, and that's where most people gets stuck...

[jfranchetto]

@naikel Looks like linking errors. Linking to the two files I pulled from my device and put them in what I believe to be the right spot in the toolchain. Seems like its finding them but giving an 'Access is denied' error when linking

EDIT: Got it sorted out

[ghost]

im still getting errors...@naikel what build linux are you using.. android ndk version and selinix.h gutils versions.... this is pissing me off.

[naikel]

@christianrodher show me the errors. Since my device is 6.0.1 I'm using the selinux and cutils headers from that version directly from android.googlesource.com. It's not hard it worked at the first try. I copied libselinux.so and libcutils.so to platforms/android-21/arch-arm/usr/lib and added the libraries to the Android.mk file to all the files and that's it.

[baselsayeh]

@naikel how did you got system_server context? after replacing /system/bin/app_process64 what to do to make the system executes it? (replaced with lsh that you provided)

[naikel]

@baselsayeh Pressing the power button on the phone will execute app_process64 by root. Just press any button or try to do anything. Remember to look at the logcat.

[baselsayeh]

@naikel I can't get it to work my compiled binary size is:5,960 bytes as soon as dirtycow finishes, the phone would restart

[naikel]

@baselsayeh too bad! what phone is it? that executable sounds a little tiny. I don't have a 64 bits phone, and my app_process32 replacement is around 17K. Try to modify it a little bit to run it as shell to see at least that it works spawning a shell through a TCP socket. After you got something that is working then replace the original.

[naikel]

Everybody is like too excited with the system_server root but I don't know if you really understand that we can't still do anything with that root. No remounts, no write files, obviously can't install su and stuff like that... So far is... nothing.

[baselsayeh]

@naikel spawning a shell through a TCP socket works but it worked once when the phone was booting and i got shell but for a very short time before the phone restarted Huawei p9 EVA-L19 android M

[naikel]

@baselsayeh no clue. My phone becomes unresponsive with a black screen, but I'm still logged in with the adb shell, I can do adb push/pull/logcat and also can telnet to it and use the system_server shell. I don't really know why your phone reboots.

[Manouchehri]

@chaosmaster What devices do you have?

@baselsayeh You sure it's actually rebooting? No visuals != rebooting.

[baselsayeh]

@Manouchehri Yes, Rebooting into EMUI recovery

[naikel]

@baselsayeh haha are you calling the flash_recovery service from your app_process64? you shouldn't unless you want to do something there, or with applypatch.

I hope you know what you are doing. Read the source codes of the files to know what you are going to achieve. Just don't play with them blindly.

[baselsayeh]

@naikel No Just a normal tcp shell from http://pastebin.com/3eU1eVYa but ignore anything above (LOGV("About to fork a shell");) http://forum.xda-developers.com/showpost.php?p=69299542&postcount=39

[jfranchetto]

I've been trying on an older S4 device with Android 4.4.2, and there is only app_process on this device (no 32/64).

I was able to build an app_process similar to yours that just starts a shell on that port so I can Netcat to it. I can also replace the one in /system/bin with my version, but it seems like there's no way to get it started again (buttons, etc don't work) and running it manually segfaults immediately. I'll have to give it a shot on a 6.0 device when I get a chance.

I'm curious, with this root shell are you able to dd with busybox?

[baselsayeh]

@naikel http://pastebin.com/raw/ZaqLxZ1p

with this my phone wont reboot but also wont start a tcp shell

[naikel]

@jfranchetto no, you can't read block devices from system_server. You could try from the recovery context (patching applypatch) and start a recovery, but the recovery context can't create TCP sockets, nor files! so basically you can read the block but can't write the result anywhere.

[naikel]

@baselsayeh DO NOT FORK!!!!!

Delete these lines:

    int newpid = fork();
    if(newpid != 0)
            return 0;

[baselsayeh]

@naikel what do you mean?

[refi64]

@naikel What do you mean when you say:

You could try from the recovery context (patching applypatch) and start a recovery, but the recovery context can't create TCP sockets, nor files!

I have an idea, but it's probably stupid, so I'm asking first...

[naikel]

@kirbyfan64 The idea is to use this project: https://github.com/jcadduono/android_external_dirtycow

And modify applypatch that, instead of flashing something in the recovery partition, reads the boot partition.

If you somehow are able to extract it (maybe copy to /cache, then using app_process again to read that file and put it somewhere else) and you think that if you can modify it you gain something, then you can use dirtycow inside applypatch to modify the boot.img, since applypatch only has read permissions on that partition, and read/write permissions on the recovery partition.

That's a lot of work but maybe you're able to do what you want (whatever that is).

[refi64]

@naikel Oh, actually I was asking how you got into the "recovery context"...

[naikel]

@kirbyfan64 read the project android_external_dirtycow. Basically you replace app_process and from that setcon to system_server, change system property via property service and start the recovery service, this will launch install_recovery.sh (which you can't access) and inside that script (if you read it in the Android Source website) it will call applypatch in the recovery context.

[baselsayeh]

@jfranchetto try running it normally before replacing with dirtycow

@naikel i debugged the problem and it's : 'no socket' what can i do?

[SquallATF]

@naikel I have trying replace app_process64 but crash

                                    --------- beginning of crash
10-29 10:05:23.375 3119-3540/? A/libc: Fatal signal 4 (SIGILL), code 1, fault addr 0x55692bca7c in tid 3540 (system_server)
10-29 10:05:23.431 2666-2666/? D/clmlib: Got activities:0x00000003
10-29 10:05:23.435 2666-2666/? A/DEBUG: *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
10-29 10:05:23.435 2666-2666/? A/DEBUG: UUID: 3879beb9-d548-4771-b221-fa446b669426
10-29 10:05:23.435 2666-2666/? A/DEBUG: SystemDump: requested
10-29 10:05:23.435 2666-2666/? A/DEBUG: Build fingerprint: 'Sony/F8132/F8132:6.0.1/35.0.A.1.282/1826537266:user/release-keys'
10-29 10:05:23.435 2666-2666/? A/DEBUG: Revision: '0'
10-29 10:05:23.435 2666-2666/? A/DEBUG: ABI: 'arm64'
10-29 10:05:23.436 2666-2666/? A/DEBUG: pid: 3119, tid: 3540, name: system_server  >>> system_server <<<
10-29 10:05:23.436 2666-2666/? A/DEBUG: signal 4 (SIGILL), code 1 (ILL_ILLOPC), fault addr 0x55692bca7c
10-29 10:05:23.507 2666-2666/? A/DEBUG:     x0   0000007f8231bd80  x1   0000000000000000  x2   0000007f8231bd88  x3   0000007f8231bf74
10-29 10:05:23.507 2666-2666/? A/DEBUG:     x4   000000000000000f  x5   0000000000000030  x6   0000007f844efa34  x7   0000000000000021
10-29 10:05:23.507 2666-2666/? A/DEBUG:     x8   0000007f8450a5f0  x9   0000007f845444b8  x10  0000000000000002  x11  0000000000000001
10-29 10:05:23.507 2666-2666/? A/DEBUG:     x12  0000000000000001  x13  000000000000036c  x14  0000000000000048  x15  0000007f84508000
10-29 10:05:23.507 2666-2666/? A/DEBUG:     x16  0000007f9f4e4d60  x17  00000055692bca7c  x18  0000007f95aa9ba0  x19  0000000000000003
10-29 10:05:23.507 2666-2666/? A/DEBUG:     x20  0000000000000003  x21  0000007f84508000  x22  0000007f8231bf80  x23  0000000000000042
10-29 10:05:23.508 2666-2666/? A/DEBUG:     x24  0000000000000018  x25  0000007f8450a380  x26  0000007f8450a3e0  x27  0000000000000003
10-29 10:05:23.508 2666-2666/? A/DEBUG:     x28  0000007f8471e400  x29  0000007f8231bd40  x30  0000007f9f429048
10-29 10:05:23.508 2666-2666/? A/DEBUG:     sp   0000007f8231bd30  pc   00000055692bca7c  pstate 0000000060000000
10-29 10:05:23.510 2666-2666/? A/DEBUG: backtrace:
10-29 10:05:23.510 2666-2666/? A/DEBUG:     #00 pc 0000000000002a7c  /system/bin/app_process64
10-29 10:05:23.510 2666-2666/? A/DEBUG:     #01 pc 000000000001c044  /system/lib64/libc.so (sigsetjmp+20)
10-29 10:05:25.111 2666-2666/? A/DEBUG: Tombstone written to: /data/tombstones/tombstone_05

[ghost]

@naikel im home Im using android-ndk-r13. Extracted the libcutils.so libselinux.so from my phone and i put them in ..../android-21/all six folder arch/usr/lib and selinux and cutils .h files in /android-21/all six folder arch/usr/include

Android.mk file

LOCAL_PATH := $(call my-dir)

include $(CLEAR_VARS)
LOCAL_MODULE := dirtycow
LOCAL_SRC_FILES := \
    dirtycow.c
LOCAL_CFLAGS += -DDEBUG
LOCAL_SHARED_LIBRARIES := liblog
LOCAL_SDK_VERSION := 21
LOCAL_LDLIBS := -L$(SYSROOT)/usr/lib -llog
include $(BUILD_EXECUTABLE)

include $(CLEAR_VARS)
LOCAL_MODULE := cow-run-as
LOCAL_MODULE_FILE := run-as
LOCAL_SRC_FILES := \
    run-as.c
LOCAL_SDK_VERSION := 21
LOCAL_LDLIBS := -L$(SYSROOT)/usr/lib -llog
include $(BUILD_EXECUTABLE)

include $(CLEAR_VARS)
LOCAL_MODULE := cow-exec
LOCAL_SRC_FILES := \
    cow-exec.c
LOCAL_CFLAGS += -DDEBUG
LOCAL_SHARED_LIBRARIES := liblog
LOCAL_SDK_VERSION := 21
LOCAL_LDLIBS := -L$(SYSROOT)/usr/lib -llog
include $(BUILD_EXECUTABLE)

include $(CLEAR_VARS)
LOCAL_MODULE := recowvery-applypatch
LOCAL_SRC_FILES := \
    recowvery-applypatch.c
LOCAL_CFLAGS += -DDEBUG
LOCAL_SHARED_LIBRARIES := liblog
LOCAL_SDK_VERSION := 21
LOCAL_LDLIBS := -L$(SYSROOT)/usr/lib -llog
include $(BUILD_EXECUTABLE)

include $(CLEAR_VARS)
LOCAL_MODULE := recowvery-app_process64
LOCAL_SRC_FILES := \
    recowvery-app_process64.c
LOCAL_CFLAGS += -DDEBUG
LOCAL_SDK_VERSION := 21
LOCAL_LDLIBS := -L$(SYSROOT)/usr/lib := -llog -lselinux -lcutils
include $(BUILD_EXECUTABLE)`

dk-build NDK_PROJECT_PATH=. APP_BUILD_SCRIPT=./Android.mk APP_PLATFORM=android-21
make[1]: Entering directory '/root/Desktop/android_external_dirtycow-android-6.0'
Android NDK: WARNING:Android.mk:recowvery-app_process64: non-system libraries in linker flags: -lselinux -lcutils    
Android NDK:     This is likely to result in incorrect builds. Try using LOCAL_STATIC_LIBRARIES    
Android NDK:     or LOCAL_SHARED_LIBRARIES instead to list the library dependencies of the    
Android NDK:     current module    
Android NDK: WARNING:Android.mk:recowvery-app_process64: non-system libraries in linker flags: -lselinux -lcutils    
Android NDK:     This is likely to result in incorrect builds. Try using LOCAL_STATIC_LIBRARIES    
Android NDK:     or LOCAL_SHARED_LIBRARIES instead to list the library dependencies of the    
Android NDK:     current module    
Android NDK: WARNING:Android.mk:recowvery-app_process64: non-system libraries in linker flags: -lselinux -lcutils    
Android NDK:     This is likely to result in incorrect builds. Try using LOCAL_STATIC_LIBRARIES    
Android NDK:     or LOCAL_SHARED_LIBRARIES instead to list the library dependencies of the    
Android NDK:     current module    
Android NDK: WARNING:Android.mk:recowvery-app_process64: non-system libraries in linker flags: -lselinux -lcutils    
Android NDK:     This is likely to result in incorrect builds. Try using LOCAL_STATIC_LIBRARIES    
Android NDK:     or LOCAL_SHARED_LIBRARIES instead to list the library dependencies of the    
Android NDK:     current module    
Android NDK: WARNING:Android.mk:recowvery-app_process64: non-system libraries in linker flags: -lselinux -lcutils    
Android NDK:     This is likely to result in incorrect builds. Try using LOCAL_STATIC_LIBRARIES    
Android NDK:     or LOCAL_SHARED_LIBRARIES instead to list the library dependencies of the    
Android NDK:     current module    
Android NDK: WARNING:Android.mk:recowvery-app_process64: non-system libraries in linker flags: -lselinux -lcutils    
Android NDK:     This is likely to result in incorrect builds. Try using LOCAL_STATIC_LIBRARIES    
Android NDK:     or LOCAL_SHARED_LIBRARIES instead to list the library dependencies of the    
Android NDK:     current module    
Android NDK: WARNING:Android.mk:recowvery-app_process64: non-system libraries in linker flags: -lselinux -lcutils    
Android NDK:     This is likely to result in incorrect builds. Try using LOCAL_STATIC_LIBRARIES    
Android NDK:     or LOCAL_SHARED_LIBRARIES instead to list the library dependencies of the    
Android NDK:     current module    
[arm64-v8a] Compile        : cow-exec <= cow-exec.c
[arm64-v8a] Executable     : cow-exec
[arm64-v8a] Install        : cow-exec => libs/arm64-v8a/cow-exec
[arm64-v8a] Compile        : cow-run-as <= run-as.c
[arm64-v8a] Executable     : cow-run-as
[arm64-v8a] Install        : cow-run-as => libs/arm64-v8a/cow-run-as
[arm64-v8a] Compile        : dirtycow <= dirtycow.c
./dirtycow.c: In function 'madviseThread':
./dirtycow.c:50:2: warning: format '%d' expects argument of type 'int', but argument 5 has type 'size_t' [-Wformat=]
  LOGV("[*] madvise = %p %d", addr, size);
  ^
./dirtycow.c:50:2: warning: format '%d' expects argument of type 'int', but argument 3 has type 'size_t' [-Wformat=]
./dirtycow.c: In function 'main':
./dirtycow.c:136:3: warning: format '%lld' expects argument of type 'long long int', but argument 4 has type 'long int' [-Wformat=]
   LOGV("warning: new file size (%lld) and file old size (%lld) differ\n", st2.st_size, st.st_size);
   ^
./dirtycow.c:136:3: warning: format '%lld' expects argument of type 'long long int', but argument 5 has type 'long int' [-Wformat=]
./dirtycow.c:136:3: warning: format '%lld' expects argument of type 'long long int', but argument 2 has type 'long int' [-Wformat=]
./dirtycow.c:136:3: warning: format '%lld' expects argument of type 'long long int', but argument 3 has type 'long int' [-Wformat=]
./dirtycow.c:142:2: warning: format '%d' expects argument of type 'int', but argument 4 has type 'size_t' [-Wformat=]
  LOGV("size %d\n\n",size);
  ^
./dirtycow.c:142:2: warning: format '%d' expects argument of type 'int', but argument 2 has type 'size_t' [-Wformat=]
[arm64-v8a] Executable     : dirtycow
[arm64-v8a] Install        : dirtycow => libs/arm64-v8a/dirtycow
[arm64-v8a] Compile        : recowvery-app_process64 <= recowvery-app_process64.c
[arm64-v8a] Executable     : recowvery-app_process64
aarch64-linux-android-g++: error: :=: No such file or directory
/usr/lib/android-ndk/build/core/build-binary.mk:690: recipe for target 'obj/local/arm64-v8a/recowvery-app_process64' failed
make[1]: *** [obj/local/arm64-v8a/recowvery-app_process64] Error 1
make[1]: Leaving directory '/root/Desktop/android_external_dirtycow-android-6.0'
Makefile:5: recipe for target 'build' failed
make: *** [build] Error 2

[naikel]

LOCAL_LDLIBS := -L$(SYSROOT)/usr/lib := -llog -lselinux -lcutils

change to

LOCAL_LDLIBS := -llog -lselinux -lcutils

That second := is a syntax error.

You don't need to specify -L, the NDK knows where the libs are.

[ghost]

removed the rest of the stuff from android.mk.. Can you set this up to only compile to armv7. ? Still getting linker errors like my libs aren't compatible with arch64

LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := recowvery-app_process64
LOCAL_SRC_FILES := \
    recowvery-app_process64.c
LOCAL_CFLAGS += -DDEBUG
LOCAL_SHARED_LIBRARIES := liblog libcutils libselinux
LOCAL_LDLIBS := -llog -lselinux -lcutils
include $(BUILD_EXECUTABLE)

ndk-build NDK_PROJECT_PATH=. APP_BUILD_SCRIPT=./Android.mk APP_PLATFORM=android-21
make[1]: Entering directory '/root/Desktop/android_external_dirtycow-android-6.0'
Android NDK: WARNING:Android.mk:recowvery-app_process64: non-system libraries in linker flags: -lselinux -lcutils    
Android NDK:     This is likely to result in incorrect builds. Try using LOCAL_STATIC_LIBRARIES    
Android NDK:     or LOCAL_SHARED_LIBRARIES instead to list the library dependencies of the    
Android NDK:     current module    
Android NDK: WARNING:Android.mk:recowvery-app_process64: non-system libraries in linker flags: -lselinux -lcutils    
Android NDK:     This is likely to result in incorrect builds. Try using LOCAL_STATIC_LIBRARIES    
Android NDK:     or LOCAL_SHARED_LIBRARIES instead to list the library dependencies of the    
Android NDK:     current module    
Android NDK: WARNING:Android.mk:recowvery-app_process64: non-system libraries in linker flags: -lselinux -lcutils    
Android NDK:     This is likely to result in incorrect builds. Try using LOCAL_STATIC_LIBRARIES    
Android NDK:     or LOCAL_SHARED_LIBRARIES instead to list the library dependencies of the    
Android NDK:     current module    
Android NDK: WARNING:Android.mk:recowvery-app_process64: non-system libraries in linker flags: -lselinux -lcutils    
Android NDK:     This is likely to result in incorrect builds. Try using LOCAL_STATIC_LIBRARIES    
Android NDK:     or LOCAL_SHARED_LIBRARIES instead to list the library dependencies of the    
Android NDK:     current module    
Android NDK: WARNING:Android.mk:recowvery-app_process64: non-system libraries in linker flags: -lselinux -lcutils    
Android NDK:     This is likely to result in incorrect builds. Try using LOCAL_STATIC_LIBRARIES    
Android NDK:     or LOCAL_SHARED_LIBRARIES instead to list the library dependencies of the    
Android NDK:     current module    
Android NDK: WARNING:Android.mk:recowvery-app_process64: non-system libraries in linker flags: -lselinux -lcutils    
Android NDK:     This is likely to result in incorrect builds. Try using LOCAL_STATIC_LIBRARIES    
Android NDK:     or LOCAL_SHARED_LIBRARIES instead to list the library dependencies of the    
Android NDK:     current module    
Android NDK: WARNING:Android.mk:recowvery-app_process64: non-system libraries in linker flags: -lselinux -lcutils    
Android NDK:     This is likely to result in incorrect builds. Try using LOCAL_STATIC_LIBRARIES    
Android NDK:     or LOCAL_SHARED_LIBRARIES instead to list the library dependencies of the    
Android NDK:     current module    
[arm64-v8a] Compile        : recowvery-app_process64 <= recowvery-app_process64.c
[arm64-v8a] Executable     : recowvery-app_process64
/usr/lib/android-ndk/toolchains/aarch64-linux-android-4.9/prebuilt/linux-x86_64/bin/../lib/gcc/aarch64-linux-android/4.9.x/../../../../aarch64-linux-android/bin/ld: skipping incompatible /usr/lib/android-ndk/toolchains/aarch64-linux-android-4.9/prebuilt/linux-x86_64/bin/../lib/gcc/aarch64-linux-android/4.9.x/libselinux.so when searching for -lselinux
/usr/lib/android-ndk/toolchains/aarch64-linux-android-4.9/prebuilt/linux-x86_64/bin/../lib/gcc/aarch64-linux-android/4.9.x/../../../../aarch64-linux-android/bin/ld: cannot find -lselinux
/usr/lib/android-ndk/toolchains/aarch64-linux-android-4.9/prebuilt/linux-x86_64/bin/../lib/gcc/aarch64-linux-android/4.9.x/../../../../aarch64-linux-android/bin/ld: skipping incompatible /usr/lib/android-ndk/toolchains/aarch64-linux-android-4.9/prebuilt/linux-x86_64/bin/../lib/gcc/aarch64-linux-android/4.9.x/libcutils.so when searching for -lcutils
/usr/lib/android-ndk/toolchains/aarch64-linux-android-4.9/prebuilt/linux-x86_64/bin/../lib/gcc/aarch64-linux-android/4.9.x/../../../../aarch64-linux-android/bin/ld: cannot find -lcutils
collect2: error: ld returned 1 exit status
/usr/lib/android-ndk/build/core/build-binary.mk:690: recipe for target 'obj/local/arm64-v8a/recowvery-app_process64' failed
make[1]: *** [obj/local/arm64-v8a/recowvery-app_process64] Error 1
make[1]: Leaving directory '/root/Desktop/android_external_dirtycow-android-6.0'
Makefile:5: recipe for target 'build' failed
make: *** [build] Error 2