yashsingh1/xdaforums huggingface dataset:
[Fire TV General] Ultraschorsch:
Ok, still no luck. Neither WiFi nor wired connection did the trick. su still can't be found.

Here's my complete try if someone wants to take a look and help me here. Thanks in advance!

jan@jan-P560 ~/Schreibtisch $ cd dirtycow_firetv1_bueller/
jan@jan-P560 ~/Schreibtisch/dirtycow_firetv1_bueller $ adb push dirtycow /data/local/tmp
126 KB/s (13784 bytes in 0.106s)
jan@jan-P560 ~/Schreibtisch/dirtycow_firetv1_bueller $ adb push su /data/local/tmp
316 KB/s (75348 bytes in 0.232s)
jan@jan-P560 ~/Schreibtisch/dirtycow_firetv1_bueller $ adb push ip_script /data/local/tmp
2 KB/s (135 bytes in 0.054s)
jan@jan-P560 ~/Schreibtisch/dirtycow_firetv1_bueller $ adb shell
shell@bueller:/ $ chmod 755 /data/local/tmp/ip_script
shell@bueller:/ $ chmod 755 /data/local/tmp/dirtycow
shell@bueller:/ $ cp /system/bin/ip /data/local/tmp
shell@bueller:/ $ ./dirtycow /system/bin/ip ip_script
/system/bin/sh: ./dirtycow: not found
127|shell@bueller:/ $ cd data
shell@bueller:/data $ cd local
shell@bueller:/data/local $ cd tmp
shell@bueller:/data/local/tmp $ ./dirtycow /system/bin/ip ip_script
WARNING: linker: ./dirtycow: unused DT entry: type 0x6ffffffe arg 0x600
WARNING: linker: ./dirtycow: unused DT entry: type 0x6fffffff arg 0x1
warning: new file size (135) and file old size (165484) differ

size 165484

[*] mmap 0xb6e74000
[*] exploit (patch)
[*] currently 0xb6e74000=464c457f
[*] madvise = 0xb6e74000 165484
[*] madvise = 0 1048576
[*] /proc/self/mem 1723858944 1048576
[*] exploited 0xb6e74000=732f2123
shell@bueller:/data/local/tmp $ cat /system/bin/ip
#!/system/bin/sh
mount -o remount,rw /system
cp /data/local/tmp/su /system/xbin
chmod 4755 /system/xbin/su
/data/local/tmp/ip "$@"
shell@bueller:/data/local/tmp $ exit
jan@jan-P560 ~/Schreibtisch/dirtycow_firetv1_bueller $ adb kill-server
jan@jan-P560 ~/Schreibtisch/dirtycow_firetv1_bueller $ adb start-server
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
jan@jan-P560 ~/Schreibtisch/dirtycow_firetv1_bueller $ adb connect 192.168.168.28
connected to 192.168.168.28:5555
jan@jan-P560 ~/Schreibtisch/dirtycow_firetv1_bueller $ adb shell
shell@bueller:/ $ su
/system/bin/sh: su: not found
127|shell@bueller:/ $ cd data
shell@bueller:/data $ cd local
shell@bueller:/data/local $ cd tmp
shell@bueller:/data/local/tmp $ su
/system/bin/sh: su: not found
127|shell@bueller:/data/local/tmp $ ls
adblink
dirtycow
ip
ip_script
server.apk
su
shell@bueller:/data/local/tmp $
[Fire TV General] JeffDC:
Have you verified the ip (on cable, no wifi, before you start the root process?) I wonder if you can ping the address first?
[Fire TV General] Ultraschorsch:
I am not sure if I understand you correctly. I started with the old IP (wired), connected with ADB, did the root process, changed the IP (wired), connected with ADB.

And if I'm able to connect with ADB I should be able to ping the device, or did I understand you wrong?
[Fire TV General] JeffDC:
Yes you are correct, if you are connected correctly, you should be able to ping the IP and receive the responses/confirmation that you are connected/have the correct IP.
[Fire TV General] Ultraschorsch:
Ok, so I did everything correctly, right?
[Fire TV General] JeffDC:
I'm wondering if the chmod 755 for the directories would need to come before the xfer of the files to the respective directories? Are some of those directory (security) permissions initially set to deny copying files into them, as they are system directories?

