yashsingh1/xdaforums huggingface dataset:
[Verizon Samsung Galaxy S 4] npjohnson:
1: Odin checks the device identifier at a very low level (unmodifiable), so it wouldn't flash

2: After some research, it seems the L model doesn't have the qfuse blown that causes the system to revert to locking the boot loader. On the non-L versions of the device, we have a microscopic fuse blown that causes the phone to revert to being locked, and then requires a specificially crafted (signed with Samsung's RSA and private key) aboot to be unlocked (ex. VZW DEV EDITION S4's). The L edition doesn't know any better, and doesn't even have to check for locked or unlocked.

Thank you for sharing these though, it was helpful to see what a similar chipsets truely unlocked aboot would look like.
[Verizon Samsung Galaxy S 4] evilryry:
Sorry for bothering I just wanted to see if it was of any use, wish it was helpful lol

Sent from my Supercharged KT Powered S5
[Verizon Samsung Galaxy S 4] ryanbg:
Test bit will disable all rollback protection, not just disable kernel/recovery rollback. It does not disable signature checking. It may not work on SBL at PBL level, but that's irrelevant.
[Verizon Samsung Galaxy S 4] jaw20:
I love how ryan loves to crank the hype machine in this thread, but on a more relevant note, have we found the test bit on the s4 or have we stopped looking for it?

Hopefully this should be of some use.
[Verizon Samsung Galaxy S 4] tulth:
Can someone explain the discrepancy between the 0x706000 and the 0xfc... fuse addresses?

Is it just different between the s4 and n3? Or does the boot (pbl) processor see a different memory layout than the krait?

Or perhaps the 0xfc... addresses are for specifying fuses to the TZ module?
[Verizon Samsung Galaxy S 4] KaratemanTJ:
Rather than blowing fuses and hoping for the best, someone with JTAG can just modify the qfuse shadow register / memory location to test this, correct? (One we have a location for the test bit fuse, of course.)
[Verizon Samsung Galaxy S 4] jaw20:
People in the thread correct me if i'm wrong but jtags cant modify the shadow reg as that is protected by a qfuse or some other protection that we cant get around by using a jtag.
[Verizon Samsung Galaxy S 4] jaw20:
Hey, check this address 0x88E15E36

Looking back, that is whats stated in the aboot code for the location of the testbit.

Just saying its a possibility.
[Verizon Samsung Galaxy S 4] npjohnson:
Upon brief spot checking, you seem to be right. But now we need to know what to mask it to as to disable roll back. (Likely different then the N3)
[Verizon Samsung Galaxy S 4] jaw20:
By blowing the fuse doesn't it set the fuse's value to 1? People more familiar with fuse are welcome to correct me, but don't we need the otg address before we can set any values?
[Verizon Samsung Galaxy S 4] npjohnson:
My bad, I didn't fully clarify, yes, we do need the otg address.

For example: 0xfc4b80ac is masked to 0x80030, this will disable roll back on the note 3
[Verizon Samsung Galaxy S 4] jaw20:
Hmm... If we know the index then we will be able to find the otp address. There was an equation for calculating the index. (Addres-otp)/ 0x10 . I think I remember a value that looked like the index in the aboot code posted in this thread. I'll look around the thread and if I come up with anything useful ill post again.

EDIT

I think I found it and if this is the index then we have the otp address which will then allow us to blow the test bit.

Possible Index: 0xFF or 0xFF00

Possible OTP: 0x88e15d37 or 0x88e05f36

EDIT 2 [MENTION=5848265]npjohnson[/MENTION] or [MENTION=3755964]tulth[/MENTION]

Could you check this refrenced area here when you have the time?

sub_88E15DE0+54j
[Verizon Samsung Galaxy S 4] tulth:
I took a break from this but maybe I should get back into it. When I left off, I wanted to reverse the sbl1 some to see where it put the derived qfuse security structure that others have alluded to.

It kinda seems like aboot just references this struct instead of directly reading the qfuses. It looked like this struct sat at 0x91000000

So it would be cool to find the 0x91... address of the printed test bit. Next, find where this is written in the sbl1. Then find out how and where sbl1 reads the qfuses to create the data written to 0x91...

After that work, we would have the qfuse test bit address.

What remains? Finding the real test bit check code in aboot; the code mentioned recently is just printing routines, not the real checking routines. Then figuring out what value to write and confirming that the testbit does disable the rollback check.

Then somehow we have to blow the rigjt data. possibly this would be leveraging the tz exploits mentioned, but perhaps just some kernel level code calls could do it.
[Verizon Samsung Galaxy S 4] npjohnson:
I'll take a look when I get home.
[Verizon Samsung Galaxy S 4] jaw20:
We think we have found the address of the test bit. We still need the otp address for the base fuse.

Also, the things that you found in aboot had the address for the test bit. Plus it xref something, i was wondering if you could find what it was xrefing.
[Verizon Samsung Galaxy S 4] jaw20:
[MENTION=3755964]tulth[/MENTION]

Maybe I wasn't that clear with the last statement I made. The aboot code that you gave us, refrences a routine at this address sub_88E15DE0+54j. If we were to identify what that address contains, it may leads us straight to the addresses of the test bit. I say addresses as we still need the base fuse address.
[Verizon Samsung Galaxy S 4] ryanbg:
I'm curious about doing this via JTAG. Unfortunately I burnt off the JTAG pads on my S4 long ago, so now it's scrap PCB. I've got a Z3x box, but I'd be more interested in doing it via Trace32 or OpenOCD. We'd need a Riff box... [MENTION=4939386]Surge1223[/MENTION] ;)
[Verizon Samsung Galaxy S 4] tulth:
I'm not that great at reversing arm but I think that section is part of the "print the KNOX security state" routine. I would like to see what you/others think. And it would be interesting to see the test bit print tracked back to a memory location
[Verizon Samsung Galaxy S 4] jaw20:
[MENTION=3755964]tulth[/MENTION]

Possibly, but we should try to go through all available options, and if possible there may be other xrefs that may be on that next address.
[MENTION=766721]ryanbg[/MENTION]

Couldn't we use a program like u-boot to blow the Qfuses?
[Verizon Samsung Galaxy S 4] npjohnson:
I havent heard of using uboot to blow fuses. I know that TrustZone can, and my bet would be, that if we figure everything out (otp address, base address, etc), and contacted dan about his QSEE vuln, I think he'd be interested in helping out.
[Verizon Samsung Galaxy S 4] jaw20:
Ok, I'm going to be disassmbling and decompiling aboot later today to check any further leads. Also, was anything found at that address that was xref'ed?
[Verizon Samsung Galaxy S 4] npjohnson:
Haven't looked yet :) will today
[Verizon Samsung Galaxy S 4] jaw20:
[MENTION=4939386]Surge1223[/MENTION]

I had seen in a post from a long time ago that you had a way to allow IDA Pro to read .mbn files using a python script. Could you hit me up on a pm about this?
[Verizon Samsung Galaxy S 4] npjohnson:
Ditto please.
[Verizon Samsung Galaxy S 4] Walter.White:
[MENTION=5552234]jaw20[/MENTION]

Here

http://xdaforums.com/showthread.php?t=2641245

https://github.com/daxgr/qcom-mbn-ida-loader

https://github.com/ralekdev/mbn_ida_loader

https://github.com/cycad/mbn_loader
[Verizon Samsung Galaxy S 4] tulth:
okay i took another look at this...

I looked at SBL1 (which is strange its MBN header is like no other), and I could not find it writing to the 0x91... series address.

So I took another look at the test bit printing code block (recent series aboot):

loc_88E15EAE
MOV.W R0, #0xFF00
LDR R1, =aTestBitD ; "TEST BIT: %d"
MOVT.W R0, #0xFF
BL print
B loc_88E15E36

The above code block is branched to from the following code blocks (testbitlookup is my name because i think thats what it does!):

loc_88E15E2C
BL testbitlookup
CMP R0, #2
MOV R2, R0
BEQ loc_88E15EAE

loc_88E15E92
LDR R1, =0x88E3FE6C
ADD R0, SP, #0x70+var_6C
BL sub_88E1CE24
MOV R0, #0xFFFFFF
ADD R1, SP, #0x70+var_6C
BL print
BL testbitlookup
CMP R0, #2
MOV R2, R0
BNE loc_88E15E36

Note that it seems to print test bit, R0 must be set to 0x02 on returning from testbitlookup.

So what does testbitlookup look like? See here:

testbitlookup
MOV.W R3, #0x438
MOVW R0, #0x7A60
MOVT.W R3, #0x70 ; 'p'
MOVT.W R0, #0x88E3
PUSH {R4,LR}
LDR R4, [R3]
MOV R1, R4
BL sub_88E1C3B8
MOV R0, R4
POP {R4,PC}
; End of function testbitlookup

Now this is interesting to me... Register R3 gets loaded with 0x700438, and that sure looks like a qfuse address!

Now what does R0 point to?

.data:88E37A60 aQfpromCommBitD DCB "QFPROM comm bit: %d",0xA,0

Interesting stuff!

Also, R0 which should be set to 0x02 on returning here, is copied over from R4 on returning from sub_88E1C3B8.

So what does sub_88E1C3B8 look like?

sub_88E1C3B8

var_134= -0x134
var_130= -0x130
var_120= -0x120
varg_r0= -0x10
varg_r1= -0xC
varg_r2= -8
varg_r3= -4

PUSH {R0-R3}
PUSH {R4,R5,LR}
SUB SP, SP, #0x11C
ADD R4, SP, #0x138+varg_r0
LDR.W R5, [R4],#4
BL sub_88E0DD14
MOVW R2, #0x39A0
MOVS R1, #0xD
MOVT.W R2, #0x88E4
MOV R3, R0
ADD R0, SP, #0x138+var_130
BL sub_88E1CE44
ADD R0, SP, #0x138+var_130
BL sub_88E1C3A0
MOV R3, R4
MOV.W R1, #0x100
MOV R2, R5
ADD R0, SP, #0x138+var_120
STR R4, [SP,#0x138+var_134]
BL sub_88E1C87C
MOV R4, R0
ADD R0, SP, #0x138+var_120
BL sub_88E1C3A0
MOV R0, R4
ADD SP, SP, #0x11C
POP.W {R4,R5,LR}
ADD SP, SP, #0x10
BX LR
; End of function sub_88E1C3B8

The hole just goes on and on. And that is as far as I have taken it.
[Verizon Samsung Galaxy S 4] npjohnson:
Wow. That's a really interesting find! Man, stuff is getting a tad bit over my head now XD. I understand how you identified the testbitlookup, but as for tracing it from there... Bravo man, I suppose further down the rabbit hole. XD
[Verizon Samsung Galaxy S 4] tulth:
wow, over at the real hacker source:

http://blog.azimuthsecurity.com/2013/04/unlocking-motorola-bootloader.html?m=1

This exact address is mentioned, 0x700438 for unlocking the Motorola razr hd family.
[Verizon Samsung Galaxy S 4] Cobaltikus:
IDA Pro has always been able to read mbn files. You just need to set the processor type to ARM little endian and set the proper address offsets. You can get those address values from my program CobaltDebugger which is no IDA substitution by any means, yet, but it's a good companion tool for now. It can read the headers and instructions for aboot.mbn, sbl1.mbn, and possibly boot.img. once you have stepped through a few instructions you can jump to executing instructions at any address by editing the PC register value.
[Verizon Samsung Galaxy S 4] npjohnson:
I know that many Qualcomm phones use similar qfuse beds.... B) could be a good lead...
[Verizon Samsung Galaxy S 4] Surge1223:
Yeah I need to check something in the script first so I'll send tomorrow. In the mean time Ralekdev's script is excellent (I used a lot of his code especially his Dword implementation)

P.S. Everyone here working on things recently... It might be beneficial to start a Google hangout/telegram chat so you guys can discuss in real time. I know xda wants to keep development on the site but in a situation like this I could see real time chats being more beneficial (xda messenger apk? hint hint xda lol). But by all means keep discussing here and sorry I haven't been involved lately (working on kernels currently has me distracted)
[Verizon Samsung Galaxy S 4] jaw20:
What version of the gs4's software did you take your aboot file from? It may be good for us to all be synchronized on the same version so there won't be discrepancy between the aboot code. This may not be a huge problem but if the code is different across version it would be good to all be on the same version of aboot.

I guess I'll have to go down the rabbit hole. Also, [MENTION=3755964]tulth[/MENTION] what address was the code found on, as I can't seem to find it.

With what surge mentioned, if any of you want to start discussing things in real time my username in telegram is jaw20.
[Verizon Samsung Galaxy S 4] ryanbg:
U-boot is a bootloader itself. It'd be pretty impossible to use an unsigned bootloader on a device that uses signature verification. Isn't that our goal anyways?
[Verizon Samsung Galaxy S 4] jaw20:
I think I may have misunderstood what U-boot was, and thanks for clarifying.

---------- Post added at 01:15 PM ---------- Previous post was at 12:37 PM ----------

Something in me has the suspicion that this was what hellsdr0id was using to rollback phones from ME7 or whatever to MDK.

I think going further into those sub might help reveal the mask of the testbit fuse.
[Verizon Samsung Galaxy S 4] kcarden:
http://www.stlinux.com/u-boot/using

Been following you guys for some time now and I finally get to contribute! :cool: Thanks for all y'alls hard work!

Sent from the eclipse of the galaxy
[Verizon Samsung Galaxy S 4] npjohnson:
I would say to either use NC5, or NC2, as they are the most popular firmware. And can be rolled back to by newer OTAs.
[Verizon Samsung Galaxy S 4] jaw20:
Ok, as last night I was looking at mj7 or something. I'll try and grab a full factory wipe img of nc2 or nc5. Also, what do you think about collaborating over telegram?
[Verizon Samsung Galaxy S 4] npjohnson:
Never used telegram, but I'll take a look. I'd definitely be interested.
[Verizon Samsung Galaxy S 4] jaw20:
If you want to contact me through telegram my username is jaw20
[Verizon Samsung Galaxy S 4] npjohnson:
Done [emoji14]
[Verizon Samsung Galaxy S 4] Surge1223:
[MENTION=4939386]Surge1223[/MENTION] on telegram not sure how to start new chats in telegram, I'm a telegram noob but I got this idea from a note 3 group who started a telegram chat for people active in their xda thread. When I joined it they were 30 strong and communicating much easier than they would if on a forum where they'd wait hours between responses. Fair warning I'm usually active at later hours lol. 3 am messages ftw.
[Verizon Samsung Galaxy S 4] jaw20:
Just for a heads up for anyone using ida or is reverse engineering aboot.mbn we are using NK1's aboot
[Verizon Samsung Galaxy S 4] jaw20:
Yesterday good progress was made, but that's all I can say.
[Verizon Samsung Galaxy S 4] tshelby73:
Best news I've heard since I've owned this phone.

Sent from S4 using the better than it was Tapatalk
[Verizon Samsung Galaxy S 4] anthonyg45157:
Glad to see this fight still going strong! Keep it up guys:thumbup:

Thankyou:)
[Verizon Samsung Galaxy S 4] doubleaykay:
Great job! I understand if you can't, but is there an ETA or anything like that you can share?

