Closed frostworx closed 1 year ago
When you make the PR would you please use the log_error function to make it clearer please? I'd just like to keep it consistent for ease of use
I noticed that you don't exit on failure. Should I modify log_error to exit on failure?
if it was already modified, then you already had it unlocked. It was supposed to fail that way. I will modify the code to check if lk is already patched, to give more proper user experience
ah that explains. thank you both again for your patient help.
I noticed that you don't exit on failure. Should I modify log_error to exit on failure?
Yes please, that would be great.
@frostworx if the program helped you unlock the echo, I need something from you in return.
Once you enable adb using fos_flags, could you please run the following command in adb shell and share the output
strings /dev/block/platform/bootdevice/by-name/userdata | grep biscuit | sort -u
If I recall correctly the OTA URLs are stored in a file that is easily accessed with cat (it is also much quicker), but I don't have access to my echo now and I don't know the file name off the top of my head
If I recall correctly the OTA URLs are stored in a file that is easily accessed with cat (it is also much quicker), but I don't have access to my echo now and I don't know the file name off the top of my head
on 5.x.x.x firmware, the url are in a sqlite database. The command I shared will help getting url from both the cases
It will even fetch update urls from free space which means if file is overwritten we still get the urls older than whats stored there
Ah ok, that makes sense
@frostworx if the program helped you unlock the echo, I need something from you in return.
Once you enable adb using fos_flags, could you please run the following command in adb shell and share the output
strings /dev/block/platform/bootdevice/by-name/userdata | grep biscuit | sort -u
I'd be glad to provide that string, but I have trouble to get a adb connection. Doesn't seem to make any difference if I hold the "circle" button while booting or not , mtk (mtkclient 1.63-1)
always exists silently with
...
LTools - Loading payload from mt8163_payload.bin, 0x258 bytes
PLTools - Kamakiri / DA Run
Kamakiri - Trying kamakiri2..
Kamakiri - Done sending payload...
PLTools - Successfully sent payload: /usr/lib/python3.11/site-packages/mtkclient/payloads/mt8163_payload.bin
Port - Device detected :)
Main - Connected to device, loading
Main - Using custom preloader : preloader_no_hdr.bin
Mtk
Mtk - [LIB]: Preloader detected as shellcode, might fail to run.
Mtk - Patched "Patched loader msg" in preloader
Main - Sent preloader to 0x201000, length 0x80000
Preloader - Jumping to 0x201000
Preloader - Jumping to 0x201000: ok.
Main - PL Jumped to daaddr 0x201000.
Main - Keep pressed power button to boot.
will play around with it later. sun is shining and my wife is waiting :)
Holding the circle only puts it in "fastboot" mode, have you used fos_flags to enable ADB yet? If not, just use the default/recommended ones. Once you have, as soon as the echo fully boots, ADB should recognise it.
thanks for the hint. No I haven't. Will check later what needs to be done to use fos_flags
(never heard of those before, I'm no android person) :)
No problem, it's just an option in the CLI (option 2 in rooting tools), you'll have to boot holding the circle button and select that option, it only takes a few seconds
fos_flags are a FireOS specific developer tool, so you won't find much information on them
thanks for the explanation :) just re-tried with your current master, also made sure before that the patch was applied:
[15:05:01] SUCCESS: Dumped lk_a.bin from device.
[15:05:01] INFO: LK is already patched. Exiting...
but when trying to set the fosflags, my device is not detected (the LEDs do not do anything at all btw)_:
Select an option: > 1
1: Root or restore
2: Calculate and set fos_flags
3: Exit
Select an option: > 2
[15:05:46] INFO: Please only use this option once you have run the rooting process. Press Ctrl+C if you wish to cancel
Do you want to use recommended options? (y/n) > y
[15:05:48] INFO: Setting fos_flags to 0xa3 using fastboot...
[15:05:48] INFO: Please replug your device now, holding the uber (dot) button. When you see a green LED ring, press enter to continue...
[Waiting for enter press...] >
< waiting for any device >
(I also made sure that the dot button is at the correct position :))
Looks like echo cli doesn't do anything to pass the preloader. when its on that message, open a new terminal and run mtkclient, the same command you were using to boot normally but keep the dot button pressed. That should put echodot in fastboot mode(green ring light) which will then be detected by echocli
thanks for the hint! This didn't work unfortunately. the first terminal remains stuck with
[Waiting for enter press...] >
< waiting for any device >
after having run mtk in a 2nd terminal:
[root@mini EchoCLI]# mtk plstage --preloader=preloader_no_hdr.bin
MTK Flash/Exploit Client V1.6.3 (c) B.Kerler 2018-2023
Preloader - Status: Waiting for PreLoader VCOM, please connect mobile
Port - Device detected :)
Preloader - CPU: MT8163()
Preloader - HW version: 0x0
Preloader - WDT: 0x10007000
Preloader - Uart: 0x11002000
Preloader - Brom payload addr: 0x100a00
Preloader - DA payload addr: 0x201000
Preloader - CQ_DMA addr: 0x10212c00
Preloader - Var1: 0xb1
Preloader - Disabling Watchdog...
Preloader - HW code: 0x8163
Preloader - Target config: 0x5
Preloader - SBC enabled: True
Preloader - SLA enabled: False
Preloader - DAA enabled: True
Preloader - SWJTAG enabled: True
Preloader - EPP_PARAM at 0x600 after EMMC_BOOT/SDMMC_BOOT: False
Preloader - Root cert required: False
Preloader - Mem read auth: False
Preloader - Mem write auth: False
Preloader - Cmd 0xC8 blocked: False
Preloader - Get Target info
Preloader - BROM mode detected.
Preloader - HW subcode: 0x8a00
Preloader - HW Ver: 0xcb00
Preloader - SW Ver: 0x1
Preloader - ME_ID: EA43742DF669F9A83859B6BB676A5389
PLTools - Loading payload from mt8163_payload.bin, 0x258 bytes
PLTools - Kamakiri / DA Run
Kamakiri - Trying kamakiri2..
Kamakiri - Done sending payload...
PLTools - Successfully sent payload: /usr/lib/python3.11/site-packages/mtkclient/payloads/mt8163_payload.bin
Port - Device detected :)
Main - Connected to device, loading
Main - Using custom preloader : preloader_no_hdr.bin
Mtk
Mtk - [LIB]: Preloader detected as shellcode, might fail to run.
Mtk - Patched "Patched loader msg" in preloader
Main - Sent preloader to 0x201000, length 0x80000
Preloader - Jumping to 0x201000
Preloader - Jumping to 0x201000: ok.
Main - PL Jumped to daaddr 0x201000.
Main - Keep pressed power button to boot.
did the echodot light changed to green?
no, still no leds at all
could it be possible that the hardcoded slot a
, which is still required here is the problem? just wild guessing :)
no, still no leds at all
ok, I am trying on my echo dot. let me see how it goes
I see, this thing is broken. Will need some time to fix the same
Sorry @viraniac is it the patcher that's broken or is it my code? Also as I'll be away for a week feel free to push changes, I added you as a collaborator so you should have push access
Its bunch of things that were broken. Starting with my own code, the lk was not really getting patched. You forgot to clear rpmb, and also flashing of lk was broken because of '.bin' in gpt key. I am raising a PR to fix all these things.
Also the preloader_no_hdr.bin can not be used to boot. I will fix a new PR tomorrow with fix for the same
@frostworx could you please uploader your preloader somewhere and share the link?
@viraniac
just pushed it here
edit: (removed the fork after the further discussion below)
thank you for your help!
@Dragon863 have nice holidays! I will be away in a week :)
@frostworx There are two bad news for you and one semi good news.
Bad news is :
Possible Solution: One possible way to fix it will be to replace it with a preloader from a more recent 5.x.x.x update. You can find the ota urls here. You can try using a preloader from 5.5.5.4 ota for example.
Now for the good news: I just pushed some updates to this repo. So it might be possible for you to rerun the root stage and then you might be able to boot from the preloader_no_hdr.bin file. I am saying might as I am on latest 6.x firmware and haven't tested the 5.x patch part. This makes you a perfect test candidate to test if this works. I remember that when I was on 5.x, I had patched the preloader in 2 different places, but I don't remember how it was patched in other place.
So give it a try. If you are still not able to boot, download 5.5.5.4 ota file and extract it. Its just a zip file. Under images directory you will find the preloader. replace your preloader.bin with the preloader thats in images directory. Make sure to rename it to have the same name and then use restore. Then update your device and once its updated, retry the script
Thank you very much, @viraniac! Will play a bit with it within the next days (likely not today).
Chances are not bad that I created other preloader files before, as I stored multiple backups (also on another machine) during tests.
edit: most of the files have the same checksums, just one is different.
20170929_175429
(the broken one) vs 20211202_231918
(also has more rpmb related human readable strings)
Funny, I already downloaded the latest zip from the same url earlier yesterday, as I had the hope it could help with my first new dot. Haven't touched it yet though. I'll report back soonish.
- Chances are not bad that I created other preloader files before, as I stored multiple backups (also on another machine) during tests. edit: most of the files have the same checksums, just one is different.
Thats brilliant.
2. Funny, I already downloaded the latest zip from the same url earlier yesterday, as I had the hope it could help with my first new dot. Haven't touched it yet though. I'll report back soonish.
Thats one of the reason I started that thread. Other being the chances of finding an LK that can be used for creating a untethered exploit similar to firetvsticks and firetv tablets. Glad that it possibly going to help you revive your device.
There is also a possibility that those Echo dots are not running the factory firmwares and are updated sometime in the past. You can use the following to fetch userdata partition from echo dot and search it for OTA Urls. Than those OTAs can be used to get the correct preloader file. It will take about 7 minutes to fetch userdata partition from the devices with the following command
$ sudo ./mtk r --preloader ./mtkclient/Loader/Preloader/preloader_biscuit.bin userdata userdata.dump
$ strings userdata.dump | grep https | grep biscuit | sort -u
recovering my other preloader worked fine, also the rest of the further process did:
* * * Remove the short and press Enter * * *
[10:38:32] Init crypto engine
[10:38:32] Disable caches
[10:38:32] Disable bootrom range checks
[10:38:32] Load payload from brom-payload/build/payload.bin = 0x45C0 bytes
[10:38:32] Send payload
[10:38:33] Let's rock
[10:38:33] Wait for the payload to come online...
[10:38:34] all good
[10:38:34] Check GPT
Partitions:
{'kb': (2048, 2048), 'dkb': (4096, 2048), 'lk_a': (32768, 2048), 'tee1': (49152, 10240), 'lk_b': (65536, 2048), 'tee2': (81920, 10240), 'expdb': (98304, 20480), 'misc': (118784, 1025), 'persist': (131072, 32768), 'boot_a': (163840, 32768), 'boot_b': (196608, 32768), 'recovery': (229376, 32768), 'system_a': (294912, 1572864), 'system_b': (1867776, 1572864), 'cache': (3440640, 1605632), 'userdata': (5046272, 2605023)}
Would you like to root your device, or restore it?
[root/restore] > restore
[10:38:37] INFO: Data is 524288 and maximum size is not defined
[1024 / 1024]
[10:39:47] INFO: Restored preloader...
[10:39:47] SUCCESS: Restored device! If you experience any problems, please contact me.
[10:39:47] INFO: Backing up misc partition...
[10:39:47] SUCCESS: Dumped misc.bin from device.
[10:39:48] INFO:
This next step WILL brick your preloader, rendering your device unbootable without a computer, as this is a TETHERED exploit. This is a reversible change. Press enter if you understand the consequences and accept that I am not responsible for any damage to you device...
[10:40:41] INFO: Backing up preloader...
[10:41:04] SUCCESS: Dumped preloader.bin from device.
[10:41:04] INFO: Looks like this preloader was already cleared. Skipping clearing and backup steps...
[10:41:04] INFO: 6.x preloader detected, applying unlock patch
[10:41:04] INFO: Downgrading rpmb header
[10:41:05] INFO: rpmb downgrade ok
[10:41:05] INFO: Detected that device is using slot A.
[10:41:05] INFO: Backing up lk_a...
[10:41:51] SUCCESS: Dumped lk_a.bin from device.
[10:41:51] INFO: LK is already patched. Exiting...
still no green led, so I'll continue with your dumps (I guessed that it was you :)) later/soon (starting with the preloader from 5.5.5.4 as you suggested)
Couple of interesting thing from that output. Choosing restore restores the firmware and then continues with the rooting. Thats a bug. I will fix it in a bit.
During rooting we fetched LK from device and then EchoCLI said its already rooted. Which means the LK in your backup is also modified. Share the LK from backup directory with me, I will unpatch it and share it with you. Then the device should boot correctly after using that LK for restore
Pushed a fix. So now it won't run rooting when user chooses restore
Wait its not lk in backup directory thats modified. we are restoring wrong LK. Fixing it
Fixed. Now @frostworx you should be able to correctly restore the device
Tested end to end for both root, restore and fos_flags (default options) with 6.x.x.x firmware (6.5.6.0 to be precise). Every things works correctly now
@frostworx lets hope you will have a better user experience now atleast after upgrading your devices.
So will I be successful if I try rooting mine again? How confident are we that the procedure is now 100% working? ;)
If you are on latest firmware (any 6.x.x.x firmware thats released since last year december), then 100%, for older firmware lk modification works, preloader might not work correctly. You have to test and let us know
Thanks for all the work @viraniac :+1:
I try to find out which of my backed lks is unmodifed and restore that, in order to be able to correctly root my devices soon. Sorry for the confusion, I understood correctly that you do no longer require my patched lk anymore, right?
Thanks for all the work @viraniac 👍
I try to find out which of my backed lks is unmodifed and restore that, in order to be able to correctly root my devices soon. Sorry for the confusion, I understood correctly that you do no longer require my patched lk anymore, right?
@frostworx The LKs are not modified. It was a bug in the program that it was restoring patched lk instead of the backed up one. If you use latest changes, you should be able to boot from your device. You can use a 6.x preloader, in combination with your actual LK and the board would boot fine after restore. And then you should be able to root it again which should also work fine now.
@viraniac the current state, in combination with my multiple backups is a bit confusing for me tbh. I do have several lks with different checksums.
what I just tried was this: I recovered
e7b01435a0d9b005d54b9fabdece907f lk_a.bin (a lk from my backups which has a different md5 than most of the other lks)
c5e60986eda79580e2a2912ae1a6af57 misc.bin (always the same?)
2d174bf293cdc5423f9788221268459e preloader.bin (the preloader picked from the downloaded 5.5.5.4 bin)
the recover went fine:
* * * Remove the short and press Enter * * *
[17:50:46] Init crypto engine
[17:50:47] Disable caches
[17:50:47] Disable bootrom range checks
[17:50:47] Load payload from brom-payload/build/payload.bin = 0x45C0 bytes
[17:50:47] Send payload
[17:50:47] Let's rock
[17:50:47] Wait for the payload to come online...
[17:50:48] all good
[17:50:48] Check GPT
Partitions:
{'kb': (2048, 2048), 'dkb': (4096, 2048), 'lk_a': (32768, 2048), 'tee1': (49152, 10240), 'lk_b': (65536, 2048), 'tee2': (81920, 10240), 'expdb': (98304, 20480), 'misc': (118784, 1025), 'persist': (131072, 32768), 'boot_a': (163840, 32768), 'boot_b': (196608, 32768), 'recovery': (229376, 32768), 'system_a': (294912, 1572864), 'system_b': (1867776, 1572864), 'cache': (3440640, 1605632), 'userdata': (5046272, 2605023)}
Would you like to root your device, or restore it?
[root/restore] > restore
[17:50:53] INFO: Fetching misc partition...
[17:50:53] SUCCESS: Dumped misc.bin from device.
[17:50:53] INFO: Detected that device is using slot A.
[17:50:53] INFO: Restoring preloader...
[17:50:53] INFO: Data is 1048576 and maximum size is not defined
[2048 / 2048]
[17:53:14] INFO: Downgrading rpmb header
[17:53:15] INFO: rpmb downgrade ok
[17:53:15] INFO: Restoring lk_a partition...
[17:53:15] INFO: Data is 1048576 and maximum size is not defined
[2048 / 2048]
[17:53:59] SUCCESS: Restored device! If you experience any problems, please contact me.
afterwards I started rooting, which seems to have worked fine as well:
Would you like to root your device, or restore it?
[root/restore] > root
[17:55:39] INFO: Fetching misc partition...
[17:55:39] SUCCESS: Dumped misc.bin from device.
[17:55:39] INFO: Detected that device is using slot A.
[17:55:39] INFO:
This next step WILL brick your preloader, rendering your device unbootable without a computer, as this is a TETHERED exploit. This is a reversible change. Press enter if you understand the consequences and accept that I am not responsible for any damage to you device...
[17:56:28] INFO: Backing up preloader...
[17:56:51] SUCCESS: Dumped preloader.bin from device.
[17:56:51] INFO: Clearing preloader header
[8 / 8]
[17:56:52] INFO: 6.x preloader detected, applying unlock patch
[17:56:52] INFO: Downgrading rpmb header
[17:56:53] INFO: rpmb downgrade ok
[17:56:53] INFO: Backing up lk_a...
[17:57:39] SUCCESS: Dumped lk_a.bin from device.
[17:57:39] SUCCESS: Modified Little Kernel! Flashing back to device now.
[17:57:39] INFO: Data is 1048576 and maximum size is not defined
[2048 / 2048]
only the md5 of the preloader changed after that root command to
f877467bf6003c61a61a537a32dbdb9b preloader.bin
next I tried the fos_flags
command again, but still I get no green led and the process it looping forever waiting for any device.
running mtk plstage --preloader=preloader_no_hdr.bin
in a 2nd terminal didn't help as well.
yeah 5.5.5.4 preloader might not work. Try the one from 6.5.6.0 for example. You only need to change preloader. You can use same LK as before
I can share you my patched preloader so that you don't have to go through the process again
Preloader is here. Use this with mtk client and you should be able to get to fastboot
thank you for clarification and your patched preloaded. got it and will report back shortly :)
yay, thank you so much, @viraniac!
Select an option: > 2
[18:32:50] INFO: Please only use this option once you have run the rooting process. Press Ctrl+C if you wish to cancel
Do you want to use recommended options? (y/n) > y
[18:32:51] INFO: Setting fos_flags to 0xa3 using fastboot...
[18:32:51] INFO: Please replug your device now, holding the uber (dot) button. When you see a green LED ring, press enter to continue...
[Waiting for enter press...] >
< waiting for any device >
(bootloader) fos_flags set to a3
OKAY [ 0.059s]
Finished. Total time: 0.059s
[18:33:35] SUCCESS: Successfully set fos_flags! Rebooting...
Rebooting OKAY [ 0.002s]
Finished. Total time: 0.202s
(in combination with the 2nd mtk terminal, not sure if this would have been required, but it worked :))
aaand:
[root@mini EchoCLI]# adb shell
root@biscuit:/ #
strings /dev/block/platform/bootdevice/by-name/userdata | grep biscuit | sort -u
unfortunately there is no /dev/block/platform/bootdevice/by-name/userdata
but only
/dev/block/platform/mtk-msdc.0/
/dev/block/platform/soc/
Keep going chaps, I've almost got python3.8 built for my next rooting attempt...
@frostworx there should be userdata under /dev/block/platform/mtk-msdc.0/
or simply run find /dev -name userdata
@frostworx out of curiosity what version are you currently on? grep version.name /system/*.prop
Hi there, First of all, thanks for this promising project! :)
I bought an echo dot2 just to try it and it arrived earlier today. Unfortunately, I have to admit that I'm a bit lost already with rooting the devices. It could be opened up easily, but I'm not sure how to follow those instructions:
INFO: Please short the device as shown in the image at https://dragon863.github.io/blog/mainboard.jpg
My first guess to simply ground it somewhere while plugging it into usb was apparently wrong (would have been too easy :)) so I'm afraid I'll have to communicate through the tiny pins shown here:
https://forum.xda-developers.com/t/amazon-echo-dot-2-locked-hardware.3512349/#post-77059942
right?
The url to the "set of slides" below the picture is 404 btw, but the good old wayback machine has a copy:
https://web.archive.org/web/20190926005232/https://www.sans.org/cyber-security-summit/archives/file/summit-archive-1498230402.pdf
Would be great if you had a pointer into the right direction on how to short the device (still have (low) hopes that high precision soldering is not required :))