I have not examined the script/files to run dirty cow, however, your output is helpful. What is this? warning: new file size (135) and file old size (165484) differ. Is that size difference supposed to be changed after a file re-write/write over?
[Fire TV General] santamanga:
Hallöchen Jan,

you are in /data/local/tmp and when entering su, it looks for su in your path but not in the actual directory.

It searches for su in /system/bin/sh

so if su works, try calling it with the whole path: /data/local/tmp/su

Also, in your dirtycow output there was a file not found. I haven't looked into the script, but there seems to be the error.
[Fire TV General] Ultraschorsch:
I will check that tomorrow. But thanks for sharing your thoughts on m problem!
[Fire TV General] santamanga:
Hi. Could you please try to replace ping ?

I'm at my parents now and connected to their fire stick with 5.2.1.1 and had

#top | grep root | grep /system/bin

running and saw ping started by root when searching for updates or fiddeling around in the settings. I'm not sure what triggers it.

---

Okay, why it's not working for me is, because the dirtycow exploit doesn't replace the file as should.

I used the dirtycow_firetv1_bueller.zip attachment from http://xdaforums.com/showpost.php?p=69673026&postcount=48 and I also tried the Dirtycow.zip arm binary from http://xdaforums.com/showpost.php?p=69640725&postcount=34

shell@montoya:/data/local/tmp $ ./dirtycow /system/bin/ping ip_script
WARNING: linker: ./dirtycow: unused DT entry: type 0x6ffffffe arg 0x600
WARNING: linker: ./dirtycow: unused DT entry: type 0x6fffffff arg 0x1
warning: new file size (137) and file old size (30160) differ

size 30160

[*] mmap 0x400e6000
[*] exploit (patch)
[*] currently 0x400e6000=464c457f
[*] madvise = 0x400e6000 30160
[*] /proc/self/mem -1048576 1048576
[*] madvise = 0 1048576
[*] exploited 0x400e6000=464c457f

if I check the md5 checkums, I can also see that the ping binary doesn't differ. Hence, cat the binary is not the ip_script.

The problem is not to find a binary called as root, it's the dirtycow exploit produces an error. Anyone has a compiled one for 5.2.1.1 ? The fire tv stick has ARMv7-A.

edit:

Okay, I understand it now: it doesn't work with sellinux.

Maybe someone will figure it out with https://github.com/scumjr/dirtycow-vdso
[Fire TV General] dzebrys:
no, aftv does not use vDSO

127|shell@bueller:/data/local/tmp $ grep vdso /proc/self/maps

1|shell@bueller:/data/local/tmp $

this is interesting, maybe sth will hatch from it

https://github.com/timwr/CVE-2016-5195/issues/9

https://github.com/jcadduono/android_external_dirtycow
[Fire TV General] Ultraschorsch:
Hallöchen Santamanga :)

Well, now it seems to "see" SU but I am not allowed to use it

127|shell@bueller:/ $ /data/local/tmp/su
/system/bin/sh: /data/local/tmp/su: can't execute: Permission denied

But you have said that there seem to be some missing files. So there's pretty much nothing left for me to do but to wait for a different version of dirtycow, right?
[Fire TV General] santamanga:
http://www.aftvnews.com/how-to-root-the-amazon-fire-tv-using-the-dirty-cow-vulnerability/

Hi Jan, plese check the guide, if your Firmware Version is supposed to work with dirty cow.
[Fire TV General] Ultraschorsch:
Thanks for the link. Seems like I am out of luck with 5.0.5.1...
[Fire TV General] rix1337:
Am I thus out of luck with my 2 shiny 5.2.1.1 tv sticks? :confused:
[Fire TV General] JeffDC:
for now
[Fire TV General] slater_g:
Nice, my guide is on AFTVNews! :)
[Fire TV General] meber:
I'm guessing I just bricked my unit. I had an old Fire TV in storage - I turned it on and I was on version 51.1.5.3 so I used the dirty cow exploit listed here. It worked great! I thought to myself lets keep going and I tried to downgrade so I could unlock the bootloader. Come to find out you can only do that if you are on version 51.1.4.0 or older. My unit doesn't power on - I'm guessing I tripped the efuse - am I out of luck?
[Fire TV General] adam_ky:
I'm having a problem doing this.... And its pushing the files believe it or not. I don't have access to /data/local/tmp/ folder.. I double checked this with a few file explorers but seems I have no way to move files there .

