[Miscellaneous Android Development] stickfiretv2020:
I'm sure your wrong as I have devices where I think the chain begins at preloader. How did you verify your tests were hitting DAA?

I need precise info on this process as my bug impacts these devices massively - To the point the entire manufacturer key must be replaced to patch it. Can't give details as bug is a new technique for hacking modern computers which has not been documented as far as I'm aware. Thats why I am looking for Amazon ROMs, I can make use of them in my technique (Other thread).

If this is burnt on eFuse these devices will be all remotely hard brickable/contraollable (MITM/One Click Brick/One Click Full System Control) as soon as I give details of my bug, with no fix possible (only partial fix possible). (One Click Brick, a little like One Click Root, might need to look for OCB in future...)

No it doesn't tether boot cycle to boot a preloader/lk.bin which hasn't been signed. You are bypassing DAA without a boot cycle happening after, how does this bypass DAA? DAA is signature verification of preloader and lk.bin on normal boot - nothing to do with flashing device.

Secure DA files control the flashing to the device, and as fbtool indicates, this happens on preloader, not bootrom. SLA bypass removes the need to secure DA files thus SPFT flashes. This should not be to do with DAA nor secureboot.

Generic DA file is needed for totally insecure device (i.e. device with SLA removed or bypassed)

DAA does not need disabling to use a Generic DA - Download Agent Authorisation, though it sounds like it is for Secure DA support, is actually Bootrom verification of Preloader Image itself, whilst Preloader is what then checks you have passed in a Secure DA file - this bit is called SLA i think.

When I looked into this initially I also thought the device has DAA - after looking in depth at the fbtool readme, its caused me to think this device is not secured like that at all. The broken english on there requires careful calculation against the MTK Boot cycle to understand where that tool sits in the manufacturing and repair of mtk devices.

Sounds like fbtool can be modified into a new"fastboot cable" but only with your own lineage compile. (Fleshing out details in other thread, this is also why I'm interested in mtk-bypass to understand more about DAA not SLA)

Yeah I'm sure this bit will help boot more interesting installs on devices - like full linux dual boot systems, and fully rooted and dm-verity disabled android installs etc, thus why I asked about it. Should also help in other weirder scenarios of device failure (For instance might even be able to tether a boot from SD Card without a working eMMC Chip - Very useful longer term - This will be hard, will require something like booting preloader from SRAM/RAM from bootrom, then booting the SRAM preloader - Issues would be whether you have SD access at bootrom level, not sure)

And that is the reason it cannot be DAA unless what I've seen from MTK readmes is false. The exploit was flashed - this would trigger DAA to refuse boot. Secure Chip should surely prevent you from booting an unsigned lk.bin image - thus if it were you would need to tether every boot cycle, unless the Kamakiri bug is presisting in RAM between cold boots/reboots.

Can you point me to where you got your info on SLA and DAA?

My understanding is SLA:

Preloader verifying it received a Secure DA File before flashing via something like SPFT

DAA:

Preloader and LK.bin signature verification by bootrom against eFuse.

Thats why I think its the other way round, Fire 7 has SLA not DAA.

How did you check that they have blown the eFuse by OTA update on mantis? This sounds like a dangerous update for failure scenario's i.e. lots of possible bricks from the update itself.

The reason to be so comprehensive is I'm investigating how serious my exploit technique is - sounds like i know how to brick/take over most android devices with technique. Its a cross platform technique possibly impacting billions of devices including, data centres. Thus all relevant info about mtk is useful even quallcomm stuff, heck, even ios bootloader info is useful!

AFTV2tools sounds like you can send a reboot command into it at handshake to get it in other modes, not sure brom DL mode is on the list, maybe that can cause brom access? Preloader has access to fbtool/datool thats why I'm looking into this more for this particular brick. I wonder if theres anyway to get the preloader to reboot to brom using fbtools method to talk to device? Really need to test it properly but need a lineage compile for it.

Yeah brainstorming that too on the other thread - I think there is SPI and JTAG and maybe some eMMC access pins/pads, not too sure how to go about it yet still researching. This would be ideal longer term on at least one of these Fires, since thats full read/write access at reasonable speeds to emmc, very confusing as to how to go about this - more of a software person than electronics.

Ultimately, I am wanting to place my apk onto a lineage compile as system - Just Amazon thought it would be a good idea to block me, thus this debacle. The strange thing is the technique I worked out is likely to cause their data centres issues as well as all their pads... If they burnt that efuse with their key in these devices will be utter junk after I say hack as it can be used in numerous ways to brick these devices with, it will be patching battle against new ways to brick/control amazons stuff.