yashsingh1/xdaforums huggingface dataset:
[Security Discussion] Agimax:
Not only that, but those of us that have LOCKED boot loaders, can't modify a Kernel. I just want to be able to remove bloat and change system files for louder audio, tweak cpu/gpu, etc. I didn't have root on the G4 but was able to modify system files and make triggers based on the /cache directory with empty files. I could probably do the same with the G5, but i am not having luck with overwrites sticking after reboot using DrityCow.

If we could only pull a system image with DD and modify and put back with DD, i would be a happy camper.
[Security Discussion] craigrs84:
guys I can get the exploit working and overwrite a system file., but all system files seem to reset back to original on reboot, even the /system/bin/run-as file gets reset.

Is this something to do with SELinux? I've got a strong programming background but don't know as much about Linux, usually I develop on a Windows machine.
[Security Discussion] vampirefo:
It's only written in memory, nothing you do will remain after reboot, if you can get temp you, you could possibly pull boot.img and recovery.img use them to get root, provided your bootloader unlocks.

I think all the articles written about this exploit is overboard, it may be able to root at some point, but unlikely to work on many devices.
[Security Discussion] refi64:
Someone supposedly was able to get root:

[youtube]4xdMteqm994[/youtube]

but they said they won't release the code, kind of like with Rowhammer. (Of course, they could also just have been trolling...)
[Security Discussion] craigrs84:
Thanks for the clarification that makes sense now. Yea it's sort of annoying I keep reading tech articles about how ANY android phone can be rooted now because of dirtycow, but really there's no hard proof yet that anyone's accomplished it... a little misleading perhaps.
[Security Discussion] matteogeniaccio:
Here are my results so far:

I can start a root shell by overwriting dnsmasq and enabling wifi tethering

I can start android apps in a different selinux context by modifying seapps_contexts

Now I'll try patching /sepolicy on the fly to add a super permissive rule
[Security Discussion] JeffDC:
This should be an interesting post to follow... education...
[Security Discussion] idler1984:
we usually patch the permissive flag in kernel when a bug leads to kernel write.. it is interesting that how the selinux policy was patched in this case while since 6.0 there is no context can setenforce or load-policy?
[Security Discussion] Scorpius666:
Yes it has this line indeed:

dontaudit kernel self:security setenforce;

It'll be a little difficult to kill SELinux completely. But you can run restorecon in the kernel context, and you can modify the /file_contexts using dirtycow. Isn't that a very dangerous combination? ;)

EDIT: Never mind, not in >= 6.0. I think for Android >= 6.0 root can't be done and we're wasting our time here, and the video is an old Android version or just trolling.

EDIT2: But if you get u:r:kernel:s0 access you can setcon to u:r:init:s0 and then do whatever you want, right?
[Security Discussion] idler1984:
not really, saying dyntrans, execute_no_trans are also resitrcted for init since 6.0.
[Security Discussion] caqo71:
I'm wondering what [MENTION=3975929]zxz0O0[/MENTION] knows about all this.
[Security Discussion] zxz0O0:
[MENTION=3669069]idler1984[/MENTION]

Interesting. If we can get the right selinux context, we can use CVE-2016-3931 to get arbitrary kernel write.
[Security Discussion] idler1984:
From what I saw, init itself has limited access to tee_device, while zygote can only dyntrans to appdomain context which does not include any can talk directly to tee_device.

[AV] 447: ALLOW gatekeeperd-->tee_device (chr_file) [append write ioctl getattr read lock open]
[AV] 1445: ALLOW surfaceflinger-->tee_device (chr_file) [append write ioctl getattr read lock open]
[AV] 1876: ALLOW fingerprintd-->tee_device (chr_file) [append write ioctl getattr read lock open]
[AV] 2266: ALLOW vold-->tee_device (chr_file) [append write ioctl getattr read lock open]
[AV] 3171: ALLOW keystore-->tee_device (chr_file) [append write ioctl getattr read lock open]
[AV] 3376: ALLOW drmserver-->tee_device (chr_file) [append write ioctl getattr read lock open]
[AV] 3636: ALLOW init-->tee_device (chr_file) [setattr read open]
[AV] 3654: ALLOW tee-->tee_device (chr_file) [append write ioctl getattr read lock open]
[AV] 4986: ALLOW mediaserver-->tee_device (chr_file) [append write ioctl getattr read lock open]
[Security Discussion] Matt07211:
Okay, I had seen the original article earlier this week (Monday I believe), and just found this today. I just want some clarifications (just to see if I read this thread correct).

