yashsingh1/xdaforums huggingface dataset:
[Security Discussion] azriek:
Hi,

i have a [vdso] entry on my lg G4 H815 ... :fingers-crossed:

Az
[Security Discussion] saturn_de:
Samsung S7 Edge also has a vdso.

$ adb shell cat /proc/self/maps| grep vdso
7fa80ba000-7fa80bb000 r-xp 00000000 00:00 0 [vdso]
[Security Discussion] retr0id:
Can anyone think of a way to force vDSO to be used on phones that don't seem to use it by default?

Maybe by loading a certain library that uses it?

In order to get dirtycow-vdso to work on android, someone is going to need to port the payload to arm, but that should be fairly trivial.

Edit: This may be of use: lwn[.]net/Articles/603184/

It would appear that ARM is capable of using vDSO, but it needs to be enabled in the kernel?
[Security Discussion] Scorpius666:
I wonder if for phones with [sigpage] instead of [vdso] you could exploit the kernel using the [vectors] like evasi0n did for iOS (at least for the second part of their exploit). Basically is to rewrite the [vectors] page the Software Interrupt vector and jump to a code that would run as root, and then cause a Software Interrupt exception to execute the code.

I'm not sure if dirty c0w could write the [vectors] page, it should be in my head, but I'm not sure (I can't read it using gdb for example but it has the read permission and execution).
[Security Discussion] retr0id:
Ok, I'm working on a root tool. Don't get your hopes up too much. Firstly because I have no idea what I'm doing, and also I might have to wait a while before releasing because of the security impact it could have.
[Security Discussion] Darkos333:
Has anyone tried THIS?

github[.]com/timwr/CVE-2016-5195

Looks promising, but given a fact Im complete newbie in playing around Android, let alone compiling and running C code on it... well, perhaps someone could teach me how to try this on my LG K8 ? ;)
[Security Discussion] zdravo:
Based on Dirty Cow : http://arstechnica.com/security/201...ed-by-most-serious-linux-escalation-bug-ever/
[Security Discussion] freddierice:
libc

timwr's code does work, however /system/bin/run-as is not a setuid on my phone.

I'm going to overwrite libc's mount... wish my phone luck!
[Security Discussion] christianrodher:
I compiled it and it works but need the rest to root.... In what to use it.
[Security Discussion] Scorpius666:
That code is useless. You can't set any other capability (any other will give you an Operation not permitted error). That code is only to demonstrate that you can get a root uid but you can't do anything with it. Not even create a single file.
[Security Discussion] christianrodher:
check the video in the website that zdravo in this thread.... cant post link yet
[Security Discussion] Scorpius666:
I saw the video, and I know the root access is plausible, but I don't think it was through timwr's approach. I might be wrong of course, but I have tried to set every single capability besides suid, ruid and guid with no success.
[Security Discussion] mobile-junky:
Is anyone able to root Moto G4 with this exploit?
[Security Discussion] Scorpius666:
Hard to say. The thing is that this exploit works pretty well on Android <= 4.1. But with SELinux enabled, even if you are root, you can't do anything to the phone. Not even change a single file.

I'm losing hope.
[Security Discussion] rpangelov:
Well that is the reason I told so many people not to set it to permissive in order to use apps as viper4android... for people still doing it - http://xdaforums.com/android/general/viper4android-universal-fix-cm13-t3337289
[Security Discussion] matteogeniaccio:
I managed to get root (with partial capabilities) on a galaxy note 4, android 6.

I used the dirtycow exploit to overwrite /system/bin/dnsmasq, then I started the wifi tethering.

It's able to read files, start a tcp server , append data to files on the sd card, execute programs in /system

I think the next step would be on the lines of:

- overwriting /system/bin/mount

- mounting with --bind over /sbin so we can put our version of adb there

- restarting the adb daemon to get all privileges.

Is it plausible?
[Security Discussion] christianrodher:
What did you overwrite?
[Security Discussion] matteogeniaccio:
Here are my steps.

first I compiled dirtycow.c and sh.c into two separate executables.

I attached the source code.

I used the android gcc compiler with the "-Os -s -pie" flags.

I uploaded them,

Then I launched ./dirtycow /system/bin/dnsmasq ./sh

