Database Users

[R&D][QUALCOMM] Using QDL, EHostDL and DIAG interfaces & features

This thread is for the research, development and discussion of open source tools (initially Linux) to communicate with and utilize the various proprietary interfaces available on Qualcomm devices.
Initial development is centered around the MSM8660 and MSM8960 devices, but should be applicable to nearly any Qualcomm device which includes a modem and USB port. Older devices with a Serial port may also work. Components to be supported: DMSS Download Protocol (QDL mode), Streaming Download Protocol (EHostDL), and parts of other HDLC structured Qualcomm protocols.
An expanded description, examples, references, and test programs to follow shortly.
Goals
To provide a partial Open Source (Linux) replacement for QPST and QXDM
To enable the full recovery of various Android devices based on supported Qualcomm SoC's
To gain a better understanding of the underlying hardware in Qualcomm based Android devices
Change Log:
2013-01-06
Initial creation to consolidate OT discussions from other threads.
2013-01-07
Expanded description
Added external thread and web links
Added #QDL_Dev on IRC Freenode for open discussion
2013-01-28
Updated a few posts to correct prior mistakes.
Internal Thread Links
coming soon...
External Thread Links
[REF][R&D] MSM8960 Info, Architecture and Bootloader(s) http://forum.xda-developers.com/showthread.php?t=1856327
Lots of important information and Qualcomm PDF's. Should be considered required reading. By E:V:A
[REF][R&D] Building Bootloaders on Qualcomm Devices http://forum.xda-developers.com/showthread.php?t=1978703
By E:V:A
[DEV][REF] El Grande Partition Table Reference http://forum.xda-developers.com/showthread.php?t=1959445
The definitive resource for device partition information. By E:V:A
No JTAG [SOLVED][JTAG,BRICK]SHV-E160L Korean model http://forum.xda-developers.com/showthread.php?t=1914359
R&D for unbricking/fully recovering a SHV-E160L and various helpful utilities. By Darkspr1te
External Web Links
Code Aurora Forum https://www.codeaurora.org/
Home to various Open Source projects related to Qualcomm technologies.
Gobi https://www.codeaurora.org/contribute/projects/gobi/
A Code Aurora Forum project fueled by Qualcomm which serves as a reference for these protocol implementations.
AnyClub Blog http://www.anyclub.org/
A blog with limited yet specific information regarding Qualcomm MSM, MDM, QRD and related products. Can get technical at times and references closed source and proprietary files/programs.
Join us for live discussion in #QDL_DEV on IRC Freenode
Credits/Thanks:
E:V:A for various reference threads which both sparked my interest and fueled my initial research.
Darkspr1te for his involvement with initial and ongoing development.
Ralekdev for providing additional insight in to msm8960 PBL
.
Yarrimapirate for creation of JET (Jewel Evita Toolkit) which served as my first hands-on with QDL and led me down the path to here.
Fuses for his emmc_recover program, which gave me my first glimpse of using HDLC to communicate with a Qualcomm based phone. Also for his typically brief and discouraging posts, which in turn drives my desire to prove him wrong
Captain_Throwback for providing firmware zips, testing, and more bricked phones then anyone else I've met.
others whom I'll add as I think of them.

Knowledge Base
Definitions:
PBL = Primary Boot Loader
SBL = Secondary Boot Loader
RPM = Resource and Power Management
TZ = Trust Zone
HDLC = High-level Data Link Control
MSM = Mobile Station Modem
DMSS = Dual-Mode Subscriber Station
QDL = Qualcomm Download
QHSUSB_DLOAD = Qualcomm High Speed USB Download
EhostDL = Emergency Host Download
DCN = Document Control Number, used by Qualcomm to track their thousands of documents
Qualcomm has built in to their firmware multiple methods of communication with outside "hosts" (a computer connected to the phone). Each method serves a particular function. AT commands are used to communicate with the modem while it is "online" and their multiple diagnostic protocols communicate with the modem in "offline" mode. These diagnostic protocols use HDLC (both synchronous and asynchronous) for the framing. It is a low overhead frame/packet transport which includes a 16 bit CRC for error checking, originally used over serial connections to the phone. Today these protocols are still being used over USB. Under Linux a usb-serial connection can be established by the qcserial kernel module via a /dev/ttyUSB (ex: /dev/ttyUSB0, /dev/ttyUSB1)
HDLC: A brief overview.
The basic HDLC structure is:
Each field is a multiple of 8-bits (1 byte).
HDLC uses 0x7e for the header and flag. For AsyncHDLC the header is optional, but Qualcomm always uses it. Also, the flag of one HDLC frame is allowed to be used as the header of the next frame. It also uses 0x7d as an escape for occurrences of 0x7e and 0x7d. All escaping is done after calculating the CRC and is applied to both the packet and CRC.
The packet is further broken down in to:
The packet header consists of:
The command is a 1 byte (0x00) code that determines the layout of the packet.
The parameters vary by command and specify different command specific options and the size of any data being transferred.
The CRC is generated using the standard CRC-CCITT-16 generator polynomial of: f(x)=x^16+x^12+x^5+1
Google it for more info.
Examples:
NO-OP: 7e 06 4e 95 7e
ACK: 7e 02 6a d3 7e
Software Version Request: 7e 0c 14 3a 7e
Software Version Response: 7e 0d 0f 50 42 4c 5f 44 6c 6f 61 64 56 45 52 31 2e 30 37 41 7e
Full Documentation:
DMSS Download Protocol: DCN 80-39912-1 Revision E
Describes in detail the commands used with QHSUSB_DLOAD (both SBL and PBL)
Streaming Download Protocol: DCN 80-V5348-1 Revision J
Describes in detail the commands used with the Flash Programmer (MPRGxxxx.hex)
CDMA DMSS Serial Data: DCN 80-V1294-1 Revision YP
Describes in detail the basic commands used with the modem Diagnostic mode. This protocol supports a MASSIVE amount of extentions covered in numerous other specialized documents. There is no current plan to implement these extensions.
...more to follow...

SPECIAL NOTE ABOUT THE NEXT POST:
If you attempt to use the msimage.mbn,YOU MUST CREATE IT USING THE SAME VERSION (or newer) FIRMWARE ALREADY ON YOUR PHONE. I'm not 100% sure if this applies to older models, but at least with msm8960 and newer.
Why?
Because, in addition to checking the signature of the image, the PBL also checks the firmware version against an efuse value for rollback prevention. If the OEM enables this feature then an older firmware will cause an error and will jump back to the last successfully loaded version of QDL mode. (ie: pbl, sbl1, etc...) This behavior has been the cause of many bricks for HTC Evo 4g LTE (jewel) owners who try to downgrade their firmware via ruu or recovery (sorry captn).
The firmware images involved are:
sbl1, sbl2, sbl3, tz and rpm.

