Database Users

Help needed in downloading .vxp file BACK from smartwatch Garett GT18 (GW01 clone).

Long story short, there's a .vxp clock face installed on my watch (not the default face, custom one, found somewhere on internet as known .zip trio: .vxp, .xml and .png). The watch is Garett GT18 (seems to be Ulefone GW01 clone - as hardware and firmware). The special thing about that clock face is that it supports date, battery level, steps, and day of week! The photo of face is here : https ://i.imgur.com/n5YPrcu.jpg (yes, I know it's a default face in GW01, but it wasn't on my GT18 it's custom one). I'm 100% sure the face was regular .vxp app, installed with Fundo Wear. The problem is, the face .zip file is completely lost due to hard disk failure. Took me 3 days in void to search for it but it was amongst many many pages about custom watch faces - so no luck there. First I tried to make a firmware dump - nothing on it. Later I found out the .vxp is probably stored in SPI internal flash disk - the same that is accessible when watch is connected to PC in "Mass storage mode". Unlucky, only user partition C: is visible, system partition D: is hidden. I later found here: https ://github.com/mandl/LinkIt_Assist_2502/blob/master/uploader.py that D: partiton may be accessed using serial modem AT commands. This leads to my final problem (the introduction is long and descriptive to avoid XY problem): how do I access said serial modem? (My os is Ubuntu Linux). When I enter Engineering mode on watch with *#993646633# code, I can access UART settings - when I set one of TST-PS config, PS confing, and TST-L1 config (I tried it separately) to "USB port 2", the watch connected with USB shows as "0e8d:0023 MediaTek Inc. S103" and two devices appear /dev/ttyACM0 and /dev/ttyACM1 (which are supposed to be serial modem and serial debug ports). But in any of these confings, the python script (modified to read directory only - by commenting out sendfile, createfile and deletefile) stops after displaying that "AT" command was sent (first step in code). Any help how to retrieve .vxd from internal flash disk or how to dump such disk would be appreciated. Profit - you're gonna have watch face with working date and weekday.
Best regards, Dawid Łękawski aka rud0lf.
Edit: I tried all the options, and with "PS config" set to "USB port" modem is visible as single "/dev/ttyACM0", under USB list as "0e8d:0003 MediaTek Inc. MT6227 phone" and responds on second command:
> send: AT+ESUO=3
> +CME ERROR: 100

I bricked my HD 8 2017 after downgrading from 5.6.4 to 5.6.0.1

