• Introducing XDA Computing: Discussion zones for Hardware, Software, and more!    Check it out!
  • Fill out your device list and let everyone know which phones you have!    Edit Your Device Inventory

[MOD][DEV] MediaTek / MTK - Auth Bypass (SLA/DAA) - Utility

Search This thread
Jun 3, 2021
26
1
Is there anyway to modify mtk-bypass to use UART TX/RX on board soldered to USB RS 232 for Fire 7 Gen 9 mt8163v? Trying to unbrick downgrade of 6.3.1.5 (hardware blocked version) to 6.3.1.2, was hoping to get either mtk-su working or hardware short working, but resulted in brick - likely preloader is now 6.3.1.2 though, and still shows up via USB as vcom preloader. Connected via uart/putty and currently only gibberish (i think its in either bootrom or preloader flash mode inverted signal)
 
Last edited:

k4y0z

Senior Member
Nov 27, 2015
1,443
1,855
Is there anyway to modify mtk-bypass to use UART TX/RX on board soldered to USB RS 232 for Fire 7 Gen 9 mt8163v? Trying to unbrick downgrade of 6.3.1.5 (hardware blocked version) to 6.3.1.2, was hoping to get either mtk-su working or hardware short working, but resulted in brick - likely preloader is now 6.3.1.2 though, and still shows up via USB as vcom preloader. Connected via uart/putty and currently only gibberish (i think its in either bootrom or preloader flash mode)
Not really sure what you're asking.
As long as brom dl-mode isn't fused on your device, check this thread to recover:

Baudrates for UART are 115200 for bootrom and 921600 for the rest.
 
Jun 3, 2021
26
1
Currently mtk-bypass uses USB mode to transfer, is there anyway to modify it so it uses the UART?

Still trying to get UART working, i think i have problem with RS232 inverting logic, so i'm seeing gibberish - Is UART only for logging output on this device, i.e. no sp flash mode?

eMMC short fix doesn't work, its a patched device. I thought it might be a software patch not hardware, thus downgrade attempt using new hack for all devices and many other platforms possibly (this is the test of my hack)... and now hard brick

Trying to brainstorm the current state of Fire 7 Gen 9 here (i.e. hardware locked devices):


mtk-bypass says it is bypassing DAA (Download Agent Authorization), Is this correct or a typo, since it looks like it is bypassing Secure DA verification conducted at preloader? DAA sounds like it occurs at bootrom to verify preloader and lk.bin has been signed itself? This is what I'm thinking based on what i see in fbtool's readme.
 
Last edited:

k4y0z

Senior Member
Nov 27, 2015
1,443
1,855
Currently mtk-bypass uses USB mode to transfer, is there anyway to modify it so it uses the UART?

Still trying to get UART working, i think i have problem with RS232 inverting logic, so i'm seeing gibberish - Is UART only for logging output on this device, i.e. no sp flash mode?

eMMC short fix doesn't work, its a patched device. I thought it might be a software patch not hardware, thus downgrade attempt using new hack for all devices and many other platforms possibly (this is the test of my hack)... and now hard brick

Trying to brainstorm the current state of Fire 7 Gen 9 here (i.e. hardware locked devices):


mtk-bypass says it is bypassing DAA (Download Agent Authorization), Is this correct or a typo, since it looks like it is bypassing Secure DA verification conducted at preloader? DAA sounds like it occurs at bootrom to verify preloader and lk.bin has been signed itself? This is what I'm thinking based on what i see in fbtool's readme.
Any USB-UART adapter (ftdi) should work fine.
If your device is fused (DL Mode disabled) then bypass cannot work either.
Bypass disables DAA and SLA, which allows using generic download agent without authentication.

To unbrick you'll probably have to access the EMMC directly using the SD-protocol via an adapter (DAT0, CMD, CLK...)
 
Jun 3, 2021
26
1
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 - Need confirmation from author - maybe author can then 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.

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.

Any guides on how to attach SD to emmc chip?

Double posting because, trying to consolidate info on one page for brainstorming in the other thread.

Yeah FTDI not PL... no inversion of signal

Currently thinking more about fbtool as unbrick rather than mtk-bypass but very interesting to use to understand mtk boot process.
 
Last edited:

k4y0z

Senior Member
Nov 27, 2015
1,443
1,855
maybe author can then 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.
The bypass utility can already disable all of these security featuers, so not sure what modification would be needed.

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?
You won't be able to boot a modified preloader with security enabled.

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.
Again, you won't be able to load a modified preloader with security enabled.

