yashsingh1/xdaforums huggingface dataset:
[Verizon Samsung Galaxy S 4] npjohnson:
Ok, checking my understanding here, there is a QFuse (On the N3) that we can blow that will do away with roll back protection, thus allowing us to downgrade past the normal limitations, (i.e. exploitable ones like MDK). Does this QFuse exist on the VZW S4? If so, why hasn't this been further delved into? On a side note, are QFuses SU User Bootable? Or does it require a secure memory overwrite style exploit? Or Something else?

I am aware that this requires more than what is listed above, but I am just asking for the sake of understanding.

Thanks ahead of time.
[Verizon Samsung Galaxy S 4] ryanbg:
It's really hard to do and there's a lot of protection standing in the way. It has to be done through TrustZone.
[Verizon Samsung Galaxy S 4] npjohnson:
Thanks for the answer. That makes sense. Did Dan ever release anything more than the abstract for his Black Hat 2014 TZ Exploit? There was alot of hype about that, and it seems like gave out just a basic abstract...
[Verizon Samsung Galaxy S 4] Walter.White:
And i think this is where we could leverage the exploit that Dan Rosenburg found in TZ.mbn.....he used that exploit to blow a qFuse on Moto device to unlock the Bootloader.

Cant we just use that same exploit to blow Rollback bit as well as Test bit qFuse??
[Verizon Samsung Galaxy S 4] ryanbg:
Warmer.
[Verizon Samsung Galaxy S 4] jhasty01:
It definitely seems like you know something. Out with it, man! Lol
[Verizon Samsung Galaxy S 4] npjohnson:
I am thoroughly enjoying this game. XD
[Verizon Samsung Galaxy S 4] ryanbg:
Don't get any wrong ideas. I have nothing to release, but I can point you guys in the right direction. You're going to have to learn how to do it on your own :)
[Verizon Samsung Galaxy S 4] ryanbg:
That's IMEM. The secure boot configuration is loaded into IMEM by SBL1 after a fuse sense, so the values from the secure boot fuses are read and stored in IMEM. Depending on the configuration, you'll have the CSB mode, OEM certificate index, etc... residing here. Unfortunately those values are set before you can even access memory. IMEM is also protected by an xPU/MPU via TrustZone, so you cannot modify it. Doing so wouldn't do anything anyways. Keep up the good work and I'll be here if you guys need me. [MENTION=4939386]Surge1223[/MENTION] is also a great source of information too.
[Verizon Samsung Galaxy S 4] tulth:
Could someone pm me a link to the mdk

series bootloader partitions (sbl1 sbl2 sbl3 tz aboot rpm etc)?
[Verizon Samsung Galaxy S 4] knox0x1:
I'm just following this thread.. are we talking about the bootloader for Verizon note 3? Just curious cause it would be nice to see development still in progress.
[Verizon Samsung Galaxy S 4] Walter.White:
[MENTION=974229]Cobaltikus[/MENTION] I think instead of attacking bootloader from chain-of-trust, side of things you should try to look into Rollback and Testbit qFuse. And seeing if blowing the testbit qFuse will allow us to use unsigned Kernels/Recoveries.

We could possibly use the following TZ exploit to blow that qFuse. I just wished Dan had released the exploit code he used to blow qFuse on Moto X to unlock bootloader.

https://www.blackhat.com/docs/us-14/materials/us-14-Rosenberg-Reflections-on-Trusting-TrustZone.pdf

https://www.blackhat.com/docs/us-14...berg-Reflections-On-Trusting-TrustZone-WP.pdf

Also here is the similar type of exploit that was present in HTC's implementation of TZ..and how it was exploited.

http://atredispartners.blogspot.com/2014/08/here-be-dragons-vulnerabilities-in.html
[Verizon Samsung Galaxy S 4] tulth:
well at least the tz is loaded fairly early. i suspect that even if the tz is patched you can still flash the old one. In other words, it probably does not check fuse numbers like aboot.
[Verizon Samsung Galaxy S 4] Walter.White:
I think the TZ does have rollback protection.