After it completed, I enabled the wifi tethering on my mobile phone (available by default).

My sh.c spawned a shell and bound it to the port 11112, then I could launch form my computer:

$ adb forward tcp:11112 tcp:11112

$ nc -v localhost 11112

and spawn a root shell
[Security Discussion] sunekosuri:
Check this out!

https://github.com/timwr/CVE-2016-5195
[Security Discussion] elliwigy:
if you have secure boot enabled (write protection) overwriting init will crash the device and force a reboot at which changes will be reverted...

you need to somehow patch init and have it reload without crashing.. its over my level of expertise lol
[Security Discussion] kryz:
In devices with dm-verity you can't make persistent the root patching boot or system, but you can patch init in hot and execute code anyways, or are you telling me that dm-verity is checking the memory mapped?

I say that because i successfully exploited a lollipop device patching init process i don't think dm-verity or secure boot enable is checking the memory of init for changes, am i right?

Regards,
[Security Discussion] Matt07211:
Dirtucow overwrites memory, not the file. This mean even if you dirtycow init with an hacked version dm-verity won't be enabled, this is becuse no files have been overwritten.

So changed do not persist with dirtycow. Dm-verity does not check memory, as dm-verity runs at boot (it generates a hash sun of the block devices and compare it values it has).
[Security Discussion] elliwigy:
not to mention it varies by device and os... lol my v20 is on Android N
[Security Discussion] kryz:
Well, i patched dynamically init and maybe now is more universal, ive tried with 5 different init and the patch is working good, the shellcode as well only 32bits.

Can someone post their init to check if the patcher is working, any init file on Android lollipop and up.

Regards,
[Security Discussion] FilthyFord:
I'm not sure if this is what you're looking for, but here ya go. This is from G930A Samsung Galaxy S7 running on stang5litre rom Android 6.0.1

https://www.dropbox.com/s/lasi13vl09bnvwa/init?dl=0
[Security Discussion] kay_rus:
I've got full root access. Escaped the selinux, escaped limited capabilities, etc. So I have root, but I still can not update the recovery/boot partitions. My SOC is msm8226.

cat /proc/secboot_mode prints 0x4e4f4253, which according to the kernel sources means: QFPROM_SECBOOT_ON (0x4E4F4253)

Is it what I faced? (dd works, but actual recovery contents is not modified, like dd to /dev/null)
[Security Discussion] norberto_:
How did you manage to reach full root?
[Security Discussion] kay_rus:
1) loaded custom sepolicy with the permissive domain

2) used uevent trick mentioned above (echo /data/local/tmp/lsh > /sys/kernel/uevent_helper)

3) transitioned from kernel to custom permissive selinux context

p.s. more easier way is to replace adbd with the patched version which won't disable capabilities and downgrade to shell.

p.p.s. right now after yet another kernel source reading, I found out that my phone could be rebooted into emergency download mode. bootloader reboot doesn't, but edl works (QHSUSB__BULK). but i have no idea what can i do with it. I tried to open virtual serial port and didn't find anything there. it doesn't accept regular commands. Have to read more about that.
[Security Discussion] Honestly Annoying:
Dirtycow has been updated to spawn a root shell by default! Push the new binaries and run :)

https://github.com/timwr/CVE-2016-5195
[Security Discussion] Matt07211:
Thanks for the heads up, I'll have a look at it.
[Security Discussion] :
Root Shell Permissions

Yes, it's true that the updated exploit spawns a root shell. The thing is though, the root shell spawned doesn't have root permissions. I've actually observed that it has less permissions than the usual user. Just thought I'd spread word. Btw, in this I was using a Polaroid P709 Tablet running Android 6.0.1. I've yet to try it on my Moto Z Droid.

Update 1:

I see your point, and it makes sense. But' I'd also like to say that I've advanced a little bit further than I did before. When you build dirtycow with "make root" instead of just "make", you get a root shell with more permissions (possibly root permissions, I've yet to check tbh).
[Security Discussion] Matt07211:
It due to the file_context it's spawned under. If it's spawned under app_process file context then that root sheel will have access to the permissions that app_process has

---------- Post added at 03:07 AM ---------- Previous post was at 02:44 AM ----------

