Fire 7 (2019, mustang) unbrick, downgrade, unlock & root - Fire Original Android Development

Make sure to read this guide completely before starting.
You will lose all data on the tablet, make a backup of important data before you start.
What you need:
- a Linux installation. Don't use a VM! Use a live USB, if you don't have Linux installed, but don't use a virtual machine.
- a microusb cable to connect your tablet to the PC
- (if you go with hw option) some way to open the tablet (pry tool, opening picks, etc)
- (if you go with hw option) something conductive (metal tweezers, a paper clip, a piece of wire, etc)
- (if you go with sw option) mtk-su from https://forum.xda-developers.com/android/development/amazing-temp-root-mediatek-armv8-t3922213
- amonet-mustang.zip from this post
- finalize.zip from this post
- update-kindle-NS6312_user_1827_0002517050244.bin: https://fireos-tablet-src.s3.amazon...ate-kindle-NS6312_user_1827_0002517050244.bin
- Magisk-v19.3.zip: https://github.com/topjohnwu/Magisk/releases/download/v19.3/Magisk-v19.3.zip
Install python3, PySerial, adb and fastboot. For Debian/Ubuntu something like this should work "sudo apt install python3 python3-serial android-tools-adb android-tools-fastboot".
0. Disconnect the tablet and all other Android devices from the PC.
1. Back up whatever important data you have on the device and perform a complete factory reset of the tablet. When going through the initial setup, don't connect to a network (see below on how to do that).
2. Disable or uninstall ModemManager from your Linux installation
3. At this point you need to get your tablet into the bootrom download mode. There are two ways it can be achieved.
a) If your tablet works, you can use the software method (which doesn't require opening the tablet) or the hardware method. Note that if something goes horribly wrong, you might still be required to open up the tablet.
b) If your tablet doesn't boot (bricked), you can only use the hardware method
----------------------------------------------------------------------------------------------------
Software method:
This will get you into bootrom mode by obtaining temporary root and temporarily bricking the device.
1. Download mtk-su from https://forum.xda-developers.com/android/development/amazing-temp-root-mediatek-armv8-t3922213
2. Enable developer mode and USB debugging on the tablet
3. Unzip the mtk-su archive
4. Transfer the executable to your tablet: "adb push arm/mtk-su /data/local/tmp"
5. Run "adb shell"
6. Keep the screen on and run the following commands in the shell on the device:
Code:
cd /data/local/tmp
./mtk-su
getenforce # Just to confirm it says Permissive
echo 0 > /sys/block/mmcblk0boot0/force_ro
dd if=/dev/zero of=/dev/block/mmcblk0boot0 bs=512 count=8
This is the sort of output you should see for that step:
Code:
[email protected]:~/Downloads/mtk-su $ adb shell
mustang:/ $ cd /data/local/tmp
mustang:/data/local/tmp $ ./mtk-su
New UID/GID: 0/0
mustang:/data/local/tmp # getenforce
Permissive
mustang:/data/local/tmp # echo 0 > /sys/block/mmcblk0boot0/force_ro
mustang:/data/local/tmp # dd if=/dev/zero of=/dev/block/mmcblk0boot0 bs=512 count=8
8+0 records in
8+0 records out
4096 bytes transferred in 0.001 secs (4096000 bytes/sec)
mustang:/data/local/tmp #
Don't close the console just yet.
Hardware method:
This will get you into bootrom mode by opening up the tablet and shorting a point to the ground.
1. Shut your device down and disconnect it from USB
2. Use a pry tool to remove the back shell from the tablet. Start at the bottom and work your way up. There are no cables between the back shell and the motherboard.
3. You will need to get something conductive and temporarily connect a point to the ground. A point suggested by @ggow is: https://forum.xda-developers.com/showpost.php?p=79683131&postcount=22. You will need to pop up the metallic shield to access it. Alternatively, there are multiple points on the back of the PCB which also work (marked as CLK/CMD/DAT0).
----------------------------------------------------------------------------------------------------
4. At this point if you went with software method, you should have a root shell open, and if you went with the hardware method you should have a capacitor or a testpoint grounded to the shield.
5. Now, open another terminal on your PC, extract amonet-mustang.zip, navigate to it, and run `sudo ./bootrom-step.sh`. It should print "Waiting for the bootrom".
6.
a) For the software method, you should already have the USB cable plugged in. Type "reboot" in the first terminal (the one you that's running "adb shell"). [If you're trying this for the second time because it didn't work for the first time, you won't have an "adb shell" terminal. In that case, just plugging the USB cable in should be enough.]
b) For the hardware method, ensure the short is applied and then plug in the USB cable.
7. You should see the following device appear in your "dmesg" log:
Code:
[1141765.113884] usb 3-1.4.3.1: USB disconnect, device number 59
[1141783.057101] usb 3-1.4.3.1: new full-speed USB device number 60 using xhci_hcd
[1141783.226498] usb 3-1.4.3.1: New USB device found, idVendor=0e8d, idProduct=0003, bcdDevice= 1.00
[1141783.226502] usb 3-1.4.3.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[1141783.506877] cdc_acm 3-1.4.3.1:1.0: ttyACM0: USB ACM device
This *must* be the device you see. If you see a "preloader" device instead, your short probably didn't work (for the hw method), or your system inexinexplicably didn't brick (for the sw method). Unplug everything and try again. If the tablet doesn't shut down, you might need to open it up and disconnect the battery.
8. The script should now tell you to remove the short. If you went with hardware method, you do need to remove it first. Otherwise, just press Enter.
9. The script will now proceed to downgrade your device and flash some essential files. Just let it be, it will take about 4 minutes. You should see the following output:
Code:
[2019-06-30 02:48:59.334098] Waiting for bootrom
[2019-06-30 02:50:41.179571] Found port = /dev/ttyACM0
[2019-06-30 02:50:41.180204] Handshake
* * * If you have a short attached, remove it now * * *
* * * Press Enter to continue * * *
[2019-06-30 02:50:49.195782] Init crypto engine
[2019-06-30 02:50:49.214278] Disable caches
[2019-06-30 02:50:49.214801] Disable bootrom range checks
[2019-06-30 02:50:49.229877] Load payload from ../brom-payload/build/payload.bin = 0x46B8 bytes
[2019-06-30 02:50:49.233418] Send payload
[2019-06-30 02:50:49.958957] Let's rock
[2019-06-30 02:50:49.959812] Wait for the payload to come online...
[2019-06-30 02:50:50.904341] all good
[2019-06-30 02:50:50.904714] Check GPT
[2019-06-30 02:50:51.240034] gpt_parsed = {'proinfo': (1024, 6144), 'PMT': (7168, 9216), 'kb': (16384, 2048), 'dkb': (18432, 2048), 'lk': (20480, 2048), 'tee1': (22528, 10240), 'tee2': (32768, 10240), 'metadata': (43008, 80896), 'MISC': (123904, 1024), 'reserved': (124928, 16384), 'boot': (141312, 32768), 'recovery': (174080, 40960), 'system': (215040, 6354944), 'vendor': (6569984, 460800), 'cache': (7030784, 1024000), 'userdata': (8054784, 22722527)}
[2019-06-30 02:50:51.240157] Check boot0
[2019-06-30 02:50:51.485287] Check rpmb
[2019-06-30 02:50:51.695083] Downgrade rpmb
[2019-06-30 02:50:51.696759] Recheck rpmb
[2019-06-30 02:50:52.591407] rpmb downgrade ok
[2019-06-30 02:50:52.837668] Clear preloader 1
[1 / 1]
[2019-06-30 02:50:52.859908] Clear preloader 2
[1 / 1]
[2019-06-30 02:50:52.882059] Flash lk-payload
[4 / 4]
[2019-06-30 02:50:53.214382] Flash tz
[5547 / 5547]
[2019-06-30 02:52:51.150851] Flash lk
[651 / 651]
[2019-06-30 02:53:05.192112] Inject microloader
[4 / 4]
[2019-06-30 02:53:05.524154] Flash preloader
[271 / 271]
[2019-06-30 02:53:11.525329] Restore preloader
[8 / 8]
[2019-06-30 02:53:11.695348] Reboot to unlocked fastboot
If the script freezes at some point, you will have to restart it. Terminate the script, then immediately run `sudo ./bootrom-step.sh` again. The exploit it set up so that after about 40 seconds of inactivity it would reboot your device and drop you back into the bootrom mode, which the script is waiting for. If you cannot restart the process, you might have to open up the tablet and replug the battery to completely power off the device.
10. You should see a success message: "Reboot to unlocked fastboot". Only proceed if you see the message.
11. Once the device boots to fastboot (check with "fastboot devices"; you should also see amazon logo on the screen.), you can run "sudo ./fastboot-step.sh".
12. At this point the device should boot into recovery, however the screen will be off. Just press the power button twice and the screen should turn on.
13. Success! You now have a custom recovery installed that can be accessed by holding down power and volume down (the leftmost) buttons. At this point if you came here from a custom ROM thread you should probably follow the ROM installation instructions. Alternatively, the next steps will detail installing a stock firmware and rooting it with Magisk.
----------------------------------------------------------------------------------------------------
14. We'll now upload required files to the recovery. On your PC, do:
adb push update-kindle-NS6312_user_1827_0002517050244.bin /sdcard/fw.zip
adb push Magisk-v19.3.zip /sdcard
adb push finalize.zip /sdcard
15. In the recovery, go to "Install", navigate to "/sdcard" and flash fw.zip
16. Go to "Wipe" and do the default wipe, then reboot
17. At the Fire setup screen, select your language. On the next screen, Wifi setup, select any password-protected network, then instead of entering the password press "cancel". Now, back at the wifi setup screen, press "Skip setup" and "Skip" in the dialog pop-up again
18. Wait for the update to finish (wait until the updating fire notification disappears)
19. Hold down the power button, press Restart and hold volume down to boot into recovery.
20. In the recovery, go to "Install", navigate to "/sdcard" and flash Magisk-v19.3.zip
21. Press back, select finalize.zip and flash it
22. Once finalize.zip is flashed, press "Reboot System"
VERY IMPORTANT STUFF:
Only ever flash boot images from TWRP. Since nothing but TWRP is aware of the exploit, if you try to flash a boot image from Android, it won't have the exploit integrated into it! This includes Magisk as well, so do NOT install or uninstall it from Magisk Manager (However, installing modules should be fine; although it depends on the specific module).
Due to how the exploit works, it takes over the first 0x400 bytes of boot.img/recovery.img. When flashing zips from the recovery, it will transparently remove and then reinstall the exploit when needed. So long as you flash zips from the recovery, you should treat the boot image normally. However, this means that you cannot use any other apps (e.g. FlashFire) to flash the boot or recovery partitions.
To uninstall the hack and revert back to stock:
- Download an update package to your PC (the update-kindle-NS6312_user_1827_0002517050244.bin file)
- Flash revert-stock-mustang.zip from TWRP
- Perform the default wipe
- Reboot to recovery; you should see amazon recovery now
- Select "apply update from ADB" in the recovery menu
- Run "adb sideload update-kindle-NS6312_user_1827_0002517050244.bin" on your PC
Other misc information / troubleshooting:
- If you need to disconnect the battery, use a pair of tweezers to grab the wires and gently pull towards yourself. You can do bootrom-step.sh either with or without the battery connected, however fastboot-step.sh should be done with the battery connected.
- If your device is bricked (e.g. from a downgrade), just follow the steps as-is.
- If you're getting an error like "Serial protocol mismatch", or any other error in bootrom-step, try disabling or temporarily uninstalling ModemManager from your Linux
- To remount /system as rw use "mount -o rw,remount /system". ("mount -o remount,rw /system" will not work)
Thanks to: aftv2-tools contributors https://gitlab.com/zeroepoch/aftv2-tools: for an implementation of mtk download protocol, @diplomatic for mtk-su, @Michajin for testing the instructions.

Thanks for your work!
On a side note, I also had adaptive storage on during the process. I was having crashing issues after install. I re-installed the firmware-wiped and booted. I followed the steps to boot without setup. Then booted back into TWRP, flashed magisk, but did not flash finalize. I like access to some of the amazon apps. Once I rebooted (I stayed off wi-fi) I sideloaded a package disabler and disabled the OTA. I registered then disabled the amazon bloat I didn't want. I have installed my sd card as portable this time, just to be safe.
also, TWRP does not have backup and restore options, is this normal on this currently?

incredible, i will try that

Thanks. We will look if it's possible to compile LOS 14.1 since it has the same processor as the HD8 2018.

hello @xyz
Do you think i can try that throught a linux virtual machine on virtualbox ?

guizzzmo said:
hello @xyz
Do you think i can try that throught a linux virtual machine on virtualbox ?
Click to expand...
Click to collapse
I unlocked my 7th gen with virtualbox so yes.

Hi guys, Is there a chance there will be a Nexus ROM released for the Mustang version of the Fire? It's been my preferred ROM on my older Ford model so I'd like to keep using it if possible.