Also, I made this spreadsheet:

https://docs.google.com/spreadsheets/d/1ZOaZTPSYVXWxPLo0RBgTW7ZJIqSYVFlR1e386uHAwM4/edit?usp=sharing

It lists all the Android versions for the S4, along with their respective build codenames. It also lists the bootloader status, and should contain links to the stock ODIN tar.gz and links to ABOOT or other important files. Its open for anyone to edit; I'm hoping this will help you guys in coordinating this exploit accross all S4s. I do ask that if you all deem it worthy (fingers crossed haha), you maybe add stuff to it!

Also,

I too will kindly ask you guys refrain from posts that are unnecessary... while the majority of the work in this thread has moved to telegram, clutter is still not good! I'm just as excited as you guys are.
[Verizon Samsung Galaxy S 4] npjohnson:
On the subject of ETAs, no, we are just researching at this point.

Thank you for the spreadsheet! We were just discussing other or not ME5 was a production build.
[Verizon Samsung Galaxy S 4] D3Seeker:
:( This thing will implode on itself by time any breakthroughs are made. Oh well. It was a dream for this one
[Verizon Samsung Galaxy S 4] 06sharpshot:
The discussion here should remain relevant to the objective. By discussing the meta (if that's the right term) rather than the actual device you derail the thread. Please keep discussion relevant to the actual device.
[Verizon Samsung Galaxy S 4] Whoop5:
Is JTAG-ing still a possibility for returning to MDK, and if so, could someone PM me how so? I'll be soon changing phones (away from my VZW S4), so I'd be interested in helping in any way possible.
[Verizon Samsung Galaxy S 4] npjohnson:
Nope. Well sort of. You can't JTAG to MDK, but after we find TESTBIT, you could JTAG and change TestBit, then roll back to MDK. (Theoretically)
[Verizon Samsung Galaxy S 4] Whoop5:
Could/are you using JTAG to find TestBit?
[Verizon Samsung Galaxy S 4] npjohnson:
Nah. Its reverse engineering aboot.
[Verizon Samsung Galaxy S 4] JeepinxJosh:
Hey I know you guys are using telegram or something to help with real time updates but can you please keep us updated to where u are at and if we can help in any ways

Sent From My S4 on XDA Free
[Verizon Samsung Galaxy S 4] TTLayland:
They will, be patient.
[Verizon Samsung Galaxy S 4] daredevl99:
cant update when there is nothing to update on :)
[Verizon Samsung Galaxy S 4] XxD34THxX:
I assume that work won't start on Lollipop because it will have similar protection against changing aboot and whatnot, unless some major(or minor) bug gets through..
[Verizon Samsung Galaxy S 4] daredevl99:
When searching for exploits and such newer firmwares always pose a threat with new security and holes being constantly patched.
[Verizon Samsung Galaxy S 4] jaw20:
Heh, about those updates... We're starting to do some field testing on some special things. More updates to come.

EDIT: There may be a surprise in the near future. ;)
[Verizon Samsung Galaxy S 4] dmt010:
The thread needs more MC [MENTION=766721]ryanbg[/MENTION] hype in here to get the juices flowing.
[Verizon Samsung Galaxy S 4] NighthawkXL:
Careful with that #hypetrain