I was on 5.11.1.4.3 and it had an update to 51.1.6.3 so I took that thinking it may help get me along. Still tho I can't push to the data folder :(

Any help?

I'm on fire TV 1 and have rooted several of these devices. Just ran into a wall here. To my surprise it went after the 51.1.6.3 update instead of the latest. Perhaps it updates in stages. If it will update to the early os5 I would be set. Its a risk tho.

But that's what I'll do as a last resort tho. Let it update and hope it lands on 5.0.1
[Fire TV General] Kramar111:
[MENTION=5704606]adam_ky[/MENTION]

/data/local/tmp
[Fire TV General] adam_ky:
I'm sorry, that's what I meant. Clerical error.

/data/local/tmp/

Same case though. I can't push anything on this box to anywhere in the data or sub folders.

Thanks for your response though any further help would be appreciated.

Edit: I gave up and took the risk of letting it update.. Went to the first os5 firmware and I rooted and installed twrp from there. So all is good.

Its a really great thing that the updates seem to go in steps and not straight to the latest available :)
[Fire TV General] matze19999:
--- DELETED ---
[Fire TV General] slackbladder:
Hi, adam_ky,

Could you explain to me please how you managed to stop your firetv from rebooting and installing further updates please.

I was also on firmware 51.1.4.0, but stupidly forgot to pull the plug on my firetv when i had an upgrade from my isp, and my dns got changed.

this allowed my unit to update to 51.1.6.3, at the time there were no other updates so I quickly put in the opendns server details to my router and no more updates.

I would like to get this 1st gen rooted but I believe it has the efuse problem.

could you please let me know what you did,.... would be really helpful if you could..

cheers..

slackbladder.
[Fire TV General] Bren123:
Does this work on 5.2.4.0?
[Fire TV General] Ultraschorsch:
You can check here: http://www.aftvnews.com/how-to-root-the-amazon-fire-tv-using-the-dirty-cow-vulnerability/
[Fire TV General] tehlers:
Fire TV Stick 5.2.1.1 rootable with dirtycow

Hello,

I just can confirm, that Fire TV Stick (montoya) on version 5.2.1.1 is rootable through dirtycow. It actually took me 5 days of research and trying. I'll not post a step by step howto, but some hints. At first you compile the dirtycow.c with toolchain for android and you need the su binary from SuperSU. You will notice, that root in nearly all selinux contexts can't read emulated sdcard, nor /data/local/tmp, while shell user can only write to these locations. So already data exchange between shell and root is very problematic. But of course you can use dirtycow, but only for small files.

Here are the hints:

/system/bin/watchdogd is started as root in context init. It can remount /system (but cannot write to any directory in /system) and read/write raw devices.