If you type "id" you can see what file context your under. If you dump your sepolicy you can then search the dump contents to see what permissions the file_context has and then work from there.
[Security Discussion] norberto_:
Hi guys,

could somebody post the new compiled binaries?

I do not have any setup to compile myself.

Thank you
[Security Discussion] :
I'll hit you up when I get home
[Security Discussion] trjv:
I broke FRP

So I was messing around with dirtycow recently and I discovered a way to use it and completely break FRP for every device that is vulnerable to the exploit. Which is pretty much all of them lol. I posted the videos on my YouTube channel showing how to do so on even a Google Pixel XL running 7.1 on the November security update. Since I cannot post links yet just search for google pixel frp bypass on youtube, i have the only video lol.
[Security Discussion] mcraeally44:
Sorry for such noob question, but how exactly would that help me rooting (bypassing) my mobile protection having my bootloader carrier locked (BL unlock allowed no) I've been subscribed to this topic for a good while, followed every single post and would be grateful if you could clear things up for me. Very much appreciated.

Using Sony Xperia Z4 Tablet running 6.0.1

Thanks
[Security Discussion] shoey63:
No exploit, dirty cow or otherwise, will help root a device with dm-verity and unlockable bootloader. As soon as you modify any of the partitions required for root, secure boot fails and the phone won't start.
[Security Discussion] acejavelin:
It doesn't help... This is to bypass Factory Reset Protection, not root a device. Basically if you're bootloader isn't unlockable and it has dm-verity this exploit won't work, ever.
[Security Discussion] trjv:
This method wont help you to root the device, just to bypass FRP. Since dirtycow doesn't persist after a reboot (I think) it wont help as far as gaining root. However it will help you to modify files on the device. I also realized that it only has the power to overwrite files that the current user has read access to, despite whether the filesystem is mounted read-only. With this in mind I was looking over my Nexus 6P and checking to see which files had read access as user and realized that GoogleLoginService.apk and GoogleLoginService.odex both fall under this category. The files are located at /system/priv-app/GoogleLoginService and associate with Google Account Manager when installed as a system app. When the data is corrupted you can install Google Account Manager as a user app, which changes the location and file names to /data/app/com.google.gsf.login-1/base.apk and base.odex. If you corrupt these files at this point then try to disable and uninstall and select replace with the factory version it wont have anything to "replace with the factory version" and tell you that uninstall failed. Once this happens you can reinstall GoogleAccountManager.apk which will again install as a user app, which will then let you perform a full successful uninstall of Google Account Manager. At this point you have full control to be able to downgrade to a previous version of Google Account Manager without it telling you that "data is corrupted" and from there perform the web sign in activity. I've tested on multiple devices and multiple versions and this works on every single device on every version of Android including the latest 7.1.1 as long as it is not on the most recent December 5 2016 security patch since dirtycow was removed with those updates.
[Security Discussion] Matt07211:
Unless you have access to a debug bootloader/boot.img which is unlocked by defult, has fastboot etc.

http://xdaforums.com/v20/development/ls997vs995h910-dirtysanta-bootloader-t3519410

So unless you lucky out, and some how manage to get a hold of a debug copy then you can't do much with dirtycow (Unless you chain spot of exploits (that are dirtycow unrelated))
[Security Discussion] kryz:
Ive made some tools for checking root in lollipop 32 bits and up is one apk and also for adb with more succes.

Now we are working to port it to 64bits and Marshmallow, after christmas we can have someting.

This tools just give you root with init context and disable selinux injecting code in init.

Check the apk if you have 64bits or Mashmallow also will tell you if you are vulnerable to patch init, is a matter of time that we get the way to do it in 64bits we don't have now any device and will try with the emulator and mashmallow images to port it.

We need really betatesters to check more but in 2 devices with lollipop is working with su executed in init context.

http://xdaforums.com/android/software-hacking/root-tool-dirtycow-apk-adb-t3525120
[Security Discussion] Fobos531:
I have a 64-bit supported LG phone running stock 32-bit Marshmallow. Does this all mean I can use dirtycow to gain temp root so I can for example, replace the preinstalled Google.apk with a modded one (that has a differing or invalid signature)? Will it persist after reboot? If yes, how can I do it?
[Security Discussion] Matt07211:
Short answer: NO

