yashsingh1/xdaforums huggingface dataset:
[Security Discussion] elliwigy:
hahaha.. really? dirtycow works on lots of devices but every device varies so the same attacks will not work on every device so it can never be utilized in a one click.. you need to go post in the king root thread lol but even then they wont support your device by asking in a thread

right haha, gotta love xda
[Security Discussion] Matt07211:
[MENTION=3812611]elliwigy[/MENTION], Did you ever mange to flash to the partitions yet. Have you been able to get jucandos (not sure how to spell his name) concept of flashing recovery blindly via run-as to work?

Am interested in your progress as it seems the inital people in this thread have left.
[Security Discussion] elliwigy:
matt, if youre talking about the v20 the answer isnt simple.. we cannot use a similar script because his script is used on devices with unlocked BL.. when they unlock the BL it essentially allows them to disable selinux or at least allow their recovery to stick.. since our bls are locked, selinux is strictly enforcing so even if we did manage to flash say a recovery or kernel, selinux will revert those changes on a reboot.. this means we need a full temp adb root shell and then we need to attack selinux either if we gain access to /init or by libc.so which are both in over our heads at this point..

if we had some serious devs whod be willing to take some of the bounty from us and help us obtain root then wed be better off, until then, we are at a stand still lol
[Security Discussion] Matt07211:
I'm not sure if you quite grasp what selinux does. Think of it like a labeling system, it designates each thing with a label, and only certain labels can do certain things. If something is bypassed, it in its self doesn't have the power to do anything, it is able to hand it off to a different process, but it it's self can't do anything as it wasn't designed to do that (E.g. Flash back a boot.img)

Not sure what wrench a locked BL is.

But if you can flash a boot.img then it's game over. With a modified boot.img you can disable/modify The sepolicy file relaxing the needed rules. You can setup the boot.img for the use of systemless and use a script that is launched at start up via init.rc as root to place necessary files nedded into the System when you don't have privileges anywhere else (I did this recently to root the xcover 3, modify the boot.img to allow the use of systemless root, and to place the necessary files as needed).

So basically once you can flash the boot.img then it's game over.

I recommend trying to aim at flashing a boot.img, once that is successful you can set it up for root.
[Security Discussion] UnixSlayer:
Sent from my rooted Samsung Galaxy S7 Edge - SM-G935T
[Security Discussion] elliwigy:
would you like to join our hangouts? itd be greatly appreciated.. we do have access to init.rc just not /init

to add, the boot.img and selinux are loaded into ram at boot.. however, once it checks in the boot process itll detect a boot not matching and device will revert the changes.. however if we can reload ram without a full system crash that would be ideal..

its not so much selinux but the boot sequence in general/dm verity.. selinux would need to be bypassed or use systemless but in order to flash to certain partitions we need temp root first since the bl is locked and we do not have fastboot mode (its disabled)..

if there is a way we have debug firmware/partitions we can push without having to modify ours at all, we can just replace it sort of like eng firmware but not as good
[Security Discussion] UnixSlayer:
https://googleprojectzero.blogspot.com/2016/12/bitunmap-attacking-android-ashmem.html?m=1

Sent from my rooted Samsung Galaxy S7 Edge - SM-G935T
[Security Discussion] baselsayeh:
We already have access to system_server context via dirtycow but that is o only useful on some older devices.
[Security Discussion] Matt07211:
I only recently learnt about my current android knowledge becuse I wanted to root my xCover3, but if you want me to join your hangouts then that would be cool.

Having access to init.rc is only useful if you can modifying during buring/before boot. Once the phones booted up and everything, then init.rc becomes useless. As it's purpose is to setup the device at boot.

As you should know, the contents inside the SanDisk gets placed into the root directory ( " / " ), so that means you can place a modofef sepolicy and it will be copied over at each boot.

I belief you should target the boot.img as that is where dm-verify resides. And as you know dm-verity runsbit checks at startup do once you modify the phone you've only got till the next reboot,;before it's a) reverted, b) a warnig is thrown or c) You get locked out of the phone. So if you can flash a bootmimg you can disable dm-verity, this you don't need to worry about being locked out of the phone.

Sorry for a late replie, I typed this out vastly just now, since I just finished some work.
[Security Discussion] elliwigy:
i think theres more to it then that lol.. you use other exploit and system server launches it.. this should work on 7 woth some serious mods.. you have to look at it and see what is allowed as the attack vector might vary but yes, newer os phones are harder to break

---------- Post added at 01:07 AM ---------- Previous post was at 01:05 AM ----------