When you boot into download mode you will see.. A#= aboot, T#=TZ etc. But for ATT N3 we can still rollback to the vulnerable TZ..so there is that.
[Verizon Samsung Galaxy S 4] tulth:
well that sucks. At least if the test bit disables rollback protection there should be similar code in both spots. . might make it easier to find.
[Verizon Samsung Galaxy S 4] npjohnson:
I just contacted Dan Rosenberg, he said he was interested in the test bit idea. But wanted to check something before we began further work. Everyone here is in agreement, Blowing the Test-Bit will disable Roll Back protection? The logic in the psudo code sounds like it should... But I just want to check.
[Verizon Samsung Galaxy S 4] tulth:
I personally am not sure of that at all yet. The code I see on the s4 indicates it exists, but not what it does. Ryan seems to have an inside source (or is the source!) and he seems confident it disables rollback on the note3 (not s4)
[Verizon Samsung Galaxy S 4] npjohnson:
I understand from your posts that it is at least referenced in the S4's boot chain, which seems good! God, I wish there was a way to test this without potentially blowing up a 600 dollar device. XD
[Verizon Samsung Galaxy S 4] Surge1223:
I don't use my s4 and I have jtag, so I'll test when things become more solid..things are still being figured out.
[Verizon Samsung Galaxy S 4] npjohnson:
Awesome. Considering no one has even found it yet, yeah... We've got a long way to go. XD
[Verizon Samsung Galaxy S 4] Surge1223:
Also just a general message to all, let's not go all around to s5, note 3, note 4 threads promoting this. We enjoy a certain amount of freedom here (maybe because this is an obsolete device?) but I if we have a bunch of people coming in asking "if this will work on so and so device" we could easily see progress be halted. I don't blame those users for asking, not their fault but it's the chain reaction that causes that I'm afraid of. Just thought I should mention.
[Verizon Samsung Galaxy S 4] npjohnson:
Agreed. Plus neither the Note 4 or the S5 are vulnerable to Dan's QSEE TZ Exploit.
[Verizon Samsung Galaxy S 4] Hashbang173:
In addition, even if it would allow them downgrade their bootloader, it would not gain them anything. From my prior knowledge those devices do not have any bootloader exploits like the S4 has (loki on mdk).
[Verizon Samsung Galaxy S 4] npjohnson:
True enough, but all S4 variants and possibly S3 variants could benefit.
[Verizon Samsung Galaxy S 4] Hashbang173:
Yes, devices that received an update patching a custom kernel method could benefit. On the S4 the me7 update patched the loki exploit on mdk. The S4 could benefit from this by being allowed to downgrade back to a bootloader that doesn't have a patch from Samsung that blocks loki.
[Verizon Samsung Galaxy S 4] ryanbg:
This. Guys please don't bother researchers either. If it was a high-value target for them they'd already have done it.
[Verizon Samsung Galaxy S 4] XxD34THxX:
Quick addition: What is the difference between safestrap and TWRP. HOW DOES SAFESTRAP avoid the locked bootloader? I'd asking this here because I read through and saw the "trust zone" thing. Does safestrap circumvent this, and how so? What ARE the major modifications? I can't find any mention of this from Hashcode or anyone else... and I do not know much about Android, my primary code experience is on PC and Linux.. Also, this "Dan" who made his "QSEE TZ Exploit", why does he not wish to release his code. Or is there some explanation that I missed. Plus, can we compare the code from an MDK s4 to a... nc5 s4? Perhaps that may shed light on the qfuse stuff.

EDIT: It avoids it by flashing a touchwiz based ROM... What are the pieces of Touchwiz that must be kept...
[Verizon Samsung Galaxy S 4] jj22212003:
the reasons are all kernel and bootchain related.... research the respective forums and the direct answers are there.