tangledweb said:
Hi guys, Is there a chance there will be a Nexus ROM released for the Mustang version of the Fire? It's been my preferred ROM on my older Ford model so I'd like to keep using it if possible.
Click to expand...
Click to collapse
Mustang uses a different kernel than Ford/Austin; custom ROMs will need to be spun up from different sources. Developer time is scarce; may or may not happen.

Finally bricked with software method.
I try to find a picture for where i can make my wire for hardware method.
SOLVED:
My battery was empty so i have just disconnect battery and plug usb with paperclip and i have got bootrom.
Great !!

much thanks for this, after some fiddling it works perfectly!!
i had some issues getting past the bootrom script part on both my galliumos & debian machines (serial error message, despite apt remove modemmanager) - until i tried an xubuntu liveusb, at which point everything went smoothly and as directed via the software method.
looking very forward to an aosp rom to replace stock and being able to make a twrp backup (i broke my install with magisk, but it was a simple recovery just reflashing fw.bin again). cheers!

Is it just me or is the hardware point picture coming up as a dead link? Can someone attach the correct point in another image?

rumblpak said:
Is it just me or is the hardware point picture coming up as a dead link? Can someone attach the correct point in another image?
Click to expand...
Click to collapse
The link (to the hardware shorting point) in the OP is indeed broken.
Try the following :
https://forum.xda-developers.com/showpost.php?p=79683131&postcount=22
Edit : The link in the OP is fixed now. (7/3/2019)

at the point where you issue 'reboot' for the software method. upon issuing that command, the device powers off, and is non responsive. cant get it to turn back on at all. Very strange. Any ideas?

wlewin said:
at the point where you issue 'reboot' for the software method. upon issuing that command, the device powers off, and is non responsive. cant get it to turn back on at all. Very strange. Any ideas?
Click to expand...
Click to collapse
Did the script run correctly? Did you get to the point where is says
* * * If you have a short attached, remove it now * * *
* * * Press Enter to continue * * *
Did you press enter and see the script run? Did it end;
[8 / 8]
[2019-06-30 02:53:11.695348] Reboot to unlocked fastboot
The reboot command puts your device into bootrom to inject the exploit. Upon completion TWRP is installed, i think you have to double click the power button. If all else fails, you might have to pry open and disconnect the battery. Were you in bootrom, because preloader can do this; run lsusb and you should see a phone connection or "dmesg" and you should see this device ;
[1141765.113884] usb 3-1.4.3.1: USB disconnect, device number 59
[1141783.057101] usb 3-1.4.3.1: new full-speed USB device number 60 using xhci_hcd
[1141783.226498] usb 3-1.4.3.1: New USB device found, idVendor=0e8d, idProduct=0003, bcdDevice= 1.00
[1141783.226502] usb 3-1.4.3.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[1141783.506877] cdc_acm 3-1.4.3.1:1.0: ttyACM0: USB ACM device

Michajin said:
Did the script run correctly? Did you get to the point where is says
* * * If you have a short attached, remove it now * * *
* * * Press Enter to continue * * *
Did you press enter and see the script run? Did it end;
[8 / 8]
[2019-06-30 02:53:11.695348] Reboot to unlocked fastboot
The reboot command puts your device into bootrom to inject the exploit. Upon completion TWRP is installed, i think you have to double click the power button. If all else fails, you might have to pry open and disconnect the battery. Were you in bootrom, because preloader can do this; run lsusb and you should see a phone connection or "dmesg" and you should see this device ;
[1141765.113884] usb 3-1.4.3.1: USB disconnect, device number 59
[1141783.057101] usb 3-1.4.3.1: new full-speed USB device number 60 using xhci_hcd
[1141783.226498] usb 3-1.4.3.1: New USB device found, idVendor=0e8d, idProduct=0003, bcdDevice= 1.00
[1141783.226502] usb 3-1.4.3.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[1141783.506877] cdc_acm 3-1.4.3.1:1.0: ttyACM0: USB ACM device
Click to expand...
Click to collapse
None of that seems clear in the steps.
the amonet script is in 'waiting for bootrom'. I then issued the reboot command, and the device blacked out, and nothing happened in terminal.
I have since disconnected the battery, and it still doesn't boot at all.

wlewin said:
None of that seems clear in the steps.
the amonet script is in 'waiting for bootrom'. I then issued the reboot command, and the device blacked out, and nothing happened in terminal.
I have since disconnected the battery, and it still doesn't boot at all.
Click to expand...
Click to collapse
My guess is you are bricked stuck in the preloader or something is wrong with your linux, and might have to do the shorting method now. Run lsusb and see if it sees your device, i believe it shows up as a phone. If you see preloader, you will have to short it. otherwise you might have to fix your linux. Make sure modemmanager is uninstalled ... I had issues trying to use ubuntu and ended up using Rasparian.

Michajin said:
My guess is you are bricked stuck in the preloader or something is wrong with your linux, and might have to do the shorting method now. Run lsusb and see if it sees your device, i believe it shows up as a phone. If you see preloader, you will have to short it. otherwise you might have to fix your linux. Make sure modemmanager is uninstalled ... I had issues trying to use ubuntu and ended up using Rasparian.
Click to expand...
Click to collapse
ah ha! Got it sorted. So, the screen going blank was very odd. turns out after sending reboot, that state is two things
1. blank screen with not indication of being powered on
2. persistent through cutting the power (disconnecting battery)
So, seemingly, the devices is totally non-functional. The issue was, in the linux VM I am using, I had to go manually select the USB devices because the identifier changed from the prior Amazon device to a mediatek device. So it was in the right state, I linux just didn't auto connect to the new USB device.
All good the in the hood. continued and worked just fine. Just PSA to others, that boot state seems like the device is just off!

2017 7" tablet too?
Will this work on my Kindle fire 7" 2017 Ed if I update to the latest software version?
Or do I have to buy a new tab to root and install custom roms on?

OP, i think you are linking to the magisk uninstaller in your original post btw. not the installer zip

PowerUser64 said:
Will this work on my Kindle fire 7" 2017 Ed if I update to the latest software version?
Or do I have to buy a new tab to root and install custom roms on?
Click to expand...
Click to collapse
WTF no. 7th gen can be unlocked and rooted. (Also there are ROMS for it: LOS 12.1, AOSP FIRE NEXUS, etc).
https://forum.xda-developers.com/amazon-fire/development/unlock-fire-t3899860

Related

[GUIDE] ADB, Fastboot, and Nandroid for Noobs