Exchange /system/bin/vcdbg (it's fairly big) with su. This can be used to start su in the exchanged watchdogd shell Script, like:

#!/system/bin/sh
/system/bin/vcdbg -ad

Reboot, now you can use "vcdbg -c <command>", e.g. test it with "vcdbg -c id". Then do something like:

vcdbg -c mkdir /data/tmp
vcdbg -c chmod 777 /data/tmp
vcdbg -c dd if=/dev/block/platform/sdhci.1/by-name/system of=/data/tmp/system.img
vcdbg -c chmod 777 /data/tmp/system.img
vcdbg -c chmod 777 /data
cp -a /data/tmp/system.img /data/local/tmp/system.img

And

adb pull /data/local/tmp/system.img

Then loop-mount the image in your computer, add su, supolicy, libsupol.so and SuperSU.apk (you see files and needed locations in the pre-rooted images). Also watch out for the default contexts these files need to be in (u:object_r:system_file:s0). If you have a linux without active selinux, copy an existing file, e.g.:

/root/temp/mount/system/bin # ls -laZ ip
-rwxr-xr-x 1 root 2000 u:object_r:system_file:s0 165484 6. Aug 2016 ip
/root/temp/mount/system/bin # cp -a ip su
/root/temp/mount/system/bin # cat /root/SuperSU/su > su
/root/temp/mount/system/bin # ls -laZ su
-rwxr-xr-x 1 root 2000 u:object_r:system_file:s0 75364 5. Aug 2017 su

push back the file to /data/local/tmp/system.img. Now you need to find a way to get this file readable for root. I did that like this:

cat /data/local/tmp/system.img | vcdbg -c 'echo "$(cat)" > /data/tmp/system.img'

Now check size and write everything back with dd:

ls -la /data/tmp/system.img
vcdbg -c dd if=/data/tmp/system.img of=/dev/block/platform/sdhci.1/by-name/system

Reboot and you are fully root. :) Afterwards you can install TWRP and install latest pre-root image.

Best

Tim
[Fire TV General] sumwong:
[MENTION=6874029]tehlers[/MENTION]: thank you for this! Maybe you can help me on my 5.2.1.1 montoya. I compiled dirtycow (timwr/CVE-2016-5195) for android21/armeabi-v7a and pushed it to the stick. Running it on /system/bin/watchdogd and /system/bin/vcdbg does nothing unfortunately. There are no changes to the files, no matter what I do. I tried a few pre-compiled binaries for dirtycow from this thread and still no changes. I'm fairly new to this. Any chance you could point me into the right direction?
[Fire TV General] tehlers:
Hi,

I'll try. :)

At first: I used exactly the same implementation of dirtycow. You need to pay attention, that you (in contrast to the other dirtycow implementations) give as arguments "./dirtycow src dst", instead of "./dirtycow dst src".

Second thing is, that it only works for a few bytes, and not always. But since it checks what bytes still actually differ, you can go further with every next round. I wrote something like this:

exit=1; while [ "$exit" != "0" ]; do ./dirtycow /data/local/tmp/watchdogd_new.txt /system/bin/watchdogd; exit=$?; echo $exit; done

You should first try it with e.g. /system/etc/hosts, exchange "127.0.0.1" with e.g. "127.0.0.2", this should go fast (but does not need to work in the first round).

I may also note that I made the shellscripts always exactly as big as the original binary (and always saved the original binary in /data/local/tmp "cp -a /system/bin/watchdogd /data/local/tmp/" before doing anything). So let's say (this is from current firmware, not 5.2.1.1):

shell@montoya:/data/local/tmp $ ls -la /system/bin/watchdogd
-rwxr-xr-x root shell 5288 2017-06-10 01:45 watchdogd

And you now have a shellscript "watchdogd_new.txt" (this is on my computer, "bc" is not part of the firmware; but the rest would also work in the stick):

> ls -la watchdogd_new.txt
-rw-r--r-- 1 root root 39 Aug 12 19:29 watchdogd_new.txt
> echo "5288-39" | bc
5249
> i=0; while [ "$i" != "5249" ]; do echo >> watchdogd_new.txt; let i=$i+1; done
> ls -la watchdogd_new.txt
-rw-r--r-- 1 root root 5288 Aug 12 19:31 watchdogd_new.txt

And last thing I would like to note: When finally exchanged everything of the binary and you want to reboot. You should first play a video from e.g. Amazon Video and skip around a bit. That has the effect, that the kernel syncs dirty caches to flash, because it needs the memory for playing the video and caching it. Since you poke with dirtycow something in the cache, a "sync" does not synchronize this to disk (or flash in this case).

I hope this helps.

Best

Tim
[Fire TV General] sumwong:
Yup! I had tried so many versions of dirtcow that my script called it with paramters in the wrong order. Also I hadn't read up on the exact mechanics of dirtcow so changes to the files were incomplete, exactly like you pointed out, probably because I just rebooted directly after dirtcow finished successfully. I am now in the process of pulling the system image and will report back if all goes well. Seems straight forward from here. Thanks again for the great work and for saving me all those hours of work!
[Fire TV General] Spider1996:
All files are in that folder (I listed them with ls -R). While running ./run_me.sh, the adb shell only returns a "./run_me.sh: can't execute: Permission denied"