we cannot flash a boit.img since our bl is locked lol thats the whole issue and the reason we are trying to obtain a temp root shell (not a limited shell like system server)
[Security Discussion] Matt07211:
Yes I realise that you can't flash a boot.img as of yet, but saying that it should be your main goal, if you want stuff to be more permenant and to lossen then restrictions.

Did you read up about this, http://xdaforums.com/fire-tv/general/guide-rooted-fire-tv-via-dirtycow-t3489922

I believe that they managed to get a temp root shell, and worked from there.

Edit: recommend you do this, use adb push, and push chainfires supolicy tool to /data/local/tmp

Use the dumpav command incojuction with the live command, and dumps it contents into a text file that your able to have a look at and use a search function on (I.E. grep). [MENTION=3812611]elliwigy[/MENTION]
[Security Discussion] elliwigy:
we tried the ip but unfortunately ours does not have root..

pm me your gmail and ill have you added to our group
[Security Discussion] UnixSlayer:
https://source.android.com/security/verifiedboot/dm-verity.html

https://source.android.com/security/verifiedboot/verified-boot.html

https://gitlab.com/pbeeler/system_core/commit/d4cea0bc16d1ad96cc6d6177232d7b339785460c

Sent from my rooted Samsung Galaxy S7 Edge - SM-G935T
[Security Discussion] elliwigy:
lol are you just randomly posting what you find on the internet?
[Security Discussion] Matt07211:
Yes and? People already know what that are. These are well known things
[Security Discussion] BH1984:
I have an AT&T H900 6.0

I ran dirty cow and didn't get a root shell. I just want to debloat and enable WiFi tethering. It executed successfully. I was thinking I could push busybox or another command but don't know which to try again root #
[Security Discussion] elliwigy:
not sure what you mean but dirtycow by itself is useless lol... you need to find another exploit in something that has root access that can spawn a shell, compile it to do what you want (the file you are using to dirtycow) which has to be the same file that you can read in your system..

dirtycow can only overwrite files that already exist that you are able to read without your root..

for example you can overwrite sepolicy since you can read it.. you CANNOT however overwrite lets say a boot.img if you cant even read it.. you need to dirtycow lets say run-as orapp_process64 with modified versions to do something you want etc.
[Security Discussion] kryz:
Ive got permanent root in xperiaZ 5.1.1 and temp/permanent root in oppo 5.1.1 with fsck_msdos target, was not hard really.

But now i have patched init process and my code was executed by qcom-system-dae process and context u:r:qcomsysd:s0 so i have control of init but is useless.

The device is a OPPO lollipop 5.1.1 and yes there is root available im just researching.

This is because ive patched the wrong area of memory in Init or is a oem issue?