Hello All!
After much frustration with setting up ADB i finally got it working. Everyone said its simple and takes minimal knowledge but when things dont work, nothing really worked. Anyways after 2 hours of research trying to get ADB to work i finally got it all working and wanted to share my knowledge to anyone else that needed help.
This Guide is for windows only. If you are using Mac OS X please go here: ADB For Dummies
If you are using Linux please go here: [HOW-TO]Set up Android SDK/ADB/Fastboot on Ubuntu Linux
Like My Guide(s)? Donate
--------------------------------------------------------------------------
Things you need:
Android SDK - Download
Winrar - Download (32bit) Download (64bit)
Windows PC
USB Cable
A Rooted HTC Dream (Google G1)
--------------------------------------------------------------------------
Setting up the Android SDK
Download the file from above
Unzip to your desktop
Take the "android-sdk-windows" folder and move it to the root of your hard drive (C:\)
Right click on My Computer and click properties
Select the Advanced Tab or Advanced System Setting (Vista/Windows 7)
Select Environment Variables...
Press New
For Variable Name type: adb
For Variable Value type: C:\android-sdk-windows\platform-tools
Now,
1. Run SDK Manager.exe located in the android-sdk-windows folder
2. If it gives you an error go to settings and click on "Force http//....."
3. Select all options and let it download and install
If you cant get the setup to work, Download the USB-DRIVERS folder - HERE (Windows XP/Vista/Windows 7)
--------------------------------------------------------------------------
Preparing your phone for ADB
Go to Settings on your phone
Select Applications
Select Development
Make sure 'USB Debugging' is checked
--------------------------------------------------------------------------
Installing Drivers
Plug in your phone through USB and DO NOT MOUNT IT!!!!!
Your computer should see a new device and try to install Android 1.0 driver (If it doesnt, scroll down to the "Im not getting a notification of Android ADB when i plug in my USB" section)
Let it load
Once it cant find them select "Install drivers from my pc"
The drivers you need are in the Android SDK 1.5r2 folder (C:\android-sdk-windows\usb_driver)
Depending on your OS pick x86 or amd64
You ADB Android Device should now be installed! Good Job
For Android SDK 1.5r7+
1. Run SDK Manager.exe
2. If it gives you an error go to settings and click on "Force http//....."
3. Select all options and let it download and install
If you cant get the setup to work, Download the USB-DRIVERS folder - HERE (Windows XP/Vista/Windows 7)
--------------------------------------------------------------------------
Check if your phone is detected by ADB
Open up Command Prompt (Go to run, type in cmd, press enter)
Type in
Code:
cd C:\android-sdk-windows\platform-tools === Press Enter
adb devices === You should see your device listed
adb shell === you should see # in the next line
Now you are all set to run adb commands
Note: for a list of commands type in 'adb' in cmd
CONGRATS YOU NOW HAVE ADB FULLY RUNNING!
--------------------------------------------------------------------------
Droid Explorer by Camalot
Droid Explorer is a Windows software that will download, install, and setup the android SDK for you all in under a minute so you are ready to go. I use this on a daily basis. This amazing piece of software has tons of plugins and a built in file explorer for all your files on your phone! All you gotta do is download, install, and go!
Download Droid Explorer - Here
Install the program, and let it setup the SDK files for you
Connect your phone
Enjoy!
--------------------------------------------------------------------------
"Im not getting a notification of Android ADB when i plug in my USB"
Why: Your computer has detected your phone but as a protable device and as a storage device.
Fix: This took me a lot of research and time to figure out so this is what your are going to do.
First download USBDeview - Here
Unzip it
Run USBDeview.exe as Administrator
You will see all drivers being used on your computer
Highlight and Uninstall all drivers with the description have HTC Android (Should be 3 of them)
Right Click on the driver and press uninstall
Once done, Unplug your phone and plug it back in
You should now get the notification of the ADB device
Follow the steps above to install the drivers
--------------------------------------------------------------------------
When Typing just adb in cmd you will get whats called a "usage doc" which gives you a lits of commands that you can use:
Code:
-d - directs command to the only connected USB devic
e
returns an error if more than one USB device is
present.
-e - directs command to the only running emulator.
returns an error if more than one emulator is r
unning.
-s <serial number> - directs command to the USB device or emulator w
ith
the given serial number
-p <product name or path> - simple product name like 'sooner', or
a relative/absolute path to a product
out directory like 'out/target/product/sooner'.
If -p is not specified, the ANDROID_PRODUCT_OUT
environment variable is used, which must
be an absolute path.
devices - list all connected devices
device commands:
adb push <local> <remote> - copy file/dir to device
adb pull <remote> <local> - copy file/dir from device
adb sync [ <directory> ] - copy host->device only if changed
(see 'adb help all')
adb shell - run remote shell interactively
adb shell <command> - run remote shell command
adb emu <command> - run emulator console command
adb logcat [ <filter-spec> ] - View device log
adb jdwp - list PIDs of processes hosting a JDWP transport
adb install [-l] [-r] <file> - push this package file to the device and instal
l it
('-l' means forward-lock the app)
('-r' means reinstall the app, keeping its data
)
adb uninstall [-k] <package> - remove this app package from the device
('-k' means keep the data and cache directories
)
adb bugreport - return all information from the device
that should be included in a bug report.
adb help - show this help message
adb version - show version num
scripting:
adb wait-for-device - block until device is online
adb start-server - ensure that there is a server running
adb kill-server - kill the server if it is running
adb get-state - prints: offline | bootloader | device
adb get-serialno - prints: <serial-number>
adb status-window - continuously print device status for a specifie
d device
adb remount - remounts the /system partition on the device re
ad-write
adb root - restarts adb with root permissions
networking:
adb ppp <tty> [parameters] - Run PPP over USB.
Note: you should not automatically start a PDP connection.
<tty> refers to the tty for PPP stream. Eg. dev:/dev/omap_csmi_tty1
[parameters] - Eg. defaultroute debug dump local notty usepeerdns
adb sync notes: adb sync [ <directory> ]
<localdir> can be interpreted in several ways:
- If <directory> is not specified, both /system and /data partitions will be u
pdated.
- If it is "system" or "data", only the corresponding partition
is updated.
--------------------------------------------------------------------------
Commands that you should know
adb push - Insert file to phone such as Stock.apk to /data/app_s
Code:
adb push <pathtofile.apk> <file system location> - Example: adb push c:\app.apk /data/app
adb pull - Remove file from phone such as Stock.apk from /data/app_s
Code:
adb pull <pathtofile.apk> <path where you want to save it>- Example: adb pull /data/app/Stock.apk C:\
adb install - Install app to phone
Code:
adb install <path to file> - Example: adb install c:/apps/apps2sd.apk
adb uninstall - Uninstall app from phone
Code:
adb uninstall <name of application> - Example: adb uninstall linda.apk
For more ADB Commands go - Here
--------------------------------------------------------------------------
Thats it for ADB! Congrats and if you have any questions please ask me or if anything is missing or not correct please tell me. I got all of this from research and personal experience.
[GUIDE] Fastboot for Noobs
Fastboot
Like My Guide(s)? Donate
Things you need:
New SPL - Download
New Radio - Download
Your Current ROM - CyanogenMod 3.6
SD Card Reader
Rooted G1 Phone
Computer
USB Cable
Patience
---------------------------------------------------------------------------------------
Install Radio FIRST
Download the Radio Update
Rename it to update.zip
Remove your SD Card from your phone and place it in your SD Card Reader
Put the update.zip at the root of your SDcard (root = not in any folder)
Insert your sdcard back into the phone
Turn off your phone (Hold power and press Power Off)
Hold the Home button and then press the power button (Keep holding power)
You will now enter recovery
Open up your keyboard and press Alt-S
Let it finish the update
When done reboot by pressing Home and Back
You should be able to access your Home screen (If its stuck on the Google G1 screen dont panic, just remove your battery for now)
---------------------------------------------------------------------------------------
Installing the new SPL
Note: To update you must have a PVT board. To Check go into fastboot (Power and Camera and check)
Take your SD Card out again and plug it into the pc
Remove the update.zip that you put in there
Download your current Rom or any other ROM that you want. I suggest CyanogenMod 3.6
Download the SPL Update
Rename the SPL Update to update.zip
Remove your SD Card from your phone and place it in your SD Card Reader
Put the update.zip at the root of your SDcard (root = not in any folder)
Insert your sdcard back into the phone
Turn off your phone (Hold power and press Power Off) or put your battery back in and turn it on
Hold the Home button and then press the power button (Keep holding power)
You will now enter recovery
Open up your keyboard and press Alt-S
Let it finish the update
Now it will reboot on its own back to recovery
Reboot again by pressing Home + Back
Your phone will be stuck on the T-Mobile G1 Screen (Again DONT FREAK)
Remove the battery from your phone
Remove your SD Card and plug it back into your computer
Take the ROM that you downloaded and rename it update.zip
Remove the update.zip that was on your SD Card and put this new one it
Put the battery back into your phone
Enter recovery (Home + Power)
Press Alt+s to update
Let it finish
Press Home + Back to reboot
Thats it! You now have your new SPL and Radio
---------------------------------------------------------------------------------------
Getting into Fastboot
Turn off your phone
Hold the back button and keep holding it while turning your phone back on
You should see 3 Android guys on skateboards
You should now be in Fastboot mode!
---------------------------------------------------------------------------------------
Setting up fastboot to work with your computer
Plug your phone in to your computer through USB
You should get a popup that your computer found the ADB Device for fastboot
When it asks you for drivers, make sure u select the option to locate the drivers from your computer yourself
Since you already have your Android 1.5r2 SDK installed, the drivers are in the same place where the ADB drivers are
C:\android-sdk-windows-1.5_r2\usb_driver
Make sure you choose the correct folder depending on your OS
Press ok to install the drivers
Fastboot should now be up and running
---------------------------------------------------------------------------------------
Make sure Fastboot is working
Open up Command Prompt
type the following
Code:
cd C:\android-sdk-windows-1.5_r2\tools === Press Enter
fastboot devices === Press enter, your device should be listed
fastboot shell === You should see a # in the next line
type fastboot and press enter for general commands
---------------------------------------------------------------------------------------
When Typing just fastboot in cmd you will get whats called a "usage doc" which gives you a lits of commands that you can use:
Code:
usage: fastboot [ <option> ] <command>
commands:
update <filename> reflash device from update.zip
flashall 'flash boot' + 'flash system'
flash <partition> [ <filename> ] write a file to a flash partition
erase <partition> erase a flash partition
getvar <variable> display a bootloader variable
boot <kernel> [ <ramdisk> ] download and boot kernel
flash:raw boot <kernel> [ <ramdisk> ] create bootimage and flash it
devices list all connected devices
reboot reboot device normally
reboot-bootloader reboot device into bootloader
options:
-w erase userdata and cache
-s <serial number> specify device serial number
-p <product> specify product name
-c <cmdline> override kernel commandline
For more fastboot Commands go - Here
---------------------------------------------------------------------------------------
Congrats! You now have Fastboot and ADB up and running!!!
----------------------------------------------------------------------------
Disclamer: I am not liable to any damage that happens to your phone. This is just a guide which you have chosen to follow, so please do not blame me for any damaged phones or bricks.
Nandroid Backup and Restore
Whats is a Nandroid Backup?
Like My Guide(s)? Donate
Nandroid Backup is a tool allowing all rooted g1 users to create a full system backup and restore which, when flashing and testing different roms can be very useful.
----------------------------------------------------------------------------
What You Will Need
A Rooted G1 phone, I suggest with the latest SPL (Guide above to install latest Radio and SPL)
Cyanogen's Pimped Out Recovery Image 1.4 - Download (IMG)
An SD Card with 100mb of free space
A Computer
SD Card reader or USB Cable
----------------------------------------------------------------------------
Installing the New Recovery Image
Download the recovery image from above, you will want the Download (IMG) download
Place the cm-recovery-1.4.img file in the root of your SD Card (Root = not in any folder)
Go back to your phone (Dont forget to unmount)
Open terminal and type in the following
Code:
su (wait for a screen to popup and press "allow")
flash_image recovery /sdcard/cm-recovery-1.4.img
If you have problems with a "no space on device" error, try using fastboot and erasing first:
Code:
fastboot erase recovery
fastboot flash recovery cm-recovery-1.4.img
----------------------------------------------------------------------------
Creating a Backup using Nandroid 2.1
Boot up your phone in recovery (Turn off, then turn on while holding Home button)
You will now see your new Cyanogen 1.3.1 + JF recovery screen (YAY!!! )
Scroll down to "nandroid v2.1 backup" and press on it to create your Backup
Let it work, it should take a minute or so
Once its done, your backup is complete and is saved on your sdcard in the "nandroid" folder
Recovering to Your Nandroid Backup
Option 1 (Without a Computer)
Note: This recovery will only recover your latest nandroid backup (the one with the newest timestamp)
Make sure u made a backup and its in the nandroid folder on your sdcard
Boot up your phone in recovery (Turn off, then turn on while holding Home button)
Scroll down to "restore latest backup" and press on it
Let it work
Once its done reboot your phone and you backup will now be restored!
Option 2 (With a computer)
Note: With this option, you can use any nandroid backup that you have made, not just the latest one
1) First go in to your tools folder where you put your SDK 1.5r2 (C:\android-sdk-windows-1.5_r2\tools as reference)
2) Take the files adb.exe fastboot.exe and AdbWinApi.dll (found here - http://sharebee.com/16a06ebb) and place them in C:\WINDOWS\system32
3) Download the Nandroid Backup and Restore GUI made by Markazeh - Here
Extract the folder to your desktop or where ever you can easily find it (I put mine in the SDK folder for easy access)
4) You will need 4 files: Boot.img, System.img , Data.img, and Recovery.img
Place those 4 files in the same folder as the Nandroid Recovery GUI folder you just extracted in step 3
5) Boot your phone into fastboot mode (Turn off the G1 and turn on while holding the BACK button. If you have an older SPL then hold the CAMERA button and press POWER)
6) Once in fastboot (you should see a white screen with three androids on skateboards) plug your phone to your computer via USB. You might have to press the BACK key to turn it into FASTBOOT mode, or follow the on screen prompts.
NOTE: If you dont have the drivers installed please look one post above to setup fastboot
7) Open NANDROID_Recovery_GUI.exe, everything on the left hand side should be "found!"
8) Choose an option from the right to Restore All, Restore all except Recovery, or Restore Data Only. Let the program do its thing.
Once its done you can reboot and all your info from your backup should be restored!
----------------------------------------------------------------------------
Congrats! You now Backed up your phone and will/have restored it!
----------------------------------------------------------------------------
Disclamer: I am not liable to any damage that happens to your phone. This is just a guide which you have chosen to follow, so please do not blame me for any damaged phones or bricks.
Credit:
Haykuro
Cyanogen
JacHero
NeoBlade
Markazeh
makethetick
XDA Community for your support and help
If i have forgot anyone, i am sorry, please tell me and i will add you
Excellent Guide bro. Although I have no need for it, still A++. Might want to include how to do a nandroid restore just a suggestion!
[EDIT]: I think this guide is worthy of a sticky! What do you guys think? ^^
You are the man!!!
Short simple and to the point!!!
0nly if all the guides were like this...
Thanks man!
not sure if this is the right spot or not but ever since I flashed from cy36 to 361 I keep losing my adb connection I have to g1s and while I'm working on one the other one isn't even connected to the computer so I just flashed the hero theme on one and plugged it in usb and tried to do the clock switcher didn't work so I go do a cmd and do an adb devices and there's nothing listed then I do an adb shell and it says error device not found but the computer sees it and the adb driver is loaded along with the mass storage driver and haven't had any problems until now.
PlatinumMOTO said:
not sure if this is the right spot or not but ever since I flashed from cy36 to 361 I keep losing my adb connection I have to g1s and while I'm working on one the other one isn't even connected to the computer so I just flashed the hero theme on one and plugged it in usb and tried to do the clock switcher didn't work so I go do a cmd and do an adb devices and there's nothing listed then I do an adb shell and it says error device not found but the computer sees it and the adb driver is loaded along with the mass storage driver and haven't had any problems until now.
Click to expand...
Click to collapse
You might want to try reinstalling the drivers and the USB Storage devices. That fixed it for me
Did you follow the "Preparing your phone for ADB" steps? and do ^ that suggestion first. lol
Mikey1022 said:
Did you follow the "Preparing your phone for ADB" steps? and do ^ that suggestion first. lol
Click to expand...
Click to collapse
yes I did I've had adb since sdk 1.0 and never had a problem like I said I actually have 1.0 and 1.5 on my computer so that when I root or re root other g1s I do adb but I noticed adb only works on it's version if I had a 1.5 g1 then the 1.0 won't work and same with the other way but that's not the problem I think I found it it's the clock switcher with 361 of Cyan because now I deleted it and restarted and it works just fine and I just tried to do the clock switcher and now it doesn't recognize either g1 again.
push apk via abd while in recovery mode?
Is it possible to use ADB to push apk files to the phone when the phone is in recovery mode? I tried and it didn't work (the files I was trying to replace weren't overwritten), and I'm wondering if it's because I did something wrong, or if it just doesn't work. I have adb working fine otherwise, have used it a bunch, including to push files while the phone was booted normally.
Specifically, I want to push the calendar.apk and calendarprovider.apk (I like the 1x4 calendar widget better than the 2x2). I want to do this in recovery mode so that the calendar isn't running when the file gets overwritten. I keep having calendar problems after pushing the 1x4 widget, and I think the problems are due to the calendar being active when the file gets replaced.
ADB Commands...
First I would like to say I think the guide is great. Though I don't have a lot of use for it, but I have some suggestions to make:
1. List some ADB commands and what they do, specifically how to use them, and what you would use them for. This forum has taught me so much about my phone and linux, but sometimes it was a slow learning process. Working the ADB push/pull feature was confusing when I first started using it.
2. Nandroid Back-ups. I still don't think I am using it correctly. I know there is a guide, but it still seems confusing. Maybe dumb it down a little.
3. Maybe more information on fastboot. I'm not sure exactly what it is or does, seems like just another version of recovery terminal, which from everything I have learned so far, if you can't get to your recovery terminal, you probably won't be able to get to your fastboot either.
ccunningham83 said:
Maybe more information on fastboot. I'm not sure exactly what it is or does, seems like just another version of recovery terminal, which from everything I have learned so far, if you can't get to your recovery terminal, you probably won't be able to get to your fastboot either.
Click to expand...
Click to collapse
Actually, you can access fastboot from the bootloader, so it's available even if the recovery console isn't.
heldc said:
Is it possible to use ADB to push apk files to the phone when the phone is in recovery mode? I tried and it didn't work (the files I was trying to replace weren't overwritten), and I'm wondering if it's because I did something wrong, or if it just doesn't work. I have adb working fine otherwise, have used it a bunch, including to push files while the phone was booted normally.
Specifically, I want to push the calendar.apk and calendarprovider.apk (I like the 1x4 calendar widget better than the 2x2). I want to do this in recovery mode so that the calendar isn't running when the file gets overwritten. I keep having calendar problems after pushing the 1x4 widget, and I think the problems are due to the calendar being active when the file gets replaced.
Click to expand...
Click to collapse
In recovery, nothing is mounted. So in order to push and overwrite the calender and calenderproviders, you have to do this in recovery/adb shell
mount /system/app
After that, You should be able to push the files + overwrite them =]. QQ why do you want to do this inrecovery and not when the phone is turned on and fully functional?o_o
but how many times is bootloader available when recovery console isn't? I understand they are different, but from everything I have seen, if you can get one, you can get the other and if you can't get one, you cant get the other either.
ccunningham83 said:
First I would like to say I think the guide is great. Though I don't have a lot of use for it, but I have some suggestions to make:
1. List some ADB commands and what they do, specifically how to use them, and what you would use them for. This forum has taught me so much about my phone and linux, but sometimes it was a slow learning process. Working the ADB push/pull feature was confusing when I first started using it.
2. Nandroid Back-ups. I still don't think I am using it correctly. I know there is a guide, but it still seems confusing. Maybe dumb it down a little.
3. Maybe more information on fastboot. I'm not sure exactly what it is or does, seems like just another version of recovery terminal, which from everything I have learned so far, if you can't get to your recovery terminal, you probably won't be able to get to your fastboot either.
Click to expand...
Click to collapse
If you type "adb" in terminal you get a whole list of the options and what they do Also what part of nandroid backup don't you understand? Its just booting into recovery and alt+b. I assume you mean nandroid restores right? Drop me a PM maybe I can help you
ccunningham83 said:
but how many times is bootloader available when recovery console isn't? I understand they are different, but from everything I have seen, if you can get one, you can get the other and if you can't get one, you cant get the other either.
Click to expand...
Click to collapse
Its because the boot loader is dependent on the SPL and if you flash the "Danger" SPL which is basically the only one that causes problems, then you have a chance of bricking your phone. In that case, brick = no bootloader no recovery
ccunningham83 said:
but how many times is bootloader available when recovery console isn't? I understand they are different, but from everything I have seen, if you can get one, you can get the other and if you can't get one, you cant get the other either.
Click to expand...
Click to collapse
Well, actually, I recently had just this happen. My fiance got a g1, and somehow in flashing it for him, it ended up without a working recovery console. It wouldn't flash the recovery image from within the OS, so I had to use fastboot to flash the recovery image. So, it's quite possible to have a bootloader and no recovery console.
alritewhadeva said:
In recovery, nothing is mounted. So in order to push and overwrite the calender and calenderproviders, you have to do this in recovery/adb shell
mount /system/app
After that, You should be able to push the files + overwrite them =]. QQ why do you want to do this inrecovery and not when the phone is turned on and fully functional?o_o
Click to expand...
Click to collapse
Ah ha, that's likely the problem, thanks!
Like I said, I want to overwrite a system app, the calendar. Every time I've done this with the phone "fully functional", the app ends up constantly force closing. I suspect this might be due to corruption from overwriting the app while it's running. I'm hoping that if I replace the app when the OS isn't on, the replacement app will work properly.
No problem You could also try replacing the calender app in a ROM and resigin it and then flash it. Have you tried rebooting after replacing the Calender app when the phone is I quote from myself " fully functional "?