What you've achieved this far, and what is still in the way:

- your able to execute the race time condition, DirtyCow, using it to gain a "root" shell. But that root shell is under the context you've pivtitoed off (which for some people is "run-as") meaning that although you can gain a shell root in a sense you've only can do what the file context can do, so your currently trying to find a file-context with the right permissions needed to properly attain a root (probably the perferble file context will probably be the "init" or similar file-context). Any changes to the system are in memory correct, so therefor you need a root shell to be able to modify system.

- Current problems are selinux, and find a good pivot point (a good file-context on which you can get a root shell), and then using a root shell to properly modify system or patch sepolicy on the flu to allow some more freedom to gain root.

Just want clarification, so I will be able to help, without doing something that had already been done.
[Security Discussion] vampirefo:
Interesting video, he installs su zip file from data partition, that would require system remounted as rw.

Without him releasing the moo script he used, we can't confirm it.
[Security Discussion] matteogeniaccio:
Could someone check what is needed to write to /dev/socket/zygote?

Because if we can write to it, then we can start apps with a chosen uid and context
[Security Discussion] lokiu.ox:
I want to contribute, what can I do?

Is this what you need?

u0_a163@find7 ~ $ ls -lZ /dev/socket/zygote
srw-rw---- 1 root system u:object_r:zygote_socket:s0 0 1970-01-23 00:48 /dev/socket/zygote

I'm not very into Android, but from what I understand, we can't use this with dirtycow as this isn't readable, right?
[Security Discussion] matteogeniaccio:
It's not readable, but since I can now start apps with privileged permissions, i should find an executable with the permission to write that socket.
[Security Discussion] christianrodher:
guys check out this repo. He is has the most work in android dirtycow published.

https://github.com/jcadduono/android_external_dirtycow
[Security Discussion] vysea:
> /system/bin/id
uid 0
uid=0(root) gid=0(root) context=u:r:netd:s0

netd shell acquired, other services can be compromised later.

it's painful you can not remount rw /system.

