yashsingh1/xdaforums huggingface dataset:
[AT&T Samsung Galaxy S 4 Android Development] DooMLoRD:
this looks a lot like the the Xperia T (MSM8960) & Xperia Z (APQ8064)...

since root is achieved you guys can take dumps of the EFS right?

i am not exactly sure how things work on the Samsung devices but on Sony devices there is a partition called TA (TrimArea) which we can take backup of using dd (post rooting)... then unlock bootloader , which makes changes in this area, and flash custom kernels... if we flash back the TA backup then bootloader gets locked again (as good as factory locked)...

may be you guys can check up the following thread:

http://xdaforums.com/showthread.php?t=2234627
[AT&T Samsung Galaxy S 4 Android Development] BeansTown106:
Sprint s4 can flash custom recovery via the old Odin so I'm assuming this new bootloader protection is also not letting u flash anything via Odin that's not properly signed probably because of how the note2 was hacked.

Basically whole point of this message was stating that I don't think we need a "new Odin" as sprints unlocked s4 is flashing fine via Odin. I just preordered the Verizon s4 when it gets here I will help with anything u guys need. I'm assuming they are locked the same way.. Sad to see this happen to att as well now :(
[AT&T Samsung Galaxy S 4 Android Development] turilo:
According to androidpolice website the ATT bootloader is unlockable. Hope this is not true :/
[AT&T Samsung Galaxy S 4 Android Development] munchy_cool:
that's why this thread is here, to unlock it.

also, AP got the news from cyanogen's g+ and this thread was in existence way before that.

Sorry for the OT
[AT&T Samsung Galaxy S 4 Android Development] BeansTown106:
Nothings unlockable.. Find someone with a prototype of the phone and dump his aboot.. That worked on vzw s3 and vzw gtab 2 7.0 and with Adam, ralekdev and jcase working on this something is bound to give ;)
[AT&T Samsung Galaxy S 4 Android Development] AdamOutler:
The T-Mobile dump is online. http://xdaforums.com/showthread.php?t=2258476 thanks to [MENTION=2624398]Quasimodem[/MENTION] for the link. TMobile GS4 is the exact same device and that was determined during the teardown of this device.

[MENTION=2918486]Ralekdev[/MENTION] any chance you can take a look at this when you get a chance? I don't think we can pull IROM from outside the TrustZone Shield. I don't know if we can get away with flashing the entire bootchain.. But we need to determine what will happen if an invalid bootloader is flashed to a device I suppose, and I have access to free JTAG for my device. If you can see any reason that would invalidate this test, let me know.
[AT&T Samsung Galaxy S 4 Android Development] mg2195:
Alright...ive been holding off and just doing pms to those that are disrespecting adams thread by posting useless crap in here because by posting In here I myself am breaking the rules..but after that post im sorry adam I need to say something!

You do realise this is the guy working on unlocking the bootloader for your device so you can flash roms do you honestly think he wants to read that post? Your post just seems like the perfect way to chase devs away. I don't care if you thought you were being funny or joking...this isnt a thread for being funny or joking its a thread to unlock the bootloader

The reason for the thread is for the DEVELOPERS TO COMUNICATE WITH EACH OTHER. This thread is not for everyone saying things like "omg thank you" "your my hero" "im willing to test" "let me know if you need anything" those responses just clutter up threads and make it hard to find the actuall dev related stuff so that they can actually brainstorm together...say what might work and what hasnt...collaborate any body above the age of 10 should be able to understand that this thread is for collaboration purposes between the devs

The guy asked not to post in the thread unless you could post something that would contribute to unlocking the bootloader (yes im aware im currently being a hypocrite) this is his thread lets respect that. I owned the htc vivid...and it was people like you and the many others that didnt respect the devs that cause 90% of the devs to stop sharing their work resulting in only two active roms/devs. I dont want that to happen here

Also...the dev section is for development purposes only. So by posting non development content in dev threads you are breaking the rules (yes im aware im currently breaking the rules and being a hypocrite...and yes im aware this isnt really enforced as its typically up to the dev to decide if he wants to enforce that rule...) dev threads are supposed to he strictly development...if you have issues or problems or want to praise the dev than that is what the Q&A and General sub forums are for

NOW UNLESS YOU ARE CONTRIBUTING TO THE UNLOCKING OF THE BOOTLOADER STOP FREAKING POSTING AND FOLLOW THE RULES IN THE FREAKING OP ***AND PLEASE NO ONE RESPOND TO THIS POST***