As for dan im sure he has his reasons.
[Verizon Samsung Galaxy S 4] chuciulla93:
We already know the differences in the bit code, at least where it matters. The hole which allowed us to get around the limitations imposed by the chain of trust was patched and so far we can't find any others that we're able to leverage to the same extent. There's a lot of interesting talk on it earlier in the thread, including line numbers and commentary. About Dan not releasing his code, there could be any number of legitimate reasons and it's well within his rights. My thoughts: If he had any inside help or discovered/utilized any other weaknesses not yet known, device makers and carriers would definitely take advantage. If that's the case, his source could really hurt the Dev community, as has happened in the past before. Again, these are just my thoughts and, regardless of his reasons, Dan has the right to withhold his code.
[Verizon Samsung Galaxy S 4] npjohnson:
The only part we cannot flash is an unsigned bootloader, or any kernel.
[Verizon Samsung Galaxy S 4] dmc2359:
Jcase uses Dans QSEE TZ vuln in Sunshine to unlock certain Moto devices, if blowing the test bit truly does disable rollback protection maybe he will add support for the s4 into Sunshine and then charge everyone $25 a pop to use it....money well spent imho.
[Verizon Samsung Galaxy S 4] XxD34THxX:
How does one enable the secret menu? I feel like this has been done, but i want to see what is the difference, if there is any, between the boot of a normal device and that of one with a SAFESTRAP ROM
[Verizon Samsung Galaxy S 4] dmt010:
/stabshimself
[Verizon Samsung Galaxy S 4] npjohnson:
Let me save you the pain, safestrap intercepts the boot process at a low level using the logwrapper, then proceeds the boot process normally.
[Verizon Samsung Galaxy S 4] SamuriHL:
No offense meant to anyone but the SafeStrap stuff really just does not belong in this thread. It has nothing to do with unlocking the bootloader whatsoever. If you want to learn about SafeStrap, there are better threads for that. I'd much rather read about the experience people are having with attempting to allow rollback. Being able to downgrade to a version that is susceptible to loki would be incredibly powerful.
[Verizon Samsung Galaxy S 4] doubleaykay:
Looks like no one has taken you up on your offer so I will: please, point us in the right direction!
[Verizon Samsung Galaxy S 4] npjohnson:
Incorrect, I looked into it, [emoji14] and am working on it, and after my research (I also ran my thoughts by Dan R., and he seemed to agree) Ryan is right (partially)! If 0xfc4b80ac is blown to 0x80030 then the "SVS SYS" Secure Revison (Roll Back Protector) will be disabled, though only for Kernel/Recovery (More on that later). The issue Dan brought up is that ODINs integrity check would prevent us from downgrading aboot, even if rollback is disabled (Don't want to cluster the thread with info about that part, if you want to know more about that, PM me.), and unfortunately, Dan also came to the conclusion that SBL1 doesn't reference or check the TESTBIT QFUSE, meaning that Aboot rollback couldn't be disabled with it (Only Kernel/Recovery Rollback), I haven't had the chance to dig through SBL1 yet, but would assume this is accurate, as it sounds completely plausible. Now, kernel/recovery rollback being disabled doesn't really help us a whole lot, as the kernel isn't what was exploited by LOKI, Aboot was. Recovery Rollback has the potential to do interesting things, but thats not my spectrum of expertise (neither is this, for that matter [emoji14])

[MENTION=766721]ryanbg[/MENTION], what do you think about this, am I missing something?

[MENTION=4708661]muniz_ri[/MENTION], Sorry to randomly reference you here, but I had a question, if we dd a signed kernel from safestrap recovery, it will not stick. But is there a special error code presented? I haven't had my S4 for a little while.

On the note of the S4, all the above research was done on the VZW Note 3's NC2 Aboot, SBl1, SBI, and Boot.img, and none of it was done on the S4, but, if someone wants to find the TEST BIT location on the S4, (I recommend using the NC2 firmware, as there are some special characteristics you won't find in non-leaked firmwares), and present it here, then we can start (trying) to apply this to the S4. I've been unable to find the test bit on the S4, but have seen it referenced (a good sign).
[Verizon Samsung Galaxy S 4] Cobaltikus:
I'm building this to help. CobaltDebugger: http://youtu.be/L5NDob2rCmI
[Verizon Samsung Galaxy S 4] npjohnson:
This looks sweet, could you add an export as IDB file button? That'd be awesome.
[Verizon Samsung Galaxy S 4] jhasty01:
A while back in this thread I remember reading about a method for bypassing ODIN's integrity check. Surge I believe knows.
[Verizon Samsung Galaxy S 4] Cobaltikus:
I'm not sure what the goal would be. Maybe we can discuss it outside of this thread.
[Verizon Samsung Galaxy S 4] doubleaykay:
Guys, looks like we have all the pieces right here.

