• Introducing XDA Computing: Discussion zones for Hardware, Software, and more!    Check it out!

Fire 7 2020 mustang Brainstorming

Search This thread
Jun 3, 2021
28
6
Trying to brainstorm ideas for unbrick (firstly) of the new Fire 7 2020 Gen 9 models that feature 6.3.1.5 and were released post Feb 2020. Already have a method to downgrade this and many other devices (HD8 Onyx and HD 10 post patch Feb 2020) possibly a lot more other devices

Downgrade is a bit of a Sledge Hammer, in that it impacts numerous parts of IT (not just Android) as a new general hacking technique, and currently there seems no way of using my technique on these devices without resulting in hard brick, with no recovery possible.

On devices, if they exist, which contain cryptographic key burnt by eFuse, my bug will not be easily fully patchable. Very likely these devices will be constantly able to be attacked by different permutations of the bug.

I'm also not entirely sure if the technique is needed at all on this device (fbtool sounds more promising Started work on my own tool to talk to bootrom and preloader -after playing around with the protocol and staring at the preloader source, it seems impossible to to send DA / jump DA properly on this device), I actually suspect it will work on the HD 10 post Feb 2020 devices better - i.e. forcing downgrade from 7.3.1.2 to 7.3.1.0 but again it might brick instead from RPMB checks, similar to current scenario with using it on the Fire 7. Need to test hack on HD 10 2020, should work fully, holding back whilst fixing the fire 7.

SOFTWARE Related Ideas/Notes:

AFTV2-tools?

THOUGHTS: Can complete handshake, but on read it stalls - no response. Was this blocked on this preloader? YES.
Does anyone have any other crash to bootrom from preloader methods other than the one's in this code base?

amonet-kamakiri?

THOUGHTS: How do you modify this to use UART instead of VCOM? Maybe UART mode for flashing might allow it, anyone know how to get device into UART SP Flash mode?
Don't think this device has UART flashing mode but can't be sure (only able to get logging)

mediatek-datool?

THOUGHTS:
This might do it, but sounds complicated, I think it might be able to be used to clear existing chain of trust if used in a certain method - still mulling over the details. Upon some brief testing when used with 6315 preloader and lk.bin i get error about .sign file, but the gibberish from the UART seems different to cold boot scenario, i.e. the device is logging something extra based on passing in command to device. Jump DA / Send DA logging appeared on UART

Need to understand what the code is doing more - looks like it is sending a preloader and lk.bin to boot the device into fastboot mode, and the sign file is rather a patch file generated by the gen-dalk-from-lk.py to make a temporary DA file to start transfer of the preloader/lk.bin to reboot into fastboot - if so, then this may work as a generic method for mtk devices to unlock/root, by compiling lineage lk.bin/preloader without secureboot enabled and with fastboot unlocked then using the script to create the .sign file and using fbtool to boot to fastboot which is then unlocked. Might also need a hacked preloader which bypasses rpmb rollback check and any other security preventing booting. I still think it is possible by using MTK's key not Amazon's key. Need to find a MTK 8163V preloader / lk.bin source code (anyone have any links?)