Regards
[Security Discussion] oF2pks:
Thx all, this thread is awesome, ( after "fast-reading" it, I noticed >5 github' ref ...) : is there a dirtycow.c/url compatible (no brick) with Intel Atom Z8500 (Lenovo Yoga Tab 3 Pro 10.1) lollipop' locked BL ?
[Security Discussion] acejavelin:
Dirty Cow does not work on Intel based devices.
[Security Discussion] rvyhmeister:
Am I understanding correctly that I need to be able to read the file before updating it? What I really want is to add one line to the /system/props.build file so that I can use the tethering (I have an AT&T LG G5, but am with a foreign SIM since I'm out of the US for now).
[Security Discussion] elliwigy:
you can dirtycow the build.prop but unfortunately it most likely wont help you.. the build.prop is loaded into RAM on boot so changing it will not do anything except visually change.. typically you reboot after making build.prop changes but with dmverity it will revert nback when you reboot the phone lol
[Security Discussion] rvyhmeister:
I was afraid of something like that... given dirtycow's ability to change RAM, any chance we can run something that will make it just not check that I'm on the ATT network (or make it believe I am)?
[Security Discussion] elliwigy:
you need full root or a way to "reload" the ram/build.prop without causing a full reboot
[Security Discussion] rvyhmeister:
I understand modifying the build.props is not feasible at this point... my question is: if we can overwrite memory, can we overwrite the right area so we can just get an OK for tethering? If that's not possible, too bad...
[Security Discussion] elliwigy:
not sure what you mean lol.. ram is loaded on boot, not after.. in order to have it read any changes you need a way to reload it, simple as that..

so dirtycow build.prop then find a way to reload ram without a reboot.. if you try to overwrite something the system is using it crashes since the device will be in an unstable state.. for example, if i replace init or libc.so the phone immediatley crashes completely and reboots because the system needs those to function..

the build.prop is loaded into ram on boot but if you were to somehow overwrite the RAM that is loaded itd most likely cause a crash.. you need to replace prop then reload ram without a crash..

i could be wrong however as im still just learning myself lol
[Security Discussion] rvyhmeister:
My thought was to not change anything in the file system... just use dirtycow to modify the memory where the verification is.... if we can make the device not check for AT&T, then I'd be able to tether... and the truth is that given I don't reboot that often, I can live with rerunning dirtycow every so often...
[Security Discussion] kryz:
You can overwrite init or libc.so but you have do it well, just write few bytes and sometimes in a special order example:

You want to modify init to change the flow and jump to your code.

1-Overwrite the payload in a area of memory that is not using.

2-Overwrite the jump to your payload when you are sure the payload is all written.

If you overwrite all together payload and jump to code maybe the code reach the jump but the payload is not all copied and then the process will crash.

This is because dirtycow doen't overwrite the memory in one time it needs many iterations to do it, specially the exploit based in ptrace which is the only working in some devices and is so slowly.
[Security Discussion] fenlon:
kryz, can you explain your process for using fsck_msdos?
[Security Discussion] kryz:
The fsck_msdos in my device has write permissions to system and boot partition.

Ive used 2 methods to root:

1-Code a program that overwrites boot partition in xperia with a TWRP image, dirtycow fsck_msdos with the new binary and umount/mount sdcard, fsck_msdos will be executed and with write permissions to boot.

2-Code a program that overwrites system partition, in Xperia the binary patch the system partition adding the su binaries.

In oppo i just overwrite one script in system partition.(init.qcom-post.sh), at the next boot have permanent root in both.

In the code don't use calls to system or execve, just FILE pointers and write, open, lseek64, etc.

Btw, i got temporal root modifying the xperia init process, but is more complex and requires computer, the fsck_msdos is posible in a click app, i have the code working well.

Ill post the shellcode to disable selinux in init soon, im just trying more ways now.

Regards,
[Security Discussion] fenlon:
Thank you for the quick reply. I look forward to seeing your code.
[Security Discussion] kay_rus:
why do you have to avoid system or execve?

BTW, I'm trying to write custom recovery into the "/dev/block/mmcblk0p12". But when I read it back it appeared to be not modified at all. Then I tried to debug stuff with /dev/zero:

dd if=/dev/zero of=/dev/block/mmcblk0p12 - dmesg showed:

When I run

dd if=/dev/zero of=/dev/block/mmcblk0p12 bs=1, then dmesg doesn't show any errors, but the contents is still the same. Why?
[Security Discussion] kryz:
I avoid system and execve because some executables like fsck_msdos even run-as in my system have not selinux permissions to execute commands, but yes to open and write some devices.

Always depends in the target to attack but usually selinux is doing well its work and is very restrictive talking about exec, open sockets,etc.

fsck_msdos context doesn't need to execute a shell, but neither doesn't need to have write/read permissions to boot and system partitions and it does in my systems ;)

For example run-as context can't do anything in my system, not exec, system, not all the other shell tools(id,cp,mkdir,etc), even i can't write a file in any place in data, data/local/tmp, sdcard.

But has read permissions to read all the staff in root / and create file descriptors.

So it can read init, patch the copy and write init again, always doing with code not with system or execve calling directly to dd or cat.

run-as can setuid and set capabilities but can't write in anywhere, but you can write code to print to console output.

//setsuid and capabilities before...
while (true){
bytes = fread(buffer, 1, sizeof(buffer), fp_init);
if(bytes<=0){
return;
}
char c=buffer[0];
printf("%c",c);
}

And after redirect to a file.

run-as > /data/local/tmp/init

Now you have a copy of init for reversing and patch it with your shellcode.

/* Our shellcode to write 0 in /sys/fs/selinux/enforce */
.text:00008C86 0F F2 14 00 ;ADR.W R0, aSysFsSelinuxEnforce ; "/sys/fs/selinux/enforce"
.text:00008C8A 41 21 ;MOVS R1, #0x41
.text:00008C8C 05 27 ;MOVS R7, #5
.text:00008C8E 01 DF ;SVC 1
.text:00008C90 01 22 ;MOVS R2, #1
.text:00008C92 04 27 ;MOVS R7, #4
.text:00008C94 0F F2 EA 01 ;ADR.W R1, ZERO_STRING_byte_8D82
.text:00008C98 01 DF ;SVC 1 ; sub_A23C
.text:00008C9A 0B E0 ;B loc_8CB4
.text:00008C9C 2F 73 79 73 2F 66 73 2F 73 65 6C 69 6E 75 78 2F ;aSysFsSelinuxEnforce DCB "/sys/fs/selinux/enforce"
.text:00008C9C 65 6E 66 6F 72 63 65 ;aSysFsSelinuxEnforce DCB "/sys/fs/selinux/enforce
.text:00008CB3 00

About your issue with the recovery partition, is really strange if you have permissions you should be able to write in it, at least always i did it.

Search those dmesg errors in google, maybe you can get a solution, each device is different and maybe the yours have some restriction in the recovery partition.

Regards,
[Security Discussion] kay_rus:
What does init binary give you? Even if you modify it you can not overwrite it without restart. Restart means reboot, reboot means you'll loose changes.
[Security Discussion] elliwigy:
not if you carefully edit using the bootchart sample and then load feature to loop/reload the policy..

more can be read here:

http://www.redtile.io/security/galaxy/

of course it is not easy and it is device specific so the s7 for example in his prebuilt doesnt work on my v20 without modifications..
[Security Discussion] kryz:
The point is that each process is loaded by mmap, so if you modify the binary map you will overwrite the memory process of init.

Init is running and you can trigger to execute some areas of memory.
[Security Discussion] kay_rus:
So it gives only the memory information and you'll be able to overwrite init functions and trigger them, correct?

I don't know about Android >=5, but KitKat's init has a trigger:

} else if (strcmp("selinux.reload_policy", name) == 0 &&
strcmp("1", value) == 0) {
selinux_reload_policy();
}