[GUIDE] How to transfer files in Linux

Now works on 32bit and 64bit Linux
Just a quick guide on how to configure Linux for file transfers using MTP. I wrote the instructions and config for Ubuntu Natty 32bit and 64bit, though the same process will work on other platforms - the only real difference being the package manager commands and possibly the config file locations.
The attached files are for the Galaxy Tab 10.1v but should work for the 10.1g / 10.1 as well. See the end of the post to learn how to modify this config to work for other devices.
How to configure for gMTP and other Media Sync tools
1) Install aptitude
Code:
sudo apt-get install aptitude
2) Install mtp-tools and mtpfs
Code:
sudo aptitude install mtpfs mtp-tools
3) Download the attached file ( View attachment 98-gtab.zip for 32bit Linux or View attachment 98-gtab.rules-AMD64.zip for 64bit Linux ) to your desktop.
4) Extract the 98-gtab.rules file to your desktop
5) Copy the rules file to /etc/udev/rules.d/
Code:
sudo cp ~/Desktop/98-gtab.rules /etc/udev/rules.d
6) Reboot
7) Connect your Tab
8) Run the following command to confirm it is working:
Code:
ls /dev | grep gtab
...which should return "gtab" if successful. If not, follow the "Modifying" guide below.
9) Download / install gMTP
Code:
sudo apt-get install gmtp
10) Open gMTP and select "connect" from the menu
11) Hit the thanks button
12) Go nuts!
Setting up for Automount (Optional, but recommended)
***You must have completed Steps 1-8 above before proceeding***
1) Edit your fstab file to add your gtab:
Code:
sudo gedit /etc/fstab
2) Add this to the end of the file:
Code:
#gtab
mtpfs /media/gtab fuse user,noauto,allow_other 0 0
3) Save and exit
4) Open fuse.conf for editing:
Code:
sudo gedit /etc/fuse.conf
5) Find the following line and remove the #
Code:
#user_allow_other
6) Save and exit
7) Open and edit the groups file:
Code:
sudo gedit /etc/group
8) Find the details for the group 'fuse' and append your username to the end of the line eg.
Code:
fuse:x:104:<YOUR USER NAME>
9) Save and exit
10) Create the folder to mount your Tab:
Code:
sudo mkdir /media/gtab
11) Take ownership of the folder:
Code:
sudo chown <YOUR USER NAME>:users /media/gtab
12) Reboot
13) Plug in your Tab.
14) Click on the Places menu and click gtab.
15) You're in business!
Modifying for other devices
If the above doesn't work immediately on the 10.1g / 10.1 (I have only tested on the 10.1v), you can easily edit the rules file to support your device.
1) Install lsusb
Code:
sudo apt-get install lsusb
2) Run lsusb
Code:
lsusb
3) Check the output of this command to find your device. The 10.1v is shown like this:
Code:
Bus 001 Device 010: ID 04e8:6860 Samsung Electronics Co., Ltd
4) Make a note of the Vendor and Product IDs. In the example above, the vendor ID is 04e8 and device ID is 6860 (note 04e8:6860 in the output).
5) Open the rules file for editing (if it's not already in /etc/udev/rules.d, copy it there now)
Code:
sudo gedit /etc/udev/rules.d/98-gtab.rules
6) Find this line:
Code:
ATTRS{idVendor}=="04e8", ATTRS{idProduct}=="6860", MODE="0666" SYMLINK+="gtab"
7) Replace the Vendor ID (04e8) and Product ID (6860) with the ones that you got from step 3 above.
8) Save and exit
9) Reboot
10) Follow step 7 onward in the first guide above
11) Hit the thanks button
If you modify it for a particular device, please post the contents of your new 'rules' file here.
32bit RULES FILE:
Code:
ACTION!="add", GOTO="gtab_rules_end"
SUBSYSTEM!="usb|usb_device", GOTO="gtab_usb_end"
ATTRS{idVendor}=="04e8", ATTRS{idProduct}=="6860", MODE="0666" SYMLINK+="gtab"
LABEL="gtab_usb_end"
LABEL="gtab_rules_end"
64bit RULES FILE:
Code:
ACTION!="add", GOTO="gtab_rules_end"
SUBSYSTEM!="usb|usb_device", GOTO="gtab_usb_end"
ATTRS{idVendor}=="04e8", ATTRS{idProduct}=="6860", MODE="0777" SYMLINK+="gtab"
LABEL="gtab_usb_end"
LABEL="gtab_rules_end"
Tested, walked through the steps to my friend (Skype ). Works 100% on Linux Mint too
Everything worked for me up to the GMTP part - I can grep through /dev and I can see the "gtab" device there. But GMTP insists "Detect: No raw devices found."
I'm still running Maverick, but I added the maverick-backports repo, which has gmtp, so I would think it would work.
This is a Samsung Galaxy Tab 10.1v (from Google I/O). Any ideas?
EDIT: I also tried the automounting option with FUSE. Attempts to cd into it with bash or open it from the Places menu in GNOME both give the message "Transport endpoint is not connected".
EDIT again:
OK, I disabled USB Debugging and now have a different set of problems. mtp-detect sees the device now, but the message upon running it is:
Code:
libmtp version: 1.0.3
Listing raw device(s)
Device 0 (VID=04e8 and PID=6860) is UNKNOWN.
Please report this VID/PID and the device model to the libmtp development team
Found 1 device(s):
04e8:6860 @ bus 2, dev 26
Attempting to connect device(s)
ignoring usb_claim_interface = -16ignoring usb_claim_interface = -22PTP_ERROR_IO: Trying again after re-initializing USB interface
inep: usb_get_endpoint_status(): Device or resource busy
outep: usb_get_endpoint_status(): Device or resource busy
usb_clear_halt() on IN endpoint: Device or resource busy
usb_clear_halt() on OUT endpoint: Device or resource busy
usb_clear_halt() on INTERRUPT endpoint: Device or resource busy
LIBMTP PANIC: Could not open session! (Return code 767)
Try to reset the device.
Unable to open raw device 0
OK.
Konklone said:
Everything worked for me up to the GMTP part - I can grep through /dev and I can see the "gtab" device there. But GMTP insists "Detect: No raw devices found."
I'm still running Maverick, but I added the maverick-backports repo, which has gmtp, so I would think it would work.
This is a Samsung Galaxy Tab 10.1v (from Google I/O). Any ideas?
EDIT: I also tried the automounting option with FUSE. Attempts to cd into it with bash or open it from the Places menu in GNOME both give the message "Transport endpoint is not connected".
Click to expand...
Click to collapse
Can you post the output from 'lsusb' ?
re the "Transport endpoint is not connected" - I just got this same error on 64bit Natty. Will try and see if I can find out why..
Ah, just saw your reply. I edited my post up above, but the gist is - you can't do this while USB Debugging is enabled. The Tab has to be running its "MTP Application".
Now I'm getting the stranger errors above. I'm going to try mounting it with FUSE now to see if that helps for some reason.
EDIT: For the record, I'm using the correct vendor and product IDs in my rules file:
Code:
ATTRS{idVendor}=="04e8", ATTRS{idProduct}=="6860", MODE="0666" SYMLINK+="gtab"
Konklone said:
I edited my post up above, but the gist is - you can't do this while USB Debugging is enabled.
Click to expand...
Click to collapse
You may be right. When I wrote this guide, I was using a VM. It is possible that the fact that I was using both MTP and ADB at the same time has something to do with how VMWare presents the devices to the guest OS.
Now I am using 'bare metal' Natty 64 bit and have the same problem as you.
I have to go out for a while but will look at it again when I get back.
EDIT: Just tried mtp-detect and it is finding the device. I suspect USB Debug is not the issue, but I'll leave it in your capable hands - really got to go now
EDIT2: See here http://www.usb.org/developers/devclass_docs/MTP_1.0.zip OK - Im really REALLY going now. Back online in a few hours
I couldn't get anywhere until I turned off USB debugging. When USB debugging is enabled, I *can* use adb to get into the shell, see files, install apps, etc. I can even transfer files over adb, through the command line! Can you get MTP to detect it with USB debugging enabled?
With USB debugging off, I have once in a great while (only twice in all my attempts) while gotten mtp-detect to connect to the device and print sane output describing the device. Even when those happened, running the command immediately again didn't connect correctly, and gave me the same error messages I was getting before. Both times I got it to connect, it was soon after plugging in the cable, but it doesn't happen every time.
Intermittent heisenbugs are the worst, yet I don't think I have a busted cable, given that adb works perfectly consistently.
Maybe I should try this again after updating to Natty...I'd been meaning to do it anyhow...
EDIT: One thing I notice is that on the Tab, when the "MTP Application" is running after plugging in, the 5-dot "in progress" animation is extremely choppy, as if the device were very very busy. If the device were very very busy for some reason, this could explain why a successful connection can happen only once in a great while. I'll try rebooting the device, I guess.
EDIT2: I rebooted the device, and I removed the USB extension cord I was using, but neither helped, still getting the same intermittent success. (I got mtp-detect to connect to it a few more times - all soon after plugging in the cable, and none were repeatable without unplugging and replugging it in.) The animation actually wasn't choppy before, that's just how it looks - 5 discrete animation frames, one for each dot.
Something interesting though: this time I had the Tab resting on my knee, and I felt a haptic buzz after running mtp-detect on one occasion. I looked down and saw the MTP Application restart itself. Then I ran mtp-detect again and I felt 3 haptic buzzes in quick succession, followed by a successful detection and output. But when running mtp-detect *again*, no dice.
This is messed up.
Messed up indeed.
Konklone said:
Can you get MTP to detect it with USB debugging enabled?
Click to expand...
Click to collapse
Yes, both work simultaneously on 32bit Natty
Note that you have to unmount the gtab for mtp-detect to work. I compared the output from mtp-detect on the 32bit working VM and the 64bit non-working 'bare metal' machine and the output was identical. I suspect this means that mtpfs is not where the problem is
Re the strange problem with haptic feedback - I have had mine power off all by itself when testing some different parameters in the rules file.
[64bit working]
OK. Problem solved... kind of. There seems to be some kind of bug in fuse which requires the filesystem to mount with higher permissions to run properly (at least on Natty AMD64)
If you use the new 64bit rules file I have attached, it should work. Basically it uses 777 permissions instead of 666. Not great, but working nonetheless.
New rules file for 64bit:
Code:
ACTION!="add", GOTO="gtab_rules_end"
SUBSYSTEM!="usb|usb_device", GOTO="gtab_usb_end"
ATTRS{idVendor}=="04e8", ATTRS{idProduct}=="6860", MODE="0777" SYMLINK+="gtab"
LABEL="gtab_usb_end"
LABEL="gtab_rules_end"
EDIT: If someone wants to experiment with lesser permissions and see what the minimum is and post back, that would be helpful for all.
Sigh, thank you for taking so much time to help me so far, but I wonder if I'm a lost cause.
I spent a bunch of today finishing my upgrade to Natty, including a full wipe and reinstall. (I have a 32-bit machine, btw.) Now I can't even get it to detect my MTP device at all (mtp-detect says "No raw devices found."), with or without debugging enabled.
One possibly important topic - it's really surprising to me that yours works either way, because lsusb shows that a different product ID is exposed to the host, depending on whether debugging is on or not. With debugging disabled, it's 6860, like your example. With debugging enabled, it's 685e. When I run lsusb, only one of those will show up, never both. So if yours is the same device, I have no idea how your rules file could be agnostic to debugging being enabled. If yours is not, then that might explain our different experiences.
Anyway, I've Thanks'd all your posts in this thread, solved or not. I appreciate your help.
Konklone said:
With debugging enabled, it's 685e. When I run lsusb, only one of those will show up, never both
Click to expand...
Click to collapse
You're more than welcome.
I noticed that in Windows, both devices appear in device manager. That is a very strange problem you have discovered.
I just posted instructions and files to give you root access! Might take your mind off the MTP issues for a while
Who knows... the problem might just go away
Konklone said:
One possibly important topic - it's really surprising to me that yours works either way, because lsusb shows that a different product ID is exposed to the host, depending on whether debugging is on or not. With debugging disabled, it's 6860, like your example. With debugging enabled, it's 685e. help.
Click to expand...
Click to collapse
Are you sure? On my device its the other way around. Without debugging its 685e and with debugging its 6860?
ajvogel said:
Are you sure? On my device its the other way around. Without debugging its 685e and with debugging its 6860?
Click to expand...
Click to collapse
Ok I got it working on my device, I switched on usb debugging in settings. lsusb now returns 6860 and I am able to mount the galaxy tab using the process outlined above.
This is craziness. Is my Galaxy Tab a rare mutant piece of hardware who had its USB numbers switched?
Also - I noticed that Ubuntu somehow automounts my tablet and can read/write to its disk, through a Nautilus plugin. But I still get nothing with mtp-detect. I don't understand how the world works.
I've also got an I/O tablet (updated to 3.1) and I followed this tutorial, so thanks for the help you provided! I managed to copy some files to the device but it ended up freezing my computer (running Ubuntu 10.10).
So I unplugged the tablet, and saw that effectively those few pictures and pdf files had been copied to the device successfully. Pictures are in the Gallery, pdf can be read with Aldiko... but the funny thing is that when I mounted again the tablet -using Ubuntu again- it shows all folders as empty!
That is, 0 files in all tablet folders.
I tried "showing all hidden files" with Nautilus. No luck, nothing is shown. Went to the folder using command line, did an ls -la (just in case who knows! maybe it would show something!). No luck either, directories are apparently empty and have "1 January 1970" as modification date... if it helps.
I can see the files inside the folders using ADB but it's obviously not ideal, specially compared with simply using Nautilus.
Does it happen to you too?
Anyone get this working? I'm having the same exact issues as Konklone. I'm on Maverick and tried the different udev rules and it still doesn't work. I'm gonna be pissed if I have to buy the stupid Samsung USB adapter just to get USB mass storage.
[ASK]Noobs need solution
gMTP tells me that there is no device. Any ideas?
I'm having the same issue. First try I was able to plug in and mount to my netbook. Tried to plug into my mac and it didn't work. Hasn't worked since then, i'm considering doing a factory reset.
I'm running Ubuntu 10.10 64-bit. Note that you do have to enable backports to install gmtp.
Edit /etc/apt/sources.list, uncomment the lines with:
Code:
deb (http-url) maverick-backports main restricted universe multiverse
deb-src (http-url) maverick-backports main restricted universe multiverse
Run
Code:
sudo apt-get update && sudo apt-get install gmtp
I had to unplug the device and replug it back in a couple of times before gmtp would connect to it properly. It seems to be pretty flaky.
Wow...........
This is nonsense ..... is there a way to enable USB Mass Storage or are we completely hosed with MTP?

