yashsingh1/xdaforums huggingface dataset:
[Security Discussion] trjv:
Actually yeah you have it exactly correct. :)

I'm not sure if stopping the process after a complete removal would enable a direct bypass just cuz I installed an older version directly afterwards. Though now it makes me wonder if after deleting the original gam what would happen during setup if you back all the way out into setup wizard and try to proceed. Crash directly into home screen maybe??
[Security Discussion] elliwigy:
actually i seem to believe itd force close and not allow you to proceed through the wizard at all.. so id say your method is most likely the best process
[Security Discussion] Fobos531:
I watched it multiple times.

Here's what I did altogether:

1. pull Google App apk and modify(decompile, smali editing, recompile) it so it allows Google Assistant.

2. push it back to the phone along in a directory where both this modded apk

3. execute these commands in terminal emulator:

cd ~
cat /sdcard/Download/dirtycow > dirtycow
cat /sdcard/Download/Googlemodded.apk > Googlemodded.apk
touch file
chmod 777 *
./dirtycow /system/priv-app/Velvet.apk Googlemodded.apk

At this point dirtycow starts running, and literally after a few seconds dirtycow finishes. My phone then proceeds to freeze and reboots afterwards. I guess this is my phone's defense mechanism? Am I doing something wrong?

p.s. i guess i should note that Velvet.apk in question indeed has the necessary read permission to be susceptible to dirtycow
[Security Discussion] -Happy Feet-:
i tried to root my Xperia Z3 but i get this message:

warning: new file size (13728) and file old size (17920) differ

size 17920

[*] mmap 0xb6da6000
[*] exploit (patch)
[*] currently 0xb6da6000=464c457f
[*] madvise = 0xb6da6000 17920
[*] madvise = 0 1048576
[*] /proc/self/mem 1610612736 1048576
[*] exploited 0xb6da6000=464c457f
shell@D6603:/ $ run-as -exec id
Current uid: 2000
Setting capabilities
Attempting to escalate to root
Current uid: 0
Executing: 'id' with 0 arguments

uid=0(root) gid=0(root) groups=0(root),1004(input),1007(log),1011(adb),1015(sdcard_rw),1026(drmrpc),1028(sdcard_r),2993(trimarea),3001(net_bt_admin),3002(net_bt),3003(inet),3006(net_bw_stats) context=u:r:runas:s0
shell@D6603:/ $ run-as -exec sh
Current uid: 2000
Setting capabilities
Attempting to escalate to root
Current uid: 0
Executing: 'sh' with 0 arguments

Failed to execute 'sh'!
1|shell@D6603:/ $ sh
shell@D6603:/ $ run-as -exec sh
Current uid: 2000
Setting capabilities
Attempting to escalate to root
Current uid: 0
Executing: 'sh' with 0 arguments

Failed to execute 'sh'!

is rooting not possible?
[Security Discussion] trjv:
Yeah I've had that happen a few times during testing. What is velvet.apk? Like what does it do for the phone and also what kind of phone are you running it on? What security patch? Have you tried to dirtycow the velvet.odex first instead of the actual apk?
[Security Discussion] kay_rus:
Finally I was able to get full emmc access on my phone (I was able to replace wlan module with my custom kernel module which reboots phone into a special mode). Unfortunately I can not boot using custom boot/recovery/fota image since they are signed. I've extracted all certificates from sbl1, rpm, sdi, aboot and tried to verify signatures of these images (256 bytes raw signature) but I could not. So I don't know which public key is supposed to verify the image and how exactly (I tried openssl dgst, openssl pkeyutl, openssl rsautl). Can anyone provide me with the info on how it is done?

Also, since I can modify everything on the emmc I have possibility to enable fastboot mode, disable write protection and so on. But I don't have a huge room for experiments since I can easily brick my phone. Can someone help me to disassemble sbl1, aboot, etc and figure out whether these partitions are signed and is there a possibility to disable qualcomm secure boot? Any help/contacts are appreciated.
[Security Discussion] shoey63:
It's an exploit of a vulnerability in the kernel, not a rooting tool.

But why can't you use the rooting methods already available for Z3?