Any guides on how to attach SD to emmc chip?
You could probably use a microSD <-> SD adapter and some level-shifters (As emmc likely uses 1.8V) to breakout the signals.
I can't recommend any guides, but I'm sure there will be some available online.
 
Jun 3, 2021
26
1
The bypass utility can already disable all of these security featuers, so not sure what modification would be needed.

Doesn't the chain of trust for these devices begin with preloader?

If it began with bootrom, wouldn't you need a tether to the device to boot into a mode where DAA is disabled along with secureboot?

Either that or is mtk-bypass modifying the bootrom itself to disable those flags? Thought bootrom was ROM? How else is DAA bypass going to work if it is part of the initial bootrom cycle which is used to verify the preloader with?

What I'm trying to get at is i think you only need to disable SLA for SPFT access, and the other two bits your setting are to do with booting the device with a modified preloader/lk.bin (I'm going by what I think the fbtool documentation is saying)

Modifying mtk-bypass to disable secureboot and DAA to then boot - not halt and wait for SPFT access, this would enable a hack where you can boot a DAA device with whatever preloader and lk.bin you have modified. (Possibly useful, not sure as I dont think Fire 7 is DAA, it is preloader secure DA enabled, i.e. SLA)

The Fire 7 Gen 9 I dont think has DAA, as it looks like others have managed to modify lk.bin and preloader using amonet-kamakiri hack and have gotten into bootrom from zeroing out preloader. These should surely trigger DAA verification failures resulting in hard brick (i.e. brick at bootrom stage since preloader will not exist let alone match signature verification) - This is the reason why I think they usually don't do DAA on devices as it will result in bootrom brick if nothing is on emmc - no preloader to verify. Therefore beginning the chain of trust at preloader stage.

DAA sounds like it is for usage scenarios where the device security is more important than the device itself - i.e. if it has been tampered with, hard brick it, most likely for weird applications (mtk sell their chips for things like GPS tracker bugs etc) I reckon its for those usage scenarios rather than phones/tablets.

Still battling through the immense lengths of Fire related info, on XDA, thus trying to summarise it all for the Gen 9 on other thread.

Have you tried fbtool before on a device? I'm quite sure that fbtool sounds like it can be used to start the chain of trust as long as you have either bootrom or preloader on device.
 

k4y0z

Senior Member
Nov 27, 2015
1,443
1,855
Doesn't the chain of trust for these devices begin with preloader?
No, it starts at bootrom.

If it began with bootrom, wouldn't you need a tether to the device to boot into a mode where DAA is disabled along with secureboot?
Which is precisely what the bypass-utility does.

What I'm trying to get at is i think you only need to disable SLA for SPFT access, and the other two bits your setting are to do with booting the device with a modified preloader/lk.bin (I'm going by what I think the fbtool documentation is saying)
Using a generic DA also requires DAA to be disabled.
SBC does not need to be disabled for SPFT, which is why the utility will only disable security if DAA or SLA are detected (unless you use the --force option).

Modifying mtk-bypass to disable secureboot and DAA to then boot - not halt and wait for SPFT access, this would enable a hack where you can boot a DAA device with whatever preloader and lk.bin you have modified. (Possibly useful, not sure as I dont think Fire 7 is DAA, it is preloader secure DA enabled, i.e. SLA)
Booting a modified preloader is theoretically already possible after disabling security via the download protocol.
Having it boot a modified pl from EMMC after disabling security instead of waiting for a handshake is something I'll have to think about.

The Fire 7 Gen 9 I dont think has DAA, as it looks like others have managed to modify lk.bin and preloader using amonet-kamakiri hack and have gotten into bootrom from zeroing out preloader. These should surely trigger DAA verification failures resulting in hard brick (i.e. brick at bootrom stage since preloader will not exist let alone match signature verification) - This is the reason why I think they usually don't do DAA on devices as it will result in bootrom brick if nothing is on emmc - no preloader to verify. Therefore beginning the chain of trust at preloader stage.
AFAIR all the fire devices have DAA but no SLA.
amonet/kamakiri do not modify the LK or PL on the EMMC.
They use bootrom-exploits (just like bypass-utility, which is based on kamakiri) to flash an exploit for LK which then modifies LK in memory to allow booting unsigned images.
Wiping the preloader causes the bootrom to fall back into DL-Mode, which can then be used by amonet/kamakiri

Still battling through the immense lengths of Fire related info, on XDA, thus trying to summarise it all for the Gen 9 on other thread.