DMSS And Streaming Protocol Tool
UPDATE: Code updated as of 17-01-2013, post will update to follow new code soon - Darkspr1te
First POC, Thats Proof of concept , not piece of c**p.
The concept behind this came from Soul Shadow, who like me feel that in a world without walls and fences who need windows and gates.
The original script was pulled from some git/website i dont remember belonging to a person i only know as scotty (please step forward )
JCSullins over from rootzwiki went running with the script to give us this working concept.
What is it?
This script fire's HDLC encoded frames at the serial port, namely qcserial for a Qualcomm HS_USB QDLOAD device 05c6:9008
within these frames are commands for various functions with great names like Hello, and Open MI.
Here is a example frame
Code:
0x7e 0x0a 0x63 0x74 0x7e
0x7e start of frame
0x0a command (this one is with out data)
0x63 crc low bit
0x74 crc high bit
0x7e close of frame
HDLC is all well document around the net so i wont go over it too much just yet. the important part is knowing the commands, what they do and what the payload, if any is and how that's formatted.
Why Do We need it?
The QDLOAD and EDLOAD protocols allow further control over your device, possible debrick solutions too, thats why we are developing it, some have mentioned other possible benifits but to reduce the google crew sending eveyone here looking for off-s solution and this thread going off topic we are avoiding that.Please can you also avoid topics of that nature.
What About Windows
You already have QPST and QXDM, us poor linux users dont. I am sure cygwin can help you there, some code changes may be required.
Enough Already, Gimme
https://github.com/jcsullins/qdloader
How Do I use it?
First you need to get the hex file for your device, if it's a msm8660 then your need mrpg8660.hex, they are found elsewhere, links will be posted later but for now use the search
then you need to run hex2bin on the hex file to have mrpgXXXX.bin which you rename hex.bin
then you need your emmc payload, this normally would be xxxx_msimage.mbn which you rename hex2.bin
then perl qdload.pl while you device is plugged in, there will be some debug output showing first and second stage uploads.
It's Didnt work,my device is still bricked, Answer my PM dammit!!
As I mentioned , this is a proof of concept file for study and not really ment to be a oneclick solution. Feed back is most welcome but dont mail the developers with questions for debricking the device, this is a tool to study and develop.
I REPEAT, stay away from this tool if you are not already familiar with qualcomm boot procedures, emmc system and the like.
EDIT: We have Found the original author of the script which we based the above on.
Scotty Walker
https://github.com/tmzt/g2root-kmod/tree/master/scotty2/pbl
Credits to The Man for making his work public.

deleted

SouL Shadow said:
SPECIAL NOTE ABOUT THE NEXT POST:
If you attempt to use the msimage.mbn,YOU MUST CREATE IT USING THE SAME VERSION (or newer) FIRMWARE ALREADY ON YOUR PHONE. I'm not 100% sure if this applies to older models, but at least with msm8960 and newer.
Why?
Because, in addition to checking the signature of the image, the PBL also checks the firmware version against an efuse value for rollback prevention. If the OEM enables this feature then an older firmware will cause an error and will jump back to the last successfully loaded version of QDL mode. (ie: pbl, sbl1, etc...) This behavior has been the cause of many bricks for HTC Evo 4g LTE (jewel) owners who try to downgrade their firmware via ruu or recovery (sorry captn).
The firmware images involved are:
sbl1, sbl2, sbl3, tz and rpm.
Click to expand...
Click to collapse
I was on 1.73 firmware(older or stock) when i bricked my phone.so you mean i have create a mbn file from a device which has 1.73 firmware?
and also how do you check whether a particular mbn file belongs to particular firmware only?.please help me
i have these files which i uploaded.can you see if these can be used for this method.
also i got the same error as i got before after following the post#4 method.i will soon upload the log file to you
sorry for being a noob
thanks

saketh91 said:
I was on 1.73 firmware(older or stock) when i bricked my phone.so you mean i have create a mbn file from a device which has 1.73 firmware?
Click to expand...
Click to collapse
Yes. All you need is the image files from an update or ruu. Check your device's forum, I'm sure someone has posted full firmware zip's. Just grab the correct one and wait for instructions.
saketh91 said:
and also how do you check whether a particular mbn file belongs to particular firmware only?.please help me
i have these files which i uploaded.can you see if these can be used for this method.
Click to expand...
Click to collapse
The msimage.mbn is created from the firmware images (sbl1, sbl2, sbl3, tz, rpm) along with the partition information for that device.
Darkspr1te has been working on tools to create this file. Once he determines them to be ready, he will post them along with instructions on how to use them.
saketh91 said:
also i got the same error as i got before after following the post#4 method.i will soon upload the log file to you
sorry for being a noob
thanks
Click to expand...
Click to collapse
Thank you for your patience and support. I know it's been frustrating being without your phone for so long. We try to share information as soon as we learn it. But sometimes it takes longer than expected to develop ways to utilize our newly found knowledge.
-SLS-

Team Unlimited has (what I believe is) the stock RUU for the Evo 4g LTE for HBOOT 1.15, 1.15 and 2.09 here (EDIT: can't post links because I am a noob with under 10 posts)
Using QPST to flash MPRG8960.HEX and 8960_msimage.mbn it always fails on 'Sending Go Command 0x2A000000', which I think is the pbl authenticating sbl1? If you are right and find a way to insert the correctly signed files into the .mbn I owe you both a beer

SouL Shadow said:
Yes. All you need is the image files from an update or ruu. Check your device's forum, I'm sure someone has posted full firmware zip's. Just grab the correct one and wait for instructions.
The msimage.mbn is created from the firmware images (sbl1, sbl2, sbl3, tz, rpm) along with the partition information for that device.
Darkspr1te has been working on tools to create this file. Once he determines them to be ready, he will post them along with instructions on how to use them.
Thank you for your patience and support. I know it's been frustrating being without your phone for so long. We try to share information as soon as we learn it. But sometimes it takes longer than expected to develop ways to utilize our newly found knowledge.
-SLS-
Click to expand...
Click to collapse
thanks for the reply.i will definitely wait for you to come up with solution.I am just trying to help you by providing you with logs.I have full confidence in you.I will wait for sure.thanks for all the help.

withRandomPrecision said:
Team Unlimited has (what I believe is) the stock RUU for the Evo 4g LTE for HBOOT 1.15, 1.15 and 2.09 here (EDIT: can't post links because I am a noob with under 10 posts)
Using QPST to flash MPRG8960.HEX and 8960_msimage.mbn it always fails on 'Sending Go Command 0x2A000000', which I think is the pbl authenticating sbl1? If you are right and find a way to insert the correctly signed files into the .mbn I owe you both a beer
Click to expand...
Click to collapse
The files you refer to on Team Unlimited's site http://www.unlimited.io are the RUU's for the HTC Evo 4g LTE (jewel). For non-Htc ppl, an RUU is a windows executable that contains the full firmware and software for the given phone. Each RUU corresponds to a software release. Yes, the firmware images needed to create an msimage.mbn for jewel are contained in the RUU.
As for the mprg8960.hex:
The PBL does not perform OEM signature checking on the hex file. The hex file is built by Qualcomm before distributing the sources to the OEM's. It's sole function is to program blank or corrupted flash memory (nand, emmc, etc...) with the firmware bootloaders (sbl1, sbl2, sbl3, tz, rpm).
The address 0x2a000000 is where the mprg.hex is stored in memory. After upload the 'GO' command is used to transfer execution to the flash programmer (the hex file). The phone is supposed to acknowledge the 'GO' command before jumping to the new code. It appears that the 8960 firmware in use by HTC and Samsung has a bug and is not sending that acknowledgement. QPST waits for this acknowledgement before moving on to the next step. This is one of the reasons that prompted the creation of this thread, to develop an alternative to QPST.
Using the perl script posted above by Darkspr1te, other ppl have shown that the 'GO' command DOES transfer execution to the flash programmer and have used it to write the firmware (msimage.mbn) to emmc flash, but have not yet had success booting the loaded firmware. That is why I pointed out the need for the correct firmware version to be used to create the msimage.mbn.
-SLS-

SouL Shadow said:
Yes. All you need is the image files from an update or ruu. Check your device's forum, I'm sure someone has posted full firmware zip's. Just grab the correct one and wait for instructions.
-SLS-
Click to expand...
Click to collapse
i don't know exactly which firmware version which i was on before bricking my phone.but i definitely flashed a rooted sense rom. however i have all zips of the roms which i probably should have installed.also will this tool apply for every device(8960) even my at&t htc one x?

Great work!
SouL Shadow said:
The PBL does not perform OEM signature checking on the hex file.
Click to expand...
Click to collapse
How do you know this? (Other sources have claimed the opposite...)
...After upload the 'GO' command is used to transfer execution to the flash programmer (the hex file). The phone is supposed to acknowledge the 'GO' command before jumping to the new code. It appears that the 8960 firmware in use by HTC and Samsung has a bug and is not sending that acknowledgement. QPST waits for this acknowledgement before moving on to the next step.
Click to expand...
Click to collapse
a) This could be an effect of PBL signature check!
b) Even if not checked, they could easily have changed the acknowledgement string to anything else.
c) It could also be an effect of a blown Qfuse...
d) Are you saying that QPST is not connecting to your phone? (What QPST version are you using?)
Using the perl script posted above by Darkspr1te, other ppl have shown that the 'GO' command DOES transfer execution to the flash programmer and have used it to write the firmware (msimage.mbn) to emmc flash, ...
Click to expand...
Click to collapse
What other people? Do they even have the same phone?