How to unlock, TWRP, root, etc from OSX Mavs - MacBook Air

somehow I managed to install the OTA MM update that I was holding off until I could unlock, root, blah, blah, blah.
I'm now on 20i.
And it responds to adb (v1.032) and fastboot commands from Terminal on my OSX MacBook Air.
Has anyone "authorized" (aka - fastboot oem unlock) their 811 and flashed TWRP from a Mavs Mac ?
Or do I need to go to my Bootcamp partition to accomplish?
Seems like to should work from Mavs direct, but …….
Bootcamp not needed.
system settings (tap on Build number until it says you’re a developer.)/developer/check oem unlock & USB debug
USB connect to Mac. I use Android File Transfer. I found it less annoying and very fast.
But it will not work with the LG drivers installed. aka LGUnitedMobileMacDriver_v4.23.zip, or LGMobileMacDriver_v5.2.zip, or LGBridge_Mac.dmg.
in Terminal:
adb devices - should reveal the devices serial - LGH811xxxxxxxxx. If not, your Mac and adb/fastboot are not set up properly.
adb reboot bootloader
fastboot devices - should reveal serial again. xxxxxxxx
fastboot oem unlock - this will WIPE the G4s internal SD that comes with the phone.
fastboot getvar unlocked - to confirm unlock
fastboot reboot - and set-up as a new device.
If you're on MM, and you set it up previously, restore should happen automatically upon reboot, after you enter your google or ID, etc.
If it seems to be taking too long, restart.
Make sure you recheck that USB debug is checked in developer options.
and then to flash TWRP and SuperSu so as to root.
Terminal:
adb reboot bootloader
fastboot boot (drag and drop the {I shortened the name of the file after duping} twrp.img into the Terminal window)
This will boot you into a temporary TWRP recovery. (v2.8.7.2)
Install twrp.img (select zip or img button bottom right)
Then install SuperSu 2.6.7.zip.
REBOOT SYSTEM
check root -
Terminal:
adb shell. should get #. if not - su. should get #.
troubleshooting.
May have to re-enter developer mode
sys settings/about/software/more/tap build number 7 times fast.
unplug USB.
Toggle USB debugging in Developer. Should get prompt about RSA.
re-plug USB
adb kill-server
adb devices
If TWRP isn't recognizing your b.u., write a new back-up. This creates the path TWRP wants to see. Copy your old b.u. into the new folder:
TWRP/BACKUPS/LGH811#########/2016-10-23--15-58-36_MRA58K
RenameÂ*the old b.u. the same as the new b.u. and toss the new one.
Reboot Recovery and you now should now able to to restore from the old b.u.

[UNLOCK][ROOT][TWRP][UNBRICK] Fire TV Stick 2nd gen (tank)