All this is useless to you, if you have a device which has the bootrom DL-Mode disabled via efuse.
Amazon has done this on later batches of many devices including mustang as well as started burning the fuse via OTA on some devices, such as mantis.
It doesn't matter if preloader is wiped, crashed or EMMC is shorted it will just refuse to boot altogether instead of falling back into DL-Mode.

So you'll need another way to access the devices EMMC to unbrick (such as building an adapter to access it directly).
 
Jun 3, 2021
26
1
No, it starts at bootrom.

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

Which is precisely what the bypass-utility does.

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.

Using a generic DA also requires DAA to be disabled.

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)

Having it boot a modified pl from EMMC after disabling security instead of waiting for a handshake is something I'll have to think about.
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)


to flash an exploit for LK which then modifies LK in memory to allow booting unsigned images.

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.
All this is useless to you, if you have a device which has the bootrom DL-Mode disabled via efuse.
Amazon has done this on later batches of many devices including mustang as well as started burning the fuse via OTA on some devices, such as mantis.
It doesn't matter if preloader is wiped, crashed or EMMC is shorted it will just refuse to boot altogether instead of falling back into DL-Mode.
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.

So you'll need another way to access the devices EMMC to unbrick (such as building an adapter to access it directly).

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.
 
Last edited:

k4y0z

Senior Member
Nov 27, 2015
1,443
1,855
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?

:rolleyes:

If it did start with preloader i.e. secure boot being disabled, you could simply flash a modified preloader and do whatever you want.

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

That sounds like a lot of BS...


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.
DAA = Download Agent Authentication.
Disabling it allows booting unsigned images, such as a generic DA, which has not been signed by the vendor (i.e. Amazon).
You could also use this to boot a modified PL via the download protocol.

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.
While the preloader may also implement the download protocol, the preloader is not involved at all when using the bypass-utility.


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.
As I've explained previously amonet/kamakiri for the Fire devices DO NOT boot an unsigned LK.
Instead LK is exploited during bootup via modified boot/recovery images.
All of this is open source on github, you should check it out, if you're really interested to understand how it works.


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.

I wrote about it here

Hi, but is mtk bypass utility also capable of temporarily disabling secure boot like amonet did?
bypass already disables secure boot.
amonet/kamakiri for the fire devices do not disable secure boot, they exploit LK.
 

XRed_CubeX

Senior Member
: rolleyes:

If it did start with preloader i.e. secure boot being disabled, you could simply flash a modified preloader and do whatever you want.



That sounds like a lot of BS...



DAA = Download Agent Authentication.
Disabling it allows booting unsigned images, such as a generic DA, which has not been signed by the vendor (i.e. Amazon).
You could also use this to boot a modified PL via the download protocol.


While the preloader may also implement the download protocol, the preloader is not involved at all when using the bypass-utility.



As I've explained previously amonet/kamakiri for the Fire devices DO NOT boot an unsigned LK.
Instead LK is exploited during bootup via modified boot/recovery images.
All of this is open source on github, you should check it out, if you're really interested to understand how it works.




I wrote about it here


bypass already disables secure boot.
amonet/kamakiri for the fire devices do not disable secure boot, they exploit LK.
Interestingly, I remember that amonet, on my m5c (I don't remember anything don't ask me, it happened months ago) it allowed to bypass secure boot and start custom LK but only for one session, if you ever restarted the phone, the exploit had to be rerun .
Second thing:
You said you can load a custom Preloader with download, how do you do it?
Do you mean flashing or is there a real procedure?
Can it be done with MTK bypass?
 

k4y0z

Senior Member
Nov 27, 2015
1,443
1,855
Interestingly, I remember that amonet, on my m5c (I don't remember anything don't ask me, it happened months ago) it allowed to bypass secure boot and start custom LK but only for one session, if you ever restarted the phone, the exploit had to be rerun .

Theoretically amonet could disable secure-boot just like bypass-utility does, it typically works by exploiting LK (and then modifying it in memory) though.
It could probably also be modified to load a modified LK after LK has been exploited.
I'm not familiar with the amonet-fork for m5c.

Second thing:
You said you can load a custom Preloader with download, how do you do it?
Do you mean flashing or is there a real procedure?
Can it be done with MTK bypass?
Basically by supplying a preloader (with headers stripped IIRC) via the send_da command.
Using bypass-utility that should be possible by running it again after disabling security, supplying preloader as payload and setting payload address to the preloader's load address.