E:V:A said:
Great work!
How do you know this? (Other sources have claimed the opposite...)
Click to expand...
Click to collapse
Qualcomm docs only mention verifying the hex, they say nothing about signature checking. For all we know it's simply verifying the uncorrupted download.
The hex is built by qualcomm and distributed with *other* files to the oem's/licensee's. It only needs to be changed when the actual hardware changes. The msimage.mbn is the oem specific component. There is no oem signature on the hex, however there may be a qualcomm signature or some kind of checksum to ensure it's a valid file.
E:V:A said:
a) This could be an effect of PBL signature check!
b) Even if not checked, they could easily have changed the acknowledgement string to anything else.
Click to expand...
Click to collapse
The acknowledgment does not contain any text. It's just a simple ACK reply.
E:V:A said:
c) It could also be an effect of a blown Qfuse...
d) Are you saying that QPST is not connecting to your phone? (What QPST version are you using?)
Click to expand...
Click to collapse
QPST hangs waiting for a response from the 8960 phones (htc evita, jewel, and sgs3), but other ppl (I don't know/remember who) using the above mentioned script have uploaded the hex and been able to communicate with the flash programmer. They were even able to upload the msimage.mbm. Although the .mbn used was probably the wrong build because after writing to emmc it did not boot in to the sbl. Either due to wrong files or older versions of firmware (causing a rollback error).
E:V:A said:
What other people? Do they even have the same phone?
Click to expand...
Click to collapse
This post: http://forum.xda-developers.com/showthread.php?p=36578082
Note the code part where it mentions 'openmulti' that command is only in the streaming download protocol which is used exclusively by the flash programmer.
EDIT 2013-01-28:
After a discussion with Ralekdev on IRC and reexamination of posted test results, it seems that the mprg8960.hex is NOT being executed. Will need to check the stored error code to see excatly why. Ralekdev was able to show me evidence of possible signature checking in the PBL. Again, we'll need to check the stored error code to confirm if that is the case. While this is a set back for msm8960 devices, it doesn't diminish the need for a full featured, open source, Linux replacement for QPST/QXDM.
-SLS-

SouL Shadow said:
Qualcomm docs only mention verifying the hex, they say nothing about signature checking. For all we know it's simply verifying the uncorrupted download.
Click to expand...
Click to collapse
Well, you should never trust Qualcomm documentation! By the time they write the documentation, there have been many changes.
Probably what you say is correct, but I'm not conviced since I haven't checked the code. It was a few months ago I was looking at this. Perhaps the HEX not checked for signature, since it's just the downloader. (But this doesn't make sense, since this would break the SecureBoot3 chain of trust.) But whatever is downloaded IS signature checked.
The acknowledgment does not contain any text. It's just a simple ACK reply.
Click to expand...
Click to collapse
Well, this is not how the Odin handshake looks like! There there is a short string, like "LOKE" / "ODIN" or something like that. (I don't remember it on top of my head.) So AFAIK, Odin is not working with these device, which would be an indication that they have changed the handshake. (What other kind of tools would the mobile operators use?)
QPST hangs waiting for a response from the 8960 phones (htc evita, jewel, and sgs3), but other ppl (I don't know/remember who) using the above mentioned script have uploaded the hex and been able to communicate with the flash programmer. They were even able to upload the msimage.mbm. Although the .mbn used was probably the wrong build because after writing to emmc it did not boot in to the sbl. Either due to wrong files or older versions of firmware (causing a rollback error).
Click to expand...
Click to collapse
Exactly.

Is it possible to access the bootloader output via USB UART for htc 8960 devices? Seems like this might be useful to get PBL/SBL output for a bricked device.

E:V:A said:
Well, you should never trust Qualcomm documentation! By the time they write the documentation, there have been many changes.
Probably what you say is correct, but I'm not conviced since I haven't checked the code. It was a few months ago I was looking at this. Perhaps the HEX not checked for signature, since it's just the downloader. (But this doesn't make sense, since this would break the SecureBoot3 chain of trust.) But whatever is downloaded IS signature checked.
Click to expand...
Click to collapse
Take a look at the creation date on the hex files in the source archive. They were created in November 2011. But that build is from a later date (I don't have it in front of me, but I think it's from april 2012). That source archive is directly from qualcomm. Why is that important? Because it shows that even with most changes to the source, the hex files don't need to be rebuilt. Besides, the flash programmer is fairly limited in what it can do. It's purpose is to rewrite the bootloaders to blank or corrupted nand/nor/emmc flash. Once written the phone will shut down and attempt to boot normally. Secure Boot only covers the boot process from power on to hardware initialization, security environment setup and finally loading appsbl. Everything after that is up to the oem to do whatever they choose. Although, interestingly enough, team unlimited was able to create a custom hboot (htc's appsbl) which will load normally even with signature checking...
E:V:A said:
Well, this is not how the Odin handshake looks like! There there is a short string, like "HELLO" / "ODIN" or something like that. (I don't remember it on top of my head.) So AFAIK, Odin is not working with these device, which would be an indication that they have changed the handshake. (What other kind of tools would the mobile operators use?)
Click to expand...
Click to collapse
I don't think we're in odin anymore toto!
PBL, the good bootloader of the east suddenly appears to tell us that someone dropped a brick on secure boot. Now all these little pdf's are singing, telling us to follow the HDLC road. Along the way we'll meet some interesting new people. There's QDL who lacks a brain. The Hex-man with no heart. And Streaming Download, a protocol in need of a little courage. Together we can follow the HDLC road to reach the great wizard of qualcomm and use the ruby .mbn file to return us to odin. That's when we'll awake to find Auntie ( a || h )boot and uncle recovery. Adb is there and fastboot and android too!
(don't ask, I don't know either ...)
And back in reality:
I've never used odin (in fact the first time I even heard of it was reading the Verizon SGS3 unlocking thread, which is how I discovered your thread, which lead me to here), but it's my understanding that it is a Samsung only feature that is integrated on the appsbl level, providing similar functionality to HTC's RUU mechanism. Although odin appears to be much more advanced. I've seen numerous samsung users with qualcomm hardware mention how they were stuck in qdl mode and no longer able to access odin to recover.
Now if you'll excuse me, I suddenly have the urge to listen to Dark Side of the Moon...
-SLS-

withRandomPrecision said:
Is it possible to access the bootloader output via USB UART for htc 8960 devices? Seems like this might be useful to get PBL/SBL output for a bricked device.
Click to expand...
Click to collapse
Sort of. Only JTAG can access full output. Error and other diagnostic info can be read from memory using the DMSS Download Protocol or through the DIAG interface.
Under Linux all communication is done via usb serial converter kernel module qcserial and device node /dev/ttyUSBn where n = your device number reported by the kernel dmesg. This goes for any modern qualcomm device using a usb port. Older products used a proprietary serial wiring (outlined in the DMSS Serial Data ICD document 80-V1294-1) to access these same protocols.
The pbl/sbl's all share the same qdl code base. They will transmit a "magic" string over usb, waiting only a programmed amount of time for a connection.
If you mount debugfs
Code:
mount -t debugfs none_debugfs /sys/kernel/debug
and load a kernel module usbmon
Code:
modprobe usbmon
then you can access raw usb streams, either per bus or for the entire computer. There's a raw text interface at /sys/kernel/debug/usb/usbmon
There's also raw binary interface through /dev/usbmon[N]
Also, see the kernel source docs:
<kernel source>/Documentation/usb/usbmon.txt
On a bricked phone qcserial will recognise the device and a ttyUSB will become available OR if sbl3 was successfully loaded usb mass storage will provide the enumerated emmc partitions (although using them is still a work in progress, I have an idea how to properly do it. Will post details once I can test it).
To utilize the qdl usb serial interface you need to use the DMMS Download Protocol outlined in document 80-39912-1 Revision E.
On a working phone there is a usb serial interface available as well. However the qcserial kernel module is not programmed with the oem's vid/pid, so it doesn't load. I've been able to connect to it via generic serial converter:
Code:
modprobe usbserial vender=0x<vid> product=<pid>
Then disconnect and reconnect the usb cable to the phone. dmesg will show the new ttyUSB device.
Unfortunately I haven't been able to actually do anything with it yet. On a working phone it should connect you to the modem which you can use AT commands to interact with. There is also an AT command to switch to DIAG mode. From DIAG more you would use the DMSS Serial Data protocol (doc 80-V1294-1 Revision YP), another HDLC based protocol, to interact.
I have a large number of doc's covering all the above mentioned items and much more (just over 100 pdf's). Unfortunately they are all watermarked with the actual username who had access. If someone has or can point me to a program that can remove said watermarks then I would happily share all of them.
-SLS-

SouL Shadow said:
... Unfortunately they are all watermarked with the actual username who had access. If someone has or can point me to a program that can remove said watermarks then I would happily share all of them.
Click to expand...
Click to collapse
Did you actually try to google that?
http://www.slideshare.net/linsu39/5-solutions-to-remove-pdf-watermark
http://download.cnet.com/We-PDF-Watermark-Remover/3000-18497_4-75593137.html
http://online2pdf.com/
http://www.freepdfconvert.com/#
http://foxyutils.com/splitpdf/

E:V:A said:
Did you actually try to google that?
http://www.slideshare.net/linsu39/5-solutions-to-remove-pdf-watermark
http://download.cnet.com/We-PDF-Watermark-Remover/3000-18497_4-75593137.html
http://online2pdf.com/
http://www.freepdfconvert.com/#
http://foxyutils.com/splitpdf/
Click to expand...
Click to collapse
Hah, yes I did. These pdf's are encrypted so most tools want a password to edit them. Looking for a Linux command line utility so I can strip about 100 pdf's. Found pdftk but it requires a password to work on encrypted pdf's. I was able to convert an encrypted pdf to a non-encrypted pdf using the pdftocairo tool... but that changes the raw pdf data so finding the watermark data is more difficult. Now I'm searching for a pdf editor since my linux distro didn't come with one. Unfortunately I've spent half my day off working on this when I could have been programming.
EDIT:
found qpdf on sourceforge!
qpdf + grep + sed = fully automated bash script to clean all the pdf's
EDIT2:
I now have a working script to remove the watermarks. Found a few bugs while cleaning my document archive. I will post it as soon as I can work them out.
-SLS-

E:V:A said:
Well, you should never trust Qualcomm documentation! By the time they write the documentation, there have been many changes.
Probably what you say is correct, but I'm not conviced since I haven't checked the code. It was a few months ago I was looking at this. Perhaps the HEX not checked for signature, since it's just the downloader. (But this doesn't make sense, since this would break the SecureBoot3 chain of trust.) But whatever is downloaded IS signature checked.
Well, this is not how the Odin handshake looks like! There there is a short string, like "LOKE" / "ODIN" or something like that. (I don't remember it on top of my head.) So AFAIK, Odin is not working with these device, which would be an indication that they have changed the handshake. (What other kind of tools would the mobile operators use?)
Exactly.
Click to expand...
Click to collapse
Absolutely correct. The download code itself has a mechanism to verify if it is valid. Some vendors check the download code before being executed if they are signed correctly, others leave the downloader as it is, but check the md5 signature within the downloader. However we managed to exploit the md5 verification to rewrite the msm7x bootloader to let us read full flash connected to radio. Not sure if they changed a lot regarding the msm89xx chipsets, but I'm going to have a look at that again, if needed. Regarding the flashing process, the flashed files are signed and checked for validity after uploading, rsa keys are in both amss and oemsbl.
Odin Protocol mainly belongs to samsung's own cpu/bootloader and has nothing to do with the qualcomm msm's/qsd's/qsc's.
What we speak of is the such called "QC Download Mode". Using the tty interface being in QC DM Mode you can just send the "3A" command to enter the "QC Download mode". For some mobiles, even if you have access to the radio download mode (qc) you cannot flash and repair the flash that belongs to the PDA part (most seen for those OMAP / MSM combinations). It's just because both cpu's use their own flash module for their firmware parts (means the flash isn't routed to both cpus, thus technically impossible).
WBR

Droid Ultra (possible Maxx) brick recovery

I want to post my findings here. It could be useful for developers playing with bootloaders, and for users who accidentally break their Droid.
DISCLAIMER: I am not responsible for any damage, caused to your phone, when you did something using information from this thread. Be extremely careful shorting any pins (and to do at YOUR OWN RISK)
There is two types of bricked device (by bricked I mean no fastboot available):
1. Device does not boot up, but responding to USB VIDID = 05c6:9008 = QHSUSB_DLOAD mode
This is qualcomm standard emergency download mode. This device become serial port (it is required drivers for Windows), and could be flashed with special protocol.
Attached is package which successfully recover Droid Ultra.
Once you see device with VIDID = 05c6:9008 = QHSUSB_DLOAD, you should run this command:
python qdload.py MPRG8960_MOTO.bin -ptf _ultra/partitions.txt
after this you should be able to use fastboot to flash desired official image back.
Tested on Windows, drivers for QHSUSB_DLOAD now included into package, serial port auto detection added, same command use. For both windows and linux you should have Python >= 2.6 installed, and PySerial installed.
2. Device not responding to USB, but start responding after battery disconnect (you need to disassemble your phone) as VIDID = 05c6:f006 = Qualcomm modem mode.
In most cases this mean that you has HARD bricked device. I still could not provide soft way to switch from this mode to QHSUSB_DLOAD mode, so currently with this situation you has only one possibility - is to find pin, which will force device to QHSUSB_DLOAD mode. For droid Ultra (and I believe Maxx) you could find this pin marked on picture attached. On my picture you could see, that I remove shield completely, but you could reach this pin by opening shield cup only. This is the shield near display connector. This pin should be grounded to force QHSUSB_DLOAD mode. Once you see device with VIDID = 05c6:9008 - STOP shorting pin to ground and follow unbrick 1 procedure.
If you not stopping SHORT ping to gound, you may have issues with uploading images in step 1 !!!
This both unbrick tested on Droid Ultra, but I assume it should work on Droid Maxx as well (I include _maxx folder with files for maxx).
Instruction to generate partitions.txt from working phone (Note you could have different name instead of mmcblk0):
1. adb shell dd if=/dev/block/mmcblk0 of=/sdcard/pt.bin bs=1024 count=10
2. adb pull /sdcard/pt.bin .
3. ./gpt_parser.py pt.bin > partitions.txt
Edit: Split package into 5 packages: 1. Image files for MAXX, 2 Image files for ULTRA, 3. Loader .bin for Motorola_8960 4. Window drivers for QHSUSB_DLOAD mode, 5. qdload.py script
qdload.py script updated to V1.2 with lot of usefull info printed.
move gpt_parser.py script to main post

VBlack said:
I want to post my findings here. It could be useful for developers playing with bootloaders, and for users who accidentally break their Droid.
DISCLAIMER: I am not responsible for any damage, caused to your phone, when you did something using information from this thread.
There is two types of bricked device (by bricked I mean no fastboot available):
1. Device does not boot up, but responding to USB VIDID = 05c6:9008 = QHSUSB_DLOAD mode
This is qualcomm standard emergency download mode. This device become serial port (it is required drivers for Windows), and could be flashed with special protocol.
Attached is package which successfully recover Droid Ultra.
Once you see device with VIDID = 05c6:9008 = QHSUSB_DLOAD, you should run this command:
python qdload.py MPRG8960.bin _ultra/partitions.txt
after this you should be able to use fastboot to flash desired official image back.
I didn't test it on Windows, but it could work, you just need to specify COM port, by additional parameter to qdload.py:
python qdload.py -tty COM10 MPRG8960.bin _ultra/partitions.txt
2. Device not responding to USB, but start responding after battery disconnect (you need to disassemble your phone) as VIDID = 05c6:f006 = Qualcomm modem mode.
In most cases this mean that you has HARD bricked device. I still could not provide soft way to switch from this mode to QHSUSB_DLOAD mode, so currently with this situation you has only one possibility - is to find pin, which will force device to QHSUSB_DLOAD mode. For droid Ultra (and I believe Maxx) you could find this pin marked on picture attached. On my picture you could see, that I remove shield completely, but you could reach this pin by opening shield cup only. This is the shield near display connector. This pin should be grounded to force QHSUSB_DLOAD mode. Once you see device with VIDID = 05c6:9008 - follow unbrick 1 procedure.
This both unbrick tested on Droid Ultra, but I assume it should work on Droid Maxx as well (I include _maxx folder with files for maxx).
Click to expand...
Click to collapse
WOW! Nice job, bud.
I would normally ask you to add a disclaimer to be extremely careful shorting any pins (and to do at YOUR OWN RISK), but anyone who needs to do this is already in a pickle, and their device useless.
Great work, impressive.

samwathegreat said:
WOW! Nice job, bud.
I would normally ask you to add a disclaimer to be extremely careful shorting any pins (and to do at YOUR OWN RISK), but anyone who needs to do this is already in a pickle, and their device useless.
Great work, impressive.
Click to expand...
Click to collapse
Done, I also add note about stop shorting this pin to ground once you get to QDL MODE, since it will cause eMMC instability, and may forbid to flash images.
Add: Package repacked with drivers for windows and updated version of qdload.py with windows serial port auto detection.

VBlack said:
I want to post my findings here. It could be useful for developers playing with bootloaders, and for users who accidentally break their Droid.
DISCLAIMER: I am not responsible for any damage, caused to your phone, when you did something using information from this thread. Be extremely careful shorting any pins (and to do at YOUR OWN RISK)
There is two types of bricked device (by bricked I mean no fastboot available):
1. Device does not boot up, but responding to USB VIDID = 05c6:9008 = QHSUSB_DLOAD mode
This is qualcomm standard emergency download mode. This device become serial port (it is required drivers for Windows), and could be flashed with special protocol.
Attached is package which successfully recover Droid Ultra.
Once you see device with VIDID = 05c6:9008 = QHSUSB_DLOAD, you should run this command:
python qdload.py MPRG8960.bin _ultra/partitions.txt
after this you should be able to use fastboot to flash desired official image back.
I didn't test it on Windows, but it could work, you just need to specify COM port, by additional parameter to qdload.py:
python qdload.py -tty COM10 MPRG8960.bin _ultra/partitions.txt
Tested on Windows, drivers for QHSUSB_DLOAD now included into package, serial port auto detection added, same command use. For both windows and linux you should have Python >= 2.6 installed, and PySerial installed.
2. Device not responding to USB, but start responding after battery disconnect (you need to disassemble your phone) as VIDID = 05c6:f006 = Qualcomm modem mode.
In most cases this mean that you has HARD bricked device. I still could not provide soft way to switch from this mode to QHSUSB_DLOAD mode, so currently with this situation you has only one possibility - is to find pin, which will force device to QHSUSB_DLOAD mode. For droid Ultra (and I believe Maxx) you could find this pin marked on picture attached. On my picture you could see, that I remove shield completely, but you could reach this pin by opening shield cup only. This is the shield near display connector. This pin should be grounded to force QHSUSB_DLOAD mode. Once you see device with VIDID = 05c6:9008 - STOP shorting pin to ground and follow unbrick 1 procedure.
If you not stopping SHORT ping to gound, you may have issues with uploading images in step 1 !!!
This both unbrick tested on Droid Ultra, but I assume it should work on Droid Maxx as well (I include _maxx folder with files for maxx).
Click to expand...
Click to collapse
This is great!! Mind if i add it here? With proper credits of course? Or quote you?
http://forum.xda-developers.com/moto-x/general/how-to-resurrecting-bricked-moto-x-t2629057

Sure, no problem, but you need your own set of files for moto x (could be obtained from fastboot oficial image), and partitions.txt.
partitions.txt you could obtain using following instruction from working phone:
1. adb shell dd if=/dev/block/mmcblk0 of=/sdcard/pt.bin bs=1024 count=10
2. adb pull /sdcard/pt.bin .
3. ./gpt_parser.py pt.bin > partitions.txt
Edit: gpt_parser moved to main post.

VBlack said:
I want to post my findings here. It could be useful for developers playing with bootloaders, and for users who accidentally break their Droid.
DISCLAIMER: I am not responsible for any damage, caused to your phone, when you did something using information from this thread. Be extremely careful shorting any pins (and to do at YOUR OWN RISK)
There is two types of bricked device (by bricked I mean no fastboot available):
1. Device does not boot up, but responding to USB VIDID = 05c6:9008 = QHSUSB_DLOAD mode
This is qualcomm standard emergency download mode. This device become serial port (it is required drivers for Windows), and could be flashed with special protocol.
Attached is package which successfully recover Droid Ultra.
Once you see device with VIDID = 05c6:9008 = QHSUSB_DLOAD, you should run this command:
python qdload.py MPRG8960.bin _ultra/partitions.txt
after this you should be able to use fastboot to flash desired official image back.
I didn't test it on Windows, but it could work, you just need to specify COM port, by additional parameter to qdload.py:
python qdload.py -tty COM10 MPRG8960.bin _ultra/partitions.txt
Tested on Windows, drivers for QHSUSB_DLOAD now included into package, serial port auto detection added, same command use. For both windows and linux you should have Python >= 2.6 installed, and PySerial installed.
2. Device not responding to USB, but start responding after battery disconnect (you need to disassemble your phone) as VIDID = 05c6:f006 = Qualcomm modem mode.
In most cases this mean that you has HARD bricked device. I still could not provide soft way to switch from this mode to QHSUSB_DLOAD mode, so currently with this situation you has only one possibility - is to find pin, which will force device to QHSUSB_DLOAD mode. For droid Ultra (and I believe Maxx) you could find this pin marked on picture attached. On my picture you could see, that I remove shield completely, but you could reach this pin by opening shield cup only. This is the shield near display connector. This pin should be grounded to force QHSUSB_DLOAD mode. Once you see device with VIDID = 05c6:9008 - STOP shorting pin to ground and follow unbrick 1 procedure.
If you not stopping SHORT ping to gound, you may have issues with uploading images in step 1 !!!
This both unbrick tested on Droid Ultra, but I assume it should work on Droid Maxx as well (I include _maxx folder with files for maxx).
Click to expand...
Click to collapse
this should be stickied for all of android. while i realize your methods were device specific, i'm guessing there are enough similarities in your situation that it can be applied globally.

640k said:
this should be stickied for all of android. while i realize your methods were device specific, i'm guessing there are enough similarities in your situation that it can be applied globally.
Click to expand...
Click to collapse
It is Qualcomm specific. Most of current Qualcomm chips has emergency download mode. the only problem is to have proper load file MPRG8960.bin is for 8960 chips family, and looks like Motorola specific (maybe I'm wrong). So for sure not all Android device could use this, but most Qualcomm device should be fine, you just need model specific set of files, which, for example, Motorola provides with fastboot flashable images.

good points and good observations. this thread definitely shouldn't get buried in a single (aging) device. there's good info here.

I don't know if it is a problem, but I used this script to try and unbrick my phone.
When running as #1 as you state above, there is a "finished with errors" after the script. So I looked at it and saw that "MPRG8960.bin" was going to be pushed to the phone and the next line states "File not found "MPRG8960.bin." Looking at the files, the file it was looking for was named "MPRG8960_MOTO.bin," so I changed it to the file it was looking for and it worked great.
I'm a noob when it comes to the guts of programming and utilities, but it's something I spotted and figured I would let you know.

This seems really promising for my bricked xt907...

HamBone625 said:
This seems really promising for my bricked xt907...
Click to expand...
Click to collapse
Op has no fix files for the M, they have never been leaked.

HamBone625 said:
This seems really promising for my bricked xt907...
Click to expand...
Click to collapse
Since XT907 use same Qualcomm chip MSM8960 - you could try to use this utility, but first you need to obtain partitions.txt from working XT907 according to instructions.
Files needed you could take from latest firmware package (sbl1.mbn, sbl2.mbn, sbl3.mbn, tz.mbn, rpm.mbn, emmc_appsboot.mbn is aboot.mbn)

MOTO X
Hi. Can somebody post the partitions.txt for the moto X? please
To get the partition.txt from a working moto X it has to be root?
thanks

When I execute the script on my Droid Mini, with their proper partitions txt file and the MBN files from the ULTRA, I got this:
QDLoad utility version 1.2 (c) VBlack 2014
Found TTY port: com64
Requesting Params...
Params:
Version: 8
Min version: 1
Max write size: 1536 (0x00000600)
Model: 144
Device size: Invalid or unrecognized Flash device, or Flash device progr
amming not supported by this implementation
Device type: Intel 28F400BX-TL or Intel 28F400BV-TL
Requesting SoftwareVersion...
Version: PBL_DloadVER2.0
Requesting SerialNumber...
Serial number: 00,00,48,03
Requesting HW Id...
HW Id: 00,00,48,03,e1,10,7e,00
Requesting PublicKey...
PublicKey: 39,c4,ee,3e,b5,be,eb,87,8e,2f,e3,b8,53,4d,14,6f,91,ca,fd,bb,94,2a,0d
,aa,d0,1e,b0,87,62,d4,b9,b8
Uploading file 'MPRG8960_MOTO.bin' to addr 0x2a000000...
Executing...
Found TTY port: com64
Sending MAGIC ...
QCOM fast download protocol targ:
Version: 7
Compatible version 2
Maximum block size 1024 (0x00000400)
Base address of Flash 0x00000000
Flash: eMMC
Window size: 30
Number of sectors: 128
First sector size: 2097152 (0x00200000)
Feature bits: 09
Sending secureMode...
Sending openMulti ...
LOG: Open multi failed, unknown error
ERROR: 0x00000007: Open multi failed, unknown error
Sending SBL Reset...
Done, with errors!!!

Where I can get the MBN files for a Droid Mini?

Hi, you could try to find it inside one of official (fastboot) package for empty flashing like in Ultra package. It fails in very strange place - I will look at it on Monday.
Sent from my XT1080 using Tapatalk

VBlack said:
Hi, you could try to find it inside one of official (fastboot) package for empty flashing like in Ultra package. It fails in very strange place - I will look at it on Monday.
Sent from my XT1080 using Tapatalk
Click to expand...
Click to collapse
I tried the MBN files from a 4.4 fastboot from an Ultra and from the Droid Mini too, but i'm getting this errors, I don't know what's wrong or what I'm doing worng.
My phone powers up and can enter to fastboot, but it fails to boot, when i use "fastboot reboot" it reboot to QHSUSB_DLOAD... but well, something is wrong,,,

HELP
When i do the third step yo obtain partitions.txt (./gpt_parser.py pt.bin > partitions.txt)
i got a message
can't create partitions.txt: Read-only file system
any help?

C:\droid_ultra>python qdload.py MPRG8960_MOTO.bin -ptf _ultra/partitions.txt
'python' is not recognized as an internal or external command,
operable program or batch file.

BUZZAPT said:
When i do the third step yo obtain partitions.txt (./gpt_parser.py pt.bin > partitions.txt)
i got a message
can't create partitions.txt: Read-only file system
any help?
Click to expand...
Click to collapse
You should execute it on PC in writable folder.
Sent from my XT1080 using Tapatalk

ReadBack Extractor mtk6260 - firmware backup utility for GT08, DZ09, GV08 and so on..

Link to the latest readback extractor thread
It is applying for mtk6260A watch phones as GT08, DZ09, GV08, T7, Iradish Y6, Q8, F8 and all variations
In short - if you intend to install in your smartwatch new firmwares, mods etc, before to initiate any flashing with the Flash Tool app (pushing that goddamn < Download > button) think twice, 'bove all better DO a backup for the original firmware, why so? because it's containing all original drivers hence you'll be able to recover 100% your watch in case of bricking.
How to:
First you have need of a full dump of your ROM. Assuming that you already got a Flash Tool 5.1308 and drivers, and you were at the point of flashing something (already chose the download agent and scatter file)
for instance let's say you have a DZ09 smartwatch:
1 - press < Readback > in upper menu and so < Add > in the middle menu
2 - click twice on the item appears in the main window, set name as ROM_DZ choose in browser the path and save
3 - set as Physical start address 0x00000000 and as Length 0x01000000 then ok
4 - press < Readback > in the middle menu wait 2 seconds and connect through USB your watch
5 - wait until the upload is complete (big green ring)
Now second stage:
1 - download the app I've built attached here (Readback Extractor mtk6260A 1.0.rar) and unzip it
2 - create a folder where you intend to keep in safe the original firmware and name it for instance DZ09-Orig
3 - do a copy of Readback Extractor mtk6260A 1.0.exe and place it inside the DZ09-Orig folder then click twice on it
4 - press <Load Readback file> and browse after the ROM_DZ file created before with the Flash Tool then open
5 - Wait about two minutes while the app will check bit by bit the integrity of your file
6 - If everything went ok and your file is healthy app will show " health 100% " so you can proceed to next step
7 - Press <Rebuild Firmware> and wait about 5 to 10 minutes (it has a progress counter there)
8 - When will appear the message " - ALL DONE!!!" close app and go back in the DZ09-Orig folder, now you'll find there 5 new files which are the original firmware kit ready to be flashed back in your phone anytime you want
AFTERWARDS READ ME story - Anywhere you search, there is no one to tell you explicitly how to extract from your mtk smartwatch the firmware kit
All says a halfmouth: Do a full < Readback > in Flash Tool, you'll do it being confident that from now on you say goodbye to any risk because you have A BACKUP hence you start flashing new firmwares. And the Big Brick is coming , you smile and get back to your < Readback > backup discovering that, sadly, you have a binary bulk at first sight good for nothing. It cannot be so useless, isn't it? after all it contains full dump of your ROM! I was in exactly the same situation, so 'cause I didn't find any answer I've started reverse engineering . . . and it worked, first I did it manually for guys being in the same situation, 've noticed that is a common issue so I had to choose how to help, simpler but dangerous (for you) way, to create a tutorial <how to> or the hard way (hard for me), to develop an app which will do all "cooking" automatically and I choose the second because in manually way there is a quite big "chance" to mess up with your primary bootloader which could get to a real tragedy - no modem - brickest brick you saw in your entire life

thanks
thank you very much!!! I was searching how to backup my firmware and I found this forum!! Thank you! Thank you! Thank you!

make video pls!!
hello, please make video how you backup dz09 smartwatch original firmware!! PLEASE!! Thank You!!!

flagerchika said:
thank you very much!!! I was searching how to backup my firmware and I found this forum!! Thank you! Thank you! Thank you!
Click to expand...
Click to collapse
Very wise decision to backUP your firmware! Let me know how things goes

gugesha said:
hello, please make video how you backup dz09 smartwatch original firmware!! PLEASE!! Thank You!!!
Click to expand...
Click to collapse
Unfortunately, my time is quite limited,follow the steps in tutorial, if anything is unclear ask here

Thank you Golem_ for this nice tut.
Unfortunately with my GT08 the FlashTool doesn't seem to start the Read Back process. I see the watch in device manager (COM4), installed the MTK VCOM drivers. I can even access the AT interface of the watch (when the watch is powered on).
The steps i tried to perform are..
1) power off the watch
2) start flash tool, start the Read Back
3) connect the watch via usb --> COM4 appears in device manager
4) flash tool detects watch on COM4 port
5) nothing further happens - Read Back won't start (not even after 1 hour of waiting)..
{
"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"
}
I've tried with FlashTool v5.1308.00.00 and even the latest v5.1524.00 from spflashtool.com. Same result..
any clues?