They have been around for ages, even for locked bootloader.
[Security Discussion] -Happy Feet-:
I can use it. But it can be an way without losing all data. Maybe to backup the data with titanium backup and then unlock the bootloader.
[Security Discussion] Fobos531:
I extracted Google App apk through an app called Apk Extractor. When extracted, the app's name is: Google App com.google.android.googlequicksearchbox(something like that). To enable Google Asisstant I use a method similar to which Assistant Enabler (Xposed module) uses: http://xdaforums.com/android/software/guide-google-assistant-marshmallow-t3478450

Since I don't know where Google App (that was preinstalled and THEN updated to the latest version) lies on my LG Spirit H440N running 32-bit Marshmallow. (September 1st security patch), I took a look at my Nexus 7 2012 running UA 7.1.1 which didn't have Google App preinstalled as far as I'm aware. I did install it afterwards. To check the file path to the Google app, I found that the Google App is located at /system/priv-app/Velvet/Velvet.apk in the Nexus 7. I then pulled the /system/priv-app/Velvet/Velvet.apk from my LG phone and I decompiled it the same way I decompiled Google App apk (which I extracted with Apk Extractor). When comparing the decompiled files, I noticed that the APKs were a bit different actually. To be specific: the apk from Apk Extractor had the required directories/files from the "Enable Google Assistant" guide while the Velvet.apk didn't. However, when trying to install the APKs, both Velvet.apk and the other one(from Apk Extractor) look the same when installing (they ask me if I want to upgrade "Google" app). I guess Velvet.apk is Now on Tap/Google Assistant itself (which isn't present in Lollipop and older versions) while the apk from Apk Extractor is the Google app. However, that would mean that I STILL don't know where the "Google" apk is located in my device. It isn't in /system/app/ nor /system/priv-app/ and I don't have permissions to "ls" on /data/app. I haven't been able to find Velvet.apk's odex file. What can I do here? I guess you now have a pretty good idea of what I'm trying to achieve.
[Security Discussion] trjv:
Wow this sounds pretty interesting! Leagues above my level of Android understanding, but I do have some disassembling experience. If you can send me copies of the partitions I'll see what I can do. Also maybe I'm just missing earlier comments but could you explain a little more on how you achieved this? Fastboot enable and write protect disable sound like a fun day haha
[Security Discussion] rczrider:
Dumb question: what is the advantage of Dirty Cow (from a root perspective) if you can't even use it to obtain temporary root?

I'm sure this is obvious to those who have a better understanding of the exploit and the way Linux functions, but I'm missing something. I have a Verizon Moto Z with a virtually unlockable bootloader (which I knew when I got it); my understanding is that DC has zero use in terms of unlocking, but it could lead to root (which is all I really want, given that stock ROM is pretty darn close to vanilla Android). I just don't understand how it *could* work.
[Security Discussion] acejavelin:
It pretty much can't in that situation... Dirty Cow is not the solution for that device, in fact the ability to use this exploit to root is pretty minimal and the newer the device the less chance it is usable for anything at all.
[Security Discussion] rczrider:
That's what I figured. I will say, however, that since I haven't allowed the Nougat OTA to be applied, my Moto Z is still running the May 2016 security patch level - and the 3.18.24 kernel - so it should still be vulnerable. As much as I'd like Nougat, I'm inclined to decline the OTA for a little while longer in case someone comes up with a way to unofficially unlock the bootloader (unlikely) or root (more likely). I assume that would lock me into MM, though, so it's possible I'll just upgrade anyway and see how long I can tolerate a locked-down device :p

Anyway, I'm just talking. Thanks for the clarification!
[Security Discussion] elliwigy:
that is not true at all.. its actually a great exploit that opens up many doors.. you just have to know what youre doing..

you can daisychain it also which will open more access.. for example, dirtycow run-as to get a limited root shell which allows access to more files then dirtycow say untrusted app process to then be able to dirtycow another process which would allow you to write to firmware blocks...

you can even gain access to say init and if you know what youre doing you could disable dm verity etc. or even modify the BL for example..

once you get to a certain point however you need to be experienced in reverse engineering a bootchain or other structures if you want to gain root or even better unlock the BL
[Security Discussion] rczrider:
Don't say this! You'll get my hopes up that I can have an unlocked BL on my VZW Moto Z (assuming I stick with MM and don't upgrade to Nougat any time soon) :p

Unfortunately, I'm not a dev and I don't think there's a great deal of dev support for the Moto Z. And as noted earlier, every day that goes by has fewer devices with the Dirty Cow exploit available (either by OTAs or simply new phones coming with November 2016 or newer security patches).

Thanks for clarifying, though!
[Security Discussion] elliwigy:
i dropped moto and jumped to the v20 with vzw and with a bit of dirty cow we have an unlocked BL lol.. the other half tho was a debug firmware but all dirtycow to write the files to the device to make it all possible
[Security Discussion] amateurhack:
Sorry, I'm not a dev, but have been following the various threads. I haven't posted, because I didn't want to clutter up a thread. So my apologies if this post is out of line:

I have a VZW Moto Droid Turbo 2, and am in a similar situation. It should be mentioned that DC was addressed in the November update that was sent out. I have seen reports both ways as to whether that update completely prevents DC from working. I have been postponing the update in hopes that a full root method would be found.

This does seem to be the best shot we have for the Verizon boot-locked devices, but there will necessarily be many steps involved, and it will likely be risky.

If any devs are interested, you may want to post in the DT2 forums as there have been many steps at a bounty for root. I for one would certainly contribute to a working root for this awesome phone.
[Security Discussion] mrmazak:
I am having trouble using dirtycow on a new "cheap" tablet. Its an rca voyager model rct6873w42 . It has android 6.0.1 June 2016 security patch. kernel version 3.14.0+. The board and chip is rockchip/sofia3gr. as far as i have found out its a intem atom/ rockchip 30sdk cross.

When I try to test dirtycow (simple text file exchange on file with chmod 0404 set) and this line comes up in logcat.

3135 W dirtycow: type=1400 audit(0.0:20): avc: denied { module_request } for kmod="personality-8" scontext=u:r:shell:s0 tcontext=u:r:kernel:s0 tclass=system permissive=0

anybody have any insight on weather or not I have a dead end here or not?

same test done on my other phone on android 6.0 kernel 3.18.19+ June 2016 security patch shows dirtycow works.

both are 32 bit
[Security Discussion] rczrider:
I assume the debug firmware was a leak from LG or some such thing? In that without it, DC alone wouldn't have been enough to unlock the bootloader?
[Security Discussion] elliwigy:
dirty cow alone isnt enough to root any phone let alone unlock the BL.. However, it can be used towards root or unlocked BL. With that I mean with dirtycow, you can attack pretty much anything you want..

for example, you can use dirtycow to say gain access to init and in theory reload an sepolicy to set the device to permissive and/or disable secure boot. You could in theory attack the bootloader or even overwrite it if you find any exploits to use with dirtycow.. it opens the doors for many things.. on the v20 for example we used a modified run as which we used dirtycow to overwrite the existing one to spawn a root shell then used that shell to dirtycow another process which we then used that process to dirtycow atd process which is able to write to the aboot blk file.. we at this point were able to overwrite existing aboot with the debug aboot which was unlocked by default and since it was signed by LG the phone accepted it and disabled secure boot as well as was unlocked and fastboot enabled..

and the v20 debug firmware was on a us996 v20 that someone was able to buy before it was even launched.. not sure if it was a lg employee or where it originally came from but you can say we got lucked out lol
[Security Discussion] aamszia:
i have 2 questions ...

I need to remove 3 apps of Republic Wireless from XT1094 .. can i do it with dirtycow .. ?

Can i edit build.prop by dirtycow on FRP LOCKED phones ... ???
[Security Discussion] mrmazak:
1. No

And

2. No

With dirtycow you can change the contents of files, but changes are not expected to survive reboot.

And phone needs to be on with adb allowed to use it, so no unlocking frp protected device.
[Security Discussion] aamszia:
And phone needs to be on with adb allowed to use it, so no unlocking frp protected device

have you seen the FRP unlock proceedure for Nexus 6 ( 7.0 ) .. by using termux and terminal ( gam6.apk gam7.0 apk ) and dirty cow .... ???

---------- Post added at 12:30 PM ---------- Previous post was at 12:29 PM ----------

Here is the link .. and i have done atleast 5 phones ...

https://www.ghostlyhaks.com/blog/mo...k-bypass-huawei-nexus-6p-android-7-x-x-nougat

commands are

cd ~

cat /sdcard/Download/dirtycow > dirtycow

cat /sdcard/Download/gam6.apk > gam6.apk

touch file

chmod 777 *

./dirtycow /system/priv-app/GoogleLoginService/GoogleLoginService.apk gam6.apk

./dirtycow /system/priv-app/GoogleLoginService/oat/arm64/GoogleLoginService.odex file
[Security Discussion] trjv:
Thank you for helping to spread the word about me :)

I was going to say the same thing, that ADB is NOT required to run a dirtycow binary on any device. I've even been able to use Termux and, after installing only a few libs and binaries managed to natively compile every version of dirtycow directly on the device without ever touching a computer. Since the many Terminal emulators give you r/w access while inside of their respective home directories then with a little trickery to get the finished binaries into the correct directories (since /sdcard/Download has weird permissions and you can't use /data/local/tmp without SHELL permissions) it allows you to use pretty much anything you want within standard user permissions.

