MTK-bypass / bypass_utility

MIT License
460 stars 114 forks source link

mt6853 test failed #26

Closed DeclanShao closed 3 years ago

DeclanShao commented 3 years ago
[2021-04-08 16:42:12.089461] Waiting for device
[2021-04-08 16:42:49.975887] Found port = COM11
[2021-04-08 16:43:53.670724] Waiting for device
[2021-04-08 16:43:57.472503] Found port = COM11
[2021-04-08 16:44:21.098240] Waiting for device
[2021-04-08 16:44:30.329271] Found port = COM11
[2021-04-08 16:44:30.413203] Can't find 0x996 hw_code in config
[2021-04-08 16:44:30.417193] Device hw code: 0x996
[2021-04-08 16:44:30.418191] Device hw sub code: 0x8a00
[2021-04-08 16:44:30.419188] Device hw version: 0xca00
[2021-04-08 16:44:30.420253] Device sw version: 0x0
[2021-04-08 16:44:30.421239] Device secure boot: True
[2021-04-08 16:44:30.422236] Device serial link authorization: False
[2021-04-08 16:44:30.423459] Device download agent authorization: True
[2021-04-08 16:44:30.425444] Disabling watchdog timer
[2021-04-08 16:44:30.427438] Disabling protection
DeclanShao commented 3 years ago
[2021-04-08 17:25:36.227571] Test mode, testing 0xc1...
[2021-04-08 17:25:36.228415] Waiting for device
[2021-04-08 17:25:43.707057] Found port = COM11
[Errno None] b'libusb0-dll:err [control_msg] sending control message failed, win error: \xc1\xac\xb5\xbd\xcf\xb5\xcd\xb3\xc9\xcf\xb5\xc4\xc9\xe8\xb1\xb8\xc3\xbb\xd3\xd0\xb7\xa2\xbb\xd3\xd7\xf7\xd3\xc3\xa1\xa3\r\n\n'
I only tested to 0xc1.
DeclanShao commented 3 years ago
[2021-04-08 19:05:55.730769] Test mode, testing 0x116...
[2021-04-08 19:05:55.731606] Waiting for device
[2021-04-08 19:06:01.951979] Found port = COM11
[Errno None] b'libusb0-dll:err [control_msg] sending control message failed, win error: \xc1\xac\xb5\xbd\xcf\xb5\xcd\xb3\xc9\xcf\xb5\xc4\xc9\xe8\xb1\xb8\xc3\xbb\xd3\xd0\xb7\xa2\xbb\xd3\xd7\xf7\xd3\xc3\xa1\xa3\r\n\n'
DeclanShao commented 3 years ago

Hello,developer. How to get the correct payload_address?

DeclanShao commented 3 years ago

Now, I have tested to 0x300,but still did not get the bootrom file. Excuse me, do I still need to continue testing?

chaosmaster commented 3 years ago

It's unlikely that the var_1 is larger then 0x300. It's also possible the device uses a different payload_address or that the vulnerability has been patched. You can also try running the utility on a patched Linux instead of windows.

DeclanShao commented 3 years ago

It's unlikely that the var_1 is larger then 0x300. It's also possible the device uses a different payload_address or that the vulnerability has been patched. You can also try running the utility on a patched Linux instead of windows.

Ok, thank you,when i have time, i will try test. Sorry, I have another question,How to get the correct payload_address?

chaosmaster commented 3 years ago

Without already having a bootrom-dump you can only guess or try the known values from other devices.

LDGZS-LX commented 3 years ago

var_1不可能比0x300大。 该设备还可能使用其他有效负载地址或漏洞已被修补。 您也可以尝试在修补的Linux而不是Windows上运行该实用程序。

好的,谢谢,我有时间的时候,我会尝试测试。 抱歉,我还有一个问题,如何获取正确的有效载荷地址?

兄弟我也在研究,你情况如何,方便留个联系方式吗

DeclanShao commented 3 years ago

var_1不可能比0x300大。 该设备还可能使用其他有效负载地址或漏洞已被修补。 您也可以尝试在修补的Linux而不是Windows上运行该实用程序。

好的,谢谢,我有时间的时候,我会尝试测试。 抱歉,我还有一个问题,如何获取正确的有效载荷地址?

兄弟我也在研究,你情况如何,方便留个联系方式吗

不行,测试不了,按这个作者的说法,是可能漏洞修复,也可能是payload_address不同,但这个payload_address,没有规律,压根不知道要递增或者递减多少去测试,一个个试也太难了。payload_address不确定,var_1不确定,我不知道怎么搞,我感觉可以寄托希望于天玑720 ,都是mt6853,应该通用。

chaosmaster commented 3 years ago

Duplicate of #14