dominic1134 said:
Thank you Golem_ for this nice tut.
Unfortunately with my GT08 the FlashTool doesn't seem to start the Read Back process. I see the watch in device manager (COM4), installed the MTK VCOM drivers. I can even access the AT interface of the watch (when the watch is powered on).
The steps i tried to perform are..
1) power off the watch
2) start flash tool, start the Read Back
3) connect the watch via usb --> COM4 appears in device manager
4) flash tool detects watch on COM4 port
5) nothing further happens - Read Back won't start (not even after 1 hour of waiting)..
I've tried with FlashTool v5.1308.00.00 and even the latest v5.1524.00 from spflashtool.com. Same result..
any clues?
Click to expand...
Click to collapse
you have to load a scatter file from a compatible firmware (just for initialization, not for flashing)

Golem_ said:
you have to load a scatter file from a compatible firmware (just for initialization, not for flashing)
Click to expand...
Click to collapse
yep, loaded the scatter from the firmware over here http://www.needrom.com/download/gt08-mt6260a-2/

dominic1134 said:
yep, loaded the scatter from the firmware over here http://www.needrom.com/download/gt08-mt6260a-2/
Click to expand...
Click to collapse
still not working? that's weird!

Golem_ said:
still not working? that's weird!
Click to expand...
Click to collapse
yep it is kinda weird...