You can even copy the entire /system/bin into a, say, Termux based /system/bin (/data/data/com.termux/files/usr/system/bin) and chmod to give sufficient privileges to use many restricted commands not normally accessible and even add them to your PATH to come before /system/bin. One issue I face is that my experience with Android is mediocre at best so I really don't understand how app process works or how to link the correct libraries to the new binaries, otherwise I would have already achieved a fully working miniature copy of the Android filesystem working inside of Termux where I have full access to do as I please. All of this being done without dirtycow but with the intent of using it afterwards to do......idk lol I didn't think that far ahead yet haha.
[Security Discussion] mrmazak:
I must be missing something. The question was if dirtycow could be used on a "frp locked" phone. Isn't an frp locked phone one the will not fully load the os because of bad user credentials. So even though you can use dirtycow from inside a terminal emulator on the phone, you cannot get into the phone if it is frp locked.
[Security Discussion] elliwigy:
you dont need a terminal on the phone to use dirtycow, you just need adb to work
[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 or an outside apk? Through the built-in web browser or a USB thumb drive for example?
[Security Discussion] trjv:
Ummm.... false. The answer to your question is yes dirtycow can be used on a phone with FRP lock. All you need is a terminal environment of any kind unless you find some way to incorporate it into an app for whatever reason. The whole point of what I've been working on for the past couple of months has been the result of my initial discovery of how to implement dirtycow specifically on a multitude of FRP locked devices and use it to bypass the lock. If you haven't seen it yet I actually made the discovery on a Nexus 6P running 7.0 and posted the video on youtube.

https://www.youtube.com/watch?v=iSsjeI7DV-k

Afterwards I've found that it actually works on every device as long as it doesn't have the Security Patch updated to the point where dirtycow has been patched. Here is the next video I made showcasing the same method used to get the first Google Pixel FRP Bypass.

https://www.youtube.com/watch?v=KI5GWFU-YiU

And then here is the method again done on a Nexus 6.

https://www.youtube.com/watch?v=yF-wb5u4rVo

So yeah, universal FRP bypass on any android device with dirtycow.

Also untrue, you just need to think outside the box a bit to get it working ;)