First, as [MENTION=5848265]npjohnson[/MENTION] said, we can blow 0xfc4b80ac to 0x80030 and now we have roll-back protection disabled for Recovery and Kernel. This should be enough to tide us over (unless a custom kernel will still mess up the signature verification chain despite rollback protection disabled...).

Next, as [MENTION=2052904]jhasty01[/MENTION] said, Surge knows how to disable the ODIN integrity check. We can use this once Aboot Rollback Protection has been disabled.

As for the Aboot Rollback protection, I believe we should start looking for the TESTBIT QFUSE, this tool:

should be able to help us, I believe (kudos to [MENTION=974229]Cobaltikus[/MENTION])!!!!

I propose we follow that course of action. First getting Kernel/Recovery protection disabled then focusing on Aboot Rollback protection and getting that disabled.
[Verizon Samsung Galaxy S 4] npjohnson:
Well, kernel/recovery rollback is all that masking TESTBIT appears to disable, as SBL1 doesn't seem to reference the test bit, meaning that aboot couldn't be downgraded using the TESTBIT fuse. That was my fear that was all but confirmed by the lack of references in SBL1, and it also explains why one of the other users found no TESTBIT references in the S4's SBL1.

TL;DR - The TESTBIT doesnt seem to possess the capability to disable aboot rollback, and without that in place, kernel/recovery downgrading means nothing.

I think you may be confused, disabling kernel/recovery rollback doesn't allow unsigned (ie GPE kernels) kernels, it only allows older kernels such as MK2, or MDK (same applies to recovery), and what we really need to get at is the aboot partition, as that would allow custom recoveries via Loki, but it is seemingly impossible with TESTBIT alone. In other words after masking the fuse, a stock MDK TAR would not flash, as SBL1, Aboot, and multiple other partitions have specific fuse checks that are checked whether or not rollback via the test bit is set.

And I am unsure of any other fuse that references the SVC SYS function that is what prevents rollback. Meaning I don't know where to go from here.

Side Note: Something that could help now is someone confirming/finding TESTBIT on the S4, as that hasn't even been accomplished yet. All I can speak for is the Note 3.

---------- Post added at 11:26 PM ---------- Previous post was at 11:20 PM ----------

IDB, ugh, my bad, autocorrect, I meant export as TXT for the sake of being able to ctrl-f and such. But yeah, I'll take it to PM if I need to ask any more questions about it.
[Verizon Samsung Galaxy S 4] muniz_ri:
In regard to your kernel question, it will not trigger an error code. Hash made is so it appears the flash was successfull when in reality the boot.img is ignored by SS. His initial SS release allowed for flashing kernels then he changed it after some guy hardbricked.
[Verizon Samsung Galaxy S 4] npjohnson:
Ah. So dd'ing the image will actually accept it, but it will just hard brick the device. Thank you. Much appreciated.
[Verizon Samsung Galaxy S 4] Surge1223:
dd'ing a kernel will just bring up the firmware error screen. To hard brick you actually need to interrupt the boot chain at a critical point, such as sbl1, aboot etc. Anything after aboot *should be recoverable.

There are caveats to the above obviously so any readers who happen upon this and decide "oh I'm going to Google the command to dd a kernel image onto my phone and see if by chance it works" I have no sympathy.