I use it to reload /sepolicy. But it doesn't help much. When I rebuild policy from the scratch using policy.conf file - I get an android notification that there is insecure app which could be harmful, etc. But permissions I added into /sepolicy don't work. After a few minutes phone is being rebooted. Don't know why (I didn't have dmesg access at this point, see below)

When I modify /sepolicy using sepolicy-inject - it still doesn't work. For example I added permission for init context to set enforce option - doesn't work. I set permission to remount partitions - it doesn't work. And I always try to make /sepolicy file exact size of smaller.

I tried kernel module possibility: https://github.com/chaosmaster/ford_selinux_permissive . Had to rename module to wlan (granted module name are hardcoded into kernel) replaced it, turned off/on wifi - nothing is happened. Module is loaded, lsmod it tells: wlan 12487 0 - Live 0x00000000 (O) but there are no messages (I added a lot to debug) in dmesg, nothing.

Btw, dmesg. I was not able to enable dmesg under root and init_shell context, but using dirtycow and triggering init service - it worked (basic syscall to write data) . I don't know why, is there any difference between init and init_shell context? I didn't find any in /sepolicy rules.

Then, I have WRITE access to block devices, but I can not modify them (contents is the same). Yet another kernel feature which is built in into the smartphone? Boot/recovery partitions are 16mb long, and I also noticed this message in dmesg:

<6>#0[ 0.000000] cma: CMA: reserved 16 MiB at 36c00000
<6>#0[ 0.000000] cma: Found secure_region, memory base 0, size 109 MiB
<6>#0[ 0.000000] cma: CMA: reserved 112 MiB at 78000000
<6>#0[ 0.000000] cma: Found adsp_region, memory base 0, size 42 MiB
<6>#0[ 0.000000] cma: CMA: reserved 44 MiB at 75400000
<6>#0[ 0.000000] cma: Found qsecom_region, memory base 0, size 13 MiB
<6>#0[ 0.000000] cma: CMA: reserved 16 MiB at 74400000
<4>#0[ 0.000000] Memory policy: ECC disabled, Data cache writealloc
<6>#0[ 0.000000] SHARED:virt=0xfa400000, pfn=64000
<6>#0[ 0.000000] UNINIT:virt=0xfa900000, pfn=30208

Does this message relate to this write behavior?

I even tried to write modified (I did that on host PC) /system block - still doesn't work.

Also I analyzed kernel sources and noticed secboot_mode:

#define QFPROM_SECBOOT_ON (0x4E4F4253)
#define QFPROM_SECBOOT_OFF (0x464F4253)
#define QFPROM_ERR_READ_FUSE (0x46525F45)

android tells me this:

cat /proc/secboot_mode
1:0x4e4f4253

What does it mean? Do I have any change to root my phone?

I don't know what else can I try... Any ideas?
[Security Discussion] kryz:
About the kernel module maybe the kernel requires signed modules.

And i got similar behavior about permissions in a run-as target, even with permissive=0,run-as was able to somethings but even not read /data/local/tmp, the trick was launch a command overwriting /sys/kernel/uevent_helper with a path of one script that launch a tcp shell, then i got kernel context and game over, have you tried this approach?
[Security Discussion] kay_rus:
how can I check whether module is signed and verified?