This post applies to your situation as well. As long as you compile the binaries for your devices architecture then all you need is access to a terminal environment to be able to use it.
[Security Discussion] haxy:
Unfortunately in our case though is that you cannot install any apps on the head unit. So there isn't a way to install a terminal emulator. Google App Store isn't on the device and we can't enter developer settings to enable unknown sources. No ADB and No installing of apps.... any thoughts?
[Security Discussion] D1kiy:
Can somebody explain how can I execute sh script by this exploit? I would like to dump kernel from phone without root.
[Security Discussion] trjv:
Enabling unknown sources isn't in developer options, it's inside Security but idk if that's the same for your case. If you can connect some type of network to the unit then it will give it an IP address and from there there's multiple ways to get a shell pulled up. Look at meterpreter or netcat or reverse PHP shells if you don't have access to a browser directly on the device. If you do have a browser then just download a terminal from apkmirror and go from there.
[Security Discussion] Mare.android:
Freezing apps

Hi, I got Sony m4 aqua with android 6.01 and july 1 2016 security patch, no DM verity...

I would like to freeze few factory apps via adb's pm disable command (or any other way possible).

I've tried to run "su pm disable package.name" but the su command is not recognized for some reason.

I am Linux noob but I got android studio with SDK and NDK installed on lubuntu machine (got it also on win7 machine).