-sorry adam and feel free to report this for the mods to delete as I know it is pretty large and will take up quite a bit of space
[AT&T Samsung Galaxy S 4 Android Development] kevnuke:
I actually thought of the same idea earlier tonight. Take an image from a variant from another carrier that isn't locked and flash it on the AT&T SGS4

http://www.xda-developers.com/andro...y-s-4-is-bootloader-locked/#comment-881058684

Hopefully I don't catch on fire for this (get flamed).

Adam, I remember you did a lot of R&D on the Hummingbird processor a while back for the Captivate and came to the conclusion that by sending commands directly to the processor through USB you could do things before the normal boot, like pre-SBL or was it even pre-PBL? I also remember you saying that eventually the manipulation of such commands could lead to all kinds of "pre-boot" mods and tweaks. Not sure if that ever took off but I thought this might give somebody with a higher degree in computer science than me some kind of inspiration for this problem. Different processor, I know, but maybe useful in unlocking the bootloader somehow?
[AT&T Samsung Galaxy S 4 Android Development] Rhamza161:
Did anyone see this recently?

Twitter posts of [MENTION=4229979]djrbliss[/MENTION] having unlocked AT&T's bootloader. photo link

Being a noob, read completely clueless, to development I am lost in this tread, but I saw this on facebook/Twitter and wanted to share, delete if you feel you feel it needs to be.
[AT&T Samsung Galaxy S 4 Android Development] BeansTown106:
Its real djrbliss is a beast as of late first the first ever moto unlock and now this wooohoooooo
[AT&T Samsung Galaxy S 4 Android Development] AdamOutler:
Ok... lemme see if I can word this.... Samsung Knox.. http://www.samsung.com/global/business/mobile/solution/security/samsung-knox

TLDR: I'm pretty sure we don't need to unlock this device in the traditional sence, but just play along with the Knox system to install Cyanogenmod and stuff.

I have high confidence that we can run custom kernels WITHOUT unlocking a device. This device was inteded to be modified with custom kernels, but in a bit of a diferent way than usual.

Examine the following:

Take note that the "Customizable Secure Boot" is located in the Bootloader. This is where the Hardware-Initiated Chain-of-Trust can be broken. All that appears to be required is to install a new certificate...

Now, I say "all that's required", but that is a pretty big task. We need a certificate authority and we need a guide as to how to obtain a certificate, install that certificate and sign our kernels properly. I would assume that each developer would be responsible for maintaining his or her own certificates or we could have a GP test certificate. Either way, this raises the complexity involved in developing an Android kernel to the n'th degree.

However, since security on mobile devices is important, I am researching Samsung Knox now, rather than trying to research how to bypass the security on the Qualcomm Processor.
[AT&T Samsung Galaxy S 4 Android Development] mohan_kr:
At least from the article, it appears swapping the root certificate won't be enough. We will have to erase the TZ policies too, correct ? Since the SEA part appears we can control via custom kernel. (assuming that's the order).
[AT&T Samsung Galaxy S 4 Android Development] AdamOutler:
once the Chain of Trust is broken, there is no need to go higher. On UBM we broke it in IBL. On Exynos 4 we broke it again in the IBL. On most devices it gets broken in the SBL. As long as there is something that can authenticate to the next higher and not care about whats below it, the security is dropped. In this case, we should be able to create our own security and install it for our own "secure" kernel.
[AT&T Samsung Galaxy S 4 Android Development] P1NK13P13:
Just in case for some reason you can't find it or to use a reference, here's the link to AP's article on the unlocked AT&T bootloader article: http://www.androidpolice.com/2013/05/01/dan-rosenberg-has-unlocked-att-galaxy-s4s-bootloader-but-we-wont-get-to-see-how-for-a-while-here-is-why/. Just don't get your hopes up, yet... cheers;)
[AT&T Samsung Galaxy S 4 Android Development] lowspeed:
Wouldn't it be easier to just unlock the bootloader and not mess around with certificates?
[AT&T Samsung Galaxy S 4 Android Development] wdouglass:
Not Necessesarily. (people who know better correct me if i'm wrong) either way it requires some security flaw for unofficial code to be loaded. If a flaw can be found in the certificate mechanism, that's our ticket. if a flaw can be found allowing us to replace the bootloader with one that is not locked (perhaps from t-mobile), then that's our method.

EDIT: typo correction
[AT&T Samsung Galaxy S 4 Android Development] slider2828:
On his twitter he gives a hint...... Is it helpful?

https://twitter.com/djrbliss/

Hint to the XDA folks trying to unlock the Galaxy S4 bootloader: only an RSA-2048 signature on kernel/recovery. Better start factoring!
[AT&T Samsung Galaxy S 4 Android Development] AdamOutler:
That means an unlock will only work until Samsung blacklists that bootloader. Believe me, we aren't going to crack a RSA-2048. We aren't going to be able to break into Qualcomm security. Even if we do , it will be addressed in an update.
[AT&T Samsung Galaxy S 4 Android Development] Curtisbeef:
He didnt refactor the RSA-2048 key. I can 100% guarantee that. If he did he would be collecting a 200,000 prize.

http://en.wikipedia.org/wiki/RSA_numbers#RSA-2048

http://en.wikipedia.org/wiki/RSA_Factoring_Challenge
[AT&T Samsung Galaxy S 4 Android Development] jcase:
He was cracking a joke. That would be highly impractical
[AT&T Samsung Galaxy S 4 Android Development] BeansTown106:
yes but even though it would be blacklisted isnt that what gave ralekdev the insight on how to redo the exploit for the 2nd note 2 jailbreak? either way iirc the motorolla bootloaders he "dan rosenburg aka djrbliss" just unlocked were qualcomm right? he gives a "very indepth" insight on how he accomplished the exploit on a security blog gimme a minute and i will gather all the info and edit my post

also on other terms i am happy he is waiting til the verizon variant ships to publish the exploit that way it can be performed on both :) from AP article "As I mentioned, there is a good reason for why the unlock method will be withheld for now. Let me just nudge your thought process in the right direction. A certain other carrier has a habit of locking down bootloaders. That carrier's GS4 variant is not going to be due out until the end of May (May 30th, to be exact). If the unlock was to be released now, that's a whole lot of time to give someone to fix a thing or two up. And if they do, that door may never open again"

