yashsingh1/xdaforums huggingface dataset:
[Miscellaneous Android Development] theexternvoid:
Running an MT6737M board (BLU Grand X LTE). It's HW code is 335, same as the MT6737, but the script doesn't work. Log below and bootrom dump attached. Anyone have a fix or suggestions on how I can figure out the fix on my own?

[2021-04-16 02:12:32.909675] Waiting for device

[2021-04-16 02:12:38.186285] Found port = /dev/ttyACM0

[2021-04-16 02:12:38.332018] Device hw code: 0x335

[2021-04-16 02:12:38.432610] Device hw sub code: 0x8a00

[2021-04-16 02:12:38.542588] Device hw version: 0xca00

[2021-04-16 02:12:38.662646] Device sw version: 0x0

[2021-04-16 02:12:38.772556] Device secure boot: True

[2021-04-16 02:12:38.882658] Device serial link authorization: False

[2021-04-16 02:12:38.992661] Device download agent authorization: False

[2021-04-16 02:12:39.102665] Disabling watchdog timer

[2021-04-16 02:12:39.213747] Insecure device, sending payload using send_da

[2021-04-16 02:12:39.334155] Found send_dword, dumping bootrom to bootrom_335.bin
[Miscellaneous Android Development] theexternvoid:
Never mind that. Stupid user error. I didn't realize you could press both volume up and down together, and that's what I needed to get into the right mode. It works now. Though SP Flash doesn't like my TWRP image, but that'd be for a different thread.
[Miscellaneous Android Development] gords78:
I nailed the tricky stuff but after running the python script successfully i get the following SP Flash error.

Its a Chinese region Redmi 6 with locked Bootloader and Global ROM. Im trying to flash a stock Chinese ROM...

Any help please?
[Miscellaneous Android Development] theexternvoid:
My guess is you will need to unlock the bootloader. Steps for that vary by phone, so search around for solutions. Here's one explanation, but it might not work for your model.
[Miscellaneous Android Development] gords78:
I thought the whole point of this exploit was to get around a locked bootloader?
[Miscellaneous Android Development] theexternvoid:
I'm not an expert, but I thought a locked bootloader is a different issue than bootloader auth security. The auth logic requires a signed image to flash, meant to prove that the image came from the manufacturer. My experiences is if you don't have a signature from an auth file, then you get S_SECURITY_SECURE_USB_DL_IMAGE_SIGN_HEADER_NOT_FOUND instead of your error.
[Miscellaneous Android Development] gords78:
ah i see that makes sense. i shall try again tomorrow with the auth file see if i get anywhere.

Thanks!
[Miscellaneous Android Development] stickfiretv2020:
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)
[Miscellaneous Android Development] k4y0z:
Not really sure what you're asking.

As long as brom dl-mode isn't fused on your device, check this thread to recover:

Fire 7 (2019, mustang) unbrick, downgrade, unlock & root

Make sure to read this guide completely before starting. You will lose all data on the tablet, make a backup of important data before you start. What you need: - a Linux installation. Don't use a VM! Use a live USB, if you don't have Linux...

xdaforums.com

Baudrates for UART are 115200 for bootrom and 921600 for the rest.
[Miscellaneous Android Development] stickfiretv2020:
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):

https://xdaforums.com/t/fire-7-2019...ade-unlock-root.3944365/page-25#post-85131253

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.
[Miscellaneous Android Development] k4y0z:
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...)
[Miscellaneous Android Development] stickfiretv2020:
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.
[Miscellaneous Android Development] k4y0z:
The bypass utility can already disable all of these security featuers, so not sure what modification would be needed.

You won't be able to boot a modified preloader with security enabled.

Again, you won't be able to load a modified preloader with security enabled.

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.
[Miscellaneous Android Development] stickfiretv2020:
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.
[Miscellaneous Android Development] k4y0z:
No, it starts at bootrom.

Which is precisely what the bypass-utility does.

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

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.

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

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).
[Miscellaneous Android Development] XRed_CubeX:
Hi, but is mtk bypass utility also capable of temporarily disabling secure boot like amonet did?
[Miscellaneous Android Development] k4y0z:
: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.
[Miscellaneous Android Development] XRed_CubeX:
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?
[Miscellaneous Android Development] k4y0z:
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.

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.
[Miscellaneous Android Development] stickfiretv2020:
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?

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.

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.

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

So why the bit where you said:

Was a lie then?

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.

Interesting!
[Miscellaneous Android Development] stickfiretv2020:
Correction:

DAA:

Preloader and LK.bin signature verification by bootrom against eFuse. Unknown chip - maybe self signed preloader or lk.bin
[Miscellaneous Android Development] k4y0z:
There are few devices with no security, Amazon's aren't among them.

Just for reference this is mustang:

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

Do you?

All I know is, that you have a bricked mustang :unsure:

OK, if you say so :rolleyes:

And where is the DA running?

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

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

Great, so Amazon devices won't require bypass to use SPFT, everybody else must have missed that.

I find that hard to believe and have not seen anyone else reporting anything like that.

SPFT is a dangerous tool if used improperly.

Won't even bother with this one 🤣
[Miscellaneous Android Development] stickfiretv2020:
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.

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?

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

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

Where did I say that, I didn't mention Amazons devices anywhere there, I am talking MTK, this is MTK thread No?

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.

Carry on glitching boot cycles unnecessarily and I'm sure you will have to bother with it.
[Miscellaneous Android Development] k4y0z:
I was trying to help you.

You keep ignoring the information I give you.

