search

bkerler / mtkclient

MTK reverse engineering and flash tool
GNU General Public License v3.0
2.64k stars 522 forks source link

Crash at kamakiri2 Stage #392

Closed azwhikaru closed 2 years ago

azwhikaru commented 2 years ago

Can't work on mt8168, seems its a newer and rarer one. . . Still I hope we can find something in these logs and my preloader.bin. . .?

log_debugmode.txt log.txt preloader.zip

bkerler commented 2 years ago

It should work using Linux. Windows is currently broken.

azwhikaru commented 2 years ago

I tried to run it again in the Ubuntu you provided, but I got the same results as in Windows.

20220609201206

During the attempt to dump brom using mtk brute, it always tells me we are "testing", but after quite a while still no results appear, it seems to be stuck in a loop?

log.txt

bkerler commented 2 years ago

If it's stuck while bruteforcing just disconnect usb and reconnect in brom mode until it successfully dumps the brom

azwhikaru commented 2 years ago

I added the --debugmode tag, ran brute again, and when it tells me "Timed out" somewhere, I unplug the usb and reconnect.

This way, it does continue to run for a while, but it still ends up in a loop.

When we finished testing 0xfffc, I unplugged the usb and reconnected as prompted, but when I reconnected, it was still re-running the last test, still asking me to reconnect the usb after testing 0xfffc, and has been stuck in this loop ever since.

log.txt

azwhikaru commented 2 years ago

I think this is a problem with any mt8168 platform, I checked all issues about mt8168 and it seems that have the same problem in your mtkclient and chaosmaster's mtk-bypass (I think some part of it is also used for mtkclient?), that dump brom never succeeded.

mouseos commented 2 years ago

The same problem occurs on my tab-a05-bd with mt8168. What device are you using? If it is not the same model, this is an issue with the mt8168.

azwhikaru commented 2 years ago

I have checked your issue and it seems we are getting the same error, so I guess this is a bug that would happen with any mt8168 :-(

My device is a smart speaker made by Xiaomi and it runs Android P.

XMing673 commented 2 years ago

It`s a Mi smarthome screen with mt8168.

mouseos commented 2 years ago

I knew it was an mt8168 problem, I rewrote the python program and modified it to try 0xfffc and beyond, but that didn't work either. It doesn't work from bootrom mode or preloader mode.

azwhikaru commented 2 years ago

Sadly, none of the current exploits seem to be able to attack it, any generic payload will not be accepted ;-(

bkerler commented 2 years ago

Does any of the devices have sbc disabled ?

bkerler commented 2 years ago

It also can be that kamakiri2 doesn't work. Using a patched kernel you could also try brute with kamakiri which should work fine unless the device has been patched.

azwhikaru commented 2 years ago

How to use kamakiri for brute testing? As far as we know, aonet-kamakiri/kamakiri is not working either, it still looks like the payload is not working.

XMing673 commented 2 years ago

SBC in the Xiaomi smarthome screen is enabled. These days I and my friend had use the kamakiri for testing, but it still doesn`t work

XMing673 commented 2 years ago

It seems that the payload.bin can`t be use in the progress

bkerler commented 2 years ago

As said above, it does work. But in order to see what is causing the issue, the device needs to have sbc disabled (no daa enabled). It doesn't make sense to just try using kamakiri because I haven't adapted it yet, for that I need a bootrom dump first.

bkerler commented 2 years ago

double of issue #262