Another thing is you can totally have a custom image flashed to the recovery partition and resume booting normally (as long as you don't boot into recovery). So in other words the recovery partition isn't actually checked during normal boot. I have always thought about flashing a custom boot.img to the recovery partition and using kexec to boot that kernel after the device was brought up (but I never got around to trying) but this is neither here nor there for what is currently being discussed.
[Verizon Samsung Galaxy S 4] tanishq.dubey:
Rowhammer Exploit?

Bit-flipping at the low level? Perhaps this could help:

(http://googleprojectzero.blogspot.com/2015/03/exploiting-dram-rowhammer-bug-to-gain.html.

I'm only a freshman Computer Engineer, but as far as I understand, if something like rowhammer could be executed at the low level, we might be able to change how some of the verification works?

EDIT: Seems like is it only a kernel exploit as of now. But could it have any applications in modifying the bootchain memory?
[Verizon Samsung Galaxy S 4] npjohnson:
My bad, I misused the term. XD

Huh. That's interesting, would the kernel being on the recovery partition be any different/yeild different results than kexec from an image? I'd assume it would hang at the same place.

Side Question: Do you know where is Download Mode stored? (I mean like, is it on a specific partition?)
[Verizon Samsung Galaxy S 4] Walter.White:
I think it's in aboot.
[Verizon Samsung Galaxy S 4] tulth:
Since aboot is already digitally signed and verified, it is possible (likely) that the rollback check for aboot is within aboot. If we blow the test fuse and it does disable the rollback check, then we could flash the mdk aboot and use the loki exploit to load custom kernels right?
[Verizon Samsung Galaxy S 4] KaratemanTJ:
I don't want to distract from the current interest in the test mode qfuse, but I was hoping for some clarification. On Dev devices, aboot uses the serial # of the eMMC chip to verify that the version of aboot corresponds that device, right? Has anyone looked at changing the serial number to match that of a Dev phone and then flashing that aboot?
[Verizon Samsung Galaxy S 4] doubleaykay:
That wouldn't work as each Dev edition phone is unique and I assume we would need a different code for each device we want to convert.
[Verizon Samsung Galaxy S 4] npjohnson:
Nope. As stated above, from the looks of it, test bit only disables kernel and recovery rollback. As SBL1 verifies aboot, and SBL1 doesn't check the TestBit

I've thought about that, but no, it isn't just the serial number, its the CID, and from my understanding, you can't change that/there would be rep repercussions if you did.
[Verizon Samsung Galaxy S 4] aigochamaloh:
Just spent 4 hours reading DR papers and getting up to speed. Certainly a lot to sort though, but I think I have the gist of it. Interested in trying to help. I'm using a S5 as my DD, so the S4 is sitting in the box on MK2 firmware.
[Verizon Samsung Galaxy S 4] RuggedHunter:
Great, thanks! Some recent developments in this thread the past few weeks should be reviewed, if you haven't already. Then, I think there's been a request for help locating the TEST BIT in the S4.

:beer: :thumbup:

AT&T S4 i337 > SafeRoot > SafeStrap 3.71 > HyperDrive RLS12

Tasker-ized
[Verizon Samsung Galaxy S 4] aigochamaloh:
Yea, I'm not too versed on the KEXEC development, but the fuse checking and etc make sense to me.

Someone said to use NC2 as there is something interesting in it not in other firmwares? I guess I need to flash it and dump the partitions, unless someone has done it already.
[Verizon Samsung Galaxy S 4] dmt010:
If I'm able to help I'll look around as well
[Verizon Samsung Galaxy S 4] aigochamaloh:
Wow still on MDK.
[Verizon Samsung Galaxy S 4] Cobaltikus:
CobaltDebugger

http://xdaforums.com/android/software-hacking/cobaltdebugger-t3052263

If you load aboot.mbn and just let it run, it will eventually throw an exception when it hits an instruction I have not yet implemented, but it may still be helpful. It's not complete but I don't have much time, so I figured I'd just go ahead and share it now.
[Verizon Samsung Galaxy S 4] npjohnson:
You don't need to flash it, just extract the NC2 tar file.
[Verizon Samsung Galaxy S 4] evilryry:
Just a small input... Sorry if this doesn't help. Verizon's lra partner carriers phones have unlocked bootloaders. I use one of those carriers. As far as the Samsung ones go they are seemingly nearly identical, even having the same fcc-id. But with unlocked bootloaders. The model for s4 is SCH-I545L. The s5 is also in the same boat with the similarities but unlocked bootloader. My question for you guys is, would the files of the 545L be of any benefit to you guys or no? I was talking to someone about dd'ing the bootloader but he never got back to me. Sorry if this is not any help.

Sent from my Supercharged KT Powered S5
[Verizon Samsung Galaxy S 4] npjohnson:
99% chance it would fail due to hardware checking. Same reason that the i9505 bootloader can't be flashed.

Though, it would be interesting to compare and see how an unlocked aboot for our device would work.
[Verizon Samsung Galaxy S 4] dmt010:
I was able to find some pretty pictures within my MDK aboot.mbn! Enjoy

00000674.jpg: JPEG image data, JFIF standard 1.01
00000778.jpg: JPEG image data, JFIF standard 1.01
00000927.jpg: JPEG image data, JFIF standard 1.01, comment: "LEAD Technologies Inc. V1.01"
00000954.jpg: JPEG image data, JFIF standard 1.01
00001046.jpg: JPEG image data, JFIF standard 1.00, comment: "LEAD Technologies Inc. V1.01"
00001048.jpg: JPEG image data, JFIF standard 1.01
00001427.jpg: JPEG image data, JFIF standard 1.01
00001437.jpg: JPEG image data, JFIF standard 1.01
00001448.jpg: JPEG image data, JFIF standard 1.01
00001492.jpg: JPEG image data, JFIF standard 1.01
00001501.jpg: JPEG image data, JFIF standard 1.00, comment: "LEAD Technologies Inc. V1.01"
00001503.jpg: JPEG image data, JFIF standard 1.01
00001508.jpg: JPEG image data, JFIF standard 1.01
00001707.jpg: JPEG image data, JFIF standard 1.01
00001714.jpg: JPEG image data, JFIF standard 1.01
00001725.jpg: JPEG image data, JFIF standard 1.01
00001736.jpg: JPEG image data, JFIF standard 1.01
00001747.jpg: JPEG image data, JFIF standard 1.01
00001757.jpg: JPEG image data, JFIF standard 1.01
00001765.jpg: JPEG image data, JFIF standard 1.01
00001777.jpg: JPEG image data, JFIF standard 1.01
00001792.jpg: JPEG image data, JFIF standard 1.01
00001804.jpg: JPEG image data, JFIF standard 1.01
00001817.jpg: JPEG image data, JFIF standard 1.00, comment: "LEAD Technologies Inc. V1.01"
00001819.jpg: JPEG image data, JFIF standard 1.01
00001834.jpg: JPEG image data, JFIF standard 1.01
00001843.jpg: JPEG image data, JFIF standard 1.01
00001853.jpg: JPEG image data, JFIF standard 1.01
00001862.jpg: JPEG image data, JFIF standard 1.01
00001872.jpg: JPEG image data, JFIF standard 1.01
00001889.jpg: JPEG image data, JFIF standard 1.01
00001901.jpg: JPEG image data, JFIF standard 1.02
00002302.jpg: JPEG image data, JFIF standard 1.01
00002313.jpg: JPEG image data, JFIF standard 1.01
00002323.jpg: JPEG image data, JFIF standard 1.01
00002330.jpg: JPEG image data, JFIF standard 1.01
00002354.jpg: JPEG image data, JFIF standard 1.01

Every little bit counts.. heres my 2cents.
[Verizon Samsung Galaxy S 4] npjohnson:
Haha. I see what you did there.

I hate to be that guy, but this thread has actually gotten on a fairly productive track, so next time, could you take non-bootloader unlock related stuff to a new thread? (Meant in the nicest way)
[Verizon Samsung Galaxy S 4] dmt010:
Yea yeah, Ill stay constructive. Sorry about that. Enjoy the images .
[Verizon Samsung Galaxy S 4] evilryry:
Even with practically a 99% similar device, same deal? Sorry for my ignorance just was trying to offer my two cents. There's VZW code in the system and aboot.

Sent from my Supercharged KT Powered S5