Alternatively there are some more advanced features available here
It's based on bypass-utility and its payloads but includes some more advanced options.
 
Jun 3, 2021
26
1
If it did start with preloader i.e. secure boot being disabled, you could simply flash a modified preloader and do whatever you want.
Exactly that, this has been process for quiet a number of MTK devices previously. Unless DAA was enabled on the device this was still the case - NOTE: MTK usually sell budget devices! How many of them have you tested?

That sounds like a lot of BS...
OK, so how do you downgrade a 6.3.1.5 locked and patched amazon device if you know this device so well - Claiming i dont have a new exploit, where is your evidence? Notice the immense amounts of evidence indicating I am heavily investigating something!

Notice the defensive manner of your speech when I have mentioned DAA and SecureBoot - Notice how neither techs have to do with SPFT directly.

DAA = Download Agent Authentication.
Disabling it allows booting unsigned images, such as a generic DA, which has not been signed by the vendor (i.e. Amazon).

NO Pay Attention Lookup the fbtool Readme from MTK staff, and look at my summarised version. Preloader is what checks Secure DA file.

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.

Any other MTK knowledgeable individuals want to comment whom sounds more accurate?

The DA booted is it? Where does it say that? The DA is Download Agent used for the transfer protocol supporting information between device and PC.

While the preloader may also implement the download protocol, the preloader is not involved at all when using the bypass-utility.

How comes SPFT asks you for a Preloader file? Is that just some kind of magic file or something?

As I've explained previously amonet/kamakiri for the Fire devices DO NOT boot an unsigned LK.
Instead LK is exploited during bootup via modified boot/recovery images.

So why the bit where you said:
to flash an exploit for LK which then modifies LK in memory to allow booting unsigned images.

Was a lie then?

All of this is open source on github, you should check it out, if you're really interested to understand how it works.
Have already taken a look, thats why I'm asking you about DAA and secureboot, When it looks like the installers of MTK-Bypass are requiring SLA Bypass, not either of the above which is used to secure the boot process on device.

BTW, when I tried mtk-bypass on my redmi 6 I got soft brick from just doing readback - Somehow boot cycle was interrupted just from mtk-bypass and readback - no other action.

Wondering if anyone else has seen their boot cycle interfered with from a readback using mtk-bypass/SPFT?

You do realise what I'm asking you above don't you? Do you understand how serious that might be if others have experienced boot cycle glitches? Computer Misuse act comes to mind.
if you ever restarted the phone, the exploit had to be rerun
Interesting!
 

k4y0z

Senior Member
Nov 27, 2015
1,443
1,855
Exactly that, this has been process for quiet a number of MTK devices previously. Unless DAA was enabled on the device this was still the case - NOTE: MTK usually sell budget devices! How many of them have you tested?
There are few devices with no security, Amazon's aren't among them.

Just for reference this is mustang:
Code:
[2021-06-23 21:50:10.588856] Device hw code: 0x8163
[2021-06-23 21:50:10.588976] Device hw sub code: 0x8a00
[2021-06-23 21:50:10.589027] Device hw version: 0xcb00
[2021-06-23 21:50:10.589092] Device sw version: 0x1
[2021-06-23 21:50:10.589150] Device secure boot: True
[2021-06-23 21:50:10.589223] Device serial link authorization: False
[2021-06-23 21:50:10.589269] Device download agent authorization: True

As you can clearly see, it has SBC and DAA enabled, but no SLA.

OK, so how do you downgrade a 6.3.1.5 locked and patched amazon device if you know this device so well - Claiming i dont have a new exploit, where is your evidence? Notice the immense amounts of evidence indicating I am heavily investigating something!
Do you?
All I know is, that you have a bricked mustang :unsure:

NO Pay Attention Lookup the fbtool Readme from MTK staff, and look at my summarised version. Preloader is what checks Secure DA file.

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.

Any other MTK knowledgeable individuals want to comment whom sounds more accurate?
OK, if you say so :rolleyes:


The DA booted is it? Where does it say that? The DA is Download Agent used for the transfer protocol supporting information between device and PC.
And where is the DA running?

How comes SPFT asks you for a Preloader file? Is that just some kind of magic file or something?
It requires configuration information for the DRAM on some devices with generic DA.


So why the bit where you said:


Was a lie then?
No, maybe you should try to understand the difference between the two things I said.

Have already taken a look, thats why I'm asking you about DAA and secureboot, When it looks like the installers of MTK-Bypass are requiring SLA Bypass, not either of the above which is used to secure the boot process on device.
Great, so Amazon devices won't require bypass to use SPFT, everybody else must have missed that.