Read this whole guide before starting.
This is for the 2nd gen Fire TV Stick (tank)
Current relase: amonet-tank-v1.2.2.zip
NOTE: Recent reports indicate a change that disables brom DL-mode
The change seems to have been introduced with devices that where manufactured in December 2019 or later.
The change is unrelated to the software-version and results in the device not showing up as a USB device when shorted.
Unfortunately these devices cannot currently be unlocked.
NOTE: If you are on version 1.0, don't update to 1.2.1 through TWRP, as there is a bug.
NOTE: This issue has been fixed in version 1.2.2
NOTE: When updating from version 1.0, don't install anything else before rebooting
To update to the current release if you are already unlocked, just flash the zip in TWRP.
What you need:
A Linux installation or live-system
A micro-USB cable
Something conductive (paperclip, tweezers etc)
Something to open the stick.
NOTE: Ideally you want to update your system to 5.2.6.9 before starting this process, since this flashes the 5.2.6.8 boot.img and people have reported issues with adb-authorization with older firmware.
Since version 1.2 this isn't required, because instead of flashing the 5.2.6.9 boot.img, your existing boot.img will be patched.
It is still recommended to first update to 5.2.6.9
Install python3, PySerial, adb and fastboot. For Debian/Ubuntu something like this should work:
Code:
sudo apt update
sudo add-apt-repository universe
sudo apt install python3 python3-serial android-tools-adb android-tools-fastboot
Make sure ModemManager is disabled or uninstalled:
Code:
sudo systemctl stop ModemManager
sudo systemctl disable ModemManager
NOTE: If you have issues running the scripts, you might have to run them using sudo.
Also try using different USB-ports (preferably USB-2.0-ports)
1. Extract the attached zip-file "amonet-tank-v1.2.2.zip" and open a terminal in that directory.
2. start the script:
Code:
./bootrom-step.sh
It should now say Waiting for bootrom.
Short CLK to GND (The metal shielding is also GND) according to the attached photo and plug it in.
NOTE:
In lsusb the boot-rom shows up as:
Code:
Bus 002 Device 013: ID [b]0e8d:0003[/b] MediaTek Inc. MT6227 phone
If it shows up as:
Code:
Bus 002 Device 014: ID [b]0e8d:2000[/b] MediaTek Inc. MT65xx Preloader
instead, you are in preloader-mode, try again.
dmesg lists the correct device as:
Code:
[ 6383.962057] usb 2-2: New USB device found, idVendor=[b]0e8d[/b], idProduct=[b]0003[/b], bcdDevice= 1.00
4. When the script asks you to remove the short, remove the short and press enter.
5. Wait for the script to finish.
If it stalls at some point, stop it and restart the process from step 2.
6. Your device should now reboot into unlocked fastboot state.
7. Run
Code:
./fastboot-step.sh
8. Wait for the device to reboot into TWRP.
9. Use TWRP to flash custom ROM, Magisk etc.
NOTE:
Only ever flash boot/recovery images using TWRP, if you use FlashFire or other methods that are not aware of the exploit,
your device will likely not boot anymore (unless you flashed a signed image).
TWRP will patch recovery/boot-images on the fly.
NOTE:
This process does not disable OTA or does any other modifications to your system.
You will have to do that according to the other guides in this forum.
Very special thanks to @xyz` for making all this possible and putting up with the countless questions I have asked, helping me finish this.
Thanks to @hwmod for doing initial investigations and providing the attached image.
Changelog
Version 1.2 (25.03.2019)
Update TWRP to twrp-9.0 sources
Implement downgrade-protection for LK/PL/TZ
Add scripts to enter fastboot/recovery in case of bootloop
Automatically restore boot-patch when you boot into recovery
Features.
Hacked fastboot mode lets you use all fastboot commands (flash etc).
Boots custom/unsigned kernel-images (need to be patched)
For the devs: sets printk.disable_uart=0 (enables debug-output over UART).
TWRP protects from accidental lk/preloader/tz downgrades
Set bootmode via preloader
NOTE: Hacked fastboot can be reached via TWRP.
NOTE: Hacked fastboot won't patch your boot/recovery-images, so you can easily go back to stock.
Use TWRP for autopatching.
There are three options for interacting with TWRP:
A mouse via USB-OTG
TWRP commandline via adb: https://twrp.me/faq/openrecoveryscript.html
Via /cache/recovery/command
Example for /cache/recovery/command:
Code:
echo "--update_package=/path/to/zipfile" > /cache/recovery/command
echo "--wipe_cache" >> /cache/recovery/command
reboot recovery
Should you somehow end in a bootloop you can boot into hacked fastboot or recovery using.
Code:
sudo ./boot-fastboot.sh
Code:
sudo ./boot-recovery.sh
NOTE:This will only work if the boot-exploit is still there.
Source Code:
https://github.com/chaosmaster/amonet
https://github.com/chaosmaster/android_bootable_recovery
how would you get to twrp after rebooting to system?
krsmit0 said:
how would you get to twrp after rebooting to system?
Click to expand...
Click to collapse
Code:
adb reboot recovery
k4y0z said:
Code:
adb reboot recovery
Click to expand...
Click to collapse
ok, made it to recovery. not sure how to navigate recovery.
krsmit0 said:
ok, made it to recovery. not sure how to navigate recovery.
Click to expand...
Click to collapse
Either via adb shell, or a mouse via USB-OTG
k4y0z said:
Either via adb shell, or a mouse via USB-OTG
Click to expand...
Click to collapse
found this, thanks, didnt know about this
https://twrp.me/faq/openrecoveryscript.html
Oh nice! I'll try it later today!
first one worked fine. second seemed to go ok but i cant get back in with adb. device unauthorized. i went through the process again to get back to recovery and i copied the adb_keys from the one that worked to the other one. permissions and ownership are the same, but it still says unauthorized. i also dont get the prompt to allow connection on the stick itself. i have connected with this stick through adb before this.
UPDATE: Factory reset didnt bring back the adb debug prompt. but an update did. I was on an older version.
krsmit0 said:
first one worked fine. second seemed to go ok but i cant get back in with adb. device unauthorized. i went through the process again to get back to recovery and i copied the adb_keys from the one that worked to the other one. permissions and ownership are the same, but it still says unauthorized. i also dont get the prompt to allow connection on the stick itself. i have connected with this stick through adb before this.
Click to expand...
Click to collapse
Mhh, what Firmware are you on?
Does it still boot normally?
Have you tried adb both over network and USB?
Can you make sure, adb is enabled in developer settings?
If that doesn't help could you try factory reset?
k4y0z said:
Either via adb shell, or a mouse via USB-OTG
Click to expand...
Click to collapse
k4y0z said:
Mhh, what Firmware are you on?
Does it still boot normally?
Have you tried adb both over network and USB?
Can you make sure, adb is enabled in developer settings?
If that doesn't help could you try factory reset?
Click to expand...
Click to collapse
it took an update to resolve it. factory reset didnt work. i was not getting the adb authorization prompt so i couldnt boot to recovery. i have it back up and running.
krsmit0 said:
it took an update to resolve it. factory reset didnt work. i was not getting the adb authorization prompt so i couldnt boot to recovery. i have it back up and running.
Click to expand...
Click to collapse
fastboot-step flashes the 5.2.6.8 boot.img, maybe that was causing an issue with older firmware.
Glad you got it solved. Now we also know updates are working fine (Allthough disabling OTA might not be the worst idea)
The photo has the points labeled but doesn't specify what gets shorted. Are you supposed to short CLK to GND?
AFTVnews.com said:
The photo has the points labeled but doesn't specify what gets shorted. Are you supposed to short CLK to GND?
Click to expand...
Click to collapse
Yes, exactly.
I have updated the OP.
Wow, nice one @k4y0z. I'm so happy this little device can now have an unlocked bootloader; it's going to open up many possibilities on a device that is so inexpensive.
My Firestick 4k bootloops
Sir i have a serious problem with my Firestick 4k. I experimented to sideload google play services on my FS 4k and it installed successfully. But when i restart my device it bootloops on and on to Firestick logo. Any solution sir? Damn i must have not do that. Please sir help me. I think i must hard reset the Firestick 4k but how?
Will the Playing with Fire pack work without any changes?
Any chance a similar exploit can be done on the 1st gen stick (montoya)?
k4y0z said:
Yes, exactly.
I have updated the OP.
Click to expand...
Click to collapse
It looks like there is a test point attached to the trace that looks like it's going to what's labeled as CLK. Is that what you can use to short, or do you have to short the thing you are pointing to?
Have you modified anything, or is this the stock stuff that the original exploit used? Are these .bin files what I would get if I were to compile everything from the github?

[UNLOCK][ROOT][TWRP][UNBRICK][...] FireTV 2nd gen Cube (raven) > PS7242

{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Raven Boot v2.0 now includes persistent root. A huge thank you to @Functioner for getting it working! This package includes unrestricted U-Boot, fastboot & Amlogic burn mode commands, as well as TWRP and Magisk support. The Raven boot tool includes options to root your Cube, gain temporary root access without modifying your device, and a number of options for recovery and backup.
NOTE: FireOS < 7.2.7.3 required
A newer method is available that works up to PS7292, that doesn't use DFU or a DFU device, but has no DFU recovery options
NOTE: This process does not require you to open your Fire TV 2nd gen Cube
Changelog:
v2.2 April 7th, 2023​
Minor update to Magisk 25.208
Hopping back on official signed Magisk app line
v2.0 and v2.1 use an unofficial Magisk build that will result in a signature mismatch when updating.
If you are using Raven root v2.0/2.1, delete the file /data/adb/magisk.db on your Cube,
before updating to Raven root v2.2.
Added USB booting for flash drives that use aml_autoscripts, for future development.
​v2.1 February 18th, 2023​
Updated TWRP v3.6.1-9-0 ---> v3.7.0-9.0
Fixed problem with TWRP not always displaying all the partitions under 'Mount/Backup'
Always mounts 'Internal Storage' to /sdcard now
Fixed bash menu to always use the included fastboot binary
Cube's physical buttons can be used on bootup
Volume Up ---> Fastboot
Volume Down ---> TWRP recovery
Action button ---> Amlogic Update
**Hold down button for ~5sec after power-on, and before the blue LEDs / 1st Amazon logo​​v2.0 February 9th, 2023​
Root is now persistent, does not require computer after every reboot
One click option to install root access, TWRP, Magisk & OTA blocker module
Magisk updates
Zygisk is working (July 1st, 2022)
Magisk can be installed from TWRP or direct installed from within Magisk Manager
Created module to block Amazon OTA updates via etc/hosts and hiding the OTA apk
updated quick access images to Magisk v25.2
TWRP updates
Bootloader flashing is blocked, so that full OTA firmware bins can be easily flashed (tested up to PS7624/3337)
Removed firmware downgrade checks & warnings
Added NTFS support for flash drives within TWRP
Added options to backup entire reserved partition, and mmcblk0boot0 & mmcblk0boot1 boot partitions in Amlogic update
Added emergency boot to Fastboot/Update modes
v1.0 May 15th, 2022​
Temporary unrestricted fastboot, u-boot & update commands
Boot with root access or Magisk support
Boot to TWRP for backup & recovery
Backup Cube using Amlogic Update
What's needed:
linux installation or live-system (Ubuntu 20.04.x recommended)
micro-USB cable
device to put Cube into device firmware upgrade (DFU) mode [read below]
libusb is needed for your linux installation to detect the Cube over USB.
sudo apt-get install libusb-1.0-0
To automatically set the proper udev rules for Amlogic install Khadas utils:
sudo apt-get install libusb-dev git
sudo apt-get install git
git clone https://github.com/khadas/utils
cd utils
./INSTALL
***NOTE: If you previously installed Magisk on your Cube from raven_boot v1.0, first run adb shell rm /data/adb/magisk.db to prevent any conflicts with the new Magisk version.
Instructions
Download the latest raven_boot.zip and unzip it. Open a terminal window from the unzipped raven_boot directory
Power off the Cube and connect your DFU device to the Cube's HDMI port. Connect the USB cable (microUSB to USB-type A) to computer & Cube
Power on the Cube, type lsusb in the terminal to confirm ID 1b8e:c003 Amlogic, Inc. is present, indicating the Cube is in DFU mode
Unplug the DFU device from the HDMI port, reconnect the Cube to TV with HDMI cord. Keep the computer connected.
In the terminal type bash menu, and choose option 1) to automatically root the Cube.
To preserve the Cube's persistent root, be sure to confirm that both TWRP & Magisk are installed.
Quick Access
For options 2) and 3) to gain temporary root, download the images zip file that corresponds to your current FireOS version, and unzip the contents into raven_boot/images directory.​For Cubes running FireOS 7242/2896 or later get ---> images_7242-2906_v2.0.zip​For FireOS versions 7201/942 to 7242/2216 get ---> images_7229-1853_v2.0.zip​
Magisk v25.206 is included with Raven boot, it's recommened that you use this version or newer. For instructions on how to update your firmware and keep root access, read here
About the exploit
This exploit is based on a vulnerability in the Amlogic bootrom that allows for us to run unsigned code in the next boot stage (Bl2). To pause the automatic boot up process, before the Cube's saved Bl2 is loaded, we rely on Amlogic's device firmware upgrade mode (DFU). In DFU, only the boot code from the Amlogic s922x SOC (Bl1) has been loaded into memory. We then use the vulnerability to load our modified Bl2, breaking the 'chain of trust', and disabling secure boot so that we can make modifications to the bootloader downstream. The last stage of the bootloader is U-boot (Bl33) which hands off the startup process to the kernel (boot.img). U-boot is modified to unlock any restrictions on u-boot and fastboot commands, giving us full access to system features. We can then use fastboot boot to load our modified boot images (TWRP, magisk-patched boot.img), into memory without modifying the Cube's eMMC.
Visit GitHub for a more in depth write-up and resources used in this project
Contributors
@Functioner
@Zenofex
@npjohnson
@zeewox
@Pro-me3us
Additional thanks to
@tchebb - a bottomless encyclopedia of Amlogic knowledge, answering countless questions & troubleshooting
@roligov - providing photos, additional FireOS updates, and testing
@osm0sis, @canyie, @vvb2060 & @yujincheng08 - the Magisk team for being awesome, troubleshooting and making a number of code changes to get all features working on the Cube
@k4y0z - helping troubleshoot some TWRP and Magisk issues
Entering the Cube's DFU mode
To boot into device firmware upgrade (DFU) mode we need to pass a '[email protected]' command, to the Cube's Amlogic s922x SOC, through the I2C bus accessible via the HDMI port. This was first described in the FireFU exploit for the 1st gen Cube. Since then there are a few more options for devices to accomplish this:
DIY modified dummy HDMI dongle. Fully self-contained, and powered by the HDMI port. Simple to use, just plug-in and unplug, can be made for $5 or less and is what I recommend.
https://github.com/superna9999/linux/wiki/Amlogic-HDMI-Boot-Dongle
I2C emulator for ATmega boards (Arduino Duemilanove, ATmega48/88/168/328). Requires less skill, potentially little to no soldering. A Tiny88 ($2-3) wired to an HDMI breakout board ($2-3) can be programmed over USB with one command.
https://github.com/tchebb/amlogic-hdmiboot-avr
Arduino sketch to boot into DFU, compatible with ARM-based Arduino boards (Due, Teensy, Genuino). Costs more but a good alternative if you already have an Arduino board.
https://www.exploitee.rs/index.php/FireFU_Exploit#Preparing_HDMI_dongle
Flashing OTA Firmware with TWRP
To upgrade the firmware past PS7273+ and keep the Cube unlocked and rooted, we need to avoid flashing any bootloader version newer than PS7242/3516. The new build of TWRP included with Raven boot v2.0+ and Raven root shrinker automatically blocks any bootloader flashing. Be sure that you are using Raven boot v2.0 or newer! Firmware bin flashing is working and tested up to PS7633/3445.
The shrinker script only works up to PS7624/3337, upgrading past this version will still maintain root, but will lose the shrinker backdoor backup.
Update Procedure:
1) Download the full firmware bin (XDA or Github), change extention .bin to .zip
2) In ADB type reboot recovery to enter TWRP. You can also open Magisk Manager and choose the reboot to recovery option in the top right corner of the main screen.
3) Copy the firmware file to your Cube via USB connected computer, flash it, and re-flash Magisk
Code:
adb push <firmware-filename.zip> /sdcard/Download/
adb shell
twrp install /sdcard/Download/<firmware-filename.zip>
twrp install /sdcard/Download/magisk.apk
If you used the shrinker method, then the magisk apk is in /data/local/tmp/ instead
Code:
twrp install /data/local/tmp/magisk.apk
If you prefer to use a USB mouse and regular TWRP interface, rather than computer, download the firmware bin directly to the Cube in FireOS. Firmware updates don't require wiping data/dalvik. If downgrading firmware, wiping data/dalvik is advisable.
NOTE: It's IMPORTANT to not forget to flash magisk.apk after each firmware upgrade. Magisk & TWRP work together to preserve root access. Magisk prevents TWRP from being deleted, and TWRP helps to prevent accidental Amazon OTA updates. Without Magisk, OTA updates will no longer be blocked by the OTA blocker Magisk module.
Protected Packages
Amazon added package protection in +PS7273. To remove this, boot into FireOS with Magisk or root support, edit /data/system/PackageManagerDenyList, delete the list of applications, and save.
To prevent the protected applications list from being regenerated on reboot, disable:
Code:
adb shell pm disable-user com.fireos.arcus.proxy
All applications can now be disabled/enabled without root, including custom launchers.
reserved
Thanks for this! So far I've only confirmed old enough firmware (PS7229/1856) and installed a uart header. Seems I will have to wait a while to get a working hdmi plug for dfu access.
While looking at the uart log, I noticed that u-boot is interruptible prior to boot, which is a little unusual. But every u-boot command is disabled, even "help"!
I noticed some text about a one time override code of some sort. Did you find any additional information about this code while working on the bootloader?
Would it not be possible to just flash a patched bootloader, much like is described at the site you've referenced? Is the stock bootloader encrypted? If so, were the relevant keys extracted?
What about ≥ 7.2.7.3 kills this exploit? Is dfu access lost? If not, what else prevents it from working? I wouldn't think that dfu could be lost, since it is in rom, unless an efuse can disable it?
goapy said:
While looking at the uart log, I noticed that u-boot is interruptible prior to boot, which is a little unusual. But every u-boot command is disabled, even "help"!
I noticed some text about a one time override code of some sort. Did you find any additional information about this code while working on the bootloader?
Click to expand...
Click to collapse
On the stock bootloader Amazon has blacklisted all uboot commands. The bootloader code is available through Amazon's open source repository. The uboot console restrictions are in:
platform/bootable/bootloader/uboot-amlogic/s922x/bl33/common/amzn_lockdown.c
The unlock codes are generated by Amazon's servers in combination with the devices' serial number. This system is the same as other fire devices. There is a list of all the uboot commands in the documents folder of raven_boot.zip to give you an idea of what's available.
To work with the U-boot console, you can also send uboot console commands via Amlogic burn-mode for convenience.
Code:
./update bulkcmd "uboot command"
Unfortunately, i don't think there is a way to route the uboot console output over HDMI or USB, so TX is still necessary for visualization. Your soldering work and connector look a lot nicer than what I was working with, I'm jealous
goapy said:
Would it not be possible to just flash a patched bootloader? Is the stock bootloader encrypted? If so, were the relevant keys extracted?
Click to expand...
Click to collapse
The bootloader is signed, and verified by the bootrom. This is part of the 'chain of trust' that ensures the bootloader is not altered / tampered with. The reason the patched bootloader in the OP can be loaded is because we are using a tethered computer to run a bootrom exploit program (amlogic-usbdl) to inject our own next stage code (bl2.bin) that bypasses the bootrom verification process. The modified Bl2 code allows for the rest of the bootloader to load. Without a computer to run the exploit, our Bl2 code would fail verification, and the Cube would hang.
The bootloader is encrypted with several keys, and the keys change with major releases. I don't know what XDA's policy is on posting keys, so I don't want to chance a violation. A more detailed description of the whole process will be added to github relatively soon.
goapy said:
What about ≥ 7.2.7.3 kills this exploit? Is dfu access lost? If not, what else prevents it from working? I wouldn't think that dfu could be lost, since it is in rom, unless an efuse can disable it?
Click to expand...
Click to collapse
@roligov said he was not able to enter into DFU with USB after 7.2.7.3. There was an option added to the efuse file last year to disable DFU from USB, my guess is Amazon chose to burn the fuse(s) in 7.2.7.3.
EDIT: If you plan to be do a lot of probing, I'd recommend going with Superna9999's HDMI dongle design, it's a lot more convenient than the Arduino boards.
goapy said:
What about ≥ 7.2.7.3 kills this exploit? Is dfu access lost? If not, what else prevents it from working? I wouldn't think that dfu could be lost, since it is in rom, unless an efuse can disable it?
Click to expand...
Click to collapse
Pro-me3us said:
@roligov said he was not able to enter into DFU with USB after 7.2.7.3. There was an option added to the efuse file last year to disable DFU from USB, my guess is Amazon chose to burn the fuse(s) in 7.2.7.3.
Click to expand...
Click to collapse
Exactly that. I had a unit that worked fine, tested DFU mode before applying update Fire OS 7.2.7.3 (PS7273/2625). After updating to that firmware version, DFU mode no longer worked. Exact same setup worked 5 minutes before and still works on other cubes. If no one on here confirms it no longer works on the latest firmware, I may sacrifice another cube and update to the latest. I thought it wasn't possible either since it's a bootrom exploit, but guessing an efuse has been burnt.
It may be possible to probe the board and achieve DFU mode by someone who knows what they doing like the method used for the Fire Sticks (I tried with 1 cube which ended up in a bootloop, luckily Amazon replaced it).
Pro-me3us said:
The bootloader is signed, and verified by the bootrom. This is part of the 'chain of trust' that ensures the bootloader is not altered / tampered with.
The bootloader is encrypted with several keys, and the keys change with major releases.
Click to expand...
Click to collapse
Whatever bootloader keys are used for the chain of trust in order to ensure an internally consistent hand-off from stage to stage are distinct from the most external bootrom key that is used to encrypt the entire bootloader partition image from start to finish, right? That most "external layer" bootrom key, that is used to encrypt the entire bootloader partition image, must remain the same for the life of all instances of the hardware, at least if all similar devices are to be able to run firmware updates, right?
By the "most external layer" of encryption, I mean this layer;
If a device that is configured for secure boot, as distinguished from a device that is not configured for secure boot, like the khadas VIM3L (but still has a bootloader partition that is at least encrypted with the most external layer key), could it not run a different bootloader (that was internally consistent and unmodified), so long as that bootloader was encrypted with a matching most external layer key? Does secure boot prevent this?
For example, if an entire bootloader was taken intact from a generic 922 device, and that entire bootloader was not internally modified at all (but happened to have a functioning u-boot bl33 layer), and that entire bootloader (after itself being decrypted with its most external layer bootrom key, if necessary) was encrypted with the most external layer key matching the v2 cube, would that bootloader not boot all the way to bl33 and beyond on the v2 cube?
Perhaps an internally consistent alternative bootloader, even if if properly encrypted with the most external layer bootroom key, would still break the chain of trust because the portion of the bootloader that is in rom (bl1) is not just generic bootloader code common to many devices, but is customized specifically for that particular secure boot device (or references a root of trust elsewhere in the rom that is individualized), so the subsequent bootloader stages would fail trust because of that individualization that is in, or referenced by, bl1, even if they were entirely unmodified?
Perhaps this bootloader might boot but avb or vbmeta verification might fail in some other way, or whatever drm magic is in the bootloader might be absent, but would it not at least boot, or does secure boot prevent any internally consistent alternative bootloader from booting, even if it is encrypted with the correct most external layer key, matching the bootrom key?
I apologize if I'm missing something obvious because of my impoverished understanding of this process.
roligov said:
Exactly that. I had a unit that worked fine, tested DFU mode before applying update Fire OS 7.2.7.3 (PS7273/2625). After updating to that firmware version, DFU mode no longer worked. Exact same setup worked 5 minutes before and still works on other cubes. If no one on here confirms it no longer works on the latest firmware, I may sacrifice another cube and update to the latest. I thought it wasn't possible either since it's a bootrom exploit, but guessing an efuse has been burnt.
Click to expand...
Click to collapse
Do you have any guesses about how the efuse is burnt by the updated system? Might the new bootloader itself do it, or the running system, or is there anything obvious in updater-script (if amazon ota's use an updater-script)?
It seems that all of the quickly obtainable edid-spoofing hdmi plugs come with an eeprom in the sot23 package, lacking the a0, a1, and a2 pins needed for the addressing change. Does anyone know of a hdmi plug that uses an 8-lead eeprom that can be ordered for quick delivery?
Otherwise I'll modify the sot23 version that I have coming tomorrow, replacing the sot23 at24cs02 with an 8-lead version that I can pull from some waste board.
goapy said:
Do you have any guesses about how the efuse is burnt by the updated system? Might the new bootloader itself do it, or the running system, or is there anything obvious in updater-script (if amazon ota's use an updater-script)?
Click to expand...
Click to collapse
At power on Amlogic devices will print a string of SOC information that starts with G12B:BL....
in that string is F2FB39B0:432060. The 2 values report the security efuse status for the device. 32bit values:
CFG9: 0x00432060
CFG10: 0xF2FB39B0
Following 7273/2625 there is a 1 bit change in CFG10
CFG10: 0xF2FB39B0 (pre 7273) = 1111 0010 1111 1011 0011 1001 1011 0000
CFG10: 0xF2F339B0 (post 7273) = 1111 0010 1111 0011 0011 1001 1011 0000
Bits are read from right to left starting with bit 0, so Flag 19 flips from 1 to 0. The security efuse table shows that an efuse was buned to disable 'IS_FEAT_USB_BOOT_ENABLE', barring DFU entry via USB.
There is little documentation on how to burn efuses, more importantly I don't know of any public information on the efuse addresses that correspond to which features. Burning efuses would have to be done through uboot and the Bl31api which is how non-secure world talks to secure world. Amazon may handle it through cmd_efuse.c, since there was an addition to that code made to disable USB boot in 2021. The following can be found in the 2nd gen Cube package from Amazon's open source page
platform/bootable/bootloader/uboot-amlogic/s922x/bl33/common/cmd_efuse.c
goapy said:
Whatever bootloader keys are used for the chain of trust in order to ensure an internally consistent hand-off from BL stage to BL stage are distinct from the most external bootrom key that is used to encrypt the entire bootloader partition image from start to finish, right? That most "external layer" bootrom key, that is used to encrypt the entire bootloader partition image, must remain the same for the life of all instances of the hardware, at least if all similar devices are to be able to run firmware updates, right?
Click to expand...
Click to collapse
There are several layers of security, including encryption and signed code. The s922x contains an AES key which is static, and it can be used to decrypt the bootloader. The Cube has boot decrypt enabled, meaning that it is expecting Bl2 to be encrypted, and it will decrypt anything passed to it with the internal AES key. Amazon takes things a step further and encrypts the later bootloader stages with 3 more AES keys. So to fully decrypt the bootloader there are 4 total keys, one of which is static.
But in the case of the Cube, decryption is not an issue since we can dig to get all the keys. The keys just allow the SOC to unscramble the image. There is also signing which involves image hashes. By modifying the image, the hash changes, failing the signature check. The function of the amlogic-usbdl exploit is to bypass the code verification, not encryption.
The Bl2 signing tool is public but Bl2 is not open source. I don't know how functional the Bl2.bin is that is included in the firetv open source repository. There's likely also other security checks I'm overlooking.
goapy said:
For example, if an entire bootloader was taken intact from a generic 922 device, and that entire bootloader was not internally modified at all (but happened to have a functioning u-boot bl33 layer), and that entire bootloader (after itself being decrypted with its most external layer bootrom key, if necessary) was encrypted with the most external layer key matching the v2 cube, would that bootloader not boot all the way to bl33 and beyond on the v2 cube?
Click to expand...
Click to collapse
If it was from a generic device without any security features implemented in the bootloader maybe? The Cube has a root key burned to it that I assume is specific to the 2nd gen Cube. I believe this is used in verifying bl2.
There would be hardware/board differences that would lead to a host of issues as well. Uboot would be missing the FireOS layer, so I would be surprised if it could hand things off properly. Bl2 would still have to be encrypted using the AES key, since the Cube has boot encrypt enabled, which is doable.
That could be tested with Amlogic's update tool in DFU.
Code:
./update write bl2.bin 0xfffa0000 //loads bl2 into memory at the run address
./update run 0xfffa0000 //executes bl2 from memroy
./update bl2_boot bootloader.img //loads and runs the rest of the bootloader into and from memory
The closest thing to Khasdas' VIM3L for the s922x is the Odroid N2/+, in terms of a developer's board with little to no security features implemented. The unsigned Cube bootloader will load fairly far on the N2+, but I don't remember if it got as far as the kernel. I never tried the reverse, loading an N2+ bootloader on the Cube.
goapy said:
Otherwise I'll modify the sot23 version that I have coming tomorrow, replacing the sot23 at24cs02 with an 8-lead version that I can pull from some waste board.
Click to expand...
Click to collapse
I did ^this^ because the 8-lead version that I ordered still hasn't arrived yet. See before/after images below. It was a success and I was able to get the exploit running.
While swapping out the eeprom, I noticed that the ddc (display data channel) pair of lines was terminated in the plug, even though this edid emulator device supports passthrough. The ddc pair carries at least two kinds of data, edid and hdcp.
Presumably ddc is terminated because otherwise there would be a serial wire device conflict on the i2c bus at address 0x50, since both the edid emulator device and the sink would each have a eeprom (or prom) at that address.
But since for dfu usage the address is changed to 0x52, I figured the ddc lines could be reconnected and the 0x52 serial device could just ride on a passthrough i2c bus. So, I wired the sda and scl lines as passthrough lines.
I hoped that this would mean that I could repeatedly use the exploit over time without swapping hdmi connections for every reboot. And it does do that. But it also takes a power cycle in order boot to dfu mode from an actively running OS. Booting any of the other images, such as fastboot, twrp, etc., do not require a power cycle and reboot straight to dfu mode with the passthrough device installed.
So, it is still more convenient to just cycle power rather than swap hdmi plugs.
As far as testing the exploit itself, I've only spent an hour so far. The included magisk patched boot image does work, although when I tried to boot a magisk patched boot image that I patched myself (using the original image on the device as a source), it did not boot. All of the provided boot images do work, and are all very useful.
goapy said:
I hoped that this would mean that I could repeatedly use the exploit over time without swapping hdmi connections for every reboot. And it does do that. But it also takes a power cycle in order boot to dfu mode from an actively running OS. Booting any of the other images, such as fastboot, twrp, etc., do not require a power cycle and reboot straight to dfu mode with the passthrough device installed.
Click to expand...
Click to collapse
That's a very nice improvement over Superna9999's design, you should share this with him I did start to strip the plating on my HDMI cable from all the plugging/unplugging during testing. With this design, does the Cube end up powering two ICs, the one on the dongle and the one in the TV HDMI port? Are there any issues having the Cube power both?
Even with the original design, I think a power cycle is required to get into DFU, rather that just a reboot. I remember adb rebooting would cause the Cube to keep resetting until a power cycle or the dongle was removed. It may be that there is a bootrom level 'reboot reason' stored in volatile memory, that's not cleared until power cycling? If you send a reboot command from u-boot / burn mode are you put in DFU, or do you still need to power cycle? I briefly looked for a command to reboot into DFU (without I2C), but couldn't find anything.
goapy said:
The included magisk patched boot image does work, although when I tried to boot a magisk patched boot image that I patched myself (using the original image on the device as a source), it did not boot.
Click to expand...
Click to collapse
You'll need to use a canary build of Magisk to make your own patched boot.img. There is an Amlogic quirk that probably affects many slot A only devices. Amlogic uses the suffix 'normal' rather than '_a', which is not recognized by Magisk. A patch was added to ignore the suffix in canary build ~24.310.
When patching the boot.img with Magisk, choose recovery mode and leave vbmeta unchecked. Using the regular boot mode (not recovery mode), results in a mount/unmount loop during bootup. The cause of this will have to be worked out long-term for a persistent root. Right now SU works for Magisk but Zygisk doesn't. I'm not sure if that is a limitation of loading Magisk with fastboot boot, or because recovery mode is being used to create the patch.
You will also want to enable UART output from the kernel. This will be applied to your Cube automatically by choosing bash menu 1) boot to FireOS with ADB root / permissive. You can do it manually by booting to fastboot
Code:
fastboot oem flags fos: 0x4
The flags are stored in IDME and can also be changed directly there
Code:
fastboot oem IDME fos_flags 0x4
The IDME values will persist without the exploit, but values like
ADB root and DM-verity off will be ignored/rejected by the native bootloader when uboot determines the Cube is not an engineering device (defined as ARB=0). But the console enable value will be accepted, letting you see native FireOS uart output.
EDIT: I added the 31 IDME properties that can be edited
Pro-me3us said:
With this design, does the Cube end up powering two ICs, the one on the dongle and the one in the TV HDMI port? Are there any issues having the Cube power both?
Click to expand...
Click to collapse
I don't think current draw is a problem. A 24c02 eeprom draws 1 mA max when reading, and 5 μA max when in standby. Even if both eeproms on the bus were read at the same, that would not be a lot of current. There is only one read operation of each serial device per power cycle.
Consider another edid emulator with passthrough, the gofanco prophecy. The gofanco emulator has not only two onboard 24c02 eeproms, but also a 3AQ20 MCU and a hc4052 mux/demux IC, all powered by the hdmi port.
Pro-me3us said:
You'll need to use a canary build of Magisk to make your own patched boot.img. There is an Amlogic quirk that probably affects many slot A only devices. Amlogic uses the suffix 'normal' rather than '_a', which is not recognized by Magisk. A patch was added to ignore the suffix in canary build ~24.310.
Click to expand...
Click to collapse
Thanks. I didn't realize that 24.310 was used on the supplied image or that a recovery style patch was required. Now it all works.
Pro-me3us said:
The flags are stored in IDME and can also be changed directly there
Code:
fastboot oem IDME fos_flags 0x4
The IDME values will persist without the exploit, but values like
ADB root and DM-verity off will be ignored/rejected by the native bootloader when uboot determines the Cube is not an engineering device (defined as ARB=0). But the console enable value will be accepted, letting you see native FireOS uart output.
EDIT: I added the 31 IDME properties that can be edited
Click to expand...
Click to collapse
Thanks for the list of IDME properties. I'm getting up to speed now. It's quite different than the typical amlogic setup. No env or vbmeta partitions. There doesn't seem to be any vulnerabilities like the uboot/rsv exploit used for the gen 1 cube.
goapy said:
I don't think current draw is a problem. A 24c02 eeprom draws 1 mA max when reading, and 5 μA max when in standby. Even if both eeproms on the bus were read at the same, that would not be a lot of current. There is only one read operation of each serial device per power cycle.
Click to expand...
Click to collapse
Oh ok that's a minuscule amount. I think HDMI ports are rated for 50-300mA output. Are you able to passthrough 4k 30FPS, 60FPS (Youtube for example) with the one of those connected? Or DV/HDR? I'm curious if a dongle like that could be left in for regular use of the device.
goapy said:
Thanks for the list of IDME properties. I'm getting up to speed now. It's quite different than the typical amlogic setup. No env or vbmeta partitions. There doesn't seem to be any vulnerabilities like the uboot/rsv exploit used for the gen 1 cube.
Click to expand...
Click to collapse
Yeah an ENV partition would have made things a lot easier. Most Fire devices are MediaTek based, and the Cube is sort of alone in the use of U-Boot. There's also the 1st gen Cube and Pendant, but they are getting hard to come by. Frederic's exploit will probably work for any G12A/G12B/SM1 SOC from Amlogic, including the 1st gen Cube and Pendant, but I don't have one to test and make the necessary modifications. Amazon no longer sells these two models, and I'm assuming they also lost DFU access with the February/March update.
I think the uboot/rsv exploit got patched pretty soon after the FireFU release. I also checked aml_emmc_partition.c for the 2nd gen Cube and it was patched by the release version 7.2.0.4.
There is the u-boot vulnerability database. I don't know if any of these are present or useful on the Cube, testing them is above my skill level. I was only able to apply Frederic's exploit to the Cube because he documented everything very well.
I've posted a draft of the raven exploit on github with a little more information. I still need to edit it a bit, but the outline is there.
Pro-me3us said:
Are you able to passthrough 4k 30FPS, 60FPS (Youtube for example) with the one of those connected? Or DV/HDR? I'm curious if a dongle like that could be left in for regular use of the device.
Click to expand...
Click to collapse
It all seems to work so far. All 19 lines are wired as passthrough. The passthrough hdmi ddc link doesn't seem to be bothered by having a non-standard i2c address eeprom on the bus.
Pro-me3us said:
I've posted a draft of the raven exploit on github with a little more information. I still need to edit it a bit, but the outline is there.
Click to expand...
Click to collapse
That's a very illuminating writeup. It instantly filled in a lot of holes in my understanding.
That also seems to have been quite a lot of work, thanks again for sharing it all.
Isn't that most projects, more work than initially anticipated
I did all my testing with the ribbon cable to the physical buttons disconnected. Can you check something for me since you have UART access with the buttons active?
When in FireOS, holding down the Cube action button (button with dot) for 15sec kills all processes and appears shut the device down. But the device is not powered off, the mute button still turns on/off. If you boot into FireOS with the adb root/permissive option, what does the UART output say when doing this?
In this mode, if I press the action button again the Cube reboots, but if I press any of the other buttons, and then action, the Cube does not reboot. So I'm wondering if the Cube is being dropped into some sort of diagnostic that may be accessible from UART.
I'd be interested in seeing any of the UART output including the reboot string
Code:
G12B:BL:6e7c85:2a3b91;FEAT:F2FB39B0:432060;POC:7;RCY:1;USB:3;
I don't know if there are any hidden button combinations when powering the device on that do anything. I'm not sure where that would be defined in the source code. Holding the vol - button during bootup puts the Cube in safe mode. I don't think there are any other known power up button functions yet.
Pro-me3us said:
When in FireOS, holding down the Cube action button (button with dot) for 15sec kills all processes and appears shut the device down. But the device is not powered off, the mute button still turns on/off. If you boot into FireOS with the adb root/permissive option, what does the UART output say when doing this?
Click to expand...
Click to collapse
I'm pretty sure that I executed the sequence described above. Advise If the following is not the correct sequence;
1. boot into FireOS with the adb root/permissive option
2. after fully booted, hold the action button for 15sec
3. after shutdown, try alternatively pressing buttons other than the action button
4. compare the results (of initially pressing buttons other than the action button after shutdown) to pressing the action button without first pressing other buttons.
Code:
=~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2022.06.08 16:45:42 =~=~=~=~=~=~=~=~=~=~=~=
idme_platform_write block_offset=3e7000, capacity=400000
fos_flags set to 87
idme_platform_write block_offset=3e7000, capacity=400000
dev_flags set to 64
cmd cb_download is download:008f2800
Starting download of 9381888 bytes
.......................................................................
downloading of 9381888 bytes finished
Booting kernel...success
boot_addr_start bootm 0x1080000
kernel_size 0x8af0af, page_size 0x800, totalSz 0x8b0000
ramdisk_size 0x0, totalSz 0x0
dtbSz 0x42000, Total actualBootImgSz 0x8f2000
amzn_verify_onetime_unlock_code: Verify one time unlock cert fail, ret = -5
ee_gate_off ...
## Booting Android Image at 0x01080000 ...
reloc_addr =73d75610
copy done
Kernel command line: rootfstype=ext4 ro rootwait skip_initramfs OTG_mode=DEVICE androidboot.selinux=permissive
load bootimage dtb from 0x74625610 ......
.
.
.
[ [email protected]] input input0: key 138 down.
.
.
.
[ [email protected]] vendor_write_shutdown_reason: shutdown_reason 0x0
[ [email protected]] hdmitx: hw: avmute set to 2
[ [email protected]] ISSI: resetting device before reboot!
[ [email protected]] meson-mmc: meson_mmc_clk_set_rate_v3 269
[ [email protected]] meson-mmc: actual_clock :0, HHI_nand: 0x80
[ [email protected]] meson-mmc: [meson_mmc_clk_set_rate_v3] after clock: 0x10100002
[ [email protected]] amvecm: shutdown module
[ [email protected]] di pre hrtimer canel 1.
[ [email protected]] [DI] shutdown done.
[ [email protected]] vout: vout2: aml_vout2_shutdown
[ [email protected]] vout: aml_vout_shutdown
[ [email protected]] fb: osd_shutdown
[ [email protected]] amvdac_drv_shutdown: shutdown module
[ [email protected]] reboot: Power down
bl31 reboot reason: 0x108
bl31 reboot reason: 0x108
system cmd 0.
bl30 get wakeup sources!
process command 00000006
bl30 enter suspend!
Little core clk suspend rate 1908000000
Big core clk suspend rate -2086967296
store restore gp0 pll
suspend_counter: 1
Enter ddr suspend
DMC_DRAM_STAT11: 0x24
DMC_DRAM_STAT11: 0x24
DMC_DRAM_STAT11: 0x24
DMC_DRAM_STAT11: 0x24
DMC_DRAM_STAT11: 0x24
DMC_DRAM_STAT11: 0x24
DMC_DRAM_STAT11: 0x24
DMC_DRAM_STAT11: 0x24
DMC_DRAM_STAT11: 0x24
DMC_DRAM_STAT11: 0x24
The above log happened both when the action button was pressed and also when any other button was pressed instead (after shutdown). New lines containing "DMC_DRAM_STAT11: 0x24" are repeated endlessly, or at least for the 10 minutes that I let it run.
Pro-me3us said:
if I press the action button again the Cube reboots, but if I press any of the other buttons, and then action, the Cube does not reboot
Click to expand...
Click to collapse
I could not get the Cube to reboot if I pressed the action button again after shutdown. Perhaps I wasn't supposed to wait to press it until the shutdown was complete?
A reboot string never appeared, just ""DMC_DRAM_STAT11: 0x24"" endlessly until the power was cycled.
I'm still running PS7229/1856. I don't have an ota for an android 9 version of fireos that is not the current version.
If this is some sort of standby mode, I can't seem to wake out of it.
Do you happen to know why a uart command prompt console can't be started? If;
start console
is executed in a shell with root access, it appears to execute successfully, but no console command prompt appears over the uart connection.
Edit: resolved, disregard.
goapy said:
The above log happened both when the action button was pressed and also when any other button was pressed instead (after shutdown). New lines containing "DMC_DRAM_STAT11: 0x24" are repeated endlessly, or at least for the 10 minutes that I let it run.
Click to expand...
Click to collapse
Ah ok, maybe it is only a shutdown command in that case. The reboot reason 0x108 might be SHUTDOWN_LONG_PWR_KEY_PRESS according to sign_of_life_vendor.c. This looks similar to adb reboot -p which is a software shutdown (0x109?). After a software shutdown the Cube can also be rebooted with the action button. There may be no way to completely shutdown Cube without a real power button. I don't know why in this state pressing the action button doesn't consistently reboot.
Pressing the power button on the remote might also put the Cube in a similar suspension state that does allow waking.
goapy said:
Do you happen to know why a uart command prompt console can't be started? If;
start console
is executed in a shell with root access, it appears to execute successfully, but no console command prompt appears over the uart connection.
Edit: resolved, disregard.
Click to expand...
Click to collapse
I only ever used UART for logs while the kernel was loaded. I never tried to bring up a command prompt. Did you manage to get input working through UART?
For fos_flags the default is 0x0. If you are using the bash menu script it is setting the fos_flags to 0x87 each time FireOS with ADB root is booted. You will have to fastboot boot the image manually to avoid that. You can also set the Flag values with ADB root using the command 'idme fos_flags value'.
The focus was pretty narrow while working on getting the exploit working. I didn't spend much time with the bootrom. Frederic gave me most of the addresses I needed once the bootrom was extracted. I haven't heard of anyone finding extra I2C commands. Both the FireFU and Superna9999 page mention [email protected], but I don't know if that actually works.
You can take a look to see if there is anything interesting. To dump the Cube bootrom run the following command with the zipped files:
Code:
sudo ./amlogic-usbdl memdump_over_usb_s922x.bin cube_bootrom
There is also the question of what that missing 20pin connector is on the Cube PCB.

Categories

Resources