Good luck, I'm done.
[Miscellaneous Android Development] llxxVENOMxxll:
Can this exploit be used to unlock the bootloader??

I am able to enter Download mode and flash files, but the locked bootloader prevents the booting of custom images.

I am damn sure that tools such as the Chimera Tool, CM2 MT2, Hydra etc. work on this principle.

Any help?
[Miscellaneous Android Development] k4y0z:
That would depend entirely how unlocking is implemented on the specific device.

For devices where it's just some flag on some partition that needs to be toggled, that can be done having write access to said partitions.

Other devices may require signed unlock-tokens to be stored on the device, so you'd have to first gain access to such a token.
[Miscellaneous Android Development] HancyParas:
I formated my phone using sfp tool now when I use mtp bypass tool I keep getting

Handshaking... [ERROR] UNEXPECTED RESPONSE: 0x68 any help?
[Miscellaneous Android Development] Warlockguitarman:
Hmm, I'm about to test this theory on the LG K51, which isn't unlockable as LG won't give out the keys to do so but I'm taking my unlocked bootloader K51 and I'm gonna dump the system with the mtk client tool, then im going to relock the bootloader and try to flash the files changed in the unlocked, cross your fingers I might be creating a way to unlock this phone and the stylo 6 and any mtk device that I can get my hands on
[Miscellaneous Android Development] superdragonpt:
Cool stuff

This is great to play with some locked fw i have in some devices here

Cheers
[Miscellaneous Android Development] dharyl2:
hello good day .. anyone can help me for this kind of error? my phone is realme 6i (mt6768)

thanks in advance
[Miscellaneous Android Development] Warlockguitarman:
Can some one make this script work on twrp on a rooted phone, I know it could be possible, considering checkra1n is made to jailbreak iphones from an android phone with twrp, that would make it so much easier for people to do this process for the stylo 6, I cannot for the life of me get the stylo 6 to connect to the mtkclient tool without using this tool first and it's not an easy task at that with the battery connected its impossible unless you use Linux. I can get it to connect by starting the process with the battery disconnected and connect it back and unplug the phone then plug it back in after closing the tools i used to disable the security
[Miscellaneous Android Development] Pachacouti:
View attachment 5275887To cure this, either remove battery, and connect device holding + vol, or wait until your fone drains... once it's dead (no power) this will cure itself automatically.
[Miscellaneous Android Development] Tooniis:
your device is probably booted into the preloader. it needs to boot into BROM for bypass_utility. Try a different button combination, or not pressing any button when plugging it in.
[Miscellaneous Android Development] luridphantom:
anyone know how to put motorola mtk phones into brom mode? like moto c/c plus/e6s/e6s plus, etc
[Miscellaneous Android Development] QAD3110:
[2021-10-04 23:33:35.401010] Waiting for device

[2021-10-04 23:33:45.883756] Found device = 0e8d:0003

[2021-10-04 23:33:46.151368] Device hw code: 0x717

[2021-10-04 23:33:46.151368] Device hw sub code: 0x8a00

[2021-10-04 23:33:46.152380] Device hw version: 0xca01

[2021-10-04 23:33:46.152380] Device sw version: 0x200

[2021-10-04 23:33:46.153379] Device secure boot: True

[2021-10-04 23:33:46.153379] Device serial link authorization: False

[2021-10-04 23:33:46.154378] Device download agent authorization: False

[2021-10-04 23:33:46.154378] Disabling watchdog timer

[2021-10-04 23:33:46.156532] Insecure device, sending payload using send_da

[2021-10-04 23:33:46.196072] Found send_dword, dumping bootrom to bootrom_717.bin

Someone please help me. my lenovo m7 TB-7306x not working. flash using sp flash tool got verified boot error (lenovocust.img). try other tools like mtk authbypass tool, bypass utilty and fastboot flash also didnt work. when i switched on device automatically to fastboot mode. please help me anyone.
[Miscellaneous Android Development] Warlockguitarman:
Try the mtkclient
[Miscellaneous Android Development] etmatrix:
I tested this tool on a nokia device but doesn't work, I tested with mtkclient works very well.

With mtkclient sp flash tool is useless and we can do many operations from command line.

Can I find the password for decrypt/encrypt records in nvdata or nvram?

I don't understand if mtkclient or mtk-bypass are useful for this scope.
[Miscellaneous Android Development] etmatrix:
I had the same issue and with mtkclient I solved it, as suggested by @Warlockguitarman
[Miscellaneous Android Development] luridphantom:
i wouldnt say sp flash tool is completely useless yet, there are some phone models especially from motorola that mtkclient cant access but sp flash tool can
[Miscellaneous Android Development] etmatrix:
sure if the device is not completely supported sp flash tool is still useful, but when the device is supported is useless for me. I stopped to use it, for me is more easy mtkclient. I don't need find the scatter file, for nokia device it need of a custom DA.
[Miscellaneous Android Development] luridphantom:
yea unfortunately some manufacturers wised up and hid Brom mode behind test points and stuff

I do like how mtkclient makes wwr.mtk obsolete now
[Miscellaneous Android Development] Warlockguitarman:
Yea the brom on the stylo 6 isn't very easy to get connected to, but once you do the mtkclient unlocks the bootloader, I unlocked the stylo 6 about 4 to 5 months ago with chimera, and right now I'm having troubles getting it updated to android 12, I flashed both slots with android 11 and it works flawlessly but when I select dsu it doesn't install properly, being in probably the only person running 11 on the stylo 6 I don't know where to turn to try to get 12 to work