We certainly are looking forward to seeing what happens. But in the meantime folks maintain the status quo...

I do admit though, it's nice seeing S4 activity ramping back up after that lull.
[Verizon Samsung Galaxy S 4] doubleaykay:
A very good point.

Guys, try to keep the hype and speculation at a MINIMUM. The last thing we want is for this to catch the attention of Samsung/Qualcomm and have them patch anything we find. This is a cat-and-mouse game, and the last thing we want is to get caught. We all are really happy, but lets keep it to ourselves! :p
[Verizon Samsung Galaxy S 4] npjohnson:
Agreed. We are getting there. But don't clog up the thread. Nothing is certain, until it is [emoji14]
[Verizon Samsung Galaxy S 4] RuggedHunter:
The lull ended with this post. Weird. :D

http://xdaforums.com/showthread.php?p=58978584

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

Tasker-ized
[Verizon Samsung Galaxy S 4] Rhymey:
Out of curiosity, is this field test being aimed at NC1?
[Verizon Samsung Galaxy S 4] Surge1223:
Clarification

Mostly it's just joint research (i.e., instead of one person reversing all the functions we are dividing and conquering...ish)

Nothing has sprung out of it in terms of new vulnerabilities or an attack plan or anything. You see we have to find out what the code says will/won't happen. Even if something looks "good" we still need to know for sure what will happen if we try anything, that means a lot of reversing luckily there's a solid start.