dominic1134 said:
yep it is kinda weird...
Click to expand...
Click to collapse
Try a RAM test (be aware, only RAM!), who knows, maybe your watch is on 64Mb

Golem_ said:
Try a RAM test (be aware, only RAM!), who knows, maybe your watch is on 64Mb
Click to expand...
Click to collapse
RAM test doesn't start either...
In the developer menu with #993646633# it says [MEM SIZE] 1299684 btw.
I can also set the UART settings, BAUD, etc.

dominic1134 said:
RAM test doesn't start either...
In the developer menu with #993646633# it says [MEM SIZE] 1299684 btw.
I can also set the UART settings, BAUD, etc.
Click to expand...
Click to collapse
Flash tool has to be set on Options / USB Download/Readback and BackUP and Restore on no action

Please does anyone have the stock ROM file for apro q18 smart watch

Unable to carry read back or memory test
Hi Golem,
Firstly please accept my appreciation for your indepth analysis and details that you have been sharing on forum..
I have been scratching since yesterday evening to do readback and install drivers , but am unable to do it succesfully. It I add drivers from device manager and then run the run back I get following error:
FLASHTOOL ERROR : S_BROM_CMD_STARTCMD_FAIL (2005)
[BROM] Can not pass bootrom start commabd! POssibly target power up too earlu.
[HINT]
Can you please help? I am scratching and trying various things - but I guess am missing something on the installation side... Tried installing with different versions including WIN XP Service pack2,3 etc. but no success... Same error when I run Memory test to check if indeed the drivers have installed..