i hope you guys would do the same thing :P only because then its only half the work this is the blog article explaining how the motorolla bootloader was exploited http://blog.azimuthsecurity.com/2013/04/unlocking-motorola-bootloader.html and like i said it is very indepth
[AT&T Samsung Galaxy S 4 Android Development] AdamOutler:
Yep. But, this entire generation of Samsung devices are equipped with monotonic counters. Basically, anything short of replacing the IROM (Internal processor firmware) can be patched over and marked so it will never work again.

Thats always been a Qualcomm feature and its been used by a few manufacturers in the past... But Samsung just included it in their Exynos 5 so its in every GS4 device now.
[AT&T Samsung Galaxy S 4 Android Development] jeboo:
Anyone putting together IDA databases yet? I'm just now starting to look at aboot and tz. djrbliss has given us a great headstart with his moto essay, and we now know a solution exists.

I don't have the device (nor a jtag), so it will be all deadlist analysis here. Nonetheless, this will be fun :)
[AT&T Samsung Galaxy S 4 Android Development] LLStarks:
Can this unlock knowledge be ported back to the Verizon Galaxy S3 and Tab 2?

aboots aren't fun since we really didn't learn much about how they work.

ralekdev and e.v.a pretty much gave up on their solutions once the S3 got its leak.

I hope the aboot doesn't leak before Dan's solution.

This is probably our one shot this year for a proper Secure Boot unlock. Let's not squander the opportunity.
[AT&T Samsung Galaxy S 4 Android Development] AdamOutler:
We have a stock firmware. http://xdaforums.com/showthread.php?t=2261573
[AT&T Samsung Galaxy S 4 Android Development] AdamOutler:
Alright, I guess this should have been on the first page since there is much confusion. Lets talk about the bootloader structures. Here's how Qualcomm works in respect to their chips, and bootloaders.

Qualcomm provides the Qualcomm chip, Modem, example SBLs and a basic kernel structure to the OEMs. The OEMs take those Modems and SBLs and folow a Qualcomm guide. Each part of the bootloader brings up certain things and handles its own security tasks. They initialize in a Chain-of-Trust. The Chain-of-Trust starts with the hardware. It is a Hardware-Initiated Chain-of-Trust. When the bootloaders are "burned" to the device, E-Fuses are blown on the device to lock the CoT into a specific model number.

recap: Qualcomm has procedures for flashing their chips with a bootloader. Flashing a bootloader involves signing the bootloader and basically "signing" the chip at the factory. This means you won't get an i337 bootloader to work on any other device.