Long Answer: Dirtycow overwrites the memory of the file whiles it's in RAM, meaning that the file itself doesn't get modified (this why people don't get locked out by Stuff like dm-verity on reboot). The file itself has to also be readable from the user perspective as well. So if you can't read the file then you cant overwrite it. So you can't overwrite file and unable to make it persistent, so therefore this won't work for your desired goal.

If I'm wrong please feel free to correct me anyone. ;)
[Security Discussion] Qwerty212:
What about a temporal root just to clean bloatware from some devices? I would love to unistall Vodafone Start or Sony's What's New
[Security Discussion] Zacharee1:
Right above you is your answer.
[Security Discussion] Silver Surfer 2069:
Can you post your codes?

With this method you could have read access to the Data partition? ex read a file in /data/misc/vold?
[Security Discussion] trjv:
I don't think you're fully understanding how this works. The whole point of dirty-c0w is the ability to write over read-only files. Think of it this way, if you don't have root and open a terminal run ls -la for all files that show a -------r-- in that position then that file is susceptible to dirty-c0w. There are a bunch of files that actually have user read permissions but the folder containing them does not (ex. /data/app /data/data and I believe /system/priv-app) so as long as you know the what's in those folders you can still cd to them. That's how I realized GoogleLoginService.apk was susceptible. So you don't need root access to overwrite that particular file but I think there's other factors preventing it. That's why in my video I use a blank "file" (made with touch file" inside a user writable directory /data/user/0/jackal.androidterm/app_HOME) to corrupt it since fully overwriting it seemed to either take hours or just not work fully. Since you can install some system apps via apk, making them user apps, doing this to both the original apk and odex again allows you to be able to install the apk once more, then when going to disable/uninstall it will prompt if you'd like to replace with factory version. Considering the device has nothing to replace it with but corrupt files it allows you to fully uninstall the app entirely thus allowing a downgrade to whatever version you'd like without it telling you "package is corrupt".
[Security Discussion] Fobos531:
So if I understood it correctly: If the preinstalled Google App apk has that read permission which makes it susceptible to dirtycow, I can do this: touch the original apk and its odex inside a user writable directory so as to corrupt it. Then I go to settings, disable/uninstall the app which will prompt me to replace it with factory version which will effectively "uninstall the app". Then, I'm able to install the modified Google App as a user app without the install_parse_failed_unexpected_exception error? Did it understand it correctly? If yes, could you tell me a bit more how exactly do I "touch" the apk and odex files? I don't quite understand that part of the process.
[Security Discussion] trjv:
Almost! So when I say "touch" what I mean is the UNIX command. Touch creates a blank file of any(?) kind that you can specify with whatever extension you want to use. So by typing $:touch file this creates a blank file called "file" with no extension and 0kb inside your current directory. Since you can't uninstall a system app by default the only possibility you have is to just disable it so if you were to just go straight into settings and try to uninstall it would just let you disable the app and not prompt for a "replace with factory version". This prompt only appears for system apps that's you have upgraded beyond whatever stock version the phone last "remembers" having. This is where you can use that to your advantage. By installing the Google account manager apk with the same version number the phone doesn't see that as harmful (side note: does anybody know what app actually handles this and decides whether an app can be installed or not by chance???) which will then install it as an "upgraded" user app version of it. So without any modifications you can just install gam.apk and then go to uninstall it and it will prompt you to replace with factory version, but it will just revert to it being a system app if you do.

So the general process is:

1) use dirtycow to corrupt the original GAM.apk and GAM.odex inside /system/priv-app

2) install same version GAM.apk which puts it in /data/app as a user app

3) use dirtycow to corrupt the newly relocated base.apk and base.odex

4) disable/uninstall GAM inside settings which will fail and change the icon to unknown

5) reinstall same version GAM.apk again and then immediately disable/uninstall again which prompts for replace with factory version but since it has nothing to replace it with due to Step 1 it just fully removes GAM.

6) Install gam6.apk (the last version containing the activity for bringing up the web sign-in screen) and sign in using it.

7) make sure to upgrade back to the correct GAM version and reboot so that Setup Wizard works properly
[Security Discussion] Fobos531:
Thank you very much. A couple of more questions:

