DANGEROUS: This tool is issuing commands as an extremely privledged root + context

This tool issues root commands on 64bit Android 6.01 dirtycow vulnerable devices. It does so without verifying anything. It will write whatever you tell it to write without even blinking!! My advice would be DON'T be a pioneer with my tools, ever!

 ------------------ True authors of this code are as follows ---------------------

---

github.com names: timwr -- dirtycow exploit, nothing would be possible without this first jcadduono -- Android genius we all took things from his code freddierice -- designed the exploit we are using the above resources, thanks buddy

Main coders: Delgoth -- Greyhat Rooting Project droidvoider -- Greyhat Rooting Project

consultants JeSTeRH4CK3D

---

------------------ Android dirtycow Greyhat Root Project -- Root Console---------------------

This tool issues root commands on 64bit Android 6.01 dirtycow vulnerable devices. It does so without verifying anything. It will write whatever you tell it to write without even blinking!! My advice would be DON'T be a pioneer with my tools, ever!

This exploit gains root + install_recovery in one loop then root + system_server in the other. Using a list of commands in a text file it will execute commands using those privledges. It executes line by line in consecutive order and using identifiers it will execute the desired command using one of the two available contexts.

If the exploit requires a file it needs to be copied to cache by another supporting process we call bridge. bridge reads the same cmd_list.txt file to know what to copy, it ignores the commands but instead reads the end copy commands.

We use two different methods to execute. The first method uses system() to execute the command. If the system(command) fails we then process the command line for execv() and try again. In some cases this is necessary, execv doesn't return and we currently do not test the status.

---

BASIC INSTRUCTIONS: This tool uses a text file to determine what commands to issue along with which supporting files to copy and where. I included an example cmd_list.txt used with an AT&T Note 5. (root and at&t note 5 just went together in a sentence. im possible)

yes, there is an intentional error in cmd_list.txt to show the execv() attempt. note: install_recovery context most powerful when calling .sh script in /system/bin/

######UPDATED: May 06 2017 lots of additions to Makefile!

sorry the Android 5.11 sections are not finished, take sections from Android 6.01..

####/system/bin/screencap is patched to be dirtycow

screencap is patched to be dirtycow so you can patch files using system_server or install_recovery An example of that is included.. It is patched back on program exit

1. create the following file ---> /data/local/tmp/cmd_list.txt
**Line Separators** All command lines will have these, or it will fail. **(spaces on command line only)**
``
**Context is the first entry** 
(we have two loops install_recovery and system_server)
u:r:system_server:s0#<command>#
u:r:install_recovery:s0#<command>#
``
**execution line between hash symbols #/path/command args1 args2 args3 args4#**
**#**  <--- entire command including binary path ---> **#**
``
example command:
u:r:system_server:s0#pm disable com.ws.dm#
another example command:
u:r:install_recovery:s0#/system/bin/mount -o rw,remount,rw /system#
``
2. place any supporting files into ---> /data/local/tmp/Superuser.apk
**Copy Line Separators** Copy lines must be at the end of "a" command line, inspecific.
**~** <--- source ---> **~** <--- destination ---> **~**
example system server WITH SUPPORTING FILES command
#/system/bin/pm install /cache/recovery/Superuser.apk#~/data/local/tmp/Superuser.apk~/cache/recovery/Superuser.apk~

3. **restart services** -- needs debugging
`adbd at the end of the first command like will reset adbd
you can add more services to restart, no gaps, start at line 1 and go down
``
example with two commands:
u:r:system_server:s0#pm disable com.ws.dm#`adbd
u:r:install_recovery:s0#/system/bin/screencap /cache/recovery/adbd /sbin/adbd#~/data/local/tmp/adbd~/cache/recovery/adbd~
``
you can add anything you want it will try to stop/start it.
4. By script or by hand. Place farm, till, toolbox, bridge, cmd_list.txt and any supporting files into
/data/local/tmp/

5. By script or by hand open an extra terminal for logging. adb logcat | grep -a GRP_Root_Kit

6. adb shell /data/local/tmp/farm

7.  Add and remove a screen lock pin. Wait between add/remove then do it again. Sometimes it happens fast, sometimes slow
(it will fire eventually see your log terminal to know.. trust me, you will get plenty of messages)

**Makefile**
If you have the Android NDK setup on ubuntu open 2 terminals, make log, make run5 or make run6

**See Makefile for basic process of how things work.
**VERY VERY IMPORTANT NOTE:**
``
###-selinux must be permissive for many actions to 'stick'
###-even though you are root and you can execute the command
###-selinux policy and libselinux.so is a great place to start
``

**LIST OF COMMANDS**

## Showing the status
```bash
make log

Running tool for Android 6.01 64 bit r1 branch

First, you must edit cmd_list.txt and carefully confirm the commands are correct and as desired!

make run6

Running tool for Android 5.11 64 bit r2 branch

First, you must edit cmd_list.txt and carefully confirm the commands are correct and as desired!

make run5

Notes

If the log gets stuck here

GRP_Root_Kit: [*] System is exploited, will trigger on any system_server call to /system/bin/toolbox

try to get system-server to run a toolbox command. (turning lockscreen on and off seems to work for galaxy s7 active and galaxy Note 5).

Updated for Note5: Playing with power + vol. up + vol. down makes the script fire!!!

Screen dim: power to undim, swipe unlock (no pin), now: power + vol. up, power + vol. down and then power to dim.. Now: power + vol. up to undim, power to dim
(keep messing with the buttons, dim/undim and it fires easily) -- no need to mess with screenlock for me **Android 6.01 Oct 2016 security**

## Notes from original creator
freddierice on github original concept. I have reworked it a lot.
his todo list ---> "* fix for armeabi? doesn't seem to work for this architecture right now."
not a bad idea....

## Help/Sources
* https://github.com/freddierice/farm-root for original code structure for this exploit
* https://github.com/timwr/CVE-2016-5195 for dirtycow exploit.
* https://github.com/jcadduono/android_external_dirtycow for some SELinux context ideas


<LOCALTEST> --- currently removed I may put this back later if we are having issues.
**LOCAL TEST WILL EXECUTE ALL COMMANDS THRUGH FARM.C FROM DIRECTORY /DATA/LOCAL/TMP**
1. Edit Android.mk
2. Add -D LOCALTEST to LOCAL_MODULE := farm like this --> LOCAL_CFLAGS    += -fPIE -DDEBUG -D LOCALTEST
See example file I renamed --> LOCALTEST-Android.mk
open 2 terminals, make log, make run