Alright. So, when the Qualcomm chip initializes, it runs a tiny program on the chip (we call it IROM or internal Read Only Memory) which initializes the EMMC, loads SBL1 and verifies the signature on the chip against the signature on the SBL1. The SBL1 performs its tasks, verifies SBL2. SBL2 verifies SBL3. SBL3 verifies ABOOT.

ABOOT is the Samsung Odin bootloader. Without checking the manual, I think ABOOT is not part of Qualcomm at all but fee free to correct me. When ABOOT loads, it has the ability to load Odin mode from within the ABOOT partion, it can load Recovery from the RECOVERY partition and it can load the Kernel from the BOOT partition. ABOOT also performs signature checks on files which it loads.

recap: Hardware>IROM>SBL1>SBL2>SBL3>ABOOT>odin or kernel or recovery. They are all signed and authenticated before loading.

Ok, so now, to throw something more in the mix, there's an item called a Monotonic Counter. A monotonic counter is something which is designed to count one direction... up. As in revisioning. The monotonic counter is used along with the signatures to ensure that old bootloader versions can never be flashed again.

Assume I have a file and its signed like xxxadfaadfadfasfdadf. That signature actually represents something like a cryptographic representation of the file merged with an expected value, plus a version. So when that signature is read it is only valid for this file and its only valid for this version of the file and after some math is performed on it it's simply a Yes, this is a valid SGH-i337 bootloader, or No, this is not a valid bootloader.

recap: Monotonic Counters mean if we find an exploit, they can make it so that it wont work. These things are the devil.

I hope this enlightens some people out there. I know that i've been receiving alot of comments "why not just do this" or "why not try that".. I hope this clears up some things.
[AT&T Samsung Galaxy S 4 Android Development] alacrify:
I'm going to try and throw this in before the questions start. If you don't know any of the acronyms (ABOOT, SBL, EMMC, etc.) please use Google and don't ask here - that's where I'm going to fill out my knowledge of the HUGE cool drop Adam just did.

And thank you Adam!
[AT&T Samsung Galaxy S 4 Android Development] dxwilliams40:
+1 Trying to soak everything up like a sponge.
[AT&T Samsung Galaxy S 4 Android Development] CarpeNoctem:
@

AdamOutler

Many thanks for the information, indeed it clarify a lot of things and also helps to understand the complexity of the work, braking the chain of trust without breaking the device.

If I understand what you explain, unlocking the bootloader equals "breaking" the iRom, my question as dumb as it may sounds is: in a chain you always attack the weakest point, is there any other component (SBLx?) that would be "easier" to crack in other to load the needed content.

Also if there is a bug in the hardware like djrbliss suggest it (and if I understood correctly), I suppose there is not way for Samsung to patch it so it is "just" a matter of understanding how to us the bug to load the desired code?

Please correct me if I am wrong and let me know if my questions should be asked somewhere else.
[AT&T Samsung Galaxy S 4 Android Development] BeansTown106:
very informative thanks bud :) i initially knew the sbl steps but didnt realize how low of a level the irom was at that makes me even more greatful of u guys than i arleady am with the original note2 unlock as it was an IROM unlock, not sure if the second was the same thing or not but its probably good that the details for the 2nd never really came out. hents verizon and samsung taking 5 months for an ota when the s3 kept getting them every month or so. have u had a chance to look at the new ota VRAMC3 ? does that patch the second unlock. im imgagining it does and ya those monotonic counters are the devil lol. so the only real way to unlock the bootloader and keep it from being patched is by getting a leak? no? or will a leak even get patched because of the monotonic counters? only reason i ask is because on the verizon s3 no matter what ota we get as long as we have root we can dd the leaked vrale6 aboot and be unlocked (seems like they cant patch it)

sorry if this went a little off topic from the att s4 but just trying to gather the grasp of what all of the above mean and your definetly the person with the most knowledge on this

from what im thinking seems like a leak is unpatchable and an exploit is patchable correct me if i am wrong
[AT&T Samsung Galaxy S 4 Android Development] LLStarks:
I'm curious if the Secure Boot Touchwiz menus are still present.

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

Unfortunately, libuck.so and similar are still missing from the shipped tars.
[AT&T Samsung Galaxy S 4 Android Development] slapdaddy:
Is there a way to disable the monotonic counter? If so, what would happen? Brick?

And this may sound dumb because I have no experience in this, but is there a way to break the CoT or inject your own commands into the process?