Can someone explain me the steps to take in order to gain root access via adb (or any other way) to be able to freeze apps?
[Security Discussion] elliwigy:
well you are not correct when it comes to my answer.. i said you do not need terminal on phone all you need is ADB.. I did not however mention at all that it wouldnt work in terminal, simply that it is not needed and if they have adb thats all they need as well to dirty cow.. basically you need one or the other or both.. both is prefferred since certain tools have access to certain areas on the device.. but yes, if you get creative you can give yourself access using either method..

i assumed however if its an frp locked phone they might not have ability to use terminal on the device, also not sure if theyd have adb access either without usb debugging on but who knows, every phone can potentially vary in these areas

edit: looking back at the post i replied to he stated its frp locked and couldnt get into phone to use an emulator to adb.. based on this i was advising he doesnt need emulator, he only needs adb.. since he cant access frp locked device, only option is to adb dirtycow until he at least can bypass frp then he can use emulator if he wishes.. so not sure how this information can be untrue when you yourself said it can be utilized via adb and/or emulator?
[Security Discussion] trjv:
Don't get so defensive brah lol. I think you're a little mixed up with what is possible on FRP locked devices. You absolutely cannot use ADB on FRP locked phone's, period. At least, not on any of the more recent firmwares. If that were the case then there would be plenty of ways to bypass because SHELL has higher privileges than default terminal emulators have.

On the other hand, there are dozens of methods to get into FRP locked phones far enough to install apps and access 99% of the device while still in a locked state. Dirty-c0w, being actually a Linux exploit that just so happens to work on Android, by default has nothing to do with ADB. If you look at the source files you'll see that you can do a standalone compile to get the binaries, they just utilize adb and the fact that you can send client side shell commands through it to access the files once they push them to a device. But that's not the only way to get them on a device nor access them once they're on there. Not trying to argue or anything just trying to inform of what I know from experience.
[Security Discussion] elliwigy:
loool.. he cant use terminal or adb so he cant use dirty cow at all until he bypasses frp.. and its not 99%.. with each update practically they block common methods unless he of course gets it unlocked via 3rd party means
[Security Discussion] trjv:
I don't even know who were referencing at this point and like I said I'm not here to argue. If referencing an FRP locked device then idc what anybody says there's always a way around the initial Android security measures. They made FRP, dozens of ways to get to a browser = installation of plenty of apps. They encrypted devices with 7.0, yet left a blatant access to /sdcard right from Settings. Looking back over the last couple pages I really don't even know who you're talking about because the only dude that mentioned no access to either was about Android auto and I'm pretty sure FRP wasn't even mentioned. I'm not sayin YOU don't know what you're talking about, but I don't know what you're talkin about lol. Anyways I'm over it.
[Security Discussion] elliwigy:
it was this guy:
[Security Discussion] aamszia:
trjv@

Motorola XT1097 and XT1096 ( 5.1 ) ( FRP ) ( August Security )

terminal & termux installed but i don't know what to do .. :)
[Security Discussion] D1kiy:
Hello. Can somebody give me run-as binary for armv7?

I found this https://build.nethunter.com/android-tools/dirtycow/

arm64 works well for me and I can execute all what I need, but armv7 on my other phone gives me such output:
[Security Discussion] trjv:
5.1 like you mean Lollipop 5.1? Just use quick shortcut maker and choose the login option for Google account manager with it. Or use Rootjunkys FRP Bypass app for a quicker access to it.
[Security Discussion] aamszia:
Google Login by browser not works on this models .... always gives error in Login ..

last April security ( 5.1 ) we use to temp root the phone by king root & paste the command via terminal emulator to bypass the security .

but in August security ( ROOT FAIL )
[Security Discussion] trjv:
Upgrade your version of Google Account Manager then. By default it doesn't let you downgrade it for newer firmwares but even on the newest firmware it will let you upgrade it by apk. Use Google Account Manager 6.0, that one seems to be the winner for most devices.
[Security Discussion] kenosis:
what is the next step after you get "root@[xxx]: /home/[name]#" ?