Also the group on telegram isn't exclusive, so if you feel like you can contribute send me a PM with your telegram username (@username found in profile) and I'll add you or you can post it in this thread.

Please don't ask to be added if you are only going to be a spectator or just want to try to learn. Believe me, it's not a good noob enthusiast learning environment, and I'll post anything learned from this Telegram experiment in a concise, learning-oriented type post for people who are curious at a later time.

But like always, any bootloader/root/vuln/coding talk is welcome here and I will continue to post here as well.
[Verizon Samsung Galaxy S 4] TTLayland:
Way to go guys! Good to hear about these positive developments.
[Verizon Samsung Galaxy S 4] kcarden:
Sorry. Meant to be a pm
[Verizon Samsung Galaxy S 4] lampclip:
I've been following this thread for a while because it has some pretty interesting information, however I have one question. I have a Verizon S3 with a locked bootloader rather than an S4. Will progress in terms of unlocking the bootloader for the S4 also work for the Verizon S3?
[Verizon Samsung Galaxy S 4] DeadlySin9:
That depends on a number of factors like how similar the bootloader is and whether or not the same vulnerability will be present or if they'd have to relocate the testbit or find a different exploit to change it's value. Someone else can probably tell you more precisely how easy or difficult it will be, but bootloader exploits typically don't work between phones as much as things like root.