Sent from my HTC Vivid.
[AT&T Samsung Galaxy S 4 Android Development] Zer0_:
Ignore Post.
[AT&T Samsung Galaxy S 4 Android Development] funkym0nk3y:
Aboot is a part of qualcomm boot chain. SBL1,2,3,ABOOT,RPM,TZ are needed to boot the device. Aboot verifies the signature checks on the boot which if it found any unsigned code, it will give security error or hang. If the aboot is erased completely from the device, it still have access to download mode (In case of all LG phones atleast). SBL1,2,3,RPM,TZ are needed to access the bootloader of any device, if any of them is altered, the phone will simply refuse to boot and will switch to QHUSB_DLOAD when connected to PC. The manuals shows different boot configs , if triggered with correct value the device can boot from sdcard just like in the case of galaxy s3 and note 2 (Intl variants).
[AT&T Samsung Galaxy S 4 Android Development] LLStarks:
Found some interesting references on glbench

T-Mobile engineering firmware: samsung/jfltetmo/jfltetmo:4.2.2/JDQ39/M919UVEAMCDSA:eng/test-keys

AT&T pre-stock firmware: samsung/jflteuc/jflteatt:4.2.2/JDQ39/I337UCUAMCA:user/release-keys
[AT&T Samsung Galaxy S 4 Android Development] kevnuke:
Speak of the devil...
[AT&T Samsung Galaxy S 4 Android Development] kevnuke:
Watch out for this update, I think it just installed itself..or I accidentally pressed the Continue button in my sleep -.-

EDIT: Should I flash that stock Odin package to get rid of it, or is that a bad idea?

Swyped from the 4th Galaxy on XDA Premium.
[AT&T Samsung Galaxy S 4 Android Development] Anthony04x:
This update is strictly performance, Adam said it was safe I believe
[AT&T Samsung Galaxy S 4 Android Development] jeboo:
Now that we have most of the structural details sorted out, I guess I'll share what I've discovered. First, here are the deduced base addresses for the binaries (from the headers, not exactly sure of the format btw). These are important for IDA analysis and resolving string refs:

aboot: 88e00000

sbl1: 2a000000

sbl2: 2e000000

sbl3: 8ff00000

rpm: 20000

tz: 2a000000

In aboot, my most interesting find thus far is a signature checking function at 88E0A2CC (returns 0/1), called from at least 4 locations. The call at 0x88E10010 is immediately followed by this string ref: "SECURE: signature check fail. (recovery.img)",0xA,0.

The code within this sig function references many supervisor calls (SVC) and also calls some functions in ranges I haven't characterized (0x88.., 89.., 8a..).

That's all I got for now..I believe this is a good test/attack point, especially knowing Dan's exploit showed a Recovery bypass. Any thoughts/ideas? I'm also pondering how a patch would be executed since any change requires upstream authentication.
[AT&T Samsung Galaxy S 4 Android Development] djrbliss:
You're doing fine so far, but I'm a bit confused why you're publishing this information. Of course I encourage anyone who's interested in these things to dig in, but since I've already prepared an exploit, continuing to publish details of your research will at best result in an additional solution (that gets promptly patched because you're talking about it in a public forum), and at worst could result in Samsung finding my exploit. I'd recommend being a bit more strategic about this and keeping your research private unless public collaboration is necessary to produce a solution.
[AT&T Samsung Galaxy S 4 Android Development] AdamOutler:
[MENTION=4229979]djrbliss[/MENTION] can you confirm or deny that you have a tethered exploit? If it is untethered, I agree with you.
[AT&T Samsung Galaxy S 4 Android Development] mattdm:
Is this something that should be answered via PM or does it not matter? I don't know enough to even know the difference.
[AT&T Samsung Galaxy S 4 Android Development] romracer:
On that same note, have you looked at the cat and mouse game with the VZW Note 2 (no pun intended)? I know Verizon just recently OTA'ed a patch and Ralek and others quickly released a new exploit. I don't expect (and hope you wouldn't) disclose details of yours until we can exploit it first, but I'm just curious if its something you've been watching? Any comments without spilling the beans? :)
[AT&T Samsung Galaxy S 4 Android Development] kevnuke:
From my experience as a penetration tester, I'd say that he couldn't say anything we laymen would understand without compromising his exploit.

Although I'm not sure it was a good idea to even make it publicly known that an exploit had been discovered in the first place. Since AT&T would (hopefully) know of all methods to circumvent the locked bootloader, they wouldn't need to know which exploit was used, only that it had been discovered. They could release an update that would patch all of them, and probably simultaneously create new exploits..albeit unknown to us, at least at the time, anyway.

Swyped from the 4th Galaxy on XDA Premium.