1. how exactly is dirtycow used in order to corrupt the original GAM.apk and GAM.odex?

2. where do I get this "same version of GAM.apk"? from the internet or do I just adb pull my own?

3. Where will these "base.apk" and "base.odex" appear so I can corrupt them?

6. Where do I get this "gam6.apk" you're talking about?

7. Which version should I exactly upgrade to?

NOTE : I plan to do this on a preinstalled Google App apk so I can get Google Assistant working with a modded apk which is the same version.
[Security Discussion] trjv:
If you watch my video up on YouTube I have links to everything you will need to use. It would honestly make much more sense if you take a look there, I also type out all the steps in a pastebin and give the link for that as well. What I mean by gam(your android version).apk is that since technically you are not allowed to downgrade GAM (Google Account Manager) by default you have to use specifically the version that matches whatever Android version u are on (ex. 7.0 needs gam7.0.apk, 7.1 needs gam7.1.apk, 7.1.1 needs gam7.1.1.apk). If you know how to modify an apk (something beyond my comprehension for now) then I'd assume as long as it is the apk for your matching android version or above then you'd probably be allowed to install but I really don't understand how that works so I think someone else may be able to shed more light on that subject.

There are 2 locations that GAM can be, depending on what is is installed as (system app or user app):

-As a system app it is located at /system/priv-app/GoogleLoginService/GoogleLoginService.apk and /system/priv-app/GoogleLoginService/oat/arm64/GoogleLoginService.odex.

-As a user app it is located at /data/app/com.google.android.gsf.login-1/base.apk and /data/app/com.google.android.gsf.login-1/oat/arm64/base.odex

Just make sure that if you are using a different architecture than arm64 that you replace "arm64" within those directories with your architecture because it will be named accordingly.

Also what I mean by "use dirtycow to corrupt" is that you just need to use dirtycow on File-A and attempt to replace with File-B but since GAM is such a big file or there are other factors I'm unaware of it will never fully finish the exploit (I sat for hours waiting and it never said finished). So just by running dirtycow on File-A you are in turn "corrupting" it because it definitely changes it to some extent just not enough for a full replacement by File-B. If you are interested though I highly recommend watching my video on YouTube because I show exactly what the process entails. I can't give links yet here so just watch the video made by GhostlyHaks, that's my channel.
[Security Discussion] ceo.mtcl:
December 5th Security Patch and DirtyCow issue

I tried your guide on Pixel on December 5th Security patch and it is not working. Any suggestions?
[Security Discussion] trjv:
It will not work because dirtycow was patched beginning with December updates. I'm currently working on a method for those updates though so check often cuz I'm close ;)
[Security Discussion] Fobos531:
so I can do this method you described directly on Google Application apk instead of gam.apk or do I need to do it first on gam.apk to be able to do it on Google Application apk?

Also: Can you please tell me what's the location of Google App apk that is preinstalled and then updated to latest version? I can't find it in /system/app/ neither /system/priv-app/. I DON'T have access to do "ls" command in /data/app

Btw. When I try to dirtycow an apk and get the "could not open(null)" output, that means that the apk in question isn't susceptible to dirtycow? I'm on September 1st security patch.
[Security Discussion] trjv:
Brotha i promise you that it will make a ton more sense if you check out my video lol. I know you can't ls because the directories themselves do not have user read permissions, I had to look at my own rooted device to see what the permissions were for all the files, that's when I noticed that all of this was even possible. There is no such thing as gam.apk, Im just lazy and wanted to save time in my videos so I renamed the Google Account Manager APKs that I downloaded from apkmirror to gam.apk. There is no gam.apk that is on the device, it is either GoogleLoginService.apk when it's located in /system/priv-app or base.apk when it's located in /data/app. Also keep an eye out for the usage context of dirtycow. Before the recent update on github the context for the command was "./dirtycow /original/file /new/file" but I believe after the update to include the automatic root shell the context has switched to "./dirtycow /new/file /original/file" so watch out for that because this could be a reason for error.
[Security Discussion] elliwigy:
so you are basically corrupting the original gam so that it gets disabled and no working gam to replace it so essentially it is removed entirely in the process therefore allowing one to bypass it altogether?