Sent from my SGH-I337
[Verizon Samsung Galaxy S 4] daredevl99:
I can say the note4 and s4 testbit are different entirely.
[Verizon Samsung Galaxy S 4] JeepinxJosh:
I thought (pretty sure) the S3 was unlockable no matter what carrier..

Sent From My S4 on XDA Free
[Verizon Samsung Galaxy S 4] NighthawkXL:
Only up to a certain firmware (at least on Verizon), basically the same boat the S4 is in. You can unlock the S3 bootloader barring your on the correct firmware or below.

Anyway, back on #topic ~ If anyone wants to see more about the S3 head over to their subforum.
[Verizon Samsung Galaxy S 4] bryantjopplin:
This is pretty amazing to see how much development is for these older phones and how much gets done. Don't get me wrong but the devs that go on to the new devices are nothing less than the best. I think the devs that stay and get these older ones updated are out of this world. True I switched to the nexus 6, but my s4 is still used daily. One on mdk and one mj7. I also use my two gnex on a daily basis that are on 5.1 because of devs that stayed and rewrote drivers and kernels for the newer os. Sorry about the rattling just think that this is the greatest site ever. Lol
[Verizon Samsung Galaxy S 4] gadget!:
I am also excited to see that there is still development interest in this for the S4.

I'm still on one of the the original mdk S4s and am personally not anxious to upgrade.

I'm not excited about anything new that's came out. I am not interested in a sub-tablet sized phone at all.

The S4 is a great phone, one that I have kept longer than any phone I have had.

If there were to be an exploit discovered to unlock versions after mdk I may even consider buying another S4 instead of upgrading.

I don't want a locked down phone, so much so that I have considered switching carriers!

sent from a Galaxy S4 far far away.
[Verizon Samsung Galaxy S 4] bryantjopplin:
Without devs, I wouldn't know what to do. Lol Taken from my mj7 s4 lol
[Verizon Samsung Galaxy S 4] doubleaykay:
Guys, once again, I understand your enthusiasm, but PLEASE don't clog up this thread. This is not a general discussion thread, but rather a development thread. While there may have been a lull in posts by the devs, this does not mean we start an open discussion.

Speaking of the devs, any updates?

EDIT: It has been pointed out to me that this is in fact a general discussion thread. My apologies. Regardless, we should all try to keep this place clean!