vir25 said:
Hi Golem,
Firstly please accept my appreciation for your indepth analysis and details that you have been sharing on forum..
I have been scratching since yesterday evening to do readback and install drivers , but am unable to do it succesfully. It I add drivers from device manager and then run the run back I get following error:
FLASHTOOL ERROR : S_BROM_CMD_STARTCMD_FAIL (2005)
[BROM] Can not pass bootrom start commabd! POssibly target power up too earlu.
[HINT]
Can you please help? I am scratching and trying various things - but I guess am missing something on the installation side... Tried installing with different versions including WIN XP Service pack2,3 etc. but no success... Same error when I run Memory test to check if indeed the drivers have installed..
Click to expand...
Click to collapse
Most common mistakes are not turning off the watch before connect to usb and connecting at usb before to start a command in flash tool. If these are not the issue then go in options/backup and restore and set on no action
Use your money wisely, DO NOT WASTE IT buying from GEARBEST

Issue not resolved yet...
QUOTE=Golem_;67280709]Most common mistakes are not turning off the watch before connect to usb and connecting at usb before to start a command in flash tool. If these are not the issue then go in options/backup and restore and set on no action
Use your money wisely, DO NOT WASTE IT buying from GEARBEST[/QUOTE]
Thanks buddy.
Removed battery, tried again - changed USB cord - tried in different port - but still gives same error - Also changed setting to no action in Option-> Backup and Restore.... Few observations - on attaching cable the device manager shows device as Mediatek USB Port (Other drivers present being MTK USB PORT, MTK USB Modem Port, MTK USB debug port, USB Modem Driver. All with a COM port assigned. Then it tries to connect and gives this error.
When tried using download with scatter files and Download agent it again gives error - META ERROR - ERROR in BOOTROM COMMUNICATION.
Can you please help - I am thinking some issue with set-up or drivers... Your suggestion? Thanks!
---------- Post added at 09:54 AM ---------- Previous post was at 09:34 AM ----------
vir25 said:
QUOTE=Golem_;67280709]Most common mistakes are not turning off the watch before connect to usb and connecting at usb before to start a command in flash tool. If these are not the issue then go in options/backup and restore and set on no action
Use your money wisely, DO NOT WASTE IT buying from GEARBEST
Click to expand...
Click to collapse
Thanks buddy.
Removed battery, tried again - changed USB cord - tried in different port - but still gives same error - Also changed setting to no action in Option-> Backup and Restore.... Few observations - on attaching cable the device manager shows device as Mediatek USB Port (Other drivers present being MTK USB PORT, MTK USB Modem Port, MTK USB debug port, USB Modem Driver. All with a COM port assigned. Then it tries to connect and gives this error.
When tried using download with scatter files and Download agent it again gives error - META ERROR - ERROR in BOOTROM COMMUNICATION.
Can you please help - I am thinking some issue with set-up or drivers... Your suggestion? Thanks!
[/QUOTE]
Dear Golem - My Skype id is: viral.gosalia, can we skype chat?

vir25 said:
QUOTE=Golem_;67280709]Most common mistakes are not turning off the watch before connect to usb and connecting at usb before to start a command in flash tool. If these are not the issue then go in options/backup and restore and set on no action
Use your money wisely, DO NOT WASTE IT buying from GEARBEST
Click to expand...
Click to collapse
Thanks buddy.
Removed battery, tried again - changed USB cord - tried in different port - but still gives same error - Also changed setting to no action in Option-> Backup and Restore.... Few observations - on attaching cable the device manager shows device as Mediatek USB Port (Other drivers present being MTK USB PORT, MTK USB Modem Port, MTK USB debug port, USB Modem Driver. All with a COM port assigned. Then it tries to connect and gives this error.
When tried using download with scatter files and Download agent it again gives error - META ERROR - ERROR in BOOTROM COMMUNICATION.
Can you please help - I am thinking some issue with set-up or drivers... Your suggestion? Thanks!
---------- Post added at 09:54 AM ---------- Previous post was at 09:34 AM ----------
Thanks buddy.
Removed battery, tried again - changed USB cord - tried in different port - but still gives same error - Also changed setting to no action in Option-> Backup and Restore.... Few observations - on attaching cable the device manager shows device as Mediatek USB Port (Other drivers present being MTK USB PORT, MTK USB Modem Port, MTK USB debug port, USB Modem Driver. All with a COM port assigned. Then it tries to connect and gives this error.
When tried using download with scatter files and Download agent it again gives error - META ERROR - ERROR in BOOTROM COMMUNICATION.
Can you please help - I am thinking some issue with set-up or drivers... Your suggestion? Thanks!
[/QUOTE]
Dear Golem - My Skype id is: can we skype chat?[/QUOTE]
sent you a message in skype
Use your money wisely, DO NOT WASTE IT buying from GEARBEST

flashtool error
i get the same erro annyone pls help

looks like same problem as Dominic, flashtool just sits waiting. Any solutions
Any solutions not already tried, multiple ports, computers, baud rates cables mem test etc.
dominic1134 said:
RAM test doesn't start either...
In the developer menu with #993646633# it says [MEM SIZE] 1299684 btw.
I can also set the UART settings, BAUD, etc.
Click to expand...
Click to collapse

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