Database Develop

[Q] Loading a custom kernel

Hi All
So, I am a little confused about how to replace my kernel. My mate has a nexus one, and his boot loader allows him to load a kernel from USB into ram to test it which is pretty sweet. If its broken, just power cycle and it gone.
I have managed to compile a gt540 kernel from the sources provided by LG, with some extra modules - hid bluez, iptables, cifs and usb host. But I am at a loss as to how to test this.
From what I can gather, the boot loader is separate from the internal file system. Obviously the nexus one has an awesome boot loader already, but I can't make my gt540 load a boot loader screen.
I had a look at (but didn't install) ClockworkMod Recovery but that doesn't look like it will help me either. I don't want to just replace the zImage kernel file on the filesystem with my new built one by hand, and reboot - if it goes wrong how do I get the old one back?
Is there anyway to have both the kernels on the device, and choose which on to load just like a big-boy computer? I am currently running Quarx 2.1 Black Edition ROM.
Sorry if this has been answered elsewhere, I had a pretty good look and couldn't find anything.
My whole goal is to be able to get some hardware buttons talking to my phone so I can play snes If I can't get an hid bluetooth profile going so i can use a bluetooth keyboard, I'll use usb host mode with a hacked up joypad with batteries inside (if the usb port doesn't supply power).

I think that it would have to be on like a memory card. Maybe some software that when you boot your phone, it will give you the option to boot from phone or memory card. That would be good! Like a bootable dvd in a computer, gives you the option to boot from it or not.
Sent from my GT540 using XDA App

Right, I worked it out. I didn't realise what "fastboot" mode was for. The rom I have installed has a fastboot already, so I turned the phone off and held volume up, search, and power all at once until the fastboot screen appeared.
Then, I plugged in my phone to usb and waited a few seconds running "./fastboot devices" - the fastboot command comes from somewhere, I am not sure where.
The output was :
Code:
[email protected]:~/android-sdk-linux_x86/tools$ ./fastboot devices
???????????? fastboot
[email protected]:~/android-sdk-linux_x86/tools$
Then, I ran the command:
Code:
[email protected]:~/android-sdk-linux_x86/tools$./fastboot boot ~/android-ndk-r4b/GT540_OpenSource_V2.1/kernel/arch/arm/boot/zImage
and it appeared to boot the kernel I built
I haven't confirmed that the kernel is the correct one, but at least I have a process that /should/ work. I need to recompile the kernel with a different version.

[FIX] Get Out Of "Test Mode"

All credit for this find goes to alasdair529.
alasdair529 said:
What I did was, I went into LGPNST and I took the VS910 dll and the original VS910ZV4_04.S4_04.P58008.R5.user.tot
found here:
http://forum.xda-developers.com/show....php?t=1120062
and put my phone in download mode (emergency mode) holding power buttone and volume up
and I flashed it using LGPNST
and Voila my phone is back to normal, no more test mode. My phone is perfect working condition with all usb modes and internet connection working, no more test mode.
Also my phone is back to charging normal. I am so happy I fixed this, I was about to sell it and get something else
honestly there is nothing more to it then that took about 1 minute to set it all up then LGNPST did all the work, very simple, I just don't know why no one else on Google could figure this out or at least post a guide to it if they did, feel free to make a post in the development section, can't wait for mtmichaelson to see this and fix his phone too!
Click to expand...
Click to collapse

I tried to flash v4 or v6, but after that it doesn't boot.
v7, it boots well, but still shows me usb test mode or usb factory mode
weird...

lentm said:
I tried to flash v4 or v6, but after that it doesn't boot.
v7, it boots well, but still shows me usb test mode or usb factory mode
weird...
Click to expand...
Click to collapse
I've had factory cable connected a new USB cable fixed that.
Sent from my VS910 4G using xda premium

I found that fix out also, but I would like to know how to ax test mode without haveing to roll back to Froyo. Because, correct me if I'm wrong, but won't flashing the v7 tot file again just create the test mode issues all over again?

atomD21 said:
I found that fix out also, but I would like to know how to ax test mode without haveing to roll back to Froyo. Because, correct me if I'm wrong, but won't flashing the v7 tot file again just create the test mode issues all over again?
Click to expand...
Click to collapse
Yes it will
Sent from my Dread Ginger Revo using Tapatalk.

Not to dread this up again, but has anyone had any progress on this? Do we know where testmode is being set? Kernal, Radio, ROM...APK?
I would think if it were a bootup setting somewhere, we should be able to do a file or text-in-file search from root up up through the child folders within the core OS. If it were in the APKs, the settings could be in the XML prefs somewhere.. still very searchable.
I have my step-daughters phone stuck in test mode... /=
I dont what to re-create the wheel and spend hours doing stuff that has been done.... so I ask you all this: what do we know so far? Has a simple OS level search in the linux system been done? Is it something in in one of the .rc init files?
It must be somewhere and if we re-root after the TOT, then we should be able to fix this.
Any of the custom ROMs have this if we flash over the TOT? That would rule out APK and ROM settings.

Today I ended up doing a full factory reset, flashed clean V7 tot, then the V8 tot and re-rooted, and finally installed the new breakout rom and I'm still in test mode...

nasaiya said:
Today I ended up doing a full factory reset, flashed clean V7 tot, then the V8 tot and re-rooted, and finally installed the new breakout rom and I'm still in test mode...
Click to expand...
Click to collapse
So this would eliminate ROM and APK.
What are we left with... kernel, radio or recovery partition? Some other hidden partition?
The TOT does a complete re-partition so there must be some hidden key in here somewhere.
I wish I were one of the heavy ROM guys, but I'm just a linux novice and decent developer.
Lets keep brainstorming!

Well I'm just guessing here so bear with me...
AFAIK the cause is flashing in emergency download mode, which is something outside of the normal system, and also outside of the recovery partition. Based on that (and the previous post) I'd guess it set a test mode flag somewhere on another partition that gets "checked" at boot.
I figure we ought to be able to get images of all the partitions with dd but I wouldn't know what to do with that data once I had it... Maybe compare with a non-test-mode phone and look for inconsistancies.
I could be totally wrong though I'm not very familiar with the boot process and that sort of thing.
EDIT: found this: http://wiki.rootzwiki.com/LG_Revolution_Software_Breakdown
Maybe it sets a flag in the MISC partition like it does to boot into recovery or something like that. That stuff is a bit over my head though.

nasaiya said:
Well I'm just guessing here so bear with me...
AFAIK the cause is flashing in emergency download mode, which is something outside of the normal system, and also outside of the recovery partition. Based on that (and the previous post) I'd guess it set a test mode flag somewhere on another partition that gets "checked" at boot.
I figure we ought to be able to get images of all the partitions with dd but I wouldn't know what to do with that data once I had it... Maybe compare with a non-test-mode phone and look for inconsistancies.
I could be totally wrong though I'm not very familiar with the boot process and that sort of thing.
EDIT: found this: http://wiki.rootzwiki.com/LG_Revolution_Software_Breakdown
Maybe it sets a flag in the MISC partition like it does to boot into recovery or something like that. That stuff is a bit over my head though.
Click to expand...
Click to collapse
That's a great find. I'm going to spend some time reviewing that data in hopes that it is something as simple as tweaking one of those partitions.

Sounds good. I'm happy to help with this in any way possible, so let me know if you need anything...
Having to use adb to transfer files all the time is annoying!

I started playing around in the android OS and here are some files I found that ahve "testmode" within them. I tried doing a full system search, but the 'find' keeps stalling/freezing. init.rc has some, what looks like, programmer patch scripts in it that directly affect testmode. What's funny is that each "patch" is labeled by the devs email address! We could probably email the guy to find out how to disable testmode.... (=
# find . -type f -exec grep -l "testmode" {} + 2> /sdcard/err.log
./init.rc
./system/lib/libandroid_runtime.so
./system/lib/libhardware_legacy.so
./system/app/VerizonHiddenMenu.apk
./system/app/Settings.apk
./system/app/LgHiddenMenu.odex
./system/app/LgHiddenMenu.apk
./system/etc/efs.txt
./system/framework/framework.odex
./system/bin/btld
./system/bin/lg_diag_app
./sys/devices/platform/testmode/uevent
./sys/devices/platform/testmode/modalias

I emailed one of the engineers listed in the init.rc file.... MAYBE if we're lucky, he'll help us out.

So far, not looking good. I think he may be thinking I was it disabled in the core, but he doesn't understand that its running actively.
Code:
[B]Eric <[email protected]> Wed, Apr 4, 2012 at 9:13 AM
To: 김세현 <[email protected]>[/B]
[I]Thank you for your response!
Can testmode be disabled in Linux or from Android. Can we dial a code to turn it off?
How can I turn it off? Do you know how or can hint at how to do it?
Thank you again[/I]
[B]김세현 <[email protected]> Wed, Apr 4, 2012 at 9:25 AM
To: Eric <[email protected]>[/B]
[I]Impossible!!
If you are guru, then you can disable it and then it make a brick.
It’s useless job. Why are you trying that?
Give up I suggest. Testmode is lg version of QCT diag cmd set.
BR.[/I]

Guys, test mode is embedded deep inside the kernel source. Disabling it in one place will cause it to not build because it is referenced in another file. Remove it from there and it won't build because of another. Etc., etc., etc. Now what you can try is asking if he knows which partition holds the flag for test mode. It is obviously not /boot, /data, /system/, or /recovery.
Sent from my VS920 4G using Tapatalk

mtmichaelson said:
Guys, test mode is embedded deep inside the kernel source. Disabling it in one place will cause it to not build because it is referenced in another file. Remove it from there and it won't build because of another. Etc., etc., etc. Now what you can try is asking if he knows which partition holds the flag for test mode. It is obviously not /boot, /data, /system/, or /recovery.
Sent from my VS920 4G using Tapatalk
Click to expand...
Click to collapse
Hey mt,
Do we know why emergency mode installed tot's flag testmode whereas regular installed tot's (from cwm recovery or usbmode) dont flag flag testmode? Same tot's same kernel, right?
Is it possible to pull the other mounts images (not /system, /data, etc) and push them to a testmode device?

I don't believe it's tots flashed from emergency mode per se, but rather phones that had bad recoveries installed first, then flashed in emergency mode.
Sent from my VS920 4G using Tapatalk

mtmichaelson said:
I don't believe it's tots flashed from emergency mode per se, but rather phones that had bad recoveries installed first, then flashed in emergency mode.
Sent from my VS920 4G using Tapatalk
Click to expand...
Click to collapse
Agreed.
Now, where is the flag, byte offset, or whatever that is flagging the whole system to be in 'testmode'. If it can be set, it can be unset.
Since /system, /data and /cache are wiped and replaced with a new ROM, then that leaves one of the other.. what (3 or 4) mounted partitions that could contain this flag. Maybe the rootfs contains this flag as a byte offset?
Again, what if a partition from a non-testmode device was exported and pushed to a testmode device? Is there a way to compare these other partitions byte for byte between a good and testmode device?
How I wish I was a linux guru right now.... damn you Microsoft!

I found a program called wxHexEdit that seems about right for the job...
It can compare two binary files / images.
I'm currently having a peek at the MISC partition but I don't have a non-testmode copy to compare it with.
If someone could hook me up with an image (mmcblk0p8) from a non-test-mode phone that would be great!

I got out of test mode easy, just csll verizon and get a new phone.

[Workshop] Unbrick fully bricked I9070

Hi,
I'm launching this thread to work on an unbrick procedure for fully bricked I9070/P without JTAG or Riffbox (same as Adam Outler, TheBeano, Odia etc... 's project "let's save some bricks")
Reminder : fully bricked = no download/recovery mode, no display, not charging, not going to recovery with a 301k Ohm jig.
I have a fully bricked I9070P and a fully functionnal I8090 (same processor).
Based on the sources and tools for the U8500 that were disclosed in january, I've managed to make my dead phone and my PC talk "a bit" together (under Windows with the VSIW tool, and under linux with recompiling the "flashkit" tools): when plugged in and inserting the battery, the tool sees the terminal, gets its serial number and various data and fails while trying to send and execute a boot file because the terminal closes the USB port.
I've managed to get a certain degree of communication with the "riff" tool (open source) of the Snowball project too (the dev board based on a U9500).
Based on this half successes, I'm pretty sure we are close to a clean solution to revive a fully bricked terminal without soldering JTAG.
Here are the main docs I've read so far :
* most posts from the threads "let's save some bricks" and "fun with resistors"
* the reference documents of the I9070 (Samsung_GT-I9070_Galaxy_S_Advance_Galaxy_S_II_Lite_service_manual.rar)
* the reference manual of the U9500 (http://www.calao-systems.com/reposi...X/DATASHEETS/AP9500_reference_manual_rev1.pdf)
* TSU6111 datasheet from TI (the USB/UART switch the 9070 is using, cf the service manual -> Lite Schematics -> u-USB SW IC part)
* lots of docs from the "flashkit" sources
My setup :
* a fully bricked I9070P
* a fully working I8190P
* an 8GB SDCard
* a Windows/Linux workstation (Ubuntu 12.04LTS + Android compiling environment + disclosed sources)
* terminal emulators
* a Prolific cable (PL2303) (any USB to TTL adapter would do it, you can buy one for 3$ as Arduino accessory, or reuse a Nokia DKU 5 -see hackaday website for a link). Take care with Prolifics : they don't work under Windows 8 with the last driver, you have to use the version before, Google is your friend)
* a set of resistors
* a multimeter
* libusb win32 drivers setup, see sourceforge (use the tool included in the drivers package to generate the right .inf file for the U8500 (or use 04CC and 8500)
Here are my conclusions so far :
* based on the Snowball docs and the U9500 spec, we don't seem to have any need to modify anything (resistors) on the mainboard to change boot sequence. The dev board does not have any switch for that and my dead I9070 and working I8190 exibit the same behaviour at bootup : the appear as a "U8500 USB ROM" for a seconds and disconnect when going on farther in the boot sequence.
Moreover, the fact that I managed to have my dead phone talk with the flashtool confort me in the fact that we are almost done.
* I have *not* managed to get any output on my terminal with my Prolific cable plugged in with a 630kOhm resistor on the pins 4 and 5. My resistor setup might be good because it make my working I8190 boot when I plug it in.
But I'm not sure of my RX/TX setup, I have crossed the RX/TX of the phone and the ones of the Prolific but I might have been wrong identifying the pins of my modified USB plug (D+ and D-).
But I'm sure the RX and TX wires of my Prolific are the right ones : when I connect them together (nullmodem configuration), the characters typed on my terminal are displayed.
So the main issue is : how can we have the dead phone keep the USB port open and not close it after 2 seconds?
My assumption is that it is always probing different boot methods (UART, USB, MMC etc) and then attempts to boot normaly from eMMC.
I don't know which part of the bootchain sequence I've garbaged on my I9070: IBL, PBL, SBL, PARAM? Managing to get any debug output on my console would greatly help me.
Has any of you tried to achieve something similar? If yes, could you post your setup and results?
Let's save some bricks another time!

any progress
flentus said:
Hi,
I'm launching this thread to work on an unbrick procedure for fully bricked I9070/P without JTAG or Riffbox (same as Adam Outler, TheBeano, Odia etc... 's project "let's save some bricks")
Reminder : fully bricked = no download/recovery mode, no display, not charging, not going to recovery with a 301k Ohm jig.
I have a fully bricked I9070P and a fully functionnal I8090 (same processor).
Based on the sources and tools for the U8500 that were disclosed in january, I've managed to make my dead phone and my PC talk "a bit" together (under Windows with the VSIW tool, and under linux with recompiling the "flashkit" tools): when plugged in and inserting the battery, the tool sees the terminal, gets its serial number and various data and fails while trying to send and execute a boot file because the terminal closes the USB port.
I've managed to get a certain degree of communication with the "riff" tool (open source) of the Snowball project too (the dev board based on a U9500).
Based on this half successes, I'm pretty sure we are close to a clean solution to revive a fully bricked terminal without soldering JTAG.
Here are the main docs I've read so far :
* most posts from the threads "let's save some bricks" and "fun with resistors"
* the reference documents of the I9070 (Samsung_GT-I9070_Galaxy_S_Advance_Galaxy_S_II_Lite_service_manual.rar)
* the reference manual of the U9500 (http://www.calao-systems.com/reposi...X/DATASHEETS/AP9500_reference_manual_rev1.pdf)
* TSU6111 datasheet from TI (the USB/UART switch the 9070 is using, cf the service manual -> Lite Schematics -> u-USB SW IC part)
* lots of docs from the "flashkit" sources
My setup :
* a fully bricked I9070P
* a fully working I8190P
* an 8GB SDCard
* a Windows/Linux workstation (Ubuntu 12.04LTS + Android compiling environment + disclosed sources)
* terminal emulators
* a Prolific cable (PL2303) (any USB to TTL adapter would do it, you can buy one for 3$ as Arduino accessory, or reuse a Nokia DKU 5 -see hackaday website for a link). Take care with Prolifics : they don't work under Windows 8 with the last driver, you have to use the version before, Google is your friend)
* a set of resistors
* a multimeter
* libusb win32 drivers setup, see sourceforge (use the tool included in the drivers package to generate the right .inf file for the U8500 (or use 04CC and 8500)
Here are my conclusions so far :
* based on the Snowball docs and the U9500 spec, we don't seem to have any need to modify anything (resistors) on the mainboard to change boot sequence. The dev board does not have any switch for that and my dead I9070 and working I8190 exibit the same behaviour at bootup : the appear as a "U8500 USB ROM" for a seconds and disconnect when going on farther in the boot sequence.
Moreover, the fact that I managed to have my dead phone talk with the flashtool confort me in the fact that we are almost done.
* I have *not* managed to get any output on my terminal with my Prolific cable plugged in with a 630kOhm resistor on the pins 4 and 5. My resistor setup might be good because it make my working I8190 boot when I plug it in.
But I'm not sure of my RX/TX setup, I have crossed the RX/TX of the phone and the ones of the Prolific but I might have been wrong identifying the pins of my modified USB plug (D+ and D-).
But I'm sure the RX and TX wires of my Prolific are the right ones : when I connect them together (nullmodem configuration), the characters typed on my terminal are displayed.
So the main issue is : how can we have the dead phone keep the USB port open and not close it after 2 seconds?
My assumption is that it is always probing different boot methods (UART, USB, MMC etc) and then attempts to boot normaly from eMMC.
I don't know which part of the bootchain sequence I've garbaged on my I9070: IBL, PBL, SBL, PARAM? Managing to get any debug output on my console would greatly help me.
Has any of you tried to achieve something similar? If yes, could you post your setup and results?
Let's save some bricks another time!
Click to expand...
Click to collapse
dude did you find any solution??same problem here

up up this thread.... i'm also experiencing with my s3 mini i8190 continuously disconnecting libusb-win32 driver... my phone is at deadboot and unable to resurrect with RIFFBOX...

neilPD_07 said:
up up this thread.... i'm also experiencing with my s3 mini i8190 continuously disconnecting libusb-win32 driver... my phone is at deadboot and unable to resurrect with RIFFBOX...
Click to expand...
Click to collapse
Mebay u have dead mini USB port in SIII mini ?
Sent from my GT-I9070 using Tapatalk

Hi guys,
I had a little time playing with this, but I have good news :
I modified the default profile used for the flashtool backend to "ADL boot" : my "dead" phone now stays connected to the USB and is reported as "started" by the flashtool CLI ("flash-tool get_connected_equipments") however, when I try some "active" flash-tool CLI commands, the backend crashes.
As I was running it either in windows 8.1 64 bits or Linux in a VM, their might have some bad interactions with the OS on the one hand and the USB port forwarding on the other hand (there was issues with the LCD and LCM drivers in Windows, I grabbed the 64 bits ones from VSIW...).
-> I have to test on a 32 bit Windows.
Good to read to understand further (extracted from flash-tool-backend.html file) :
Note : ME stands for mobile equipment, "boot indication" can take the following values : ADL, ALT, Normal, Production, Programming : set into the config files pointed by the .mesp file)
Boot process description
When the peripheral boot sequence starts, the ME sends an asic id to the connected PC tool. The PC tool then answers with a boot indication. If normal, "ADL" or "production" is sent as boot indication; this means that the x-loader will start the binary software stored at the corresponding location in the boot image (based on the location stated by the TOC). If programming is used as boot indication, the PC will send a completely new set of boot code to the ME. This is used when a loader is downloaded during service mode startup via the Flash Tool Backend. When the normal boot indication is sent, Flash Tool backend sends no more data and the ME is booted with the binary software stored in the place where the normal software is stored according to the TOC.
The ADL boot scenario works like this:
1. Flash Tool Backend receives asic id
2. Boot indication ADL is sent
3. Flash tool backend starts LCD and LCM and waits for a loader startup message.
The loader is stored at the ADL location of the boot image (this is supported by the assemble tool).
I think I'd have to assemble the correct bootloader to enable "profile-STE_DBX500_flashloader.prfl" profile to work (we are missing corresponding loader.ldr loader). It would enable the use of the "LoaderCommunication"
I think I have all the pieces and the docs (we even have the certificates to sign it !): just need time and a better GFAF (Girlfriend acceptance factor).
The guys who managed to unbrick some Qualcomm based devices might be of a huge help, they would be much more efficient than I can be... I any of you have time to drive them around here, do not hesitate!
Enjoy!

flentus said:
Hi guys,
I had a little time playing with this, but I have good news :
I modified the default profile used for the flashtool backend to "ADL boot" : my "dead" phone now stays connected to the USB and is reported as "started" by the flashtool CLI ("flash-tool get_connected_equipments") however, when I try some "active" flash-tool CLI commands, the backend crashes.
As I was running it either in windows 8.1 64 bits or Linux in a VM, their might have some bad interactions with the OS on the one hand and the USB port forwarding on the other hand (there was issues with the LCD and LCM drivers in Windows, I grabbed the 64 bits ones from VSIW...).
-> I have to test on a 32 bit Windows.
Good to read to understand further (extracted from flash-tool-backend.html file) :
Note : ME stands for mobile equipment, "boot indication" can take the following values : ADL, ALT, Normal, Production, Programming : set into the config files pointed by the .mesp file)
Boot process description
When the peripheral boot sequence starts, the ME sends an asic id to the connected PC tool. The PC tool then answers with a boot indication. If normal, "ADL" or "production" is sent as boot indication; this means that the x-loader will start the binary software stored at the corresponding location in the boot image (based on the location stated by the TOC). If programming is used as boot indication, the PC will send a completely new set of boot code to the ME. This is used when a loader is downloaded during service mode startup via the Flash Tool Backend. When the normal boot indication is sent, Flash Tool backend sends no more data and the ME is booted with the binary software stored in the place where the normal software is stored according to the TOC.
The ADL boot scenario works like this:
1. Flash Tool Backend receives asic id
2. Boot indication ADL is sent
3. Flash tool backend starts LCD and LCM and waits for a loader startup message.
The loader is stored at the ADL location of the boot image (this is supported by the assemble tool).
I think I'd have to assemble the correct bootloader to enable "profile-STE_DBX500_flashloader.prfl" profile to work (we are missing corresponding loader.ldr loader). It would enable the use of the "LoaderCommunication"
I think I have all the pieces and the docs (we even have the certificates to sign it !): just need time and a better GFAF (Girlfriend acceptance factor).
The guys who managed to unbrick some Qualcomm based devices might be of a huge help, they would be much more efficient than I can be... I any of you have time to drive them around here, do not hesitate!
Enjoy!
Click to expand...
Click to collapse
Any good updates & tested solution sir? I'm still waiting for a big solution for this kind of problem... TIA

Hi !
well, I'm almost done with the bootloaders: I have a loader.ldr compiled + 2 bin.
I've reset my dev. env. to an Ubuntu 10.04 according to a .doc I found in the sources (search for "*.doc", you will find "getting_Started_with_Android_and_Linux.doc"): I now have far less compilation errors, but I'm still struggling to get the full compilation process just right. For eg. I had to remove the "alsactrl" component due to dependency issues I've not been able to solve.
As already stated, I'm far from being a dev. expert so it takes me a lot of time to acheive the right compilation.
I would highly need the help of s/b who is fluent with Android compilation/dev env.: first it would be necessary to establish how to merge correctly the disclosed sources with Google's sources + the open sources from Samsung (kernel + system) (we have duplicates here as the kernel is also available in the disclosed sources, but both are different releases).
As already stated, given the few spare tile I have and without the help of the right people this will take me ~4 months+ to have this unbrick done (if I face no deadlock).
So, if you want this faster: get the right guys on the forum (from the "dev" branches) and drag them here so we can go forward much faste!

Hi!
So, I think I'm getting close: I now have the boot files build procedure working (+kernel and sytem, but I don't need those).
When I try to boot my phone with those boot files using the "flasher -tXXXX -X0,normal.bin" command, it seems that they are rejected as the phone connects and disconnects (boot loop on the iRom startup, I believe).
So, now I really need to have some kind of debug console setup to understand what's going on (cause of rejection, like signature problem etc...):
I've been working blindly up to now hopping that the software would work "off the shelves"... it never does
I'll have to try to understand how the "trigger UART" parameter of flashkit backend works and what is it intended to (I'll have to read the code for that as I've never seen any explanation about it anywhere in the docs). I don't figure out how this could work as on the backend GUI it lists the host PC's serial ports...
Another option would be to have my FTDI debug setup working. Maybe it's not "another option" but is required if the "trigger UART" is just enabling UART debug on the phone and requires a debug cable to read these debug data. My problem in that case would be how to have USB *and* UART on the same port... unless all this is designed for dev targets that have 2 USB ports as the Calao's u8500 targets. In that case, i'd have to find something smarter
As usual, if someone with knownledge on all this is willing to help: wave your hand, I'd happy to share my researches and go forward much faster. But I really feel I'm alone on this (even if I know that there will be tons of leechers when/if I manage to have this work
That's life on XDA!

Nice nice
flentus said:
Hi!
So, I think I'm getting close: I now have the boot files build procedure working (+kernel and sytem, but I don't need those).
When I try to boot my phone with those boot files using the "flasher -tXXXX -X0,normal.bin" command, it seems that they are rejected as the phone connects and disconnects (boot loop on the iRom startup, I believe).
So, now I really need to have some kind of debug console setup to understand what's going on (cause of rejection, like signature problem etc...):
I've been working blindly up to now hopping that the software would work "off the shelves"... it never does
I'll have to try to understand how the "trigger UART" parameter of flashkit backend works and what is it intended to (I'll have to read the code for that as I've never seen any explanation about it anywhere in the docs). I don't figure out how this could work as on the backend GUI it lists the host PC's serial ports...
Another option would be to have my FTDI debug setup working. Maybe it's not "another option" but is required if the "trigger UART" is just enabling UART debug on the phone and requires a debug cable to read these debug data. My problem in that case would be how to have USB *and* UART on the same port... unless all this is designed for dev targets that have 2 USB ports as the Calao's u8500 targets. In that case, i'd have to find something smarter
As usual, if someone with knownledge on all this is willing to help: wave your hand, I'd happy to share my researches and go forward much faster. But I really feel I'm alone on this (even if I know that there will be tons of leechers when/if I manage to have this work
That's life on XDA!
Click to expand...
Click to collapse
U R great man..UP UP UP :good::good::good:

use UART debug on USB
This will help me, I'll test it on my working S3 mini (same proc and very similar HW)... when I have time...
-> this will validate my UART debug setup : http://forum.xda-developers.com/showthread.php?t=2100809

ok, UART debug up and partially running on my SIII mini: debug messages displayed on terminal but keystrokes do not reach the phone, this is secondary for me at the moment, I may have a bad contact somewhere.
Tested on my dead I9070: no display, so the Xloader on my eMMC is garbaged (or Xloader UART debug is disabled, but this is less likely).
As expected, I now have to figure out how to have flashloader boot files upload *and* debug working together to understand what's wrong with my compiled boot files. I think the "trigger UART" thing is a good track, but I'm really puzzled by how to have the USB *and* the UART setup at the same time.
I fear to fry something by having phone D+/D- connected to USB port of the PC and connected at the same time to my Prolific TxD/RxD + 5V VCC connected to PC USB... sounds like a bad thing.
Another track would be USB debug I see in some parts of the code, but I don't know how to read the debug from there, more code to inspect...

got it~
---------- Post added at 02:03 PM ---------- Previous post was at 01:22 PM ----------
I also have a fully bricked I9070( not I9070P).I`m waiting for your good news.Thanks first.

I received this PM, I believe it can be useful for others experimenting with it
flentus said:
Ola Paul,
I contact you on an advise from Cocafe.
I launched a while ago the thread "[Workshop] Unbrick fully bricked I9070" (http://forum.xda-developers.com/showthread.php?t=2701363)
I'm looking for help to acheive the task as I don't have very much time to spend on it due to huge work I have this year.
Would you be ok to participate if you have a little spare time and interest in it?
I think I'm very close to the solution, and this would help a lot of 9070 owners (and maybe SIII mini and Sony too).
As explained in my thread, I have difficulties getting the disclosed sources to build correctly up to the end when integrated with Google SDK. As a result the "finalizing" scripts (that gather the binaries and tidy the "out" directory) don't execute: I end up with a large mess and STE tools don't work out of the box. I have to gather the pieces one by one to have them run which is very time consuming and error prone.
I can say that the recovery process won't need any kind of soldering, wiring or whatever: just a regular USB cable and the right sofware.
The disclosed sources contain everything we need: PBL/SBL sources, signing tool+certificates, the software to talk to the iROM + various documentation.
The problem is just a question of assembling the pieces...
My idea is to assemble an Xloader (PBL) + Uboot (SBL) + recovery and boot from that to execute recovery.
The "flashkit" tool enables this process, I quote the docs: "If 'programming' boot indication is used as boot indication, the PC will send a completely new set of boot code to the ME. This is used when a loader is downloaded during service mode startup via the Flash Tool Backend.".
Tell me if you wish to help me, or if you know someone who has competencies and would wish to!
I speek average spanish if you prefer to exchange in this language.
Regards
Click to expand...
Click to collapse
I am sorry for pointing this out, STE tools wont work ever on i9070, the reason being that we do not have a STE bootloader, heck, most of the low level stuff do not resemble the ST-Ericsson Montblanc development board. You can't even change the bootloader arguments, you can only add to them (the way I first enabled SELinux), the Samsung Bootloader version that we have may be not as restrictive as others, but Sonys bootloader resembles more to STE's than ours.
The only way you may found how to restore it is accessing the JTAG mode (something that is determined only if JTAG is connected and recognized) and depends solely on the emergency bootloader (if that exists, because I am not sure how the device powers on without PBL), the "seconds" of power you get on the USB is the device looking for JTAG.
The "disclosed" sources are for ST-Ericsson devices
Something you should do, is analyze the structures of /dev/block/mmcblk0p10, which contains our partition table (GUID Partition Table - GPT).
Simple way of doing it, you have to do dd if=/dev/block/mmcblk0p10 of=/sdcard/janice.pit on terminal emulator, this is ROM agnostic, because the structures are the same on both stock and any custom ROM. Of course, that is from a working device, I'll do that and drop it here later since I am working on something else right now, and thanks diegoch for discovering this.
Anyway, as diego pointed to me, our partition table is like this.
PIT, CSPSA, EFS, MODEM fs, SBL, SBL2, PARAM, IPL modem, MODEM, Kernel, Kernel2, system, data, cache, preload, fota, sdcard
This is the correct order I believe, since basically, when you use ODIN and use a PIT file, the partition table gets rewritten according to whatever is on that .pit file. So PIT is basically the GPT partition table; obviously SBL is the Samsung bootloader, and SBL2 I believe it's either stage 2.5 or a backup of the first.
So, no clue by going the STE way, something familiar here.
So, I may say something good at the end, see if the i9100 guys ever did it, and go from there, since our device is largely based around i9100 (Galaxy S II)

Hi Paul,
thanks for your contribution.
A few replies/questions :
* you state that Montblanc dev board and I9070 are completly different: isn't the aim of dev dev board to be close to ME while adding extra connectors to ease debug and interfacing for prototyping? Calao dev board looks very close to I9070: I have compared the schematics and component list: they look very very much alike. For me, NovaThor U8500 plateform consists of a DB8500 SoC, a Mali 400, a built-in modem + chips for USB, audio and SIM operations.
So, to me, I may be wrong, at least the processor (u8500), PLL, eMMC, SDRAM, UART + several low level controlers should be the same. As we are trying to work at such level (just trying to get the basic system to boot to just enable eMMC write), don't we have a chance to manage to have those work (maybe with adressing adaptation, those might be tough)?
* I can't agree with you that "the "seconds" of power you get on the USB is the device looking for JTAG.": on boot time, even without trashed PBL, the ME connects to USB properly with vendor/ID=04cc/8500, and sends its ASIC ID (displayed on PC screen). As stated earlier in the thread, I manage to send some commands and receive response from the ME in this state using STE tools (flashkit_cli, sending commands threw flashkit_backend).
It's definetly not any JTAG stuffs. JTAG on the I9070 is accessible on the mainboard via dedicated pads, you can locate using the light schematics provided in the "Service manual" package.
This early boot behaviour is documented in the "flash-tool-backend.html" document (available in s-4.1_vendor_st-ericsson.tar in ./s-4.1_vendor_st-ericsson/vendor/st-ericsson/tools/platform/flash_kit/flash_tool_backend/com.stericsson.sdk.backend.build/doc):
Boot process description
When the peripheral boot sequence starts, the ME sends an asic id to the connected PC tool.
The PC tool then answers with a boot indication.
- If normal, ADL or production is sent as boot indication; this means that the x-loader will start the binary software stored at the corresponding location in the boot image (based on the location stated by the TOC).
- If programming is used as boot indication, the PC will send a completely new set of boot code to the ME. This is used when a loader is downloaded during service mode startup via the Flash Tool Backend.
- When the normal boot indication is sent, Flash Tool backend sends no more data and the ME is booted with the binary software stored in the place where the normal software is stored according to the TOC.
The ADL boot scenario works like this:
1. Flash Tool Backend receives asic id
2. Boot indication ADL is sent
3. Flash tool backend starts LCD and LCM and waits for a loader startup message.
The loader is stored at the ADL location of the boot image (this is supported by the assemble tool).
* If I understand well, as we don't have the sources for the bootloader, your proposal is to grab one from a working device.
That sounds a really good idea!
Here is the complete partition table/PIT of the I9070 (recovered by someone with a Riff box from a GB archive, if I remember well):
(copy/paste it in a traditional editor and add padding to recover the table).
Partition number Filename in archive Name in PIT starting offset HEX Size in bytes HEX
MBR, GPT 0 20000
STE_boot.bin TOC ISSW XLOADER 20000 60000
mmcblk0p10 GT-I9070P_EUR_XX_8G.pit PIT 80000 100000
mmcblk0p6 cspsa.img CSPSA FS 180000 180000
EMPTY 300000 100000
mmcblk0p7 EFS.img EFS 400000 A00000
mmcblk0p2 modemfs.img MODEM FS E00000 100000
mem_init.bin STE MEM INIT 1E00000 80000
power_management.bin PWR MGT 1E80000 80000
mmcblk0p14 normal.bin SBL 1F00000 200000
mmcblk0p16 normal2.bin SBL_2 2100000 200000
mmcblk0p1 param.lfs PARAM 2300000 1000000
mmcblk0p12 ipl.bin IPL MODEM 3300000 200000
mmcblk0p13 modem.bin MODEM 3500000 1000000
mmcblk0p15 kernel.bin KERNEL 4500000 1000000
mmcblk0p17 kernel2.bin KERNEL2 5500000 1000000
mmcblk0p3 system.img SYSTEM 6500000 26400000
mmcblk0p5 userdata.img DATAFS 2C900000 80000000
mmcblk0p4 cache.img CACHEFS AC900000 13200000
mmcblk0p9 hidden.img HIDDEN BFB00000 14000000
mmcblk0p11 ssgtest.img FOTA D3B00000 3200000
mmcblk0p8 ums.rfs UMS D6D00000 FAA00000
--> PBL corresponds to "TOC ISSW XLOADER" (STE_boot.bin in the flash archive) and SLB to normal.bin. So basically we have our boot files. We can extract them from the GB flash archive or from a ROM dump (I have dd'ed every partitions from 2 different I9070P + a full recovery dump from a 9070 provided by Riff box support files I found once I don't remember where).
So, if I have time one of theses days, I'll try to build a flash archive based on these files and try to boot from STE tools on it using "programming" as boot indication.
* Using the knowledge of the I9100 (Galaxy S II): I'm afraid this is a very different hardware, I9100 uses an Exynos 4210, so I hardly see what we could use from there... Could you give us some more advise on that idea?
Regards

Hi!
I had no time working on this for a while: extremely busy at work.
Maybe this weekend...
@cocafe: I've read you know how to extract the initramfs from the kernel, modify, repack, and reflash it. I'll need to do that to modify the "on boot" section of the init.rc to launch the recovery from standard boot. Could you drop me here the command lines to do that? Thanks in advance!

This looks by far the most advanced research into bringing back a hard bricked i9070.
@flentus Did you manage to upload a new bootloader?

Hi,
had to time at all to play with this for a loooong time.
I have grabed a few new phones so me 9070 is now burried deep into a drawer but I really wish to finish this one day because I feel I'm very close to something.
If anybody would like to take over this, feel free, I can provide support for the stuff I have understood (and remember of...)
Regards

[UNLOCK][ROOT][TWRP][UNBRICK] Fire TV Stick 4K (mantis)

NOTE: There have been multiple reports of devices with serial numbers containing VM190 or higher being shipped with DL-Mode disabled in BROM.
These devices cannot be unlocked using kamakiri.
These devices do not show up at all on USB when shorted.
After the old bootrom-exploit (amonet) we've been using for unlocking all these Fire-gadgets is closed in more recent Mediatek SOCs like the one used in the FireTV Stick 4K, @xyz` has done it again and found another bootrom-exploit.
Together we proudly present kamakiri for the FireTV Stick 4K.
Before proceeding make sure to read and understand this entire post.
Running this exploit requires a patched linux-kernel on the PC you are using.
We have put together a Live-ISO that already contains all prerequisites required for running kamakiri.
You can find the current version of the ISO at:
https://github.com/amonet-kamakiri/fireiso/releases
It can be burned to a CD or to a USB-flashdrive.
Current Version: kamakiri-mantis-v2.0.1.zip
You will need to open the device and remove the heatshield on the side without the antennas (2 square bricks).
NOTE: It is not required to desolder or force the shield off, it is just clipped onto a frame. (The attached picture may be a bit misleading, since it also has the frame removed)
You will need something for shorting (wire, aluminum foil etc.)
Boot the ISO
Download and extract the exploit package.
Open a terminal in the kamakiri directory
Run
Code:
./bootrom-step.sh
Short one of the points in the attached photo to ground (the cage of the shielding).
Ideally you want to use DAT0, since that is tiny it might be easier to short the point marked CLK instead.
It is very important that you use a piece of soft wire or aluminum foil or something similar for shorting. Don't use tweezers as that makes it incredibly easy to knock of the capacitor off the PCB and kill the board!
Connect the stick to your computer (while keeping it shorted)
The script should tell you to release the short and hit enter
Once finished run
Code:
./fastboot-step.sh
Your device will now reboot into TWRP
Important information
Don't flash boot/recovery images from FireOS (FlashFire, MagiskManager etc.)
TWRP will prevent updates from overwriting LK/Preloader/TZ, so generally installing an update should work without issues (only full updates, incremental updates won't work).
For ROM developers there is still an option to overwrite these, which should only be done after thorough testing and if needed (LK should never be updated).
It is still advised to disable OTA.
thanks to @hwmod for the picture
thanks to @Sus_i for providing an update.bin
thanks to @zeroepoch for developing aftv2-tools
Contributors
k4y0z, xyz`
Source Code: https://github.com/amonet-kamakiri/

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, TWRP contains a special boot menu that will be displayed when you boot the stick with an OTG-cable connected.
It will give you 5 seconds to hit cancel and stay in TWRP or reboot into the OS otherwise.
NOTE:This will only work if the boot-exploit is still there.

Changelog:
Version 2.0.1 (04.03.2022)
Fix Boot Menu on TWRP-Install
Version 2.0 (02.03.2022)
Update PL and TZ
Update TWRP to 3.6.1_9-0
Add support for boot-recovery and boot-fastboot
Add support for fused devices with FireOS < 6.2.8.7
Version 1.2 (20.10.2019)
Update TZ from 6.2.6.6
Add support for updating via TWRP
Version 1.1 (17.10.2019)
Add delay to properly flush data to EMMC

Yesss!!! Thanks.

Mother of GOD.
Can't believe.
And can't wait for a clean Android TV Rom.
It will be amazing since I need to use an American account to use this fire stick 4k in my country.

Complete, no issues... Great job! Thanks for the live USB, could not have made this easier!

@k4y0z I wonder why this cannot be done in Ubuntu?
I'm able to install pyusb with:
Code:
sudo apt-get install python-usb python3-usb
And then the scripts start. Is due the kernel patch?
BTW: good work I still looking at the exploit in github and looks awesome lol.

Rortiz2 said:
@k4y0z I wonder why this cannot be done in Ubuntu?
Click to expand...
Click to collapse
k4y0z said:
Running this exploit requires a patched linux-kernel on the PC you are using.
Click to expand...
Click to collapse
If you patch your kernel, there is no reason it wouldn't work on ubuntu.

I love the option to go into TWRP on boot with an OTG.... Fantastic!

Thanks to everyone involved. So happy to get some control over the 4k!

Can someone explain how to get the shield off?

rbox said:
Can someone explain how to get the shield off?
Click to expand...
Click to collapse
The heatsink and shield come off together, they are clipped on.
Start levering it up from the narrow side.

@k4y0z
Excellent work as always!!! :highfive::highfive::highfive::highfive::highfive:
Now, any chance that you can create a fastboot exploit such that there'd be no need to open the case? Same story with Fire TV2 (tank), fastboot exploit?
Keep the good stuff coming!!!

Is this something that Amazon can fix with future updates? I am holding off until we have a more refined rom..

rootuser11 said:
Is this something that Amazon can fix with future updates? I am holding off until we have a more refined rom..
Click to expand...
Click to collapse
No, the only way they can fix it is with a new hardware revision.

Does this permanently install anything? If I reboot after getting into TWRP the first time with fastboot the hacked fastboot splashscreen doesn't come back, it just boots FireOS normally with no options to boot TWRP.

Getting off the heatsink was a bit daunting especially because I didn't know there was also a sticky pad holding it on. Also spent ages trying to short the DAT0 point, got fed up and got it first time with CLK. Now I just need a rom to install!

iLLNiSS said:
Does this permanently install anything? If I reboot after getting into TWRP the first time with fastboot the hacked fastboot splashscreen doesn't come back, it just boots FireOS normally with no options to boot TWRP.
Click to expand...
Click to collapse
Everytime i boot from power off with a OTG it gives the option for TWRP. It installed TWRP recovery. From there you can install root.
Try
ADB reboot recovery

bibikalka said:
@k4y0z
Excellent work as always!!! :highfive::highfive::highfive::highfive::highfive:
Now, any chance that you can create a fastboot exploit such that there'd be no need to open the case? Same story with Fire TV2 (tank), fastboot exploit?
Keep the good stuff coming!!!
Click to expand...
Click to collapse
Unfortunately the fastboot bug cannot be used like that on the 4K or we probably would have done so from the start
I will look into the FireStick 2 when I get the time, but given the fastboot-bug is LK-Version specific and can be easily patched, I am unsure if it's worth the effort.

Michajin said:
Everytime i boot from power off with a OTG it gives the option for TWRP. It installed TWRP recovery. From there you can install root.
Try
ADB reboot recovery
Click to expand...
Click to collapse
I’m guessing I have to actually install TWRP once inside TWRP the first time? I don’t have an OTG cable so never did anything once inside the first time.

[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.