BTW, when I tried mtk-bypass on my redmi 6 I got soft brick from just doing readback - Somehow boot cycle was interrupted just from mtk-bypass and readback - no other action.

Wondering if anyone else has seen their boot cycle interfered with from a readback using mtk-bypass/SPFT?
I find that hard to believe and have not seen anyone else reporting anything like that.
SPFT is a dangerous tool if used improperly.

You do realise what I'm asking you above don't you? Do you understand how serious that might be if others have experienced boot cycle glitches? Computer Misuse act comes to mind.
Won't even bother with this one 🤣
 
Jun 3, 2021
26
1
As you can clearly see, it has SBC and DAA enabled, but no SLA.
Are you sure your reading the Flags correctly for this device? As you said Amazons devices are secured differently.

Sersiously, that is your response when you claim to know about this procedure and are the developer for this code?

Notice, I'm trying to reach the correct academic conclusion on the terminology used, whilst you are just being blase about the issue.

And where is the DA running?

That's what my question was too, so you don't know and your securing the transfer of the ROM now?

My guess is that it is loaded after preloader authroises it by signature verification. How comes you know so much about a preloader which we don't have the source code for? Did you use IDA on it?

It requires configuration information for the DRAM on some devices with generic DA

Thats what I said above no? The DA is Download Agent used for the transfer protocol supporting information between device and PC.

No, maybe you should try to understand the difference between the two things I said.

Your not making logical sense in your statements, look at it yourself. You said FLASH, didnt you, therefore triggering DAA No?

Great, so Amazon devices won't require bypass to use SPFT, everybody else must have missed that.
Where did I say that, I didn't mention Amazons devices anywhere there, I am talking MTK, this is MTK thread No?

I find that hard to believe and have not seen anyone else reporting anything like that.
SPFT is a dangerous tool if used improperly.

This is why I am wanting to see if anyone else noticed it. It wasn't a hard error, but was hijacking the Boot Cycle - Temporary boot cycle glitch on reboot after SPFT readback.

XDA is a dangerous tool if your thick too.

Won't even bother with this one
Carry on glitching boot cycles unnecessarily and I'm sure you will have to bother with it.
 

k4y0z

Senior Member
Nov 27, 2015
1,443
1,855
  • Like
Reactions: Rortiz2

Top Liked Posts

  • There are no posts matching your filters.
  • 21
    As some of you have already noticed, a couple of weeks ago @Dinolek and I published a utility, that allows bypassing authentication on MTK devices.
    The tool is based on an exploit dubbed kamakiri, which was originally found by @xyz` and released for the Amazon FireTV Stick 4K (mantis)

    What does this mean?
    You can use this utility to bypass Serial Link Authentication and Download Agent Authentication on supported devices to use software such as SP Flash Tool to unbrick devices that would otherwise require authentication (AUTH-file).

    The tool has since been expanded to support more SOCs by contributions from @viperbjk, @Rortiz2 and others.

    It currently supports the following SOCs (and their variations):
    • mt6261
    • mt6572
    • mt6580
    • mt6582
    • mt6735
    • mt6737
    • mt6739
    • mt6753
    • mt6755
    • mt6757
    • mt6761
    • mt6763
    • mt6765
    • mt6768
    • mt6771
    • mt6779
    • mt6785
    • mt6795
    • mt6797
    • mt6799
    • mt6873
    • mt6885
    • mt8127
    • mt8163
    • mt8173
    • mt8516
    • mt8695
    There are two parts to this project, the Utility itself and the Exploit Collection.

    Please refer to the projects README how to set up your environment to use this utility successfully.

    Please note, this project has already been incorporated in multiple commercial tools without even a mention.
    This software is free to use, but the courtesy of at least mentioning the original authors is expected.

    If you like this software and would like to support us, you can donate
    3
    REDMI 6A MT6765_Android no luck

    C:\Users\*****\AppData\Local\Programs\Python\Python37>python main.py
    Traceback (most recent call last):
    File "main.py", line 213, in <module>
    main()
    File "main.py", line 37, in main
    raise RuntimeError("Default config is missing")
    RuntimeError: Default config is missing
    Extract the exploit collection
    2
    2
    2
    Wow! Amazing work! Quick question, is there any chance in the future of expanding this exploit to support MTK6762? My Redmi 6 has been bricked for two years now because I can't get access to a Xiaomi Auth account...