Hi, i was happen to wander around the forum to find a method to root my HD 8 2017, and seems that my tablet has automatically update to the point where root is not possible (the current version was 5.6.4.0 build 636559820), therefore i tried to downgrade to 5.6.0.1,since the root method only covers the 636558520 build version, and after using adb sideload, i found out that the device has been totally bricked and can't be turned on, after a few googling. i've found the post about debricking, but requires me to short the TP28 circuit (which i don't know where it was after removing the cover), so i use amonet and it still didn't work, please help!!
--- and here is the log of the terminal:
[email protected]:~/Downloads/amonet$ sudo ./bootrom-step.sh
[2019-11-04 14:00:27.420553] Waiting for bootrom
[2019-11-04 14:00:43.250282] Found port = /dev/ttyACM0
[2019-11-04 14:00:43.287246] Handshake
* * * If you have a short attached, remove it now * * *
* * * Press Enter to continue * * *
b''
b'\x00\x01'
Traceback (most recent call last):
File "main.py", line 256, in <module>
main()
File "main.py", line 129, in main
load_payload(dev, "../brom-payload/build/payload.bin")
File "/home/lubuntu/Downloads/amonet/modules/load_payload.py", line 123, in load_payload
dev.write32(0x10007008, 0x1971) # low-level watchdog kick
File "/home/lubuntu/Downloads/amonet/modules/common.py", line 163, in write32
self.check(self.dev.read(2), b'\x00\x01') # arg check
File "/home/lubuntu/Downloads/amonet/modules/common.py", line 90, in check
raise RuntimeError("ERROR: Serial protocol mismatch")
RuntimeError: ERROR: Serial protocol mismatch

Dkhanh0412 said:
Hi, i was happen to wander around the forum to find a method to root my HD 8 2017, and seems that my tablet has automatically update to the point where root is not possible (the current version was 5.6.4.0 build 636559820), therefore i tried to downgrade to 5.6.0.1,since the root method only covers the 636558520 build version, and after using adb sideload, i found out that the device has been totally bricked and can't be turned on, after a few googling. i've found the post about debricking, but requires me to short the TP28 circuit (which i don't know where it was after removing the cover), so i use amonet and it still didn't work, please help!!
--- and here is the log of the terminal:
[email protected]:~/Downloads/amonet$ sudo ./bootrom-step.sh
[2019-11-04 14:00:27.420553] Waiting for bootrom
[2019-11-04 14:00:43.250282] Found port = /dev/ttyACM0
[2019-11-04 14:00:43.287246] Handshake
* * * If you have a short attached, remove it now * * *
* * * Press Enter to continue * * *
b''
b'\x00\x01'
Traceback (most recent call last):
File "main.py", line 256, in <module>
main()
File "main.py", line 129, in main
load_payload(dev, "../brom-payload/build/payload.bin")
File "/home/lubuntu/Downloads/amonet/modules/load_payload.py", line 123, in load_payload
dev.write32(0x10007008, 0x1971) # low-level watchdog kick
File "/home/lubuntu/Downloads/amonet/modules/common.py", line 163, in write32
self.check(self.dev.read(2), b'\x00\x01') # arg check
File "/home/lubuntu/Downloads/amonet/modules/common.py", line 90, in check
raise RuntimeError("ERROR: Serial protocol mismatch")
RuntimeError: ERROR: Serial protocol mismatch
Click to expand...
Click to collapse
Wow my PM
Please don't pm me for this things, create a thread as you done or ask in the UNBRICK thread.
So about your error..
Mean that you're in Preloader Mode instead of BootROM Mode:
Code:
RuntimeError: ERROR: Serial protocol mismatch
Be sure to have modemmanager disabled.
Try to short again, it can take a lot of tries (For me like 20+).
If still no, change the object that you're using to short.
If thse same, try other USB cable and other USB port (BETTER 2.0 instead 3.0).
If after try all the suggestions still the same error, do the process with the battery disconnected, that worked in most cases.
Cheers!

Rortiz2 said:
Wow my PM
Please don't pm me for this things, create a thread as you done or ask in the UNBRICK thread.
So about your error..
Mean that you're in Preloader Mode instead of BootROM Mode:
Code:
RuntimeError: ERROR: Serial protocol mismatch
Be sure to have modemmanager disabled.
Try to short again, it can take a lot of tries (For me like 20+).
If still no, change the object that you're using to short.
If thse same, try other USB cable and other USB port (BETTER 2.0 instead 3.0).
If after try all the suggestions still the same error, do the process with the battery disconnected, that worked in most cases.
Cheers!
Click to expand...
Click to collapse
Thanks for replying! But can you be more specific about the short process? since i don't know where is the CLK test point of the board, the original guide showed that it is near the the emmc, it would be nice if you can show me the image of where to short on the motherboard? And about the Preloader mode? So i have to use the brick-9820.sh to confirm the brick then proceed to bootrom-step.sh?

Dkhanh0412 said:
Thanks for replying! But can you be more specific about the short process? since i don't know where is the CLK test point of the board, the original guide showed that it is near the the emmc, it would be nice if you can show me the image of where to short on the motherboard? And about the Preloader mode? So i have to use the brick-9820.sh to confirm the brick then proceed to bootrom-step.sh?
Click to expand...
Click to collapse
No, you don't need to run any brick.sh since you already bricked but in the WRONG WAY, so you need to short TP28.
If you search a bit, you can find the TP28 image
https://imgur.com/9ThIUqK (The Light blue one) (thanks @<br />)
You need to short that point with something conductive as a paper clip or a little or a small cable with bare ends.
One end of the object you put in TP28 and the other in any place with metal that is on the motherboard (a screw for example).
At same moment that you're doing this the script should be executed and waiting for handshake the bootROM:
Code:
sudo ./bootrom-step.sh
After that short the point as described and connect the tablet into the computer AT SAME TIME. If all goes OK it will ask to remove the short. Remove it and press enter, the script will do the magic
If you still getting the Serial Protocol error, use my suggestions of my previous post.
That's all, a bit tricky but has solution
Cheers!

I
Rortiz2 said:
No, you don't need to run any brick.sh since you already bricked but in the WRONG WAY, so you need to short TP28.
If you search a bit, you can find the TP28 image
https://imgur.com/9ThIUqK (The Light blue one)
You need to short that point with something conductive as a paper clip or a little or a small cable with bare ends.
One end of the object you put in TP28 and the other in any place with metal that is on the motherboard (a screw for example).
At same moment that you're doing this the script should be executed and waiting for handshake the bootROM:
Code:
sudo ./bootrom-step.sh
After that short the point as described and connect the tablet into the computer AT SAME TIME. If all goes OK it will ask to remove the short. Remove it and press enter, the script will do the magic
If you still getting the Serial Protocol error, use my suggestions of my previous post.
That's all, a bit tricky but has solution
Cheers!
Click to expand...
Click to collapse
Again, thanks bro, you saved my day

Rortiz2 said:
No, you don't need to run any brick.sh since you already bricked but in the WRONG WAY, so you need to short TP28.
If you search a bit, you can find the TP28 image
https://imgur.com/9ThIUqK (The Light blue one) (thanks @<br />)
You need to short that point with something conductive as a paper clip or a little or a small cable with bare ends.
One end of the object you put in TP28 and the other in any place with metal that is on the motherboard (a screw for example).
At same moment that you're doing this the script should be executed and waiting for handshake the bootROM:
Code:
sudo ./bootrom-step.sh
After that short the point as described and connect the tablet into the computer AT SAME TIME. If all goes OK it will ask to remove the short. Remove it and press enter, the script will do the magic
If you still getting the Serial Protocol error, use my suggestions of my previous post.
That's all, a bit tricky but has solution
Cheers!
Click to expand...
Click to collapse
Seems like i've ran into some problems,i still get that same error after numerous times of shortening the circuit,
ModemManager disabled
USB 2.0 port used
A bare-ends wire used to short the circuit
But it still display the serial protocol mismatch error (
Here is the image: https://imgur.com/a/D4JTYhJ

Dkhanh0412 said:
Seems like i've ran into some problems,i still get that same error after numerous times of shortening the circuit,
ModemManager disabled
USB 2.0 port used
A bare-ends wire used to short the circuit
But it still display the serial protocol mismatch error (
Here is the image: https://imgur.com/a/D4JTYhJ
Click to expand...
Click to collapse
Disconnect the battery then.

Rortiz2 said:
No, you don't need to run any brick.sh since you already bricked but in the WRONG WAY, so you need to short TP28.
If you search a bit, you can find the TP28 image
https://imgur.com/9ThIUqK (The Light blue one) (thanks @<br />)
You need to short that point with something conductive as a paper clip or a little or a small cable with bare ends.
One end of the object you put in TP28 and the other in any place with metal that is on the motherboard (a screw for example).
At same moment that you're doing this the script should be executed and waiting for handshake the bootROM:
Code:
sudo ./bootrom-step.sh
After that short the point as described and connect the tablet into the computer AT SAME TIME. If all goes OK it will ask to remove the short. Remove it and press enter, the script will do the magic
If you still getting the Serial Protocol error, use my suggestions of my previous post.
That's all, a bit tricky but has solution
Cheers!
Click to expand...
Click to collapse
Rortiz2 said:
Disconnect the battery then.
Click to expand...
Click to collapse
Well the code did run, but after that nothing happens, i press the power button then the tablet plays a sound, but it still didn't boot up
here is the near end of the log:
[2019-11-05 16:01:19.097336] Force fastboot
[2019-11-05 16:01:19.406864] Flash preloader header
[4 / 4]
[4 / 4]
[2019-11-05 16:01:19.857129] Reboot

Dkhanh0412 said:
Seems like i've ran into some problems,i still get that same error after numerous times of shortening the circuit,
ModemManager disabled
USB 2.0 port used
A bare-ends wire used to short the circuit
But it still display the serial protocol mismatch error (
Here is the image: https://imgur.com/a/D4JTYhJ
Click to expand...
Click to collapse
Well i disconnect the battery and have successfully executed the bootrom-step.sh, and now it still remains bricked, for the first time, when i hold the power button, the tablet plays the start up sound but did not boot up, what should i do now!?

Rortiz2 said:
No, you don't need to run any brick.sh since you already bricked but in the WRONG WAY, so you need to short TP28.
If you search a bit, you can find the TP28 image
https://imgur.com/9ThIUqK (The Light blue one) (thanks @<br />)
You need to short that point with something conductive as a paper clip or a little or a small cable with bare ends.
One end of the object you put in TP28 and the other in any place with metal that is on the motherboard (a screw for example).
At same moment that you're doing this the script should be executed and waiting for handshake the bootROM:
Code:
sudo ./bootrom-step.sh
After that short the point as described and connect the tablet into the computer AT SAME TIME. If all goes OK it will ask to remove the short. Remove it and press enter, the script will do the magic
If you still getting the Serial Protocol error, use my suggestions of my previous post.
That's all, a bit tricky but has solution
Cheers!
Click to expand...
Click to collapse
Well since the method here is almost unusable, i was thinking of flashing the .bin file of my Fire using MiracleBox, maybe this could help with my problem: https://www.google.com/amp/s/ifindhub.com/flash-bin-firmware-files-mediatek-device.html/amp

Dkhanh0412 said:
Well since the method here is almost unusable, i was thinking of flashing the .bin file of my Fire using MiracleBox, maybe this could help with my problem: https://www.google.com/amp/s/ifindhub.com/flash-bin-firmware-files-mediatek-device.html/amp
Click to expand...
Click to collapse
Dude...
That box comunicates with Preloader which is patched on Amazon tablets.. If it were that easy we would have rooted this tablet many years ago.
About your problems, seems like a LCD cable problem. Unmount again the tablet and check all cables, specially the LCD one.
Cheers.

Rortiz2 said:
Dude...
That box comunicates with Preloader which is patched on Amazon tablets.. If it were that easy we would have rooted this tablet many years ago.
About your problems, seems like a LCD cable problem. Unmount again the tablet and check all cables, specially the LCD one.
Cheers.
Click to expand...
Click to collapse
Hmmm, i'll make sure to double check everything again to keep things intact, thanks a lot bro

Fire 8 HD 2018 boots into diagnostic mode only

I have been helping a friend to fix his Fire 8 HD 2018.
This device only boots into Diagnostic Mode with a table showing various values. Specifically
FATPSN = Invalid
Abnormal battery status = AUT
See attached image.
Any way out of this problem?
https://drive.google.com/file/d/1wrT31f-xhus-vtIP_BojSLgxv4mH4q41/view?usp=sharing
UPDATE: Problem solved. See Post #10.

I can't see the image

https://drive.google.com/file/d/1wrT31f-xhus-vtIP_BojSLgxv4mH4q41/view?usp=sharing
Hope this image works.

Just guessing, Abnormal Battery Status = AUT could mean Abnormal Upper Temperature. This is because temperature shows 310.
Any view?

I have swap the battery and the problem still persists.
It is unlikely that both the original and replaced batteries are faulty simultanously.
Thus I would deduce that either the battery checking sensor (if any) is faulty or the firmware is corrupted.
Interestingly, the replacement battery still continues to be charged up while this device is connected to a USB charger.

drdtyc said:
I have swap the battery and the problem still persists.
It is unlikely that both the original and replaced batteries are faulty simultanously.
Thus I would deduce that either the battery checking sensor (if any) is faulty or the firmware is corrupted.
Interestingly, the replacement battery still continues to be charged up while this device is connected to a USB charger.
Click to expand...
Click to collapse
How does the PC recognizes the tab while it's in that mode? (VID/PID).

Rortiz2 said:
How does the PC recognizes the tab while it's in that mode? (VID/PID).
Click to expand...
Click to collapse
Left the replacement battery to charge for a few hours.
Now battery status is back to normal. But the warning AUT still flashes as before. It can normal boot into this particular dignostic screen only as shown in the above attached image.
Powered it down and tried rebooting into fastboot mode. Voila! The tablet is now in fastboot mode waiting for further input from my computer.
I was thinking of flashing it with the latest FireOS 6.3.1.5 and then see how it goes. What adb command can I use? Is it "sudo adb sideload <image file name>"?
Please advise.

After playing with the device for awhile, here are my findings:
1. Press Power button to boot
It only boots into Diagnostic Mode (see image in Post#1)
2. Press Volume Up and Power buttons to boot
It boots into Recovery Mode and stay there for about 20 seconds.
Then automatically switches to Normal Boot.
Going back to the Diagnostic Mode screen (see image in Post #1)
3. Press Volume Up and Power buttons to boot
It boots into Fastboot Mode and stay there waiting indefinitely.
4. Tried to softbrick the device by following this thread by k4y0z for Fire karnak.
The terminal showed the following.
$ sudo ./bootrom-step.sh
[2020-06-15 10:55:09.828365] Waiting for bootrom
[2020-06-15 10:55:19.682090] Found port = /dev/ttyACM0
[2020-06-15 10:55:19.721626] Handshake
* * * If you have a short attached, remove it now * * *
* * * Press Enter to continue * * *
Traceback (most recent call last):
File "main.py", line 213, in <module>
main()
File "main.py", line 111, in main
load_payload(dev, "../brom-payload/build/payload.bin")
File "/amonet-karnak-v3.0.1/amonet/modules/load_payload.py", line 99, in load_payload
dev.write32(0x10007008, 0x1971) # low-level watchdog kick
File "/amonet-karnak-v3.0.1/amonet/modules/common.py", line 160, in write32
self.check(self.dev.read(2), b'\x00\x01') # arg check
File "/amonet-karnak-v3.0.1/amonet/modules/common.py", line 87, in check
raise RuntimeError("ERROR: Serial protocol mismatch")
RuntimeError: ERROR: Serial protocol mismatch
^Z
[2]+ Stopped sudo ./bootrom-step.sh
Click to expand...
Click to collapse
Is there anything to correct the Serial protocal mismatch above?
5. Tried to shorting contact and hard bricking the device by following this thread by k4y0z for Fire karnak.
The terminal showed the following.
$ sudo systemctl stop ModemManager
$ sudo systemctl disable ModemManager
$ sudo ./bootrom-step.sh
[2020-06-15 11:17:09.613717] Waiting for bootrom
[2020-06-15 11:17:47.845559] Found port = /dev/ttyACM3
[2020-06-15 11:17:47.846549] Handshake
^Z
[5]+ Stopped sudo ./bootrom-step.sh
Click to expand...
Click to collapse
Is there anything else I can try?
All suggestions are welcome.

Rortiz2 said:
How does the PC recognizes the tab while it's in that mode? (VID/PID).
Click to expand...
Click to collapse
I overlooked your question. Apologies!
I connected my Linux laptop to the device already booted up in Diagnostic Mode.
In a terminal on the laptop, lusbs showed the following:
$ lusbs
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 005: ID 05c8:022a Cheng Uei Precision Industry Co., Ltd (Foxlink) HP Webcam
Bus 001 Device 004: ID 0bda:b00b Realtek Semiconductor Corp. Bluetooth Radio
Bus 001 Device 003: ID 0bda:0177 Realtek Semiconductor Corp. USB2.0-CRW
Bus 001 Device 002: ID 046d:c52b Logitech, Inc. Unifying Receiver
Bus 001 Device 033: ID 1949:0230 Lab126, Inc. Fire
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Click to expand...
Click to collapse
I presume ID 1949:0230 Lab126, Inc. Fire is this Fire 8HD
What else I may try?

FINAL UPDATE:
Followed this thread to short the CLK contact and hard-brick the device after opening the back cover. The main trick is to use the sharp tips of a metallic tweezer to ensure the shorting is well performed. Otherwise, the script bootrom-step.sh simply stuck without further progress. Thus the bootloader of the device has been unlocked and TWRP has been installed successfully.
Now I have flashed Lineage OS 14.1 on this karnak device and it runs very smoothly. Problem solved in the end.

same problem on HD8(2017)
hello, I also meet this problem on my hd8 2017(we are not the same device ),my device stuck in diagnostic mode and the status shows AFT. I dont know how to boot to system .I have already tried adb reboot recovery and adb reboot system .but It didnt work .just reboot to diagnostic mode again!Have you solved the problem now?If you get a way ,please help me !thanks !:crying::crying:

[Deleted]

[Deleted]

Venvalur said:
Sorry for the extremely late reply. This "abnormal battery status" is normal, it's the same as the diags of the kindles, so you've lost money and time replacing your battery. Also, to keep this in the same reply, how did you or your friend got into diagnostics mode in the karnak? Because this firmware could be used to software downgrade kindles with OS 6.3.1.2+!!! No need to open the tab!!! Sadly no one asked you to extract the .bin of diags firmware, and I'm pretty sure you don't have it anymore. If you have any information please share, this is getting good.
Click to expand...
Click to collapse
Just noticed your comment to my old post.
That device which booted into diagnostics mode only was passed by a guy to me for fixing. I gathered he bought a lot of several pre-owned devices from eBay that also included this peculiar device. In the end, I could not boot it into FireOS. But I could unlock its bootloader, flash twrp recovery and installed LOS 14.1 on it. He was very happy about the somewhat unexpected outcome when I returned to him a fully working karnak running LOS 14.1. Needless to say, I did not extract the .bin of diags firmware. Sorry!

[EXPLOIT] [BOOTLOADER] Mediatek based LG K10 2017 M250 bootloader secure boot bypass.

Hello.
I managed to bypass secure boot on LG K10 M250E (should also work on other versions like M250 M250N etc.)
See https://github.com/arturkow2000/lgk10exploit
This repository contains LK exploit capable of booting unsigned system and tools for reading/writing from/to device.
For instructions check README.md in repository.

Hi and sorry for the inconvenience, I am happy that you finally managed to make this exploit to this device which unfortunately I no longer have. But can this exploit be ported to other devices or is it just for this device?

XRed_CubeX said:
Hi and sorry for the inconvenience, I am happy that you finally managed to make this exploit to this device which unfortunately I no longer have. But can this exploit be ported to other devices or is it just for this device?
Click to expand...
Click to collapse
Exploit is only for this device.
However this repository also contains tools that can aid in creating exploits for other Mediatek based devices and tools that can read/write device memory, these should work most mt6755 devices as long as they can bypass preloader/bootrom security.
If you have any MT6755/MT6750 (should also work for MT6795/MT6797) device you can try using these tools as replacement for SP Flash Tool.

OficerX said:
Exploit is only for this device.
However this repository also contains tools that can aid in creating exploits for other Mediatek based devices and tools that can read/write device memory, these should work most mt6755 devices as long as they can bypass preloader/bootrom security.
If you have any MT6755/MT6750 (should also work for MT6795/MT6797) device you can try using these tools as replacement for SP Flash Tool.
Click to expand...
Click to collapse
I can flash partitions only in preloader mode with SP flash tool or with root with Android, however my problem is on an MT6737, which also has fastboot but not an unlockable bootloader and I would like to try to port it

See these:
https://github.com/xyzz/amonet
https://github.com/amonet-kamakiri/kamakiri
https://forum.xda-developers.com/hd...fire-hd-8-2018-downgrade-unlock-root-t3894256
And these leeks:
https://gitlab.com/mt6797/vendor
https://gitlab.com/MT6795/vendor
Exploit works by crafting boot image that on load overrides LK data with payload, it works because mboot_android_load_bootimg does not check if it overlaps.
https://gitlab.com/MT6795/vendor/-/...otloader/lk/platform/mt6795/load_image.c#L811
Probably your device is vulnerable in same way.
See here how to craft boot image
https://github.com/arturkow2000/lgk10exploit/blob/master/microloader/inject_microloader_nougat.py
and here
https://github.com/amonet-kamakiri/kamakiri/blob/master/microloader/inject_microloader.py
At the beginning you could set inject_addr to some invalid address like 0x0 or 0xFFFFFFFF to trigger crash, LK will print all registers and stack pointer.
Do you have access to UART or some other way to get logs from crashed LK?

OficerX said:
See these:
https://github.com/xyzz/amonet
https://github.com/amonet-kamakiri/kamakiri
https://forum.xda-developers.com/hd...fire-hd-8-2018-downgrade-unlock-root-t3894256
And these leeks:
https://gitlab.com/mt6797/vendor
https://gitlab.com/MT6795/vendor
Exploit works by crafting boot image that on load overrides LK data with payload, it works because mboot_android_load_bootimg does not check if it overlaps.
https://gitlab.com/MT6795/vendor/-/...otloader/lk/platform/mt6795/load_image.c#L811
Probably your device is vulnerable in same way.
See here how to craft boot image
https://github.com/arturkow2000/lgk10exploit/blob/master/microloader/inject_microloader_nougat.py
and here
https://github.com/amonet-kamakiri/kamakiri/blob/master/microloader/inject_microloader.py
At the beginning you could set inject_addr to some invalid address like 0x0 or 0xFFFFFFFF to trigger crash, LK will print all registers and stack pointer.
Do you have access to UART or some other way to get logs from crashed LK?
Click to expand...
Click to collapse
No, because I don't know how to solder, if there is no alternative to the UART I first try on another device to see if I can solder well.

Some devices expose UART over USB, see this: https://wiki.postmarketos.org/wiki/Serial_debugging
it may help.
If not try crashing LK, your device after reboot may show logs.
In my device when LK crashes after reboot it enters DemiGod Crash Handler which shows all relevant information.
Alternatively you may try porting this:
https://github.com/arturkow2000/lgk...9bc63f1ad7e0a5f3aeba1d1/plib/__init__.py#L421
This does temporary unlock lasting till reboot but it will allow you to run tampered LK.
Then you can redirect dprintf() calls in exception handler to video_printf().
This temporary unlock method uses gcpu to bypass BootROM range checks (bootrom checks memory address/length you read/write).
And then writes two magic values:
0x3B6C243C at 0x102080
0xF843E0A at 0x00102084
This causes preloader to ignore EFUSE state and turn Secure Boot off.
See amonet thread I linked in previous post, @xyz` described there how to disable range checks.
Use this to dump BootROM https://github.com/arturkow2000/lgk...9bc63f1ad7e0a5f3aeba1d1/plib/__init__.py#L455

XRed_CubeX said:
No, because I don't know how to solder, if there is no alternative to the UART I first try on another device to see if I can solder well.
Click to expand...
Click to collapse
No soldering, just pressure. It depends the device of course...
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
http://cxzstuff.blogspot.com/2017/02/making-connections-ainol-crystal-dual.html

CXZa said:
No soldering, just pressure. It depends the device of course...
http://cxzstuff.blogspot.com/2017/02/making-connections-ainol-crystal-dual.html
Click to expand...
Click to collapse
No, forgive me but what is that? Pliers? How does it work?

XRed_CubeX said:
No, forgive me but what is that? Pliers? How does it work?
Click to expand...
Click to collapse
Yep. Pliers have rubber bands (not showing) to keep them closed holding those wires made out of copper paper clips. Visit the link to see bigger pics.

OficerX said:
Some devices expose UART over USB, see this: https://wiki.postmarketos.org/wiki/Serial_debugging
it may help.
If not try crashing LK, your device after reboot may show logs.
In my device when LK crashes after reboot it enters DemiGod Crash Handler which shows all relevant information.
Alternatively you may try porting this:
https://github.com/arturkow2000/lgk...9bc63f1ad7e0a5f3aeba1d1/plib/__init__.py#L421
This does temporary unlock lasting till reboot but it will allow you to run tampered LK.
Then you can redirect dprintf() calls in exception handler to video_printf().
This temporary unlock method uses gcpu to bypass BootROM range checks (bootrom checks memory address/length you read/write).
And then writes two magic values:
0x3B6C243C at 0x102080
0xF843E0A at 0x00102084
This causes preloader to ignore EFUSE state and turn Secure Boot off.
See amonet thread I linked in previous post, @xyz` described there how to disable range checks.
Use this to dump BootROM https://github.com/arturkow2000/lgk...9bc63f1ad7e0a5f3aeba1d1/plib/__init__.py#L455
Click to expand...
Click to collapse
OK, I managed to get the brom payload with the help of a friend of mine, however what do you mean by "Tampered LK"?
How can I modify this LK and boot it with this brom-payload?

XRed_CubeX said:
OK, I managed to get the brom payload with the help of a friend of mine, however what do you mean by "Tampered LK"?
How can I modify this LK and boot it with this brom-payload?
Click to expand...
Click to collapse
XRed_CubeX said:
OK, I managed to get the brom payload with the help of a friend of mine, however what do you mean by "Tampered LK"?
How can I modify this LK and boot it with this brom-payload?
Click to expand...
Click to collapse
https://drive.google.com/file/d/158G2a-xX_I3USwlIbxGw0mMUKsO_TaYU/view?usp=sharing
Use these strings to find video_printf
then look for references to "undefined abort, halting", "data abort", "prefetch abort", "unhandled syscall".
these are directly followed by call dprintf, change them to call video_printf
https://drive.google.com/file/d/1xCKjLaXFYoGimKmoeQojRtHRI9ZBhSGB/view?usp=sharing
Next call (here sub_4601C90C) is to function that dump registers and stack contents.
https://drive.google.com/file/d/1iLNVs-ntfjW33UhHWslRP8jSWWNPYS16/view?usp=sharing
Change all dprintf calls to video_printf.
Flash exploit and patched lk then reboot.
Your device should boot into directly into bootrom, then run unlock procedure, your device should resume booting and proceed to loading LK from.
Device after leaving bootrom should enter for a moment into preloader download, so before flashing anything you can use pl.py --identify command to check if SBC, SLA and DAA are all off to check if unlocking works.

OficerX said:
https://drive.google.com/file/d/158G2a-xX_I3USwlIbxGw0mMUKsO_TaYU/view?usp=sharing
Use these strings to find video_printf
then look for references to "undefined abort, halting", "data abort", "prefetch abort", "unhandled syscall".
these are directly followed by call dprintf, change them to call video_printf
https://drive.google.com/file/d/1xCKjLaXFYoGimKmoeQojRtHRI9ZBhSGB/view?usp=sharing
Next call (here sub_4601C90C) is to function that dump registers and stack contents.
https://drive.google.com/file/d/1iLNVs-ntfjW33UhHWslRP8jSWWNPYS16/view?usp=sharing
Change all dprintf calls to video_printf.
Flash exploit and patched lk then reboot.
Your device should boot into directly into bootrom, then run unlock procedure, your device should resume booting and proceed to loading LK from.
Device after leaving bootrom should enter for a moment into preloader download, so before flashing anything you can use pl.py --identify command to check if SBC, SLA and DAA are all off to check if unlocking works.
Click to expand...
Click to collapse
Correct me if I'm wrong but the addresses to change the secure boot are the same right?

OficerX said:
https://drive.google.com/file/d/158G2a-xX_I3USwlIbxGw0mMUKsO_TaYU/view?usp=sharing
Use these strings to find video_printf
then look for references to "undefined abort, halting", "data abort", "prefetch abort", "unhandled syscall".
these are directly followed by call dprintf, change them to call video_printf
https://drive.google.com/file/d/1xCKjLaXFYoGimKmoeQojRtHRI9ZBhSGB/view?usp=sharing
Next call (here sub_4601C90C) is to function that dump registers and stack contents.
https://drive.google.com/file/d/1iLNVs-ntfjW33UhHWslRP8jSWWNPYS16/view?usp=sharing
Change all dprintf calls to video_printf.
Flash exploit and patched lk then reboot.
Your device should boot into directly into bootrom, then run unlock procedure, your device should resume booting and proceed to loading LK from.
Device after leaving bootrom should enter for a moment into preloader download, so before flashing anything you can use pl.py --identify command to check if SBC, SLA and DAA are all off to check if unlocking works.
Click to expand...
Click to collapse
Hey,
Could you check those links? The second and the last one aren't working and I'd like to see how the function that dumps registers looks like (as reference).
Thanks :good:

XRed_CubeX said:
Correct me if I'm wrong but the addresses to change the secure boot are the same right?
Click to expand...
Click to collapse
I'm 99% sure they are, I found this while reversing seclib from MT6535, it turned out these addresses are valid for my SOC, your SOC is very similar to my and MT6535, so I think should correct.
But you can find it by looking for reads from 0x10206060 (efuses).
See here
https://drive.google.com/file/d/19kqoLTT0nKR7vmf9AwwHOy6ihKjqEoNo/view?usp=sharing
As you can see it checks for these values and if they match it disables secure boot.
https://drive.google.com/file/d/19ITt5NV9EZggnFjfbUmf_cp5WCPBG_m_/view?usp=sharing
https://drive.google.com/file/d/1JeBjTOwTOjdjBTZkQmaP22edgZEKPiBE/view?usp=sharing
Rortiz2 said:
Hey,
Could you check those links? The second and the last one aren't working and I'd like to see how the function that dumps registers looks like (as reference).
Thanks :good:
Click to expand...
Click to collapse
Oops, forgot to set permissions, now it's working.

OficerX said:
I'm 99% sure they are, I found this while reversing seclib from MT6535, it turned out these addresses are valid for my SOC, your SOC is very similar to my and MT6535, so I think should correct.
But you can find it by looking for reads from 0x10206060 (efuses).
See here
https://drive.google.com/file/d/19kqoLTT0nKR7vmf9AwwHOy6ihKjqEoNo/view?usp=sharing
As you can see it checks for these values and if they match it disables secure boot.
https://drive.google.com/file/d/19ITt5NV9EZggnFjfbUmf_cp5WCPBG_m_/view?usp=sharing
https://drive.google.com/file/d/1JeBjTOwTOjdjBTZkQmaP22edgZEKPiBE/view?usp=sharing
Oops, forgot to set permissions, now it's working.
Click to expand...
Click to collapse
Thanks you!
BTW, secure boot addresses are different for mt8163:

OficerX said:
Some devices expose UART over USB, see this: https://wiki.postmarketos.org/wiki/Serial_debugging
it may help.
If not try crashing LK, your device after reboot may show logs.
In my device when LK crashes after reboot it enters DemiGod Crash Handler which shows all relevant information.
Alternatively you may try porting this:
https://github.com/arturkow2000/lgk...9bc63f1ad7e0a5f3aeba1d1/plib/__init__.py#L421
This does temporary unlock lasting till reboot but it will allow you to run tampered LK.
Then you can redirect dprintf() calls in exception handler to video_printf().
This temporary unlock method uses gcpu to bypass BootROM range checks (bootrom checks memory address/length you read/write).
And then writes two magic values:
0x3B6C243C at 0x102080
0xF843E0A at 0x00102084
This causes preloader to ignore EFUSE state and turn Secure Boot off.
See amonet thread I linked in previous post, @xyz` described there how to disable range checks.
Use this to dump BootROM https://github.com/arturkow2000/lgk...9bc63f1ad7e0a5f3aeba1d1/plib/__init__.py#L455
Click to expand...
Click to collapse
Hi, I think that the option to modify the LK and modify the printf will take some time for now because unfortunately I don't have the knowledge and skills in using such a powerful tool as ida pro, another option that I you had advised, the UART via micro USB, it is not the first time I hear it and once I have already tried to build a UART with a micro usb cable but unfortunately I have not obtained any logs from the devices and I think I have built it wrong , I'll probably get a pre-made one from a shopping site. A friend of mine advised me not to use the microusb cable because it "probably" doesn't get the logs from a crashed LK.
So I ask you that you are probably sure or you have tried it, but UART via microusb is a good option?
From fastboot if I do "fastboot oem p2u on", fastboot responds and confirms so I can be sure my device supports UART. If anything you have any tips or tutorials to build a uart cable correctly?
My UART adapter is a CP2102, okay?
(P.S: My micro usb connector doesn't have a wire ID, ONLY D+, D- and GND and VCC)
(P.S2o you have any tips or tutorials to disassemble the binary well in ARM)

XRed_CubeX said:
Hi, I think that the option to modify the LK and modify the printf will take some time for now because unfortunately I don't have the knowledge and skills in using such a powerful tool as ida pro, another option that I you had advised, the UART via micro USB, it is not the first time I hear it and once I have already tried to build a UART with a micro usb cable but unfortunately I have not obtained any logs from the devices and I think I have built it wrong , I'll probably get a pre-made one from a shopping site. A friend of mine advised me not to use the microusb cable because it "probably" doesn't get the logs from a crashed LK.
So I ask you that you are probably sure or you have tried it, but UART via microusb is a good option?
From fastboot if I do "fastboot oem p2u on", fastboot responds and confirms so I can be sure my device supports UART. If anything you have any tips or tutorials to build a uart cable correctly?
My UART adapter is a CP2102, okay?
(P.S: My micro usb connector doesn't have a wire ID, ONLY D+, D- and GND and VCC)
(P.S2o you have any tips or tutorials to disassemble the binary well in ARM)
Click to expand...
Click to collapse
On my device at first I was booting modified LK, it was very slow process, at one point I couldn't move further, I had working exploit running my payload but I couldn't make it boot Linux (later it turned out that it did not load DTB, I added call to bldr_load_dtb and it worked then), device was just hanging.
I updated to Oreo, LG added crash handler so I did'nt have to boot patched LK anymore and this significantly sped up everything.
I could'nt use UART because LG disabled it.
When device boots preloader checks whether proper cable is connected and either switches USB into UART or leaves it as it is, but in my case this feature was disabled at compile time.
You can check in linux source in usb phy driver code that performs mode switch and then check if preloader or LK has it.
P.S. Now I have partially working UART, I enable it in payload (see microloader/linuxboot), it works (TX voltage goes high to ~3.3V), but I cannot get output till Linux boots, I still need to figure it out.
This won't help you in making exploit but can help later during kernel development.
If you won't get UART working then I think that patching LK is all you have left.

OficerX said:
On my device at first I was booting modified LK, it was very slow process, at one point I couldn't move further, I had working exploit running my payload but I couldn't make it boot Linux (later it turned out that it did not load DTB, I added call to bldr_load_dtb and it worked then), device was just hanging.
I updated to Oreo, LG added crash handler so I did'nt have to boot patched LK anymore and this significantly sped up everything.
I could'nt use UART because LG disabled it.
When device boots preloader checks whether proper cable is connected and either switches USB into UART or leaves it as it is, but in my case this feature was disabled at compile time.
You can check in linux source in usb phy driver code that performs mode switch and then check if preloader or LK has it.
P.S. Now I have partially working UART, I enable it in payload (see microloader/linuxboot), it works (TX voltage goes high to ~3.3V), but I cannot get output till Linux boots, I still need to figure it out.
This won't help you in making exploit but can help later during kernel development.
If you won't get UART working then I think that patching LK is all you have left.
Click to expand...
Click to collapse
Maybe you need to patch the cmdline? I don't know, I'm just throwing some ideas.

Rortiz2 said:
Maybe you need to patch the cmdline? I don't know, I'm just throwing some ideas.
Click to expand...
Click to collapse
I already did that, UART works in Linux, it doesn't work in LK, it's enabled but there is no output, I need it to get working as early in boot process as possible to debug 64 bit kernel (for it's not booting at all)
My UART driver must faulty.
I turned in Linux most stuff related usb, gpio, clocks into no-op and UART is still working.
Right now i'm porting TWRP, but whem I finish it I will try again with uart.

Fire HD10 (2019) bricked itself

Hi,
A few days ago, my Fire HD10(2019) refused to power on, or rather it would show some life (amazon screen IIRC), but go no further. Now it doesn't even do that.
On a PC I can see whats its doing across USB. "Bus 002 Device 083: ID 0e8d:0003 MediaTek Inc. MT6227 phone" on usb for about 45 seconds, then it disconnects for maybe 20s, and then repeats. Now I take the 0e8d:0003 device to be the amazon bootloader - so looks to me like the bootloder works, but crashes hard and restarts as soon as it tries to start android. So looks like the box is bricked.
I've tried the various buttons to go into fastboot - no success. Neither "adb devices" nor "fastboot devices" can see the device. On first booting, the machine brings up a serial interface (USB ACM device), alas I've not been able to connect to this.
So what are my options of getting into the machine? If I can't access the bootloader via the serial interface, are there UART pins on the board? If so where? If I can access the bootloader, can I switch to fastboot mode, so I can reflash the android OS? Where is the best place to look for info like this?

davidsummers said:
Hi,
A few days ago, my Fire HD10(2019) refused to power on, or rather it would show some life (amazon screen IIRC), but go no further. Now it doesn't even do that.
On a PC I can see whats its doing across USB. "Bus 002 Device 083: ID 0e8d:0003 MediaTek Inc. MT6227 phone" on usb for about 45 seconds, then it disconnects for maybe 20s, and then repeats. Now I take the 0e8d:0003 device to be the amazon bootloader - so looks to me like the bootloder works, but crashes hard and restarts as soon as it tries to start android. So looks like the box is bricked.
I've tried the various buttons to go into fastboot - no success. Neither "adb devices" nor "fastboot devices" can see the device. On first booting, the machine brings up a serial interface (USB ACM device), alas I've not been able to connect to this.
So what are my options of getting into the machine? If I can't access the bootloader via the serial interface, are there UART pins on the board? If so where? If I can access the bootloader, can I switch to fastboot mode, so I can reflash the android OS? Where is the best place to look for info like this?
Click to expand...
Click to collapse
It is actually the mediatek bootrom (your device can have mtk-su temp root access, if you downgrade). You must have one of the early release ones that have access to it. My guess there is something wrong with the preloader... While i can't pin it down, the information to reload is all in this thread...
New Fire HD10 2019 Bootless Root Method + Bootloader Unlock Brainstorming
There's a new Fire 10 coming out, with an Octacore processor, USB-C charging, and FireOS based on Pie: https://arstechnica.com/gadgets/2019/10/amazons-new-fire-hd-10-tablet-costs-149-and-charges-via-usb-c/ I most certainly don't need any more...
forum.xda-developers.com

Yes it was an early device. Alas it connected to the web, and updated itself from 7.3.1.0 before I disabled most of the amazon processes. So the original mtk-su for 7.3.1.0 never worked on my machine. Alas can't use this any more - as can't get into android any more.
I'm up to page 30 of the thread you posted, alas nothing read so far has managed to get into the machine.

And first progress - bypass_utility version 1.4.2. can connect (when run as root) and gives:
[2023-01-22 14:32:12.028038] Waiting for device
[2023-01-22 14:32:39.691833] Found port = /dev/ttyACM0
[2023-01-22 14:32:40.083041] Device hw code: 0x788
[2023-01-22 14:32:40.083391] Device hw sub code: 0x8a00
[2023-01-22 14:32:40.083586] Device hw version: 0xca00
[2023-01-22 14:32:40.083770] Device sw version: 0x0
[2023-01-22 14:32:40.083959] Device secure boot: True
[2023-01-22 14:32:40.084143] Device serial link authorization: False
[2023-01-22 14:32:40.087904] Device download agent authorization: True
[2023-01-22 14:32:40.088223] Disabling watchdog timer
[2023-01-22 14:32:40.092031] Disabling protection
[Errno 5] Input/Output Error
[2023-01-22 14:32:41.464834] Payload did not reply

davidsummers said:
And first progress - bypass_utility version 1.4.2. can connect (when run as root) and gives:
[2023-01-22 14:32:12.028038] Waiting for device
[2023-01-22 14:32:39.691833] Found port = /dev/ttyACM0
[2023-01-22 14:32:40.083041] Device hw code: 0x788
[2023-01-22 14:32:40.083391] Device hw sub code: 0x8a00
[2023-01-22 14:32:40.083586] Device hw version: 0xca00
[2023-01-22 14:32:40.083770] Device sw version: 0x0
[2023-01-22 14:32:40.083959] Device secure boot: True
[2023-01-22 14:32:40.084143] Device serial link authorization: False
[2023-01-22 14:32:40.087904] Device download agent authorization: True
[2023-01-22 14:32:40.088223] Disabling watchdog timer
[2023-01-22 14:32:40.092031] Disabling protection
[Errno 5] Input/Output Error
[2023-01-22 14:32:41.464834] Payload did not reply
Click to expand...
Click to collapse
It has been a long time. Maybe try disconnecting the battery, not sure if it is staying in bootrom mode.... I remember mine had to have the battery removed or it would try to goto the preloader (i think). I used the process to downgrade back to 7.3.1.0, but it was like a year ago.

Michajin said:
It has been a long time. Maybe try disconnecting the battery, not sure if it is staying in bootrom mode.... I remember mine had to have the battery removed or it would try to goto the preloader (i think). I used the process to downgrade back to 7.3.1.0, but it was like a year ago.
Click to expand...
Click to collapse
Yes - mine stayed in 0e8d:0003 mode, when the device bricked itself - made no difference with battery on or off, always when through the same minute cycle, where the device would disconnect, then reboot.
Interesting after running the bypass utility - it has stayed up in the 0e8d:0003 mode - and hasn't rebooted.

davidsummers said:
Yes - mine stayed in 0e8d:0003 mode, when the device bricked itself - made no difference with battery on or off, always when through the same minute cycle, where the device would disconnect, then reboot.
Interesting after running the bypass utility - it has stayed up in the 0e8d:0003 mode - and hasn't rebooted.
Click to expand...
Click to collapse
it disabled the watchdog timer. From what is can see everything points to a potential wrong setup..
bypass_utility/README.md at master · MTK-bypass/bypass_utility
Contribute to MTK-bypass/bypass_utility development by creating an account on GitHub.
github.com

This post shows the same error as you read through it.
Payload did not reply · Issue #13 · MTK-bypass/exploits_collection
[Errno 5] Input/Output Error Payload did not reply
github.com

OK - using SP_Flash_Tool v5.2008 to attempt to flash maverick-downgrade-7.0_PR7310_940N and I get the error:
Connect BROM failed: STATUS_SEC_AUTH_FILE_NEEDED(-1073545198)
Disconnect!
BROM Exception! ( ERROR : STATUS_SEC_AUTH_FILE_NEEDED (-1073545198) , MSP ERROE CODE : 0x00.
[HINT]:
Please select a valid authentication file or ask for help.)((ConnectBROM,../../../flashtool/Conn/Connection.cpp,105))
So where do I get the authentication file from?

Michajin said:
it disabled the watchdog timer. From what is can see everything points to a potential wrong setup..
bypass_utility/README.md at master · MTK-bypass/bypass_utility
Contribute to MTK-bypass/bypass_utility development by creating an account on GitHub.
github.com
Click to expand...
Click to collapse
ah yes - that explains why it was rebooting. So guess I have to dig into [Errno 5] Input/Output Error.
Seems like only way I have into the tablet any more is the mediatek bootrom, but as the tablet is sick - if that doesn't work, then probably its permanently dead. E.g. even getting access to a uart wouldn't help.

You have to only do file by file.
5. bypass_utility run succes with message "Protection disabled"
6. Run SPFlash Tool and flash boot, recovery, vendor, system. Wait to finish
7. Hold power button 15s to power off (check Ports in Device Manager windows)
8. Hold volume up and power boot to recovery with triactangle icon
9. Hold power and tap volume up then choose reset factory
10. Reboot

Thanks Michajin - I'm obviously having problems with the bypass_utility, whilst it connects to the MediaTek bootrom, it is not able to disable protection - and test mode bombs out. I've taken this up on the bypass_utility thread:
xda bypass utility