didn't get what do you mean here. Can you explain?
[Security Discussion] kryz:
In one device i got root and enforce=0 targeting a run-as binary, but after get a shell with run-as with enforce=0, the permissions of run-as where little bit restricted, even with init context.

To escalate privileges to a kernel context sometimes you can overwrite the file:

/sys/kernel/uevent_helper

You have to write the path of a binary, and will be executed within kernel context.

I don't know how the kernel check the signatures but sure is not easy to bypass being in user mode.
[Security Discussion] elliwigy:
the galaxy method you quoted was able to provide lg v20 with a form of root that allowed access to /init.. however that alone is not helpful as you need to carefully modify or patch init and unless u got a debug oreng BL you would also need to find a way to exploit the BL to unlock or to find a form of root
[Security Discussion] bibikalka:
Correct! Right now LS676 has the access to fastboot disabled, at the same time there is an OEM unlock option in the menu (could be fool's gold ...). So if temporary root can help to overwrite the laf partition ( dd if=/dev/zero of=/dev/block/mmcblk0p35 ), it might allow access into fastboot, where oem unlock might just work. Then we'll see what's possible.

At the moment I can run a Dirty Cow'ed app_process32, but I have not figured out how to move from there to any kind of root ...

Update :

By Dirty Cow'ing the version of app_process32 from this link, I can actually execute some commands as root, with fairly limited access:

adb shell "/data/local/tmp/busybox nc localhost 11112 < /data/local/tmp/commands"
#pwd
/
#cat /proc/1/maps
00008000-00096000 r-xp 00000000 00:01 2933 /init
00096000-00099000 r--p 0008d000 00:01 2933 /init
00099000-0009b000 rw-p 00090000 00:01 2933 /init
0009b000-00154000 rw-p 00000000 00:00 0 [heap]
b6ee1000-b6ee3000 rw-p 00000000 00:00 0
b6ee3000-b6f07000 rw-s 00000000 00:0c 9338 /dev/__properties__
b6f07000-b6f08000 r--p 00000000 00:00 0
b6f08000-b6f09000 ---p 00000000 00:00 0
b6f09000-b6f0b000 rw-p 00000000 00:00 0 [anon:thread signal stack]
b6f0b000-b6f0c000 r-xp 00000000 00:00 0 [sigpage]
beecb000-beeec000 rw-p 00000000 00:00 0 [stack]
ffff0000-ffff1000 r-xp 00000000 00:00 0 [vectors]
#/system/bin/ls -l /dev/block
/dev/block: Permission denied
#exit

Can I somehow run dd using this ?
[Security Discussion] elliwigy:
dont think it matters if you could since if you dd a modified partition you can brick the device due to a locked BL.

on the V20 we used a signed debug BL which was already unlocked.. my vzw v20 didnt have fastboot or even an option in settings but when flashed the debug aboot i was able to access fastboot no issues.

You need to gain access to /init and then reverse engineer the bootchain for vulnerabilities which unfortunately is a lot more difficult..

you could try to overwrite another context with dirtycow lol daisy chain lol.. get a dumpav.txt and scour through it and hope to find something easy
[Security Discussion] mrmazak:
Since your getting access denied to the /dev/block I do not think you will be able to DD to it with dirtycow. I suspect selinux enforcing is problem. It seems the R1 so far is only one with selinux and a hole in the policy that will allow access to /dev/block.

It is worth a shot to try "setenforce 0" from that limited shell,

I don't think it will do it though.

Can you cat the laf partition from the shell?
[Security Discussion] Matt07211:
I suggest you examine the sepolicy contents to see what file_contexts have what permissions, and work from their, dirtycowing the files that have the correct permissions needed for DD (E.g. Write to block device)
[Security Discussion] bibikalka:
OK, I was able to run a shell via toybox as in the 1st post here :

http://xdaforums.com/r1-hd/how-to/blu-r1-hd-v6-6-dirtycowed-f-amazon-root-t3490882

Unfortunately, dd did not work with useful partitions.

That's tougher than one might think !

I wonder if I could perhaps overwrite /init process copy that's already in memory, so that I can get around the lack of read permissions.
[Security Discussion] Matt07211:
For dumping sepolicy, use c hainfires supolicy tool, with the dumpav command and output the contents into a text file :)

I currently can't comment on /init though :( sorry
[Security Discussion] Scorpius666:
You would need a [vdso] entry in /proc/self/maps to make that exploit work. I have no such thing on my device, and I don't think you would find that on any ARM device.

But I have a [sigpage] though...