Thanks for your work anyway. :)
[Fire TV General] tehlers:
Hi,

ok, you unziped on a windows system, right? I'll update the description above for permissions.

Best Tim
[Fire TV General] Spider1996:
yeah, currently I use Windows. Got a Linux System here too if needed. Does it make any difference? I execute the script right in the shell.
[Fire TV General] tehlers:
Hi,

on a linux system the permissions would have been correctly unzipped and transferred. The rest should be the same for windows or linux, just do "chmod 755 dirtycow run_me.sh run_me2.sh" in the directory on the stick.

Best Tim
[Fire TV General] Spider1996:
Now it keeps repeating the attached message
[Fire TV General] tehlers:
looks good, let it keep doing dirtycow. :)

EDIT: You are currently in the state, where I said: "Second thing is, that it only works for a few bytes, and not always. But since it checks what bytes still actually differ, you can go further with every next round."
[Fire TV General] Spider1996:
Okay, after that is done, I see I have to play a prime video or something like that. How to do that without Wifi connection? If I connect, the Stick wants to update I think. (Still waiting for Dirtycow to end the second process now.)
[Fire TV General] tehlers:
mhh, yeah I have disabled the update domains in my nameserver, so I could use the stick. I think what sumwong wrote

should disable updates (or maybe "pm uninstall -k --user 0 com.amazon.device.software.ota"). Maybe for this case someone else with experience on that could help?
[Fire TV General] Spider1996:
I read somewhere, thats only possible on rooted devices. Do I need to play something from Amazon Prime? Maybe it is possible to push a video to the device and a file explorer app?

Edit: Now it asks for that prime video. It is possible to block this: http://www.aftvnews.com/how-to-block-software-updates-on-the-amazon-fire-tv-or-fire-tv-stick/#router
[Fire TV General] tehlers:
you just need to allocate memory, that the stick is writing the changes on flash. It may already work by pushing a large file in /sdcard or /data/local/tmp (and delete it afterwards). If you want to try if you poked around enough, you can try to reboot and check with "vcdbg -c id". If this command gives you "uid=0(root) gid=0(root) context=u:r:init:s0", then everything has worked, otherwise start over with "./run_me.sh".

If you want to keep the original contents of the binaries watchdogd and vcdbg, save them from /data/local/tmp/ before starting over, because my script will overwrite them with every call of "./run_me.sh" and they may have already changed a few bytes.

Best
[Fire TV General] Spider1996:
okay blocked everythying in Method 3. No Amazon Service, but YouTube works/was possible to download. So playing some Videos from there....

So it's late in germany now and vcdbg -c id gave me "Segmentation fault". Trying again tomorrow
[Fire TV General] sumwong:
Probably because the changes haven't been written to flash yet, as stated above. But seg faults also happened to me before I had the *new* vcdbg (su) padded to the exact length of vcdbg and also when dirtycow hadn't yet overwritten the entire file correctly (it returned success but after I let it dump to flash by watching a few videos and restarted dirtycow it found changes again. Thats what I meant by unstable).

I havent looked at how tehlers auto root package works - but you might want to check the size of the su file and compare to the original vcdbg. Also you might want to try executing the entire process more than once to make sure dirtycow has done the entire job.

pm disable is *not* reliable so you should block the update servers through your router. Or create a temp ad hoc wifi network for your aftv through your phone or computer where in turn you have blocked the domains through dns or a similar method (just thinking out loud here ;)
[Fire TV General] Spider1996:
hmm okay, I am only a normal user. I don't understand things like this. :D

Now it's doing the two lines "Warning: linker..." only one time and in 2 Seconds for watchdogd like it is skipping it. Maybe the vcdbg is "failing"?

I'll tried it 6 times yet but no change. I will give it 5 more attempts and then I will wait for other instructions. (Im something like your tester. I don't need my FireTV Stick for now because there was no root for it.)

