yashsingh1/xdaforums huggingface dataset:
[Security Discussion] tomtom1265:
./dirtycow.c:17:91: note: expanded from macro 'LOGV'
..."exploit", __VA_ARGS__); printf(__VA_ARGS__); printf("\n"); fflush(stdou...
^~~~~~~~~~~
8 warnings generated.
[arm64-v8a] Executable : dirtycow
[arm64-v8a] Install : dirtycow => libs/arm64-v8a/dirtycow
[arm64-v8a] Compile : recowvery-app_process64 <= recowvery-app_process64.c
./recowvery-app_process64.c:5:10: fatal error: 'cutils/properties.h' file not
found
#include <cutils/properties.h>

here is where I am at.
[Security Discussion] Geofferey:
I removed the targets for that from the Android.mk file since I didnt need it.
[Security Discussion] tomtom1265:
[MENTION=7811757]christianrodher[/MENTION] said we need them to get root shell, I found cutils/properties.h and selinux.h placed them inside same directory, now get this.

./recowvery-app_process32.c:30: undefined reference to `getcon'

./recowvery-app_process32.c:63: undefined reference to `property_set'

clang++: error: linker command failed with exit code 1 (use -v to see invocation)

I am beginning to think this is a wild goose chase, if you manage to compile this please help the community by posting a how to guide, I will do the same if I figure it out.

Would be nice if [MENTION=7811757]christianrodher[/MENTION] just posted a how to compile this thing, as he already knows how, if I get this compiled screw that other thread, I will post a how to, straight and to the point on how to compile this thing and get shell root.

I see [MENTION=7811757]christianrodher[/MENTION] had the same problem, but can't find where he posted the answer.

@naikel did you manage to compile recowvery-app_process64.c? im using android-ndk-r13 putting selinux/selinux.h in the include folder and still getting the same errors.
./obj/local/arm64-v8a/objs/recowvery-app_process64/recowvery-app_process64.o: In function main': /root/Desktop/android_external_dirtycow-android-6.0/./recowvery-app_process64.c:79: undefined reference togetcon'
/root/Desktop/android_external_dirtycow-android-6.0/./recowvery-app_process64.c:87: undefined reference to setcon' /root/Desktop/android_external_dirtycow-android-6.0/./recowvery-app_process64.c:95: undefined reference togetcon'
/root/Desktop/android_external_dirtycow-android-6.0/./recowvery-app_process64.c:121: undefined reference to `property_set'
clang++: error: linker command failed with exit code 1 (use -v to see invocation)
/root/Desktop/android-ndk-r13/build/core/build-binary.mk:715: 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

---------- Post added at 10:23 AM ---------- Previous post was at 09:59 AM ----------

Well it means until people share what they know you are out of luck, If I could compile it, you would already have it, simple as that, the people who are willing to share their knowledge don't know as much as those that don't, there are open source minded people and closed minded people. we need an open source minded person to compile this then share their knowledge we us.

The exploit is only available cause of an open source minded person.
[Security Discussion] vampirefo:
Good luck, it's unlikely that anyone will help you, as being a **** is the norm. Sure several people know what to do, yet won't help cause they got that God like rush.

---------- Post added at 10:50 AM ---------- Previous post was at 10:29 AM ----------

If you are looking for an open source guy, http://xdaforums.com/general/security/farm-root-recovery-image-pulling-t3490089

Doesn't matter if it works on your device or not, just nice to see someone trying to help the community.
[Security Discussion] kennylam:
By avoiding contexts of SELinux, I focused the binaries that related to low level file operation.

Currently I tired

/system/bin/fsck_exfat

When I dcow-ed the "fsck_exfat", and than I inserta MicroSD with 2 exFAT partation, the "fsck_exfat" will be triggered with uid=0 , but the context is limited to to the read/write operations on mmcblk.

I successed to read boot.img/recovery.img/system.img by using context of "fsck_exfat", by open()/read()/write() directly on /dev devices.

But I had no luck on write it back, dumped recovery and wrote it back, it just doesn't boot into recovery, may related to my file I/O impementation, may be the security check on my device.
[Security Discussion] tomtom1265:
Would you be willing to explain this, no one seems to want to help, just state what they can do, great for them.

A simple root shell or ability to pull recovery or boot from device is all that's needed, but to get someone who knows how to do it to explain how to do it is impossible.
[Security Discussion] kennylam:
Sure, but it is already mid-night in my time zone and the development machines and source codes are not with me right now, I hope I can share it on GitHub in daytime.

I cann't disclosure my device model, but I can say its specification instead.

Spec

SoC: QCOM Snapdragon 430 msm8937

OS: Android 6.0.1

Storage: 2GB RAM+16GB eMMC

External MicroSD card slot, hotpluggable (don't need to take battery out)

Draft step:

1. Prepare a MicroSD card with 2 partitions, the first one is exFAT, and the second one is for write(), like "dd" does, my MicroSD 16GB card is partitioned to 512MB(exFAT)+15GB, partitioned by "fdisk" on Mac OSX

2. Compiled CVW-2016-5195

3. A "fake-fsck.c" program that is used to replace "/system/bin/fsck_exfat",

setresgid()/setresuid() are not needed!

because "fsck_exfat" will be ran as root by default, and it is still readable on uid2000 , so contexts of setresgid/setresuid are no longer painful, just focus on the BLOCKS. I will release the source code once it is ready.

It is allowed from[I] scontext=u:r:vold:s0[/I] -> [I] tcontext=u:object_r:block_device:s0[/I]
[ 47.357248] type=1400 audit(1477829349.300:123): avc: granted { read open } for pid=3629 comm="fsck_exfat" path="/dev/block/mmcblk0p27" dev="tmpfs" ino=12129 scontext=u:r:vold:s0 tcontext=u:object_r:block_device:s0 tclass=blk_file
[ 47.357821] type=1400 audit(1477829349.300:124): avc: granted { read } for pid=3629 comm="fsck_exfat" name="mmcblk0p29" dev="tmpfs" ino=12137 scontext=u:r:vold:s0 tcontext=u:object_r:block_device:s0 tclass=blk_file

Since the context (I forgot the names) of "fsck_exfat" is only allowed to perform block-level actions, EVEN /data/local/tmp/ won't be writable, so you need to read() the boot/recovery partition and write() to the second partition of microSD card, it is something like "/dev/block/vold/public:166,56" on my device, didn't remember the exact value.

4. Make it on the Android device

adb push libs/armeabi/fake-fsck /data/local/tmp/fake-fsck
adb push libs/armeabi/dirtycow /data/local/tmp/dirtycow
adb shell chmod 777 /data/local/tmp/fake-fsck
adb shell chmod 777 /data/local/tmp/dirtycow
adb shell /data/local/tmp/dirtycow /system/bin/fsck_exfat /data/local/tmp/fake-fsck

This step is finished, don't manually run "/system/bin/fsck_exfat", it is not "run-as"

5. To let "/system/bin/fsck_exfat"(replaced by "fake-fsck") ran, just insert the MicroSD card prepared on Step 1, the process of a card inserted event is likely to be:

Card inserted, the system will read partition table

exFAT detected, than perform fsck_exfat before mounting

/system/bin/fsck_exfat

is ran, this is the trick

Although the above steps are quite unorganized, but I still hope that can bring some insights to those who are working on it
[Security Discussion] craigrs84:
Question for you all:

- Dirtycow exploit worked fine for me on my old, already rooted Galaxy S3 running cyanogenmod, API level 22

- Dirtycow exploit fails on my wife's unrooted Galaxy S3 running API level 18. The run-as command is not overwritten, it retains original functionality.

Any ideas why the exploit fails on the unrooted Galaxy S3? I'm mainly testing with these older devices for the time being because I don't care so much if I accidentally break them. I can go back to the already rooted S3 but really wanted to use an unrooted device for a more realistic scenario.

---------- Post added at 08:06 PM ---------- Previous post was at 07:13 PM ----------

Also, posted below is a link to my current C code that I've been experimenting with. I just threw it on Dropbox for the time being.

Some notes:

- I don't promise it will add much value :p, it's more for my own learning than anything, and not really a serious attempt...

- It doesn't seem to work consistently on all devices, doesn't work on my wife's Galaxy S5 for some reason.

- It's set up to be compiled from Windows. You only need the lastest NDK and ADB installed.

- To compile the just run "make.bat build"

- To install to your phone run "make.bat install"

- Once installed, type either "run-as pkg <package-name>" or "run-as con <context-name>"

- You can pass in a dynamic SE Linux context name, but most contexts are restricted so it's really not much help.

https://dl.dropboxusercontent.com/u/33496602/mydirtycow.zip
[Security Discussion] tomtom1265:
This doesn't work.

adb shell /system/bin/toybox nc localhost 11112
nc: connect: Connection refused

I just noticed you have r1hd phone, and possibly pissed off the guy who could have helped you root it, you need to unlock bootloader on your device, vamp knows how to do that via settings app.

---------- Post added at 04:44 PM ---------- Previous post was at 04:07 PM ----------

Anyway I still don't have root shell, but can compile recowvery-app_progress64.c, it compiles easily via cm13.

the instructions to build it are here. https://github.com/jcadduono/android_external_dirtycow

Just download android_external_dirtycow and android_external_libbootimg place both in cm13/external

example

cm13/external/dirtycow

cm13/external/libbootimg

Then start build process similar to building cm13, or twrp.

make clobber

source build/envsetup.sh

lunch cm_mydevice-userdebug

make -j5 dirtycow recowvery-applypatch recowvery-app_process64 recowvery-run-as

after they compile, you will find them in.

cm13/out/target/product/mydevice/system/bin

use adb to push to /data/local/tmp
[Security Discussion] craigrs84:
Figured out my mistake where I couldn't get the dirty cow exploit to run on some newer phones.

You have to compile dirtycow using arm64-v8a to get it to work on these phones that support 64 bit.
[Security Discussion] Root-Maniac:
I have a bone stock s7 from tmobile to test if you want once you have something. Just plugging it in and flashing the stock tmobile firmware....
[Security Discussion] xCHAOSNCx:
I have a Verizon s7e on pd2 firmware I'd be willing to test on if needed. Though you may have to guide me thru it
[Security Discussion] vysea:
fork init and execve another shell, running at u:r:init:s0.

but my device has kernel module signing enabled, but this may work on some devices to insmod a ko.

need help to shutdown selinux without another kernel exploit.

I will write some stuff on the whole.
[Security Discussion] freddierice:
How did you fork init? On my phone, it only executes under ueventd and watchdogd after the kernel runs init, and no contexts can [dyn]transition to init.
[Security Discussion] vysea:
write some thing here, may be some typos.

https://v-e-o.blogspot.com/2016/10/way-to-android-init-with-cve-2016-5195.html

not very familiar with selinux bypass, any help appreciated!
[Security Discussion] Matt07211:
Good overview of what you've done so far, probably help the other people working on it.
[Security Discussion] LLStarks:
From what I'm reading, it seems that whatever exploit path we end up with, it'll be very roundabout. I think people are just jittery over how dm-verity, selinux, knox, and general recovery-locked bootloader **** will react.

Is that a fair assessment? I don't mind doing exotic **** like 2nd init or reading from USB OTG.
[Security Discussion] freddierice:
Yes. Totally fair. I overwrote my recovery image (galaxy s7 active) and it told me something along the lines of ``**** you, I'm not booting''.

It will be along the lines of a systemless-su + re-pwn at startup.

I'm going to try taking a look at my bootloader. I really want real root. And I like the chase :p.

Nice writeup! I'm probably going to use your work to poke around next week when I have more time.
[Security Discussion] craigrs84:
anyone know where the implementation of the setcon method is in the android source code? I can't seem to find it. Just wanted to peek inside and see what it's doing.
[Security Discussion] vysea:
It will invoke SELINUX in kernel, it will check if SELINUX policy satisfied.
[Security Discussion] craigrs84:
thanks, that was my suspicion.
[Security Discussion] asusm930:
Guys, does this have any use for phones on locked BL? For my knowledge, editing things like build.prop on locked BL is useless as the phone will revert back changes on reboot. I really want this to work on my phone as I cant do jackshi* because USB to PC is broken and I cant unlock BL amd root etc. Would this be useful for my use case when it comes out? (locked BL, wanting to edit system files). From what ive read here it'll be useless because the locked BL will interfere. Don't want to get my hopes up too much :(
[Security Discussion] xCHAOSNCx:
I have a locked bootloader on my g935v and it's been rooted since the day I got it including build.prop edits the whole 9. Only thing the locked bootloader stops is flashing custom roms based off other carriers or twrp and custom kernal's.
[Security Discussion] asusm930:
thank you so.mucj
[Security Discussion] Geofferey:
You were lucky tho because you were able to flash an engineering bootloader. That's not available for every device. Those sboots allow you to have a modified boot IMG in place. On locked galaxy devices flashing a boot.img that would allow root without the sboot will definitely loop.

Rooting without modifications to the boot.img is getting harder because of Androids verified boot from. 6.0 on. With verified boot the boot.img verifies the system. Locked bootloaders can mean the boot.img also gets verified, but not always.

Worst case scenario for fastboot unlockable devices that are in a locked state...

Locked Bootloader verifies boot.img if √ boot; else no boot > boot.img verifies system > any uncorrectable errors = no boot

On a nexus 5x it verifies the boot.img always but will only display warnings locked or not so long as dm-verity is removed from boot.img. The verification of boot.img doesn't stop boot it just warns the user.

https://source.android.com/security/verifiedboot/
[Security Discussion] Agimax:
Though, you can pull a system IMG file, edit most things and them put it back with a locked bootloader. I did this on the LG G4 using DD. It's not root, but it's next best thing as I modded the shi*t out of the ROM and made UltraPOP. I'm hopping to be able to use DD and do similar on G5.
[Security Discussion] asusm930:
does this exploit have the ability to become a stand alone no pc required affair? asking because my USB port is broken lol. It charges but no detection on PC
[Security Discussion] vampirefo:
Not as of right now.
[Security Discussion] TwinAdk:
I'm following a git issue thread, and based on what they accomplish, it could be an apk solution with a server online to provided the needed files etc.

No exploit for full root exists yet (newer devices that is), but genius people are working on it! :good:

Kind Regards

Twinadk
[Security Discussion] jaykoerner:
No universal exploit exists, people have gotten root on MM/NG/LP devices, unlocked bootloaders ect... But each device has to be developed for independently, different files modified ect...
[Security Discussion] s0nik:
In theory; will this exploit work on Sealime protected devices?
[Security Discussion] Am115h:
hey guys can this exploit be used to root toshiba at300 -100.this tablet is bootloader locked maybe there is a way
[Security Discussion] TwinAdk:
Yes, and that is where the server online kicks in, supplying needed files and steps, based on the data from the device in the hand of the user. It's possible, I think it's how the approach should be - a joint effort where all methods are in a single service :good:
[Security Discussion] elliwigy:
hopefully someone can work it for us non tmo v20 users.. we get no love lol
[Security Discussion] Matt07211:
Cool, Basically like what kingoroot does. (Search the database and apply needed exploit to gain root).

With this sort of thing it will need moderation and the verification of succesfull exploits.
[Security Discussion] elliwigy:
kingroot downloads exploits for devices from the cloud.. i doubt it will work that way since if theres no exploits for your device (obviously not if trying dirty cow) then it will not have any exploits to root.

thats like saying why cant we just give supersu temp root so it can install binaries lol. doesnt work that way..

i think were better off going route of depixel8... utilizing dirty cow to somehow unlock the BL so that way we can use custom recovery and a more proper root..

some devices have dm verity so if we install any root it modifies the system and were unable to boot afterwards so wed also need a spevial root from chainfire almost on a device specific level
[Security Discussion] haxy:
A group of us are working on getting into the Honda Civic Headunit that runs android but are having trouble. The headunit blocks access to developer settings and only has two male usb ports. ADB is not running on the device. It includes a package installer app but blocks installation of apks that arent white listed. The Honda Pilot has had more success as ADB was already running but without root access. Is there any way the Dirty Cow exploit can be used without ADB? Through the built-in web browser or a USB thumb drive for example?
[Security Discussion] HuEx:
Guys .. I wanna get root Access on my LG V10 (Locked bootloader) wht should i do ?

I dont see any steps ... Yes Im a Noob ?✋
[Security Discussion] elliwigy:
if you need to ask you shouldnt bother lol you cant just "get root" easily using dirty cow.. theres a lot more to it
[Security Discussion] HuEx:
I ask for Guide i knw it requires a lot .. But didnot understand it perfectly.. So Just i wana to knw how it works in simple Way .. For sure i Knw i cant Did mine .. Btw Just wonder if i ? ..

Btw wht i understood it's Works Perfect on 4.1 And before .. But in 5,6 & 7 works but not much as The older versions of Android .. So how it works ?! And if there a Good Progress in This way ? :')

Thx in Advance :)

₪HuEx₪
[Security Discussion] vampirefo:
There is no guide dirtycow on some devices is able to copy files, doesn't root any device.

If your device can use the two current methods to get root, via dirtycow then use them, if it can't you are out of luck.

Start here.

https://github.com/bkerler/CVE-2016-5195
[Security Discussion] HuEx:
Thx ..

₪HuEx₪
[Security Discussion] DamnCampers:
I know several of you were talking about the limits of what you can do in the shells that you create. I came across this article https://www.thanassis.space/android.html about a guy that did his own root to get what he wanted. Halfway down the article he mentions sepolicy-inject. He used it to modify selinux as it was not giving him the access that he wanted to make changes while root.

Please read the main article as the author explains what he went thru in order to get the end result that he wanted. Might we be able to use the sepolicy-inject to get around selinux like he did? I'm not a developer, but I am grateful for everyone that is working on this and thought that if I can point out something that might be helpful that I should give back to everyone that has put in the hard work so far.
[Security Discussion] caqo71:
interesting, maybe [MENTION=3975929]zxz0O0[/MENTION] could check taht out.
[Security Discussion] Matt07211:
SELinux is a major problem for gaining root. As some may know, the sepolicy is located in the ramdisk which is inside the boot.img, which gets copied /system each boot. So any modification to sepolicy won't persist (which is to big a problem when only needed temporary) without a modifed boot.img.

From what I know of the current implementations of dirty cow in the forum, you are only able to modify a file that currently exist, so you can't delete/create files. If this where different you could use 2 different sepolicy injecting tools.

Sepolicy-inject, copy a file of the phone to sd card (not sure dirty cow implementations are able to do this yet), move to computer, patch and put the modifed sepolicy back.

Or Do it on the phone with chainfires supolicy tool (closed source, so not sure id legal implications when incorporated into a larger app without permission). It can be done like so (adapt code as necessary, as using adb push is used in below code, no need for root, just the 2 files (libsupol.so and supolicy binary), making sure to add "--live" instead of "--file" to patch the live sepolicy, and adding the allow rules needed.

Below code was used when I needed to patch sepolicy with chainfires supolicy tool.

adb push libsupol.so /system/lib/libsupol.so
adb shell chmod 0644 /system/lib/libsupol.so
adb push /system/xbin/supolicy
adb shell chmod 0755 /system/xbin/supolicy
adb push supolicy /data/local/tmp/supolicy
adb shell chmod 0755 /data/local/tmp/supolicy

adb push sepolicy /data/local/tmp/sepolicy
adb shell
cd /data/local/tmp
chmod 0755 supolicy
LD_LIBRARY_PATH=/data/local/tmp:$LD_LIBRARY_PATH ./supolicy --file sepolicy sepolicy_out
[Security Discussion] LaughingCarrot:
Now would this method work on phones with locked bootloaders?
[Security Discussion] Matt07211:
In theory yes, but at the moment won't work as dirty cow exploit shown in these forums are only able to modify an existing file, and they are unable to create files, therefor both the above methods of patching sepolicy files won't work (they either need some filles to be pulled, or need to place files in the system.)

Other then the practice limitations of the exploit, if you where to patch the current sepolicy file, it would only last till reboot, which is still enough for root. An example of how this is helpful; if a DirtyCow exploit is able to write/pull files they can patch the current sepolicy and "allow" their current context the permissions needed to pull partitions (e.g. boot) make the necessary changes for systemless root, and push the boot partition back into the correct area, effectively working around the problem of the locked bootloader (they are usually lock so stuff like and fastboot won't work, so yoill need a different way of flashing, I.e.DirtyCow).

This is just theory, untill someone is able to actually implement it, but it seems after the initial shock of this exploit being found that this thread has become stagnant, and I am in no position myself to build and test DirtyCow exploits.
[Security Discussion] DamnCampers:
I the article that I linked above, the author was able to dd a copy of the boot partition of his phone. He then copied it to a SD card and used the sepolicy-inject to redirect the system to use his modified selinux policy. He then had to adjust his privileges to have the enough access in order to be able to make changes.

I know that's a lot of steps, but wouldn't dirty cow allow us to make the first steps in doing the same? I know I probably glazed over some of what he did, but that is what I'm taking away from the article.
[Security Discussion] vampirefo:
You can't dd without already being rooted.
[Security Discussion] Matt07211:
There is the problem that all the DirtyCow expliots being talked about in this thread can only overwrite a file that already exist, until they can leverage a way of adding/removing a file, so until that happens it seems like trying to do something with the sepolicy file is limited.
[Security Discussion] elliwigy:
is there any write up to use dirty cow to gain a root shell via adb just so we can pull system files?