Database Users

[Q] Root Exploit failed

Hey,
I tried several times to root my thinkpad tablet with the Thinkpad Tablet Root Exploit but only got "Exploit failed".
Unfortunately the thinkpadforums.com is currently down so I couldn't search for solutions.
The Tablet is connected to the PC and I can see the device in adb. It's also connected to a WIFI network.
I also tried to make a factory reset -> "Exploit failed"
I don't know what to do and hope you can help me.
Thanks
Trekky
Sorry forgot to download the needed Packages in SDK..works now

Trekky said:
Sorry forgot to download the needed Packages in SDK..works now
Click to expand...
Click to collapse
Could you elaborate on this? I'm also having trouble getting the exploit to work on my tablet, even after multiple tries and a factory reset... What exactly are the packages that you installed that helped?
Cheers,
-Alrua

alrua said:
Could you elaborate on this? I'm also having trouble getting the exploit to work on my tablet, even after multiple tries and a factory reset... What exactly are the packages that you installed that helped?
Cheers,
-Alrua
Click to expand...
Click to collapse
Hey,
because the thinkpadtabletforum was down I couldn't see the instructions for the Android SDK.
I forgot
Code:
3.3 At the end of the install chose to run the Android SDK Manager.
3.4 You will need the following package for the TPT:
-Android SDK Tools
[B]-Android 3.1 (API 12)[/B]
-Extras > Google USB Driver package
Check the status column for each and if is not installed select the check box beside the packages and click the Install Packages button.
3.5 If you get a Dependencies List select the Accept All radio button and click the Install button.
I hope this helps you.
Trekky

Don't believe what your c prompt says. I've heard a lot of folk saying theirs looked like it failed, but they have root access now. Check to see of you have access to your root directory with Root Explorer, ESFile Explorer, or another app that requires root. You also may need to download SU and Terminal from Market.

Hey,
I have the same problem. I started off with a factory reset.
I can see my device in adb. It is connected to a WIFI network, it is connected by USB, the screen is on, USB debugging is also switched on. I got all the needed packages in Android SDK [except the Google TV Addon which can be found under Android 3.1 --> it says: "Not compatible with Windows"]
Here is my log (just in case)
Code:
[*] Lenovo Thinkpad Tablet root script (Windows version)
[*] Exploit copyright (C) 2012 Dan Rosenberg (@djrbliss)
[*]
[*] Before continuing, ensure USB debugging is enabled, that you
[*] have the latest Lenovo drivers installed, that your phone is
[*] connected via USB, and that your phone is connected to a wifi
[*] network.
[*]
[*] Press any key to root your phone...
Press any key to continue . . .
[*]
[*] Waiting for device...
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
[*] Device found.
[*] Let's get ready to rumble...
[*] This may take awhile...
[*] Ignore any prompts or pop-ups on your tablet.
585 KB/s (5993 bytes in 0.010s)
[*] Thinkpad Tablet Root Exploit
[*] Copyright (c) 2012 Dan Rosenberg (@djrbliss)
[-] Exploit failed.
[1] Segmentation fault /data/local/tmp/...
[*] If the words "exploit failed" appear above, exit now and try again.
[*] Note: a segmentation fault is supposed to happen and should be ignored.
[*] Otherwise, press any key to reboot and continue rooting.
Press any key to continue . . .
Even if I simply continue; the device will not be rooted afterwards. Here the log which appears after I continue after the "Exploit failed"-error:
Code:
[*] Lenovo Thinkpad Tablet root script (Windows version)
[*] Exploit copyright (C) 2012 Dan Rosenberg (@djrbliss)
[*]
[*] Before continuing, ensure USB debugging is enabled, that you
[*] have the latest Lenovo drivers installed, that your phone is
[*] connected via USB, and that your phone is connected to a wifi
[*] network.
[*]
[*] Press any key to root your phone...
Press any key to continue . . .
[*]
[*] Waiting for device...
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
[*] Device found.
[*] Let's get ready to rumble...
[*] This may take awhile...
[*] Ignore any prompts or pop-ups on your tablet.
585 KB/s (5993 bytes in 0.010s)
[*] Thinkpad Tablet Root Exploit
[*] Copyright (c) 2012 Dan Rosenberg (@djrbliss)
[-] Exploit failed.
[1] Segmentation fault /data/local/tmp/...
[*] If the words "exploit failed" appear above, exit now and try again.
[*] Note: a segmentation fault is supposed to happen and should be ignored.
[*] Otherwise, press any key to reboot and continue rooting.
Press any key to continue . . .
And yes, I am aware that for some people, although they experienced some errors as well, the root worked just well. I do not seem to be one of the lucky ones.
I don't know what I can do anymore. I followed all the steps, everything works except that stupid root.
Edit: I think this has to do with the firmware update which came in during the last days. I installed the update and tried the root just afterwards but got the same "Exploit failed" result. That was the reason why I did a factory reset in the first place.

Sorry dude, the latest update fixed the exploit. The only thing you can do now is wait till some one finds a new exploit. Either that or haope that your micro usb port breaks and then get the main board replaced as that will likely be on old version you can then do the root again, that's hoping the service engineer is feelkng helpful and run all the updates for you.
Cheers
Tom
Sent from my ThinkPad Tablet using Tapatalk

I am the same ,just waiting.....

[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

[Q] Problem running CASUAL

I'm trying to use CASUAL with my AT&T GS4 (sch-i337) as discussed in this thread:
http://forum.xda-developers.com/showthread.php?t=2297900
Sadly I seem to be the noob who proves that it is not noob-proof. My post count is too low to post in that thread, so I'm posting here instead.
I get nowhere because CASUAL never detects my phone. My phone has USB debug mode enabled and is running pure stock MDL firmware, unrooted . My computer is running Win 7 x64, has AV and firewall disabled, latest Java installed, and no 3rd party USB drivers for the phone. The phone shows up normally in Windows Explorer, and I can browse the files on it. I tried 2 different USB cables, rebooted both the phone and computer, and always get the same result.
Here's the CASUAL log:
Code:
[DEBUG]working
[INFO]We are running Windows 7
Creating Temp Folder in:T:\Temp\CASUALMomDad-2013-07-30-23.56.04\CASUAL Cross-platform Android Scripting and Unified Auxiliary Loader
Revision:774 build:6,461
CASUAL Copyright (C) 2013 Adam Outler
This program comes with ABSOLUTELY NO WARRANTY. This is free software,
and you are welcome to redistribute it, under certain conditions; run
'T:\samsung_i337\Root-and-Recovery-ATT-TMO-GS4-CASUAL-R774b--Nightly.jar --license'
for details. http://android-casual.googlecode.com for source.
[DEBUG]ClassJar:jar:file:/T:/samsung_i337/Root-and-Recovery-ATT-TMO-GS4-CASUAL-R774b--Nightly.jar!/CASUAL/CASUALTools.class
[DEBUG]launching GUI
[DEBUG]Picking Jar File:/T:/samsung_i337/Root-and-Recovery-ATT-TMO-GS4-CASUAL-R774b--Nightly.jar ..scanning.
[DEBUG]Found Windows Computer
[DEBUG]Attempting to write T:\Temp\CASUALMomDad-2013-07-30-23.56.04\Elevate.exe
[DEBUG]File verified.
[DEBUG]Attempting to write T:\Temp\CASUALMomDad-2013-07-30-23.56.04\adb.exe
[DEBUG]File verified.
[DEBUG]Attempting to write T:\Temp\CASUALMomDad-2013-07-30-23.56.04\AdbWinApi.dll
[DEBUG]File verified.
[DEBUG]Attempting to write T:\Temp\CASUALMomDad-2013-07-30-23.56.04\AdbWinUsbApi.dll
[DEBUG]File verified.
[DEBUG]Searching for scripts
[DEBUG]Setting executable T:\Temp\CASUALMomDad-2013-07-30-23.56.04\adb.exe. Result=true
[VERBOSE]TimeOut on T:\Temp\CASUALMomDad-2013-07-30-23.56.04\adb.exe after 5000ms. Returning what was received.
[VERBOSE]ADB Server Started!!!
[DEBUG][TRANSLATION]@interactionWindowsDeviceNotDetected
[DEBUG][STANDARDMESSAGE]@interactionWindowsDeviceNotDetected
[RESPONSEEXPECTED]
Thanks in advance for any help.

Uninstall the phone drivers from your computer. Remove kies if it is installed. Reboot pc and phone. Give her another try.
When you connect the phone, run casual and let it get the correct drivers. Don't install them via windows.

I assume you have read and know this but open your settings and select about phone and then make sure your baseband does not end with MF3. Otherwise CASUAL won't work. A root method and all that jazz still needs to be found for that baseband.
Sent from my SAMSUNG-SGH-I337 using xda app-developers app

system is not seeing your device, make sure debug is selected, and it looks to me also that you have a driver conflict, if you have keis, I suggest removing the drivers.

xBeerdroiDx said:
Uninstall the phone drivers from your computer. Remove kies if it is installed. Reboot pc and phone. Give her another try.
When you connect the phone, run casual and let it get the correct drivers. Don't install them via windows.
Click to expand...
Click to collapse
Thanks, but no phone drivers or Kies have ever been installed on that computer. Rebooted phone and computer several times. Tried several different builds of CASUAL. Phone is never detected by CASUAL.

CAG-man said:
I assume you have read and know this but open your settings and select about phone and then make sure your baseband does not end with MF3. Otherwise CASUAL won't work. A root method and all that jazz still needs to be found for that baseband.
Click to expand...
Click to collapse
Thanks, but as mentioned in the OP, the phone has stock MDL baseband, so that's not the issue. I never actually get far enough for that to be an issue.

Gave up on original Win 7 x64 computer. Switched to another computer with Win Vista x32. As be.fore, this computer has never had phone drivers or Kies installed. When I plug the phone into the computer, Windows successfully detects it and I can browse the files in Windows Explorer. And yes the phone definitely has USB debugging mode enabled.
With the last couple of nightly builds, CASUAL tells me that the phone is detected. However, there seems to be an error in those builds because the script is missing. Looking in the temp folder where CASUAL extracts the files, there is no SCRIPTS subfolder. Therefore the "Do It" button does nothing. Here is an example log:
Code:
[DEBUG]working
[INFO]We are running Windows Vista
Creating Temp Folder in:C:\Users\Admin\AppData\Local\Temp\CASUALAdmin-2013-07-31-22.49.17\CASUAL Cross-platform Android Scripting and Unified Auxiliary Loader
Revision:778 build:6,497
CASUAL Copyright (C) 2013 Adam Outler
This program comes with ABSOLUTELY NO WARRANTY. This is free software,
and you are welcome to redistribute it, under certain conditions; run
'C:\Users\Admin\Downloads\gs4\Root-and-Recovery-ATT-TMO-GS4-CASUAL-R778b--Nightly.jar --license'
for details. http://android-casual.googlecode.com for source.
[DEBUG]launching GUI
[DEBUG]Picking Jar File:/C:/Users/Admin/Downloads/gs4/Root-and-Recovery-ATT-TMO-GS4-CASUAL-R778b--Nightly.jar ..scanning.
[DEBUG]Found Windows Computer
[DEBUG]Attempting to write C:\Users\Admin\AppData\Local\Temp\CASUALAdmin-2013-07-31-22.49.17\Elevate.exe
[DEBUG]File verified.
[DEBUG]Attempting to write C:\Users\Admin\AppData\Local\Temp\CASUALAdmin-2013-07-31-22.49.17\adb.exe
[DEBUG]File verified.
[DEBUG]Attempting to write C:\Users\Admin\AppData\Local\Temp\CASUALAdmin-2013-07-31-22.49.17\AdbWinApi.dll
[DEBUG]File verified.
[DEBUG]Attempting to write C:\Users\Admin\AppData\Local\Temp\CASUALAdmin-2013-07-31-22.49.17\AdbWinUsbApi.dll
[DEBUG]File verified.
[DEBUG]Searching for scripts
[DEBUG]Setting executable C:\Users\Admin\AppData\Local\Temp\CASUALAdmin-2013-07-31-22.49.17\adb.exe. Result=true
[VERBOSE]ADB Server Started!!!
[VERBOSE]TimeOut on C:\Users\Admin\AppData\Local\Temp\CASUALAdmin-2013-07-31-22.49.17\adb.exe after 5000ms. Returning what was received.
[DEBUG]Controls Enabled status: true
[DEBUG]State Change Detected, The new state is: 1
[DEBUG]Device Connected
[DEBUG]@stateConnected
[DEBUG]Controls Enabled status: true
Going back to the last instabuild R773b, it does properly extract the SCRIPTS folder, but it never detects the phone (or detects it only momentarily). Here's the log:
Code:
[DEBUG]working
[INFO]We are running Windows Vista
Creating Temp Folder in:C:\Users\Admin\AppData\Local\Temp\CASUALAdmin-2013-07-31-22.56.50\CASUAL Cross-platform Android Scripting and Unified Auxiliary Loader
Revision:773 build:6,423
CASUAL Copyright (C) 2013 Adam Outler
This program comes with ABSOLUTELY NO WARRANTY. This is free software,
and you are welcome to redistribute it, under certain conditions; run
'C:\Users\Admin\Downloads\gs4\Root-and-Recovery-ATT-TMO-GS4-CASUAL-R773b--InstaBuild.jar --license'
for details. http://android-casual.googlecode.com for source.
[DEBUG]ClassJar:jar:file:/C:/Users/Admin/Downloads/gs4/Root-and-Recovery-ATT-TMO-GS4-CASUAL-R773b--InstaBuild.jar!/CASUAL/CASUALTools.class
[DEBUG]launching GUI
[DEBUG]Picking Jar File:/C:/Users/Admin/Downloads/gs4/Root-and-Recovery-ATT-TMO-GS4-CASUAL-R773b--InstaBuild.jar ..scanning.
[DEBUG]parsing SCRIPTS/
[DEBUG]Found Windows Computer
[DEBUG]Attempting to write C:\Users\Admin\AppData\Local\Temp\CASUALAdmin-2013-07-31-22.56.50\Elevate.exe
[DEBUG]File verified.
[DEBUG]Attempting to write C:\Users\Admin\AppData\Local\Temp\CASUALAdmin-2013-07-31-22.56.50\adb.exe
[DEBUG]File verified.
[DEBUG]Attempting to write C:\Users\Admin\AppData\Local\Temp\CASUALAdmin-2013-07-31-22.56.50\AdbWinApi.dll
[DEBUG]File verified.
[DEBUG]Attempting to write C:\Users\Admin\AppData\Local\Temp\CASUALAdmin-2013-07-31-22.56.50\AdbWinUsbApi.dll
[DEBUG]File verified.
[DEBUG]parsing SCRIPTS/-build.properties
[DEBUG]parsing SCRIPTS/GS4 Root and Loki Recovery.meta
[DEBUG]parsing SCRIPTS/GS4 Root and Loki Recovery.scr
[DEBUG]parsing SCRIPTS/GS4 Root and Loki Recovery.txt
[DEBUG]parsing SCRIPTS/GS4 Root and Loki Recovery.zip
[VERBOSE]found zip at SCRIPTS/GS4 Root and Loki Recovery.zip
[DEBUG]parsing SCRIPTS/-logo.png
[DEBUG]parsing SCRIPTS/-Overview.txt
[DEBUG]
Starting CASPAC unzip.
[DEBUG][TRANSLATION]@noUpdateRequired
[INFO]Verified up-to-date.
[DEBUG]unzip of SCRIPTS/GS4 Root and Loki Recovery.zip is beginning.
[VERBOSE]Unzipping busybox
[VERBOSE]Unzipping pwn
[VERBOSE]Unzipping Superuser.apk
[VERBOSE]Unzipping su
[VERBOSE]Unzipping recovery.img
[VERBOSE]Unzip Complete
[DEBUG]unzip of SCRIPTS/GS4 Root and Loki Recovery is complete.
[DEBUG]Searching for scripts
[INFO]misc hacks for AT&T Galaxy S4
[DEBUG]adding SCRIPTS/GS4 Root and Loki Recovery to UI
[INFO]
[DEBUG]Setting executable C:\Users\Admin\AppData\Local\Temp\CASUALAdmin-2013-07-31-22.56.50\adb.exe. Result=true
[VERBOSE]ADB Server Started!!!
[VERBOSE]TimeOut on C:\Users\Admin\AppData\Local\Temp\CASUALAdmin-2013-07-31-22.56.50\adb.exe after 5000ms. Returning what was received.
[DEBUG]Controls Enabled status: true
[DEBUG]State Change Detected, The new state is: 1
[DEBUG]Device Connected
[DEBUG]@stateConnected
[DEBUG]Controls Enabled status: true
[DEBUG]State Change Detected, The new state is: 0
[DEBUG]@stateDisconnected
[DEBUG]Device Removed
[DEBUG]Controls status: false
The originally posted build 527 also does not detect the phone. Here's a log from that version:
Code:
[INFO]We are running Windows Vista
Creating Temp Folder in:C:\Users\Admin\AppData\Local\Temp\AdminTEMPCASUAL9F5DDC95\CASUAL Cross-platform Android Scripting and Unified Auxiliary Loader
Revision:527 build:3,811
CASUAL Copyright (C) 2013 Adam Outler
This program comes with ABSOLUTELY NO WARRANTY. This is free software,
and you are welcome to redistribute it, under certain conditions; run
'C:\Users\Admin\Downloads\gs4\Root%20and%20Recovery%20for%20ATT-TMO%20GS4-CASUAL-R527b.jar --license'
for details. http://android-casual.googlecode.com for source.
[DEBUG]Picking Jar File:/C:/Users/Admin/Downloads/gs4/Root%20and%20Recovery%20for%20ATT-TMO%20GS4-CASUAL-R527b.jar
[DEBUG]Found Windows Computer
[DEBUG]Found: GS4 Root and Loki Recovery
[DEBUG]OMFGWOOT GUI running!
[INFO]misc hacks for AT&T Galaxy S4
[DEBUG]Searching for scripts
[DEBUG]Updating Scripts for UI
[VERBOSE]From Resource: true
[INFO]--GS4 Root and Loki Recovery--
[INFO]This will install root and recovery for you Qualcomm based Samsung Galaxy S4
##############################
# Motochopper Copyright (C) 2013 Dan Rosenberg (@djrbliss)
# Loki Copyright (C) 2013 Dan Rosenberg (@djrbliss)
# TWRP recovery - Team Win
##############################
# Instructions:
# 1. Put your device in debugging mode
# 2. Attach it via USB
# 3. Click the Do It button
##############################
[DEBUG]Created zipResource at /SCRIPTS/GS4 Root and Loki Recovery.zip
[DEBUG]Exiting comboBoxUpdate()
[DEBUG]attempted to lock controls but controls are not availble yet
[DEBUG]Extracting archive....
[DEBUG]Target Script Is resource
[VERBOSE]Unzipping busybox
[VERBOSE]Unzipping pwn
[DEBUG]Attempting to write C:\Users\Admin\AppData\Local\Temp\AdminTEMPCASUAL9F5DDC95\Elevate.exe
[DEBUG]File verified.
[DEBUG]Attempting to write C:\Users\Admin\AppData\Local\Temp\AdminTEMPCASUAL9F5DDC95\adb.exe
[VERBOSE]Unzipping Superuser.apk
[DEBUG]File verified.
[DEBUG]Attempting to write C:\Users\Admin\AppData\Local\Temp\AdminTEMPCASUAL9F5DDC95\AdbWinApi.dll
[VERBOSE]Unzipping su
[VERBOSE]Unzipping recovery.img
[DEBUG]File verified.
[DEBUG]Attempting to write C:\Users\Admin\AppData\Local\Temp\AdminTEMPCASUAL9F5DDC95\AdbWinUsbApi.dll
[DEBUG]File verified.
[DEBUG]sleeping for Windows ADB start
[VERBOSE]Unzip Complete
[DEBUG]Attempting to write C:\Users\Admin\AppData\Local\Temp\AdminTEMPCASUAL9F5DDC95\adb_usb.ini
[DEBUG]File verified.
[DEBUG]###executing: C:\Users\Admin\AppData\Local\Temp\AdminTEMPCASUAL9F5DDC95\adb.exe###
[VERBOSE]List of devices attached
[DEBUG]Device List:
[DEBUG]unknown
At this point I've wasted several hours trying to get this tool to work and have gotten nowhere, so I'm feeling pretty frustrated.

Success!!
It seemed to me that I was having driver problems (except for the builds that are missing the script). So despite all the advice to the contrary, I decided to try installing the Samsung USB driver and then retry CASUAL. That did the trick (on the Vista machine, I didn't try it on the Win 7 machine).
The Samsung USB driver can be downloaded here:
http://www.samsung.com/us/support/owners/product/SGH-I337ZKAATT
After installing that (which literally took about an hour with the hard drive constantly busy), then I ran that latest CASUAL instabuild (r773b) and it worked like a charm.
Yay! Now off to freeze the stupid AT&T software update tasks to make sure they don't push MF3 to me.

spocko said:
Thanks, but as mentioned in the OP, the phone has stock MDL baseband, so that's not the issue. I never actually get far enough for that to be an issue.
Click to expand...
Click to collapse
Yikes. Sorry. I reread OP and I missed the MDL part. I see it now. Lol
Sent from my SAMSUNG-SGH-I337 using xda app-developers app

spocko said:
It seemed to me that I was having driver problems (except for the builds that are missing the script). So despite all the advice to the contrary, I decided to try installing the Samsung USB driver and then retry CASUAL. That did the trick (on the Vista machine, I didn't try it on the Win 7 machine). The Samsung USB driver can be downloaded here:
http://www.samsung.com/us/support/owners/product/SGH-I337ZKAATT After installing that (which literally took about an hour with the hard drive constantly busy), then I ran that latest CASUAL instabuild (r773b) and it worked like a charm. Yay! Now off to freeze the stupid AT&T software update tasks to make sure they don't push MF3 to me.
Click to expand...
Click to collapse
Good job! It seems to always be that way -several hours of frustration where every "correct step" just does not work, then all of the sudden . . .success! Not sure I would have figured it out quickly either -although I did load the Samsung driver myself prior to using CASUAL so I did not have any experience of CASUAL getting drivers for me. . . It's a good data point thanks! Good idea to kill the AT&T OTA as soon as you can! Next stop. . .nice roms to customize!

[ROOT] Amazon Fire TV Gen 2 (4k)

There is an updated thread now for rooting the AFTV2 that supports both 5.0.3.1 and 5.0.4 and maybe others in the future, see http://forum.xda-developers.com/fire-tv/general/root-amazon-fire-tv-2-updated-t3277556. The new method is simpler than this method and requires less to download and less steps to run.
To be safe run checkver.py every time you handshake since 5.0.4 is starting to roll out! Checkout the 5.0.3.1 tag in order to use this older method.
If you were able to root your AFTV2 we'd appropriate if you report your success on the poll located here.
NOTE: Root was obtained a few weeks ago so... this procedure is not the most time efficient, but it is just a few simple steps that anyone with a technical background can follow. There are ideas and some work in progress to make it easier. It depends also on serial port stability, which is somewhat random luck. Linux experience will be beneficial. The usual disclaimers apply, which means this rooting procedure comes with some risks and the scripts involved haven't been tested in all environments. Any harm that may come from rooting your device using this procedure is at your own risk and I assume no responsibility for any damage it may cause. I will do my best to help you get through it and recover if possible.
Root the Device
It's taken quite a bit of effort, but I've finally managed to create a pre-rooted system image (as well as backup the original) and provide a semi-efficient way to flash the rooted system image. Before attempting any of the steps listed below YOU MUST BE RUNNING 5.0.3.1. You should also have a unmodified/pristine system partition. You would probably know if you had any modifications and at this point that would be uncommon. If the patching fails for some reason just power off the device, reboot your computer (resets the serial port buffer), start the handshake script, then turn on the device. Once the handshake completes run the patching command again. There is no harm running the patching command two or more times. If it keeps hanging try a different computer.
To get started you will need a system that meets the following requirements:
Linux (Mac OS X or Windows w/ changes)
Python 3.x
PySerial
sudo yum install python3-pyserial # Fedora or RedHat
sudo apt-get install python3-serial # Ubuntu or Debian
USB Male A to Male A cable
R/W access to /dev/ttyACM0 (or use sudo)
ADB USB access (optional, but helpful)
Stop ModemManager (if you have it setup, which blocks handshaking)
Now run the following sequence of commands:
Code:
git clone --branch 5.0.3.1 https://gitlab.com/zeroepoch/aftv2-tools.git
cd aftv2-tools
wget http://download.zeroepoch.com/aftv2/5.0.3.1/system.root.img.gz
wget http://download.zeroepoch.com/aftv2/5.0.3.1/system.diff.gz
gunzip system.root.img.gz
gunzip system.diff.gz
adb reboot ; ./handshake.py # or restart but run ./handshake.py first
./checkver.py # STOP if it reports NO!
./patch_mmc.hs 0x00000000058e0000 system.root.img system.diff # takes ~2 hours
# last address is 0x50dce600
For Macs (see post #115, thanks @ians325) to satisfy the requirements above you will need to install python 3.5.0 for Mac OS X from python.org then run "sudo pip3 install pyserial" to install pyserial. Instead of "wget $URL" use "curl -O $URL".
Windows is working now, but it's constantly improving to make it easier for novice users. The bash script has been ported to a batch file (no cygwin needed) and the serial port has some auto-detection built in now. The files needed for Windows have already been added to the repo but the README is constantly evolving. @ImCoKeMaN (big thanks) and myself are working to improve the process and make it easier for Windows users.
Anyone interested in rooting using an Ubuntu VM should watch the YouTube video by @ultimate_spy_binns, https://www.youtube.com/watch?v=CZQqLoO6ojM. There is also a script to help automate the process if you are doing this on an Ubuntu live CD/USB found here (by @BagiMT).
To test that root is working you should first connect to adb shell and then run the command "su". You will need to accept a prompt on the screen (HDMI port) at least once. The shell should change from a dollar-sign ($) prompt to a hash (#) prompt.
If you would like to disable updates after rooting you can use the following commands:
Code:
adb shell
su
pm disable com.amazon.device.software.ota
To go back to stock in case you want to update or for whatever other reason:
Code:
wget http://download.zeroepoch.com/aftv2/5.0.3.1/system.orig.img.gz
gunzip system.orig.img.gz
adb push system.orig.img /data/local/tmp
adb shell
su
pm enable com.amazon.device.software.ota
dd if=/data/local/tmp/system.orig.img of=/dev/block/platform/mtk-msdc.0/by-name/system bs=1m
sync
reboot
I don't always have the best luck transferring large files over ADB so another option is to copy the uncompressed image file to a microSD card and changing the path to /storage/sdcard1/system.orig.img. Be extremely careful that you have the right path, that the file you are reading exists, and that the file is around 1.2 GB in size. Otherwise you may potentially trash your system.
Background Info
This root method works by rebooting the device and halting the boot process at the MediaTek preloader. Once halted at the preloader we can use the preloader binary API to send a series of MMC commands to the flash chip which allows 512 byte blocks to be read and written using a simple FIFO. Since we have both the original and modified system images we can generate a list of blocks that are different between the two images and only patch those blocks. This means we need to write less than 10 MB instead of 1.2 GB. If we had to send the entire system image at the speeds the preloader is limited to it would take about 2 weeks. If for some reason the system partition becomes unbootable that would be your only option to recover right now. By sending just the differences the patching only takes about 2 hours. There are ways to speed this up (about 5-10 minutes instead), but you'd need to obtain limited root access first using a much much more complicated procedure. I choose to provide instead a slower but much simpler series of commands.
The MT preloader is a process that runs before the regular bootloader (lk/fastboot) and of course before the kernel boots. It only shows up for about 3 seconds. Unfortunately the preloader is writable and could potentially be updated. The entire boot chain is cryptographically signed from what I've been able to inspect including the preloader. An unlocked bootloader would most likely be needed to flash a custom kernel (no kexec built-in of course, but modules/device drivers can be loaded) and create ROMs not based on stock. @rbox has been working on getting kexec working as a module but no ETA yet. So in conclusion the tools here allow you to modify the flash contents and using these facilities we have add SuperSU binaries to the system partition.
Anyone interested in how root was obtained should look at the history starting with this post. You should also read the README file from the aftv2-tools git repo. Also feel free to PM me if you have any questions.
Tips
If you want to disable the pop-up message when becoming root you can change notify=1 to notify=0 in /data/data/eu.chainfire.supersu/files/supersu.cfg. You need to reboot the device after making this change. It's also suggested to make the file read-only because it seems to get reset sometimes. (Thanks @ultimate_spy_binns)
Special Thanks
@qwertytical
@budokaiboy

great news
i never powered on my unit - awaiting root
can we have a 5.0.3.1 image to safely flash before root
otherwise the system might update to different version
now that rooting is out
amazon might be quick ...

reiteravi said:
great news
i never powered on my unit - awaiting root
can we have a 5.0.3.1 image to safely flash before root
otherwise the system might update to different version
now that rooting is out
amazon might be quick ...
Click to expand...
Click to collapse
Yeah, mine pre-ordered one is still in a box so I'd need to update it too. I guess I can do that tonight before a new version comes out.

reiteravi said:
great news
i never powered on my unit - awaiting root
can we have a 5.0.3.1 image to safely flash before root
otherwise the system might update to different version
now that rooting is out
amazon might be quick ...
Click to expand...
Click to collapse
Unfortunately you will need to do a normal update first before patching the system partition. It just takes too long to flash a full system image, original or modified, using the methods we have available to us now. Also the boot partition and other partitions are updated with each OTA. I hope we can continue to provide rooted versions of updated system images, but as you know there is no guarantee of that. I'd update now before there is any new updates and then root it. We could in theory root the older versions as well and even before first boot, but without the OTA updates and applying them in reverse I can't go back and patch the older releases. I strongly think the method used to write the system partition can not be fixed since I believe the preloader code is in a ROM.

Mac Update
A few notes for Mac users willing to experiment a little:
I installed python 3.5.0 for Mac OS X from python.org and then ran "sudo pip3 install pyserial" to install pyserial for python 3.x. The final change I needed to make was to change PORT in handshake.py and read_mmc.py/write_mmc.py (only tested reading the boot partition, but everything else should work). In my case the PORT was /dev/cu.usbmodem1430. The device filename seems to be based on the USB port it's connected to. I'm not sure if there is an easier way to find the device filename besides scanning /dev and looking for new devices matching a given pattern. Maybe others on this forum have some better ideas. The final caveat was I need to unplug and replug the USB cable after the handshake completed otherwise the read_mmc.py script would hang on the first read.

I succeeded in rooting mine! For comparison purposes, here's the md5sums of my partitions:
Code:
0e450c032ddce170667ba3ddc26cb960 DKB
a3ad800f012a153953b403ef1fa36e14 EXPDB
d693da95eb68b40e4315333bcf74918b KB
50f24ce4c7ac388b33310bff6f79636a LOGO
59071590099d21dd439896592338bf95 MISC
f9b5ef697fde92c42bbbec35e5a6cad4 PRO_INFO
8a9d058f87711c2e8ccc698647f5026b TEE1
eda2733e1d0214873d9cb9d78c68425f TEE2
97a2ccdb7a02838b26b9a57e4f31d51d boot
fbd20aa58cd63c07392080cad7627e18 lk
74f0bac463bae8141acf20594987a559 recovery
a06c3d6a8c73923ed5c38b479c4410d3 system
So my DKB, KB, and system partitions are different from yours.

NaturalBornHaxor said:
I succeeded in rooting mine! For comparison purposes, here's the md5sums of my partitions:
Code:
0e450c032ddce170667ba3ddc26cb960 DKB
a3ad800f012a153953b403ef1fa36e14 EXPDB
d693da95eb68b40e4315333bcf74918b KB
50f24ce4c7ac388b33310bff6f79636a LOGO
59071590099d21dd439896592338bf95 MISC
f9b5ef697fde92c42bbbec35e5a6cad4 PRO_INFO
8a9d058f87711c2e8ccc698647f5026b TEE1
eda2733e1d0214873d9cb9d78c68425f TEE2
97a2ccdb7a02838b26b9a57e4f31d51d boot
fbd20aa58cd63c07392080cad7627e18 lk
74f0bac463bae8141acf20594987a559 recovery
a06c3d6a8c73923ed5c38b479c4410d3 system
So my DKB, KB, and system partitions are different from yours.
Click to expand...
Click to collapse
That is awesome news! The first confirmed case I've heard of someone else repeating my success
About the DKB and KB partitions being different it makes me wonder what those partitions are for? I didn't include cache and userdata in the MD5SUM of course, which you noticed, because those change all the time. NVRAM when I looked inside appeared to have a few things that looked to be device specific. The system partition being different is actually expected because I found every time I rebooted my system partition changed checksums. Also that is the MD5SUM of the unmodified system partition. I noticed this weird MD5SUM behavior when I was first gaining root and doing some sanity checks. It happens right after daemonsu is started. My best guess is that the SuperSU tools mount the system r/w quickly and that causes the last mounted timestamp to change. Don't know for sure what causes it, but don't worry that's not unexpected. The main reason I kept those hashes in the repo was so when the next version comes out I know which partitions were changed and need to be updated by users who wish to maintain root.

------------------SOLVED-----------------
Please read on if you have problems with handshake script looping forever...
-----------------------------------------------
Hi zeroepoch,
meanwhile I received my Fire TV 2 and tried your scripts but unfortunately without success.
As far as I can see, there are 2 problems:
- The /dev/ttyACM0 device appears on rebooting the Fire TV, but only for some 100th of a second, then it disconnects again.
- If I give it another try, the device will appear as /dev/ttyACM1, next time /dev/ttyACM2, aso.. So I either have to update the handshake script for every try or reboot my computer (then it starts with /dev/ttyACM0 again).
When I first tried it, the handshake-script ran forever, it just missed the short time of availability of /dev/ttyACM0. So I reduced the sleep-timeout in the script from 0.25 to 0.001. Now the handshake script detects the serial device but runs into an I/O Error during one of the next steps (each time different, seems to be a "race condition").
Can you offer any advice? Could my Laptop be too slow somehow or is there some trick to make the Fire TV keep the port open for a longer time?
Greetings, Christian
Code:
shell:
[email protected]:~/aftv2-tools# adb reboot ; ./handshake.py
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
Traceback (most recent call last):
File "./handshake.py", line 17, in <module>
dev = serial.Serial(PORT, BAUD)
File "/usr/lib/python3/dist-packages/serial/serialutil.py", line 261, in __init__
self.open()
File "/usr/lib/python3/dist-packages/serial/serialposix.py", line 282, in open
self._reconfigurePort()
File "/usr/lib/python3/dist-packages/serial/serialposix.py", line 413, in _reconfigurePor t
termios.tcsetattr(self.fd, TERMIOS.TCSANOW, [iflag, oflag, cflag, lflag, ispeed, ospeed , cc])
termios.error: (5, 'Input/output error')
Code:
/var/log/syslog;
Nov 11 11:25:41 DeepThought systemd[1111]: Reached target Default.
Nov 11 11:25:41 DeepThought systemd[1111]: Startup finished in 15ms.
Nov 11 11:27:28 DeepThought kernel: [ 217.460463] usb 8-2: USB disconnect, device number 2
Nov 11 11:27:31 DeepThought kernel: [ 220.608049] usb 8-2: new high-speed USB device number 3 using ehci-pci
Nov 11 11:27:31 DeepThought kernel: [ 220.741857] usb 8-2: New USB device found, idVendor=0e8d, idProduct=2000
Nov 11 11:27:31 DeepThought kernel: [ 220.741860] usb 8-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Nov 11 11:27:31 DeepThought kernel: [ 220.741862] usb 8-2: Product: MT65xx Preloader
Nov 11 11:27:31 DeepThought kernel: [ 220.741864] usb 8-2: Manufacturer: MediaTek
Nov 11 11:27:31 DeepThought mtp-probe: checking bus 8, device 3: "/sys/devices/pci0000:00/0000:00:1d.7/usb8/8-2"
Nov 11 11:27:31 DeepThought mtp-probe: bus: 8, device: 3 was not an MTP device
Nov 11 11:27:31 DeepThought kernel: [ 220.855737] cdc_acm 8-2:1.1: ttyACM0: USB ACM device
Nov 11 11:27:31 DeepThought kernel: [ 220.884047] usbcore: registered new interface driver cdc_acm
Nov 11 11:27:31 DeepThought kernel: [ 220.884050] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters
Nov 11 11:27:31 DeepThought kernel: [ 220.924931] usb 8-2: USB disconnect, device number 3
Nov 11 11:27:31 DeepThought ModemManager[511]: <warn> (ttyACM0): tcgetattr() error: 5
Nov 11 11:27:31 DeepThought ModemManager[511]: <warn> (ttyACM0): port attributes not fully set
Nov 11 11:27:31 DeepThought kernel: [ 220.928861] cdc_acm 8-2:1.1: failed to set dtr/rts
Nov 11 11:27:31 DeepThought ModemManager[511]: <info> (tty/ttyACM0): released by modem /sys/devices/pci0000:00/0000:00:1d.7/usb8/8-2
Nov 11 11:27:31 DeepThought ModemManager[511]: <warn> (Plugin Manager) (Cinterion) [ttyACM0] error when checking support: '(Cinterion) Missing port probe for port (tty/ttyACM0)'
Nov 11 11:27:31 DeepThought ModemManager[511]: <warn> (Plugin Manager) (Nokia) [ttyACM0] error when checking support: '(Nokia) Missing port probe for port (tty/ttyACM0)'
Nov 11 11:27:31 DeepThought ModemManager[511]: <warn> (Plugin Manager) (Iridium) [ttyACM0] error when checking support: '(Iridium) Missing port probe for port (tty/ttyACM0)'
Nov 11 11:27:31 DeepThought ModemManager[511]: <warn> (Plugin Manager) (Generic) [ttyACM0] error when checking support: '(Generic) Missing port probe for port (tty/ttyACM0)'
Nov 11 11:27:33 DeepThought ModemManager[511]: <warn> Couldn't find support for device at '/sys/devices/pci0000:00/0000:00:1d.7/usb8/8-2': not supported by any plugin
Nov 11 11:27:35 DeepThought wpa_supplicant[837]: nl80211: send_and_recv->nl_recvmsgs failed: -33
Nov 11 11:27:36 DeepThought kernel: [ 226.092142] usb 8-2: new high-speed USB device number 4 using ehci-pci
Nov 11 11:27:37 DeepThought kernel: [ 226.225936] usb 8-2: New USB device found, idVendor=1949, idProduct=0241
Nov 11 11:27:37 DeepThought kernel: [ 226.225945] usb 8-2: New USB device strings: Mfr=2, Product=3, SerialNumber=4
Nov 11 11:27:37 DeepThought kernel: [ 226.225951] usb 8-2: Product: FireTV
Nov 11 11:27:37 DeepThought kernel: [ 226.225956] usb 8-2: Manufacturer: Amazon
Nov 11 11:27:37 DeepThought kernel: [ 226.225961] usb 8-2: SerialNumber: G070GV05544205DE
Nov 11 11:27:37 DeepThought mtp-probe: checking bus 8, device 4: "/sys/devices/pci0000:00/0000:00:1d.7/usb8/8-2"
Nov 11 11:27:37 DeepThought mtp-probe: bus: 8, device: 4 was an MTP device
After taking a closer look at my syslog and doing some research on problems with /dev/ttyACM0, I finally found the problem. It's the modemmanager. That service immmediately "grabs" the device and tries to do some invalid settings, which leads to an near immediate disconnect.
After I uninstalled the modemmanger (which seemed preinstalled in debian jessie, at least I never installed it on purpose) with
Code:
apt-get remove modemmanager
both of my problems were gone. The device stayed up for 3 seconds and after reboot of the Fire TV it had the same devicename /dev/ttyACM0 again. So I could undo my changes to the handshake script and had instant success with it.
Now I'll try rooting. WHOOT!

Thank you very much for your efforts!
I'd just like to check my understanding - are the instructions you posted comprehensive to obtaining root from absolute scratch?
I know soldering of eMMC and such things were used in development, but that is not needed now after you've done the hard work, correct?
I can just follow your steps above and root the FTV2?

gu3stZA said:
Thank you very much for your efforts!
I'd just like to check my understanding - are the instructions you posted comprehensive to obtaining root from absolute scratch?
I know soldering of eMMC and such things were used in development, but that is not needed now after you've done the hard work, correct?
I can just follow your steps above and root the FTV2?
Click to expand...
Click to collapse
Yes, you're right. No need to solder anything. You just need the tools stated in the instructions.
Hardware:
- a computer running Linux (or something very close)
- a A to A USB cable
Software:
- python3 and python3-serial packages
- adb package (not necessary but recommended)
- zeroepochs scripts and patchfiles
That said, a certain amount of base knowledge regarding Linux doesn't hurt .

Thanks! I've played around with Linux but would definitely classify myself as a beginner. I guess we'll see how user-friendly the instructions are

This is good news, definitely progress, could this be integrated into ADBFire for windows

Jay794 said:
This is good news, definitely progress, could this be integrated into ADBFire for windows
Click to expand...
Click to collapse
This would be perfect. Or even adb. I've just never used Linux

zeroepoch said:
It has only been tested on a US device and I don't know at this point if non US devices are different, maybe not.
Click to expand...
Click to collapse
Hi zeroepoch,
I just used your rooting scripts successfully on a non US (in my case German) version of the Fire TV 2!
Greets,
Christian

skyball2 said:
Hi zeroepoch,
I just used your rooting scripts successfully on a non US (in my case German) version of the Fire TV 2!
Greets,
Christian
Click to expand...
Click to collapse
Thanks for the feedback. Glad to hear it worked!

Successful root under arch Linux! Thanks for your hard work.

By any chance does this root work for the original fire TV ?
Sent from my SM-N910F using Tapatalk

Savage13 said:
By any chance does this root work for the original fire TV ?
Click to expand...
Click to collapse
No. It's MediaTek specific. It may work on most MediaTek devices though.

how can u tell handshake is ok and start patching ?

reiteravi said:
how can u tell handshake is ok and start patching ?
Click to expand...
Click to collapse
It will print "Handshake Complete". Also the serial device will remain present rather than disappear after a few seconds.

Need help on preparing to install lineage OS 16 on S5 device

Hi everyone,
I need some help in preparing to install lineage OS 16 on my used S5 device.
So far I have followed the following steps:
1) Enabled Developer options on the phone and enabled USB debugging
2) Downloaded heimdall as per the instructions here : https://wiki.lineageos.org/devices/klte/install
3) Ran Zaidag.exe and did everything in the steps but the final step I got the following error when i tried to run *heimdall print-pit* as an Administrator on command prompt.
C:\Samsung\Heimdall>heimdall print-pit
Heimdall v1.4.0
Copyright (c) 2010-2013, Benjamin Dobell, Glass Echidna
http://www.glassechidna.com.au/
This software is provided free of charge. Copying and redistribution is
encouraged.
If you appreciate this software and you would like to support future
development please consider donating:
http://www.glassechidna.com.au/donate/
Initialising connection...
Detecting device...
libusbx: error [init_device] program assertion failed: unable to find ancestor bus number for '\\.\USB#VID_0BDB&PID_1911&REV_0000&MI_06&OS_NT&WWAN#01'
ERROR: Failed to detect compatible download-mode device.
C:\Samsung\Heimdall>
Am i missing something here?

centerpide said:
Hi everyone,
I need some help in preparing to install lineage OS 16 on my used S5 device.
So far I have followed the following steps:
1) Enabled Developer options on the phone and enabled USB debugging
2) Downloaded heimdall as per the instructions here : https://wiki.lineageos.org/devices/klte/install
3) Ran Zaidag.exe and did everything in the steps but the final step I got the following error when i tried to run *heimdall print-pit* as an Administrator on command prompt.
C:\Samsung\Heimdall>heimdall print-pit
Heimdall v1.4.0
Copyright (c) 2010-2013, Benjamin Dobell, Glass Echidna
http://www.glassechidna.com.au/
This software is provided free of charge. Copying and redistribution is
encouraged.
If you appreciate this software and you would like to support future
development please consider donating:
http://www.glassechidna.com.au/donate/
Initialising connection...
Detecting device...
libusbx: error [init_device] program assertion failed: unable to find ancestor bus number for '\\.\USB#VID_0BDB&PID_1911&REV_0000&MI_06&OS_NT&WWAN#01'
ERROR: Failed to detect compatible download-mode device.
C:\Samsung\Heimdall>
Am i missing something here?
Click to expand...
Click to collapse
Downgrade to 5.0 Android for your phone via Odin.
Then look this post for the 5.0 bootloader unlock and root and installing custom rom.
Method 2: Unlocker via Safestrap (Easy! thanks @jrkruse) For OE1, OK3, PB1 (LOLLIPOP)
https://forum.xda-developers.com/ve...t/rd-unlocking-galaxys-s5-bootloader-t3337909

centerpide said:
Hi everyone,
I need some help in preparing to install lineage OS 16 on my used S5 device.
So far I have followed the following steps:
1) Enabled Developer options on the phone and enabled USB debugging
2) Downloaded heimdall as per the instructions here : https://wiki.lineageos.org/devices/klte/install
3) Ran Zaidag.exe and did everything in the steps but the final step I got the following error when i tried to run *heimdall print-pit* as an Administrator on command prompt.
C:\Samsung\Heimdall>heimdall print-pit
Heimdall v1.4.0
Copyright (c) 2010-2013, Benjamin Dobell, Glass Echidna
http://www.glassechidna.com.au/
This software is provided free of charge. Copying and redistribution is
encouraged.
If you appreciate this software and you would like to support future
development please consider donating:
http://www.glassechidna.com.au/donate/
Initialising connection...
Detecting device...
libusbx: error [init_device] program assertion failed: unable to find ancestor bus number for '\\.\USB#VID_0BDB&PID_1911&REV_0000&MI_06&OS_NT&WWAN#01'
ERROR: Failed to detect compatible download-mode device.
C:\Samsung\Heimdall>
Am i missing something here?
Click to expand...
Click to collapse
which S5 variant is it and why are you usign heimdall instead of odin?