And yeah, I used the childlock from my fritzbox to disable the Amazon Servers on my Guest Network. Then I connected my FireTV to that network.
[Fire TV General] tehlers:
Hi,

don't get frustrated. :) You are half the way. No worries, I prepared the files in correct length and if watchdogd is like skipping and gives you in 2 seconds exitcode "0", then the changes are done and synced for watchdogd, so you only have to get the same for su in vcdbg.

Cheers Tim
[Fire TV General] Spider1996:
okay Im done. Simply played a Video vom the South Park App for 40 Minutes. (I wasn't interacting with the video, I just slept an hour). Now it skips all from the run_me.sh. But I can't run run_me2.sh. It aborts with "(run_me.sh) went wrong, please try again".

vcdbg -c id returns "uid=0(root) gid=0(root) context=u:r:init_shell:s0" :)

Oh is see, your script waits for a "uid=0(root) gid=0(root) context=u:r:init:s0". The "_shell" is missing
[Fire TV General] tehlers:
Hi,

congrats! First round done. Yeah, that's the thing, that I could not check. I thought it would return "context=u:r:init:s0" and checked for that in run_me2.sh.

I'll put the new script on this post. When you are finally successful, I'll update it in the original zip-file, too.

Best Tim
[Fire TV General] Spider1996:
On ADB Shell I run "rm run_me2.sh" and "ls" if the file was gone. Then pushed the new file again. Set Permissions. Tried - not working. Simply checked "adb pull /data/local/tmp/auto-root-fireos-5.2.1.1/run_me2.sh run_mepull.sh" and this gets the new file back on my computer. It is the same error like before.

Thats the full vcdbg command from console (It's returning two lines, first is "vcdbg -c id" and the second one the "uid..."):

shell@montoya:/ $ vcdbg -c id
vcdbg -c id
uid=0(root) gid=0(root) context=u:r:init_shell:s0
shell@montoya:/ $
[Fire TV General] tehlers:
Hi,

mhh, that's weird, I could not remember that vcdbg as su did echo the command in addition. The final SuperSU, when fully installed, is not echoing the command either. If you want to try anyway, this script should work with the additional output. I hope the transfer with cat to /data/tmp is working, but script would stop if not (I'll check md5 of the file before overwriting).

Best Tim
[Fire TV General] Spider1996:
Error still present "Step 1 (run_me.sh) went wrong, please try again"
[Fire TV General] tehlers:
Hi,

ok, next try. :) I want to fix the check, not only disable it.
[Fire TV General] Spider1996:
Works. "Now copying system.img to /data/tmp" I'll say when it's ready/the next "bad" thing happens.

Edit: It seems to take very long to copy the files. Maybe you should add this to the text... Still waiting :)
[Fire TV General] tehlers:
And? Working? Should be ready by now....
[Fire TV General] Spider1996:
Nope still copying data. btw if you need for any reason -> TeamViewer

Edit: Done via TeamViewer. Thanks for your work. I waited so long for root. :)
[Fire TV General] tehlers:
Just for the record: We successfully rooted the stick from [MENTION=4398758]Spider1996[/MENTION]. All changes needed are in the updated file on androidfilehost.com in post: #109
[Fire TV General] Mattwmaster58:
This wouldn't work for a Firestick with version 5.2.4.1 would it?
[Fire TV General] tehlers:
Hi,

no, definitively not. I think 5.2.1.1 was the last version with dirtycow bug. The dirtycow bug was found in October 2016, where 5.2.1.1 was released (and was not fixed there, as we can see). The next version, according to http://www.aftvnews.com/amazon-fire-tv-fire-tv-stick-software-update-history/ was released in January 2017 (5.2.1.2) with release notes "Security Patches". I'm pretty sure, that this was the dirtycow fix.

Best Tim
[Fire TV General] RagManX:
Not related to this specific message, but just wanted to say thanks for your work and letting me know about this via private message. I haven't had a chance to hook up my firestick and try this, but I'm confident I won't have problems getting this to work. Looking forward to having a chance to try this and get my stick rooted.