hoping /system/lib/modules/*.ko can be flushed back to the disk.
[Security Discussion] christianrodher:
its that with se linux active?

can you r/w /dev/block?
[Security Discussion] Scorpius666:
That won't work on my device since netd is not readable. It looks like some devices are more secure than others.

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

Well that's a little dangerous to try on a non-rooted phone.

What this guy do is to patch app_process, that runs on the zygote context. The zygote context can setcon to system_server, and he does it. After the context transition he flashes /cache/recovery.img to /dev/block/bootdevice/by-name/recovery, and then issuing a reboot recovery command it should load the custom recovery that would allow to install the su binary.

Anybody brave enough to try it?
[Security Discussion] lssong99:
Just wonder now that we could change app_process, is it possible just install xPosed framework (manually, maybe) and use xPosed framework to avoid th3 actual need to put su into /system ?
[Security Discussion] mrmazak:
I can try it, but not for almost 10 hours before I get back to my PC. And then will need to compile and see how to activate. And probably by then someone else will have done it.

If then files are already compiled and I can download them right when I get there it will speed it up.
[Security Discussion] zxz0O0:
How about overwriting mediaserver binary and using a DoS exploit to crash it and force a restart of mediaserver?
[Security Discussion] vampirefo:
Would not be a good ideal, now if the script instead of flashing recovery.img and or boot.img dd them to sdcard, this would be great.

Blindly flashing a recovery.img on an unrooted phone with bootloader locked, would most likely software brick the phone.

You are free to try, even if it worked, which I doubt still isn't that great, seeing the device has already been rooted at least once, that's how the recovery was made in the first place.

That's why creating a file that can pull a recovery.img or boot.img from an unrooted device is way more valuable.
[Security Discussion] mrmazak:
This is my testing phone and I have it rooted and unlocked

And full package to spft flash it back if it goes south

I think I am missing something you said there. Blindly flashing some recovery. From the .c file it reads that the recovery file is coming from tje sdcad, so you would have to have a recovery file for your phone loaded onto the sdcad in order for it to be flashed. As long as I read that part right.
[Security Discussion] Scorpius666:
You read it right. It patches two files: applypatch and app_process. You aren't supposed to execute any of the files, just patch them and wait looking at the logcat.

The patched app_process will spawn if you unlock the screen of your phone for example. You'll see it running as zygote then transitioning to system_server. It will copy the recovery.img from the sdcard to /cache. Then it will change a property using the property service to start a flash recovery service.

The flash recovery service calls install_recovery.sh, and this will call applypatch, that you patched. This will read /cache/recovery.img and copy it to the recovery partition.

This would make the phone unusable through the GUI (black screen and non responsive since you killed the real app_process) but the phone will work through the shell just fine. After it finishes just type reboot recovery and that's it. Don't freak out if the phone is not responding through the screen: it is expected.
[Security Discussion] craigrs84:
silly question, i'm just trying to experiment and learn new things here.

the original run-as command reads from the file /data/system/packages.list.

I was just trying to duplicate this in my own c code but I don't seem to have permission to open /data/system/packages.list even after replacing run-as with the dirty cow exploit. it always fails to open this file when run this code:

int fd = open("/data/system/packages.list", O_RDONLY);

if (fd < 0)

{

printf("%s\n", "OPEN FAILED"); //THIS IS ALWAYS PRINTED (IT ALWAYS FAILS)

}

So my question is, why can the original run-as command read from /data/system/packages.list but my replacement run-as cannot? I know it's not required to read from that file for what we're doing but was just curious. Why the apparent difference in permissions if I've replaced the original file? Why can original run-as open /data/system/packages.list but my replacement cannot?
[Security Discussion] vampirefo:
That is my point, the phone what ever phone that uses that exploit has already been rooted before, so not that impressive.

Had that device never been rooted before, the recovery flashed, would be blind.

It's nothing more than a recovery flasher.

Take a device that has never been rooted, no root or recovery for this device.

How does flashing a recovery on it helps?

Where did the recovery come from? How was it packed? How was the packing determined?

How ever a device that has been rooted, already has a recovery, don't really no need for an exploit to flash a recovery.

Again if the exploit can be changed from flashing to dd, it would be great, as is useless to most people.
[Security Discussion] Scorpius666:
The original run-as executable transitions from the runas context to the appdomain context.

If you have any doubt read the audit entries from your logcat and check your .te files.

---------- Post added at 12:49 PM ---------- Previous post was at 12:48 PM ----------

It works on devices that could be rooted once, but after an update you couldn't root them anymore. Like the Moto G4 for example.

Remember that with a custom recovery you can do whatever you want, including install a su binary, with no need to unlock the bootloader.
[Security Discussion] Unjustified Dev:
I can answer that. For the ZTE Axon 7 we didn't need the original recovery. On Qualcomm devices most of the offsets and partition sizes for boot and recovery are the same. He tested it on a msm8996 snapdragon 820 device. How I did it was ZTE gave us the kernel source and I compiled the recovery using that. So technically you don't need to obtain a stock image. In this case they provided fastboot flash but there was no root method to obtain stock recovery or boot image. I'd have to assume the device he used had kernel source, but your right it's still blind. The partition sizes could be wrong etc. But once you get recovery booted you would be able to go back and fix those afterwards.
[Security Discussion] Scorpius666:
You can easily change the current approach to extract the stock recovery instead of flashing a new one on it. It's trivial, is just changing one line of code or two. Is that what you're talking about?

I feel lost now.
[Security Discussion] another_uncreative_name:
Sorry if this is a bit off topic, but do you think a similar method should work for the ZTE Zmax Pro?
[Security Discussion] vampirefo:
If that can be done, it would be great.

---------- Post added at 02:24 PM ---------- Previous post was at 02:21 PM ----------

Yes, if kernel source is available, most devices that don't have root, don't have kernel source available.

If the exploit pulls the recovery.img and or boot.img it makes root much more possible.
[Security Discussion] pvineeth97:
I tried to run the dirtycow.c and run-as.c file given in the github. I got "uid=0". But when I type "id" I get "uid=2000".

Any way to root the phone? :)
[Security Discussion] vampirefo:
You need to compile them, I don't see anywhere that root is confirmed, perhaps they are getting close.

Flashing recovery.img has been confirmed, but you need a kernel be it stock or custom to use that method.
[Security Discussion] mrmazak:
Now I get it. You have good point. DD the the original onto sdcad so you can get ram disk out and then make the recovery from it and then do this to install it. Very good idea
[Security Discussion] vampirefo:
I have an Intel that I would like to root, no kernel source, so I need a method to pull boot.img or recovery.img from it.

Repack flash and have root.

I hope something can be done via dirtycow exploit, that makes this possible.
[Security Discussion] pvineeth97:
I have the kernel for the phone. I mean it was for Android 5.0.2. Will it work?
[Security Discussion] acejavelin:
If you can get TWRP to start, couldn't you use the forced systemless method to root, it modifies the existing boot.img to root, before flashing SuperSU, go to Advanced - Terminal and enter:

echo SYSTEMLESS=true>>/data/.supersu

Then flash SuperSU.

Just a thought.
[Security Discussion] matteogeniaccio:
I'm sharing with you my dirtycow code.

It's faster and supports loading from file even if it spawns multiple pages.

It skips blocks that are already the equal, so it's useful for making small changes to existing files.
[Security Discussion] pvineeth97:
For root?
[Security Discussion] matteogeniaccio:
No, just for writing read only files.
[Security Discussion] vampirefo:
I am not aware of a way to launch twrp without a kernel.

Twrp is the ramdisk part of recovery.img, I need a kernel to go with twrp, if I had a kernel, I wouldn't even need this exploit, I would simply flash twrp via fastboot.
[Security Discussion] beziarum:
excuse me, I'm new here but why we can't add in /fstab a line to mount sdcard with exec and suid enabled, then upload su in the sdcard ? In my system it can be read by everyone
[Security Discussion] matteogeniaccio:
You can easily remount the sdcard by overwriting /system/bin/sdcard.

The problem is a security feature called SElinux that prevents apps from executing operations that aren't explicitly enabled by the policy
[Security Discussion] Scorpius666:
That will never work. Everything under the sdcard belongs to the SELinux context u:r:sdcardd:s0 and you can't even execute a file even if you remount it with exec and suid.
[Security Discussion] acejavelin:
Sorry, I misunderstood.... I thought you had working twrp. My bad
[Security Discussion] vampirefo:
No if I had a working twrp, I would already be rooted.

I have tried every dirtycow I could find so for none can copy a file to my Intel.
[Security Discussion] acejavelin:
Sorry... I misread your post, didn't mean to get your hopes up.
[Security Discussion] vampirefo:
It's not you, it's the media that advertise this exploit as being able to root ever android when in fact it roots none lol.

So far this exploit is a complete waste of time.
[Security Discussion] cloud1250000:
Hi guys,

The guy that patched applypatch and flashed recovery.img was working on an unlocked device. Unfortunately, his device doesn't have any useful fastboot function (like flash? ahah) so he had to do it that way.

http://xdaforums.com/showpost.php?p=69312919&postcount=148

So don't use this if your device is still locked.

This variant of dirtycow claims it's bypassing selinux (which is blocking us from doing anything)

https://github.com/scumjr/dirtycow-vdso

is it possible to adapt it for android?
[Security Discussion] refi64:
The payload and the prologues seem to be written in x64 assembler, so someone with good knowledge of ARM assembly (a.k.a. not me :() could probably make it work.

---------- Post added at 07:38 PM ---------- Previous post was at 07:35 PM ----------

As a mostly unrelated note, I'm trying to see if I can use this to get stuff like DSP Manager running on un-rooted Android. Probably not going to work, but it's worth a try.
[Security Discussion] Honestly Annoying:
shell@p1:/data/local/tmp $ ./dirtycow /system/bin/dnsmasq ./sh

load destination error

Why does this happen?
[Security Discussion] vampirefo:
cd /data/local/tmp
[Security Discussion] Honestly Annoying:
Now I just get

shell@h1:/data/local/tmp $ ./dirtycow /system/bin/dnsmasq ./sh

mmap ffffffffffffffff

0 0

shell@h1:/data/local/tmp $
[Security Discussion] vysea:
uh... my netd is not readable too.

the reason I take down netd is I want to gain read permission of all 771 files, then i can dirtycow other binaries in easier way.

dirtycow those read only binaries is annoying, glad I had only to break one (netd).

---------- Post added at 11:19 AM ---------- Previous post was at 11:17 AM ----------

I'm trying to take vold down, which seems can mount rw system

---------- Post added at 11:22 AM ---------- Previous post was at 11:19 AM ----------

similar way of how I take down netd
[Security Discussion] freddierice:
don't waste your time -- vold does not have access to /system.

---------- Post added at 04:30 AM ---------- Previous post was at 04:26 AM ----------

(wow that came out blunt. sorry. I tried vold and there are explicit policies against its use with /system and other key devices.)
[Security Discussion] vysea:
tried su -cn vold context in cm 13, mount rw is work, not sure about the policy in other models
[Security Discussion] Yattaze:
ROOT

I've Managed to spawn a root shell on my phone using the dirty cow exploit so I'm working on persistent root
[Security Discussion] Apology11:
Can you explain how you managed to spawn the roor shell?

Gesendet von meinem UMI_SUPER mit Tapatalk
[Security Discussion] freddierice:
I'm pretty close (I think) to pulling a recovery image from my phone. How can I get init to run app_process64? Its the only part I need working.
[Security Discussion] idler1984:
In fact if we have control over init, we can kill any process we like directly.
[Security Discussion] christianrodher:
was anyone able to compile recowvery-app_process64.c?
[Security Discussion] cloud1250000:
http://xdaforums.com/showpost.php?p=69312919&postcount=148
[Security Discussion] zxz0O0:
True but first you need to find a way to get init context. Or is there?
[Security Discussion] norberto_:
Hi guys,

Could this help?

https://gist.github.com/Arinerron
[Security Discussion] vampirefo:
Looks good, I don't have computer so viewing from phone, root.sh looks interesting.
[Security Discussion] refi64:
`root.sh` just seems to be a script that runs `make root` in the CVE repo.
[Security Discussion] matteogeniaccio:
I patched adbd so it runs as root without dropping privileges. when i spawn a shell, it still runs as id shell and not root. What to do now?
[Security Discussion] Termich:
Anyone managed to compile for armeabi-v7a phones?
[Security Discussion] norberto_:
It creates a binary called 'run-as' that can execute packages as root according to the author.

first comment under the script.

https://gist.github.com/Arinerron/0e99d69d70a778ca13a0087fa6fdfd80
[Security Discussion] steppinthrax:
Hey guys you know how this would work on a LG Stylo 2 (VM Variant). Loaded with Marshmallow and locked bootloader? No way to unlock bootloader or even load to fastboot. You can load recovery and run adb commands.
[Security Discussion] jkyoho:
Another run-as uid2000 "root" samples only. NOT actually push su&supolicy/binary to system, which the ROOT Android user normally looking for
[Security Discussion] craigrs84:
There's a method named selinux_android_setcon in selinux/android.h:

https://android.googlesource.com/platform/external/selinux/+/master/libselinux/src/android/android.c

If we could somehow call the selinux_android_setcon method from our custom run-as program, would that help at all?

I've been tinkering with it but my c language knowledge is not very good and can't figure out how to reference the method.

I also noticed that the official source code for run-as says: // The 'run-as' binary is installed with CAP_SETUID and CAP_SETGID file capabilities

Does this mean there's something special about the run-as command that we can take advantage of if we overwrite it with our own version?

https://android.googlesource.com/platform/system/core/+/master/run-as/run-as.cpp
[Security Discussion] refi64:
I think that's how the DirtyCow one that flashes the recovery works.
[Security Discussion] craigrs84:
Yea I guess then that my main question is can we call selinux_android_setcon to change the selinux context? I don't think the current dirtycow exploit does anything like that (if it's even possible).
[Security Discussion] refi64:
Looks like it:

https://github.com/jcadduono/androi...lob/android-6.0/recowvery-app_process64.c#L87

I'm just not sure exactly how that context works. All the author is using it for is to flash the recovery image, which leads me to believe it's still restricted in some way, but maybe less restricted?

---------- Post added at 01:52 PM ---------- Previous post was at 01:50 PM ----------

Actually, the context it's using *is* restricted: http://xdaforums.com/showpost.php?p=53857471&postcount=16

The author says:

I'm confused though as to how this works, then, since in the example code, it actually opens a file in order to copy it.
[Security Discussion] jkyoho:
with bootloader locked, even flashed recovery.img on top won't boot up the phone. AFAIK

why not just try "adb push" su binary to system/bin w/ modfied run-as
[Security Discussion] craigrs84:
Thanks, I was looking a different version of the CVE code that didn't have that line in it where it calls "setcon".

I'll check it out.
[Security Discussion] refi64:
FYI, some progress is being made here: https://github.com/timwr/CVE-2016-5195/issues/9