This will only work with lineage compiles not FireOS as you need to boot it in secure chip mode using fbtool which then would need an auth file from existing amazon key (This is assuming that there is no existing key check to block fbtools from booting up - Need to confirm if fbtool can be used in insecure mode to boot into fastboot on this device Insecure mode doesn't work) - There is still possibly a way to use FireOS, but it would mean fully unsigning FireOS and resigning it with your own key then flashing that on, after having generated the relevant auth file / sign file for fbtool - This approach should enable FireOS with your own key. Whilst once in hacked fastboot should be able to reflash the original full ROM which would cause it to revert to stock.

I think fbtool is one of the only uses for the preloader, and offers a chance to unbrick devices which only have preloader access and no bootrom access (like this patched device). Need to either sign with Amazon or MTK's key - I think either one may work. Whilst Amazon's key is unavailable, isn't MTK's key supplied in the BSP?

Anyone have lineage installed on Fire 7?
Need someone to test generating a DA file from fbtool's python script to see if it works. If what I'm thinking about the difference in Secure DA and DAA is right it is likely to work - DAA i think is disabled as it looks like it is to do with verifying preloader / lk.bin at bootrom stage.

Doesn't seem to have lk.bin. lk..bin provided by MTK not android project...

Some further ideas to investigate:
Using a blank preloader file for fbtool, to see if it causes device to drop into bootrom mode

DIdn't notice in fbtool readme that enable DAA was a one time operation.


Does anyone know of a definitive example of a device which has eFuse blown for crypto key?

Looking at previous threads, there is an indication that amazon attempted to test whether the eFuse is functioning, but there was no verified proof that eFuse has been blown. For the Fire 7 Gen 9 that I have, it appears the brom access was disabled by changing the eMMC chip not blowing a eFuse.

There is also no evidence of Amazon using an eFuse to store the crypto keys for this device that I can locate, meaning fbtool is very likely to be where chain of trust begins.


I think the way to check properly is to look at SPFT's terminal mode for reading the efuse's on the device. We might be able to do this on a unlocked/accessible Fire 7 Gen 9 2019 (i.e. one with available eMMC short to brom)

signfile-for-brom.sh indicates the preloader is patched with key? Does the preloader.img.sign file get accessed by the brom when being used by fbtool?

Need to look at bootrom code to verify what it does when fbtool has sent it a sign file as part of reboot to fastboot cycle. Looked at preloader code for answers instead

Is TEE/TZ1/TZ2/Trustzone updated by fbtool/datool? Is this where it is processing the sign files. Its also maybe using RPMB to store keys?

fbtool requires a almost payload like data structure, this is contained in gen-dalk-from-lk.py and will require one per SoC type. The above github does not contain a copy, but I have located one for MT8163 from another source. In order for this method to work on more devices, would need to locate more "payloads" for other SoCs. This method is very likely to be a clean method to access numerous MTK based devices.

The preloader contained inside Amzons rom files seems to be split into main preloader.img and preloader.hdr0/1 files, These look like they need merging or prehaps they are the MTK headerless version of the files (fbtools readme indicates a need for headerless files)

Any ideas where you might find "fbtool-da-pl.bin is a pre-built preloader_${PROJECT}_NO_GFH.bin" for this device? Should be in preloader/lk.bin compile process.

What about boot.img renamed to factory.img and placed on sdcard?

THOUGHTS: strings on the preloader indicate this may be possible, unless this has been blocked and the message hasn't been removed. Need this tested. No sdcard boot on preloader/lk.bin available but... Bootrom boot maybe possible see latest!

Tried SP Flash 5.1532 (insecure boot version) any other flashing tools that might work?

If it is in preloader mode, will there still be security blocking flashing if attempting to do UART flash instead of USB flash (UART might have different permission level than USB), will MTK-Bypass work with some modifications to talk to real COM port instead of VCOM?

THOUGHTS: mtk-bypass says it is bypassing DAA (Download Agent Authorization), My current understanding is it is disabling DAA and SecureBoot unnecessarily and should only disable SLA.

DAA sounds like it occurs at bootrom to verify preloader and lk.bin has been signed itself (fbtool Readme)

Secureboot sounds like it is the flag that is passed through to AVB (Android Documentation)

SLA sounds like it is the Secure DA being verified at preloader stage

Had a look at source / info online about it, and i think I'm right that DAA and secureboot disabling are not needed - SLA bypass is needed for SPFT fulll flash as that is bypassing secure DA check on preloader - whilst DAA and secureboot bypass via MTK-Bypass is needed only for a tethered boot scenario where device has DAA enabled fully, and you want to boot a preloader/lk.bin that hasn't been signed, mtk-bypass could then be used to tether bootup to disable both flags and enable booting - maybe then we can modify it a bit for devices where DAA is fully working with secureboot?

Which devices have problems with modified preloader/lk.bin which feature mtk chip, those would likely benefit? Not relevant for this Fire 7 I dont think. This allows a tethered boot solution for various scenarios, like linux dual boot, full system rw android install, etc.

Would using a hacked preloader which has secure DA verification disabled, whilst the device has bricked preloader and in bootrom mode, enable SPFT to flash device without mtk-bypass?

This would mean mtk-bypass is only worth using if you can't remove secure DA support from the preloader file itself - i think it might be patchable out with decompilation. Either that or the preloader is not fully bricked and still being read by bootrom to perform secure DA verification, would likely also need mtk-bypass in this situation.


This pad is ridiculously infuriatingly annoying to attempt to recover back to stock... Unless I am missing something obvious that i haven't tried.

Also anyone know where I can find the signed images for 6.3.1.1 6.3.1.0 or earlier, need the original update-*.bin files?
THOUGHTS: Already got everything from waybackmachine - any other sources of urls from their servers?

Also is there any available Preloader versions for this device or any *OTHER* Amazon devices that have preloader crash to Bootrom available?
I need full collection of Amazon ROMs for all devices if possible, with it I might be able to get unlock/root working on them all - Chasing after a preloader that works to crash to get into bootrom or has available shortcut to enter bootrom (i.e. power/vol buttons) - with it plus what i've worked out, should be answer to all Amazon devices unlock, hopefully. I might also be able to repeat for all other devices - this might even work with the 2021 HD 10 which is just released!

Also any good guides to preloader/IDA Pro decompiling? Is this what I need to buy from IDA in order to repair and recover my Fire 7?
IDA Pro Computer License [Windows]1879 USD
ARM64 Decompiler Fixed License [Windows]2629 USD
ARM32 Decompiler Fixed License [Windows]2629 USD
The home version is a cloud based decompiler isn't it? Above is minimum price for offline decompilation isn't it?
 
Last edited:
  • Like
Reactions: Kramar111
Jun 3, 2021
28
6
Hardware related Ideas/Notes:

Tried hw method for CMD/DAT0/CLK and the emmc pin at front, no response (CMD jumps to preloader while all other test points result in no response - same as previous testers of newer Fire 7 device)

Anyone know what the other testpoints are, like:

VCOM/VGH/RST/ON/ID/VBAT/AUX_NTC/PWRKEY/USB_ID/DP/DM/VBUS/VGP3_PMU/FCHR_ENB/COL0

GND - Why did they put a pad for this when there is GND everywhere on the board?
CLK/CMD/DAT0 - MicroSD connection! NOT eMMC... Test with ohmmeter against MicroSD pins!
TX/RX - UART

SDI/SDO/SCI/CS
Is SDI/SDO/SCI/CS some kind of SPI or another interface? Likely it is SPI (anyone know how to talk to it? I have raspberry pi's / picos / arduinos / ch341a)

What about the covered over points?

VIO8_PMU - 1.8V to eMMC?
VCC_IO - Cant rememebr if it is this one or above, need to retest.
VEMC3V_PMU - 3.3V to eMMC?
VCCK_PMU - Voltage to SoC?

AVOD/VGL/LEDA/LEDK/SPK_N/SPK_P/VPROC_PMU/VMCH_PMU/VMCA_PMU/VCAMD_IO/VCAMD_PMU/HPL/HPR

Maybe can make a list of all points and how they behave for this board?

Anyone know of how to interface directly with the eMMC by soldering MMC adapter?
Tried to attach to dat0 from front of board but ended up tearing pad - need to use a better method than soldering, maybe use Rubber+Needles+Crocodile Clips

Any chance of doing stock recovery by UART RX/TX flash?

THOUGHTS: Probably not, likely only get boot logs.

Can I use a raspberryPi B to connect to UART, Do I have to use RS232 or TTL?
THOUGHTS: No, possibly dangerous, RaspberryPi B is at 3.3v whilst this is possibly 1.8v - need to measure using voltmeter. RS232 should be safe as it uses -13v-+13v for RX/TX. USB TTL would also need a logic level shift from 3.3v to 1.8v. Therefore USB RS232 adapter is best choice. (I think for TX from board to RX from USB Serial - But dangerous from RX from board to TX from USB Serial because of over voltage from adapter possibly supplying +13v - need confirmation as this is useful for potentially debugging other gear by UART) Problem with RS232 is signal is inverted when read, therefore needing inversion by another chip to display correctly - better RS232 USB adapters seem to be able to be flashed by EEPROM to invert signal (FTDI ones with mProg). Need a USB TTL for further testing. Need to see if PL2303 can be hacked to invert signal - maybe driver hack for linux possible? Anyone have any simpler solutions to see UART logging from this device, or do I need a logic level analyser?

If so how to connect it?


THOUGHTS: Connect TX to Pin 2 from RS232 and GND to Pin 5 (Dont attach RX from board, else possible over voltage from sending data from PC). Using CH340G attach RX to TX on PCB, GND to GND, Make sure cables are shielded or split due to interference from cabling touching each other. Connection currently without battery installed seems to output gibberish, need to test with battery installed (Maybe bootloader logs will output) -Currently despite gibberish output it is most likely 961200 baud Databits 8, no flow control, 1 stop bits for preloader. Bootrom logging sounds like it might be 115200 (according to older kindle device thread )

Since the device can seemingly only output from UART, why is there an RX pad on the board? How or what can you transmit to the device by UART?

Is there anything inside the console for flashing back 6.3.1.5? No Console

Managed to hook this pad up by UART - RS232, but despite trying all the baud speeds / settings only getting gibberish output - is this because the UART is spitting out MTK flashing protocol language since its in preloader mode without battery attached?
THOUGHTS: Think it is inverted signal logic rather than low level protocol.

Should I attach battery instead of USB power to see Bootloader logs? If so, how to attach battery to board whilst UART is soldered to cabling?
THOUGHTS: Unlikely to help, and potentially dangerous

Anyone tried any dongles with the Fire 7 or any other Amazon devices? MT/NCK/etc?

Last thing I can think to try is the NCC Group Hack on mt8163v chips using FPGA and chip whisperer. Anyone know how to simplify that process for this scenario of brick recovery rather than full unlock? - sounds like some well timed shorts in bootup might glitch it enough. Does this even work still or was this fully patched as part of mtk-su patching? Tried GND VCCK_PMU but couldn't get anything other than normal boot

 
Last edited:
  • Like
Reactions: Kramar111
Jun 3, 2021
28
6

"The difference between the two is, in SLA, BootROM performs the checks and in DAA, Download Agent (DA) performs the check. Download Agent is loaded by SP Flash Tool. On devices that implement SLA, you cannot load a DA file without completing the SLA challenge. On devices that implement DAA, the challenge is done by DA and a modified DA file is enough to bypass security (That is, assuming you manage to reverse things or have the BSP)."

I think the above (one of the few places I've seen talking about DAA online) is again not quiet entirely right - Description above indicates DAA is Just normal Secure DA necessity, i.e. less secure than SLA.

SLA is the usage of a Secure DA itself, whilst DAA is preloader and lk.bin signature verification.

Secure DA could contain, in this case Xiaomi Authroisation Request, therefore in this case only SLA needed disabling.

What is interesting is the mention of BSP. fbtool is part of this isn't it?

Given how complicated this is and the number of slight mistakes in terminology use I see everywhere online, I think fbtool really might work on this device and many others for a "fastboot cable" with enough tinkering.

Also notice how the tool is named both datool and fbtool in the same package, google also returns very little about both of these, and DAA now contains only links to mtk-bypass. Suspicious!
 
Last edited:
  • Like
Reactions: Kramar111
Jun 3, 2021
28
6

The above links to the cryptocore usage for X30 chip MT6799W, which sounds like a more complex design than the MT8163V.

"Chaining of secondary public keys, signed by the root-of-trust public key, to permit parts of the system image to be signed by other trusted developers"

Don't we just need a copy of the root-of-trust public key for signing the bootloader image?

"The module remains assigned to the User Role permanently, unless the operator moves the module into one of the special Life Cycle States intended for fualt discovery (Secure Debug and RMA)"

"a) Run a special boot loader that can be flashed to the device
Flash a special boot loader to the device and power up
The boot loader enables RMA state
Set all 1’s for all the platform keys that are stored in OTP
b) Use a PC tool to send command to the device
Send a zeroization command from PC tool to the device
Device firmware interpreters the command and enables RMA state
Set all 1’s for all the platform keys that are stored in OTP"


Wonder how to shift the Life Cycle State? Wonder what PC tool is being referred to there?

I doubt the MT8163 is as secure, can anyone confirm?

Also notice they call it One-Time-Programmable but you seem to be able to set all 1s after the One Time Programming operation! (isn't zeroing setting it to 0 not 1...)

Bit off topic, but too appropriate:

 
Last edited:
  • Like
Reactions: Kramar111
Jun 3, 2021
28
6
After months of slowly calculating this I finally have some solutions for the latter hw revised devices!

Option 1:

Randomly poke at area near the emmc chip, yes seriously... I did it on one that I was trying to scrape the pcb tracks on, after tearing off pads near emmc by accident. It now doesn't boot but I get bootrom output!?! bootrom is halting (as seen on uart) and its error message is varying based on changes to inserted microSD (i.e. change partition names on card and I get different error from bootrom), i.e. I think I got bootrom booting from microSD - I don't think these newer devices have bootrom DL mode at all anymore, replaced by microSD boot instead. The damage to board is likely the cutting of one of the eMMC tracks that has done this, need a microscope to see where i cut exactly on the pcb.

Problem I now have is how do I partition a microSD card to match the eMMC's layout and flash Android onto the card? Anyone got good instructions? It is MTK Bootrom MicroSD boot mode not preloader/lk.bin boot Android from MicroSD mode. I think I need to partition EMMC_BOOT0 EMM_RPMB EMMC_USER etc like Jedec standard, or like armbian.

There is a second option but I wont go into that as it is very hard! requires special circuit made from arduino/microcontroller and a really clever hack for fire 7 2020, for fire 10 2020 it may only need hack still waiting to try it on my pads, holding back testing it because of this dead fire 7 i've been trying to fix instead.
So close!
 

douginoz

Senior Member
Jan 18, 2007
199
30
Melbourne
Is there a way to identify these devices? I was given a new Fire 7 Gen 9 and updated it to the stock rom 6.3.2.1 I think. Then used the h/w trick of shorting a tiny pin, which worked. It's now running a non-stock rom with TWRP 3.3.1-0. I don't know how to tell if I have an older device or just lucky with the new device.
 

Top Liked Posts

  • There are no posts matching your filters.
  • 1
    Trying to brainstorm ideas for unbrick (firstly) of the new Fire 7 2020 Gen 9 models that feature 6.3.1.5 and were released post Feb 2020. Already have a method to downgrade this and many other devices (HD8 Onyx and HD 10 post patch Feb 2020) possibly a lot more other devices

    Downgrade is a bit of a Sledge Hammer, in that it impacts numerous parts of IT (not just Android) as a new general hacking technique, and currently there seems no way of using my technique on these devices without resulting in hard brick, with no recovery possible.

    On devices, if they exist, which contain cryptographic key burnt by eFuse, my bug will not be easily fully patchable. Very likely these devices will be constantly able to be attacked by different permutations of the bug.

    I'm also not entirely sure if the technique is needed at all on this device (fbtool sounds more promising Started work on my own tool to talk to bootrom and preloader -after playing around with the protocol and staring at the preloader source, it seems impossible to to send DA / jump DA properly on this device), I actually suspect it will work on the HD 10 post Feb 2020 devices better - i.e. forcing downgrade from 7.3.1.2 to 7.3.1.0 but again it might brick instead from RPMB checks, similar to current scenario with using it on the Fire 7. Need to test hack on HD 10 2020, should work fully, holding back whilst fixing the fire 7.

    SOFTWARE Related Ideas/Notes:

    AFTV2-tools?

    THOUGHTS: Can complete handshake, but on read it stalls - no response. Was this blocked on this preloader? YES.
    Does anyone have any other crash to bootrom from preloader methods other than the one's in this code base?

    amonet-kamakiri?

    THOUGHTS: How do you modify this to use UART instead of VCOM? Maybe UART mode for flashing might allow it, anyone know how to get device into UART SP Flash mode?
    Don't think this device has UART flashing mode but can't be sure (only able to get logging)

    mediatek-datool?

    THOUGHTS:
    This might do it, but sounds complicated, I think it might be able to be used to clear existing chain of trust if used in a certain method - still mulling over the details. Upon some brief testing when used with 6315 preloader and lk.bin i get error about .sign file, but the gibberish from the UART seems different to cold boot scenario, i.e. the device is logging something extra based on passing in command to device. Jump DA / Send DA logging appeared on UART

    Need to understand what the code is doing more - looks like it is sending a preloader and lk.bin to boot the device into fastboot mode, and the sign file is rather a patch file generated by the gen-dalk-from-lk.py to make a temporary DA file to start transfer of the preloader/lk.bin to reboot into fastboot - if so, then this may work as a generic method for mtk devices to unlock/root, by compiling lineage lk.bin/preloader without secureboot enabled and with fastboot unlocked then using the script to create the .sign file and using fbtool to boot to fastboot which is then unlocked. Might also need a hacked preloader which bypasses rpmb rollback check and any other security preventing booting. I still think it is possible by using MTK's key not Amazon's key. Need to find a MTK 8163V preloader / lk.bin source code (anyone have any links?)

    This will only work with lineage compiles not FireOS as you need to boot it in secure chip mode using fbtool which then would need an auth file from existing amazon key (This is assuming that there is no existing key check to block fbtools from booting up - Need to confirm if fbtool can be used in insecure mode to boot into fastboot on this device Insecure mode doesn't work) - There is still possibly a way to use FireOS, but it would mean fully unsigning FireOS and resigning it with your own key then flashing that on, after having generated the relevant auth file / sign file for fbtool - This approach should enable FireOS with your own key. Whilst once in hacked fastboot should be able to reflash the original full ROM which would cause it to revert to stock.

    I think fbtool is one of the only uses for the preloader, and offers a chance to unbrick devices which only have preloader access and no bootrom access (like this patched device). Need to either sign with Amazon or MTK's key - I think either one may work. Whilst Amazon's key is unavailable, isn't MTK's key supplied in the BSP?

    Anyone have lineage installed on Fire 7?
    Need someone to test generating a DA file from fbtool's python script to see if it works. If what I'm thinking about the difference in Secure DA and DAA is right it is likely to work - DAA i think is disabled as it looks like it is to do with verifying preloader / lk.bin at bootrom stage.

    Doesn't seem to have lk.bin. lk..bin provided by MTK not android project...

    Some further ideas to investigate:
    Using a blank preloader file for fbtool, to see if it causes device to drop into bootrom mode

    DIdn't notice in fbtool readme that enable DAA was a one time operation.


    Does anyone know of a definitive example of a device which has eFuse blown for crypto key?

    Looking at previous threads, there is an indication that amazon attempted to test whether the eFuse is functioning, but there was no verified proof that eFuse has been blown. For the Fire 7 Gen 9 that I have, it appears the brom access was disabled by changing the eMMC chip not blowing a eFuse.

    There is also no evidence of Amazon using an eFuse to store the crypto keys for this device that I can locate, meaning fbtool is very likely to be where chain of trust begins.


    I think the way to check properly is to look at SPFT's terminal mode for reading the efuse's on the device. We might be able to do this on a unlocked/accessible Fire 7 Gen 9 2019 (i.e. one with available eMMC short to brom)

    signfile-for-brom.sh indicates the preloader is patched with key? Does the preloader.img.sign file get accessed by the brom when being used by fbtool?

    Need to look at bootrom code to verify what it does when fbtool has sent it a sign file as part of reboot to fastboot cycle. Looked at preloader code for answers instead

    Is TEE/TZ1/TZ2/Trustzone updated by fbtool/datool? Is this where it is processing the sign files. Its also maybe using RPMB to store keys?

    fbtool requires a almost payload like data structure, this is contained in gen-dalk-from-lk.py and will require one per SoC type. The above github does not contain a copy, but I have located one for MT8163 from another source. In order for this method to work on more devices, would need to locate more "payloads" for other SoCs. This method is very likely to be a clean method to access numerous MTK based devices.

    The preloader contained inside Amzons rom files seems to be split into main preloader.img and preloader.hdr0/1 files, These look like they need merging or prehaps they are the MTK headerless version of the files (fbtools readme indicates a need for headerless files)

    Any ideas where you might find "fbtool-da-pl.bin is a pre-built preloader_${PROJECT}_NO_GFH.bin" for this device? Should be in preloader/lk.bin compile process.

    What about boot.img renamed to factory.img and placed on sdcard?

    THOUGHTS: strings on the preloader indicate this may be possible, unless this has been blocked and the message hasn't been removed. Need this tested. No sdcard boot on preloader/lk.bin available but... Bootrom boot maybe possible see latest!

    Tried SP Flash 5.1532 (insecure boot version) any other flashing tools that might work?

    If it is in preloader mode, will there still be security blocking flashing if attempting to do UART flash instead of USB flash (UART might have different permission level than USB), will MTK-Bypass work with some modifications to talk to real COM port instead of VCOM?

    THOUGHTS: mtk-bypass says it is bypassing DAA (Download Agent Authorization), My current understanding is it is disabling DAA and SecureBoot unnecessarily and should only disable SLA.

    DAA sounds like it occurs at bootrom to verify preloader and lk.bin has been signed itself (fbtool Readme)

    Secureboot sounds like it is the flag that is passed through to AVB (Android Documentation)

    SLA sounds like it is the Secure DA being verified at preloader stage

    Had a look at source / info online about it, and i think I'm right that DAA and secureboot disabling are not needed - SLA bypass is needed for SPFT fulll flash as that is bypassing secure DA check on preloader - whilst DAA and secureboot bypass via MTK-Bypass is needed only for a tethered boot scenario where device has DAA enabled fully, and you want to boot a preloader/lk.bin that hasn't been signed, mtk-bypass could then be used to tether bootup to disable both flags and enable booting - maybe then we can modify it a bit for devices where DAA is fully working with secureboot?

    Which devices have problems with modified preloader/lk.bin which feature mtk chip, those would likely benefit? Not relevant for this Fire 7 I dont think. This allows a tethered boot solution for various scenarios, like linux dual boot, full system rw android install, etc.

    Would using a hacked preloader which has secure DA verification disabled, whilst the device has bricked preloader and in bootrom mode, enable SPFT to flash device without mtk-bypass?

    This would mean mtk-bypass is only worth using if you can't remove secure DA support from the preloader file itself - i think it might be patchable out with decompilation. Either that or the preloader is not fully bricked and still being read by bootrom to perform secure DA verification, would likely also need mtk-bypass in this situation.


    This pad is ridiculously infuriatingly annoying to attempt to recover back to stock... Unless I am missing something obvious that i haven't tried.

    Also anyone know where I can find the signed images for 6.3.1.1 6.3.1.0 or earlier, need the original update-*.bin files?
    THOUGHTS: Already got everything from waybackmachine - any other sources of urls from their servers?

    Also is there any available Preloader versions for this device or any *OTHER* Amazon devices that have preloader crash to Bootrom available?
    I need full collection of Amazon ROMs for all devices if possible, with it I might be able to get unlock/root working on them all - Chasing after a preloader that works to crash to get into bootrom or has available shortcut to enter bootrom (i.e. power/vol buttons) - with it plus what i've worked out, should be answer to all Amazon devices unlock, hopefully. I might also be able to repeat for all other devices - this might even work with the 2021 HD 10 which is just released!

    Also any good guides to preloader/IDA Pro decompiling? Is this what I need to buy from IDA in order to repair and recover my Fire 7?
    IDA Pro Computer License [Windows]1879 USD
    ARM64 Decompiler Fixed License [Windows]2629 USD
    ARM32 Decompiler Fixed License [Windows]2629 USD
    The home version is a cloud based decompiler isn't it? Above is minimum price for offline decompilation isn't it?
    1
    Hardware related Ideas/Notes:

    Tried hw method for CMD/DAT0/CLK and the emmc pin at front, no response (CMD jumps to preloader while all other test points result in no response - same as previous testers of newer Fire 7 device)

    Anyone know what the other testpoints are, like:

    VCOM/VGH/RST/ON/ID/VBAT/AUX_NTC/PWRKEY/USB_ID/DP/DM/VBUS/VGP3_PMU/FCHR_ENB/COL0

    GND - Why did they put a pad for this when there is GND everywhere on the board?
    CLK/CMD/DAT0 - MicroSD connection! NOT eMMC... Test with ohmmeter against MicroSD pins!
    TX/RX - UART

    SDI/SDO/SCI/CS
    Is SDI/SDO/SCI/CS some kind of SPI or another interface? Likely it is SPI (anyone know how to talk to it? I have raspberry pi's / picos / arduinos / ch341a)

    What about the covered over points?

    VIO8_PMU - 1.8V to eMMC?
    VCC_IO - Cant rememebr if it is this one or above, need to retest.
    VEMC3V_PMU - 3.3V to eMMC?
    VCCK_PMU - Voltage to SoC?

    AVOD/VGL/LEDA/LEDK/SPK_N/SPK_P/VPROC_PMU/VMCH_PMU/VMCA_PMU/VCAMD_IO/VCAMD_PMU/HPL/HPR

    Maybe can make a list of all points and how they behave for this board?

    Anyone know of how to interface directly with the eMMC by soldering MMC adapter?
    Tried to attach to dat0 from front of board but ended up tearing pad - need to use a better method than soldering, maybe use Rubber+Needles+Crocodile Clips

    Any chance of doing stock recovery by UART RX/TX flash?

    THOUGHTS: Probably not, likely only get boot logs.

    Can I use a raspberryPi B to connect to UART, Do I have to use RS232 or TTL?
    THOUGHTS: No, possibly dangerous, RaspberryPi B is at 3.3v whilst this is possibly 1.8v - need to measure using voltmeter. RS232 should be safe as it uses -13v-+13v for RX/TX. USB TTL would also need a logic level shift from 3.3v to 1.8v. Therefore USB RS232 adapter is best choice. (I think for TX from board to RX from USB Serial - But dangerous from RX from board to TX from USB Serial because of over voltage from adapter possibly supplying +13v - need confirmation as this is useful for potentially debugging other gear by UART) Problem with RS232 is signal is inverted when read, therefore needing inversion by another chip to display correctly - better RS232 USB adapters seem to be able to be flashed by EEPROM to invert signal (FTDI ones with mProg). Need a USB TTL for further testing. Need to see if PL2303 can be hacked to invert signal - maybe driver hack for linux possible? Anyone have any simpler solutions to see UART logging from this device, or do I need a logic level analyser?

    If so how to connect it?


    THOUGHTS: Connect TX to Pin 2 from RS232 and GND to Pin 5 (Dont attach RX from board, else possible over voltage from sending data from PC). Using CH340G attach RX to TX on PCB, GND to GND, Make sure cables are shielded or split due to interference from cabling touching each other. Connection currently without battery installed seems to output gibberish, need to test with battery installed (Maybe bootloader logs will output) -Currently despite gibberish output it is most likely 961200 baud Databits 8, no flow control, 1 stop bits for preloader. Bootrom logging sounds like it might be 115200 (according to older kindle device thread )

    Since the device can seemingly only output from UART, why is there an RX pad on the board? How or what can you transmit to the device by UART?

    Is there anything inside the console for flashing back 6.3.1.5? No Console

    Managed to hook this pad up by UART - RS232, but despite trying all the baud speeds / settings only getting gibberish output - is this because the UART is spitting out MTK flashing protocol language since its in preloader mode without battery attached?
    THOUGHTS: Think it is inverted signal logic rather than low level protocol.

    Should I attach battery instead of USB power to see Bootloader logs? If so, how to attach battery to board whilst UART is soldered to cabling?
    THOUGHTS: Unlikely to help, and potentially dangerous

    Anyone tried any dongles with the Fire 7 or any other Amazon devices? MT/NCK/etc?

    Last thing I can think to try is the NCC Group Hack on mt8163v chips using FPGA and chip whisperer. Anyone know how to simplify that process for this scenario of brick recovery rather than full unlock? - sounds like some well timed shorts in bootup might glitch it enough. Does this even work still or was this fully patched as part of mtk-su patching? Tried GND VCCK_PMU but couldn't get anything other than normal boot

    1

    "The difference between the two is, in SLA, BootROM performs the checks and in DAA, Download Agent (DA) performs the check. Download Agent is loaded by SP Flash Tool. On devices that implement SLA, you cannot load a DA file without completing the SLA challenge. On devices that implement DAA, the challenge is done by DA and a modified DA file is enough to bypass security (That is, assuming you manage to reverse things or have the BSP)."

    I think the above (one of the few places I've seen talking about DAA online) is again not quiet entirely right - Description above indicates DAA is Just normal Secure DA necessity, i.e. less secure than SLA.

    SLA is the usage of a Secure DA itself, whilst DAA is preloader and lk.bin signature verification.

    Secure DA could contain, in this case Xiaomi Authroisation Request, therefore in this case only SLA needed disabling.

    What is interesting is the mention of BSP. fbtool is part of this isn't it?

    Given how complicated this is and the number of slight mistakes in terminology use I see everywhere online, I think fbtool really might work on this device and many others for a "fastboot cable" with enough tinkering.

    Also notice how the tool is named both datool and fbtool in the same package, google also returns very little about both of these, and DAA now contains only links to mtk-bypass. Suspicious!
    1

    The above links to the cryptocore usage for X30 chip MT6799W, which sounds like a more complex design than the MT8163V.

    "Chaining of secondary public keys, signed by the root-of-trust public key, to permit parts of the system image to be signed by other trusted developers"

    Don't we just need a copy of the root-of-trust public key for signing the bootloader image?

    "The module remains assigned to the User Role permanently, unless the operator moves the module into one of the special Life Cycle States intended for fualt discovery (Secure Debug and RMA)"

    "a) Run a special boot loader that can be flashed to the device
    Flash a special boot loader to the device and power up
    The boot loader enables RMA state
    Set all 1’s for all the platform keys that are stored in OTP
    b) Use a PC tool to send command to the device
    Send a zeroization command from PC tool to the device
    Device firmware interpreters the command and enables RMA state
    Set all 1’s for all the platform keys that are stored in OTP"


    Wonder how to shift the Life Cycle State? Wonder what PC tool is being referred to there?

    I doubt the MT8163 is as secure, can anyone confirm?

    Also notice they call it One-Time-Programmable but you seem to be able to set all 1s after the One Time Programming operation! (isn't zeroing setting it to 0 not 1...)

    Bit off topic, but too appropriate: