Would it be plausible to use JTAG to rewrite an unlocked firmware?

[Bobcus Leper]

so far, it would seem so. I was able to get full tmobile firmware on it and am testing with cf-auto root

Awesome!

It's currently just laying back and letting me flash a tmobile stock rom (full stock tar) through odin. I feel...definitely not humble at the moment

I think we all would feel the same way.

I quoted him, didn't I?

What?:what:

 

[dreamwave]

Awesome!

I flashed tmobile everything, and it tried on the first boot to do into safestrap even though I thought I had cleared everything, still trying to figure out what is read/write and what is read only on this, I kind of wonder whether or not its carrier identification and such is read only. In download mode it still says sm-g900v, so I know that flash didn't completely overwrite that...

 

[dreamwave]

ooopsies, maybe flashing a verizon pit file and not checking efs clear could contribute to that

 

[dreamwave]

Unfortunately the method I was originally hoping would work definitely won't, as they patched part of it a while ago at the hardware level, but I'm still a tiny bit optimistic that the t-flash method just might yield at least something

 

[dreamwave]

now im confused...does t-flash flash from sd->phone or phone->sd?

 

[dreamwave]

Ok, so looking at this the t-flash isn't anything I can use. The hash keys are actually kept at the near hardware level within what are referred to as "Qfuses", non volatile memory directly in the chip :/

 

[mrjiggywiggy]

I'm a little confused with the many posts you're posting. Correct me if I'm wrong but is it that the stock tar doesn't affect every file in the system and that cf auto root failed. If I'm getting my information correct I also assume that the method failed and that the bootloader unlock isn't possible with this method. A quick summary would be very helpful.

 

[dreamwave]

I'm a little confused with the many posts you're posting. Correct me if I'm wrong but is it that the stock tar doesn't affect every file in the system and that cf auto root failed. If I'm getting my information correct I also assume that the method failed and that the bootloader unlock isn't possible with this method. A quick summary would be very helpful.

I'm editing the first post to include everything I've discovered. Unfortunately this method almost definitely isn't the entire answer, but it may very well help.

 

[Jrjy3]

Also, I'm in ongoing discussion with the FCC as to block C violations by Verizon of aspects of the regulations that upon research have not really been argued to any substantial extent, so if that comes to fruition hopefully there'll be simple ODIN flashable patches for this stuff :fingers-crossed:

Definitely keep us updated on this, whether it's in this thread or in another. I'm sure people have tried contacting the FCC before, but maybe with enough complaints, they'll actually take action

 

[dreamwave]

Definitely keep us updated on this, whether it's in this thread or in another. I'm sure people have tried contacting the FCC before, but maybe with enough complaints, they'll actually take action

I think they kind of just ignored the flood when the masses were mainly just sending in pre-scripted complaints that did argue about open access, but did not really have any comeback to some of the replies from Verizon. I have a thread where I put my complaint and responses, but here's a link: http://forum.xda-developers.com/verizon-galaxy-s5/general/petition-to-verizon-fcc-to-unlock-t3150092

 

[dreamwave]

Definitely keep us updated on this, whether it's in this thread or in another. I'm sure people have tried contacting the FCC before, but maybe with enough complaints, they'll actually take action

I just posted a reply to the complaint thusfar, and it reads as follows:
"In summary, I specifically demand of Verizon, as a company and as an entity, *direct* and *factually supported* responses to the following questions/complaints I currently have previously mentioned:

1. The stance that it is an accepted standard that constitutes "reasonable network management":
Across the industry, the average phone is released with a system initiation/execution system (bootloader) that is possible to modify by the user after accepting that doing so will make the warrantee "null and void," and that after doing so modification, its consequences, and the repairs that may be required are the burden of the user.
Across all devices Verizon offers, there are several that have had bootloaders that have been possible *by design and original intent* to modify, notably the Galaxy Nexus. This lack of any continuity nullifies the argument that it provides for an increase in the security of the carrier's network systems as such devices would be readily available to users with mal-intent, however they are not used for that reason, primarily because of the following question/complaint I have

2. A device with an unlocked bootloader does not, above what is offered by similar devices with restricted bootloaders, pose any significant *demonstratable or previously demonstrated* risk to the security of the host network. I have failed, in extensive research and with contact with Verizon over the matter, been shown any case or hypothetical example that would allow for a phone to compromise the security of the host network by a method that an unrestricted bootloader would serve a role beyond trivial, passive, involvement. On a whole, due to the unrestricted nature of the application ecosystem of Android, the execution of dangerous code on a network would not be affected by an unrestricted bootloader even if it were at all possible to directly execute any such code on a network that makes use of modern protocols and standards for server operation.

3. I still find no supported objection to, or exception from, the contents of paragraph 222 and footnote 500 of FCC-07-132A1 that would allow for the restrictions mentioned

4. As mentioned in the original phone call from Verizon, one argument they provided was that they were allowed choice of operating system based on footnote 502. Although I do not currently have access to the document directly at the current time due to the FCC undergoing server renovation/upgrades, to the best of my memory it carried meaning as follows: the carrier may be allowed to implement and use their choice of software such as to not require modification of the host network. This allows for the preinstallation of endorsed applications and the modification of the /system partition of the phone to interface with update protocols that Verizon has established, along with various modem/radio firmware modifications to accommodate the network bands and protocols in use. This does not specifically allow for undue burden on the consumer, and as it is modification that does not affect the ability of the phone to interface with the network to avoid network modification, it is not protected under this clause.

5. The protection (on the part of the end user) that is provided by wording to the effect of the following: "the installation of applications on the part of the user may not be impinged or disrupted by the host carrier outside of existing laws and regulations or reasonable network management.

I make these demands of defense on the part of the carrier as demands based on the fact that the regulations pertaining to Block C place the burden of proof on the part of the licensee, and any direct challenge to the licensee's adherence to Block C regulations requires that the licensee prove, beyond a reasonable doubt, that they are, indeed, following these regulations."

 

[blair.sadewitz]

Forget about booting the OS. See if you can even get it to load some other kernel. If you somehow manage that, other people will make it work.

---------- Post added at 07:32 AM ---------- Previous post was at 07:27 AM ----------

Ok, so looking at this the t-flash isn't anything I can use. The hash keys are actually kept at the near hardware level within what are referred to as "Qfuses", non volatile memory directly in the chip :/

Just try it anyway. Maybe it'll work--probably not. Ive been wondering about this sort of exploit for months.

I think t-flash writes that "unbrick image" to the external sd.

 

[dreamwave]

Forget about booting the OS. See if you can even get it to load some other kernel. If you somehow manage that, other people will make it work.

---------- Post added at 07:32 AM ---------- Previous post was at 07:27 AM ----------



Just try it anyway. Maybe it'll work--probably not. Ive been wondering about this sort of exploit for months.

I think t-flash writes that "unbrick image" to the external sd.

Too tired of this **** from phone companies, sorry I sold the s5 on ebay

I can try and continue to help but I no longer have the actual phone...#gotanOGmotox

 

[tr4nqui1i7y]

I forgot about this thread?! Where do we stand, and how can I help?

 

[dreamwave]

I forgot about this thread?! Where do we stand, and how can I help?

So far, things don't look promising on the hardware side of things. I'm working on the legal side with the FCC but I don't have a crap-ton of time to work on that. If you wanted to help there, just in finding arguments and such, that would be great

 

[dreamwave]

Just found out that someone wrote an exploit for the note 3 that is now confirmed to work on the s5 with modification that seems based on the sd debrick method at first glance. Kind of wishing I had kept pursuing that for longer, but props to them for figuring it out!

Sent from my Oneplus One with XDA Premium

 

[camcorder123]

Actually, it is based upon leaked vendor commands for the eMMC cards, and involves the flashing of a developer bootloader. The developer bootloader is normally device specific, but we've just found a way to change the CID (a unique ID assigned to the eMMC) to match the one in the bootloader.

Kinda interested in what's gonna happen when Verizon notices thousands of devices with the same CID on their network..... If brickbug detector has access to it, Verizon does.

 

[[email protected]]

ooopsies, maybe flashing a verizon pit file and not checking efs clear could contribute to that

how do i flash g900t on g900v i would love to know :laugh: how do i do it
can i get the modified debrick img please or how to do it

 

[Lightn1ng]

Okay here's what I'll pitch in here:

You're not getting anywhere with the SD method. The Qualcomm mask ROM checks the signature of anything on the SD card if it ends up falling back the boot to that.

JTAG has the same deal - the device will refuse to boot simply because the ROM will check the signature of anything on the device (And hash it with the device's CID, but that's already well documented enough in the Samdunk PDF).

QFuses are a funny thing - it is a HARDWARE FUSE - once it's tripped, there is NO GOING BACK. Period.

Since I have nothing better to do in my free time other than read documentation on the low-level boot process of Qualcomm processors, feel free to ask any other questions here.

 

[[email protected]]

I just hate verizon that much that is why I want to use this method I just want to be able to use the g900t firmware and bootloader

Sent from my SM-G900V using Tapatalk

---------- Post added at 06:02 AM ---------- Previous post was at 05:41 AM ----------

I already have a 0x1 warranty bit

Sent from my SM-G900V using Tapatalk

---------- Post added at 06:03 AM ---------- Previous post was at 06:02 AM ----------

I already have a tripped q fuse whether it is physical or software and Knox warranty bit is 0x1

Sent from my SM-G900V using Tapatalk

---------- Post added at 06:58 AM ---------- Previous post was at 06:03 AM ----------

I've Debricked my phone using SD card method once already a couple weeks ago

Sent from my SM-G900V using Tapatalk