yashsingh1/xdaforums huggingface dataset:
[Verizon Samsung Galaxy S III] Loglud:
Actually there is a release of the i535 Kernel and System out there on samsungs open source site. We have known about the kexec exploit for some time now, but the problem is that we do not have a way of flashing over current partitions without signing them.

Adam and I have been talking the last couple of days about this, and he thinks he might have a solution, though I'm sure time will tell. The big thing is that for people whom are developers of roms, but not of the exploits, can develop roms, while another exploit is found. And yes rothnic it is the same, I thought I would put it in lame-mans terms though.
[Verizon Samsung Galaxy S III] rothnic:
Yes I'm referring to CyanogenMod. The reason you see nightlies pop up today for the other US variants is the CM developers were working out bugs internally before starting to support officially.

---------- Post added at 04:32 PM ---------- Previous post was at 04:27 PM ----------

Right, though we can kexec a kernel sitting on the sdcard with the recovery with a kexec enabled kernel since we can flash unsigned images to the recovery partition. Though we have to boot into recovery to do so. A more streamlined way to go through that process would be a great interim solution compared to the unlocked bootloader.
[Verizon Samsung Galaxy S III] sydewayz:
Thanks for that link.

I filed my complaint.

Locked bootloader or not, this phone rocks. I'm keeping it.
[Verizon Samsung Galaxy S III] PGleo86:
My thoughts exactly, the speed is phenomenal before custom ROMs and kernels! I can only imagine after...
[Verizon Samsung Galaxy S III] aj8600:
nothing to see here move along
[Verizon Samsung Galaxy S III] tonu42:
Keep things like this in irc, please edit and remove.
[Verizon Samsung Galaxy S III] killerT721:
Wait really? For the verizon gs3?
[Verizon Samsung Galaxy S III] ExodusC:
Both IRC and xda are public channels, so unless the news that's CM9 was in the works for our variant was in a PM between two devs or something, I don't see why it needs to be removed.

Plus I figured someone would make a kang and post it regardless, since we have the ability to boot custom kernels, even if it's a bit of a pain.
[Verizon Samsung Galaxy S III] tonu42:
Except its not ready yet. And doesnt need to be exposed like this.
[Verizon Samsung Galaxy S III] alquimista:
{Q} SS_DL.dll

NVM.

___security_cookie is used to avoid buffer overflows.

~ALQI
[Verizon Samsung Galaxy S III] Loglud:
ALQI:

To me that looks like a secure authentication protocol used for flashing via odin. Looking further into it I found that all of the samsung device packages come with this. Unfortunately it is not that useful from what i can see... Could be wrong though (wouldnt be the first time nor the last). I think if you want to disassemble something useful you will have to do a dump of the bootloader and then with an arm toolchain disassemble that.
[Verizon Samsung Galaxy S III] juryben:
Could be unrelated, but in VS the /GS flag adds these security check cookies around buffers to detect overflows.

http://msdn.microsoft.com/en-us/library/aa290051(v=vs.71).aspx
[Verizon Samsung Galaxy S III] alquimista:
Thanks Loglud. Yeah, I googled the security cookie and its just a buffer overflow protection for C++.

I can give dumping the bootloader and dissasembling that a go. The bootloader is aboot or "/dev/block/mmcblk0p5" right?

ta,

ALQI
[Verizon Samsung Galaxy S III] ThePagel:
Ok everyone is talking about motorola using chips for the encryption but I was under the understanding that it was the efuse that holds the devices back. When motorola releases a dev phone its bootloader is incompatible with the efuse so it would brick the non dev phone. In s3 case if there is no efuse then it might be as easy as replacing bootloaders. Is there a efuse in our phones?
[Verizon Samsung Galaxy S III] Juicy92:
I always thought efuse was a myth
[Verizon Samsung Galaxy S III] papi92:
No efuse but its encrypted. We need to figure out though if there is a way to bypass that encryption. We SHOULD be able to unlock just will take time. We need to see IF we can modify boot loader and replace and if we can how to go about doing it. Its not as simple as replacing it like a copy and paste
[Verizon Samsung Galaxy S III] alquimista:
I don' think there's an eFuse, but I could be wrong. As I understand it, If there were an eFuse, the device would just reboot to recovery until a valid file was flashed.

The problem with the SGS3 is that we can't even flash something to trip an efuse!! Nand write fails all over the place ;-)
[Verizon Samsung Galaxy S III] papi92:
We tripped boot loader when manually applying boot.img to dd block. That doesn't mean anything tho as we could restore. If someone modifies the boot loader and flashes that will show if there is an efuse or what but wait for Adam to look. He will know how to precede
[Verizon Samsung Galaxy S III] alquimista:
Anyone know what encryption is used? RSA, SHA?

After running strings on the bootloader I see references to all kinds of encryption and a magic number, which is weird cause I thought that was for wake on LAN?

I'm done for the night, but the fight aint over till I give up and start crying.
[Verizon Samsung Galaxy S III] AdamLange:
AFAIK the __security_check(s) are not connected to any bootloader checks. Its just security step in binary to check if it was not tampered or (most probably) to check device status before doing anything to not brick it.

The same checks you will find in Odin binary :)

this binary is a waste of time :) better take a look at aboot.bin

Adam
[Verizon Samsung Galaxy S III] Loglud:
OK now that I'm not busy I think I can ahead some light on efuses. The best way to think of it is a ROM (Read Only Memory). The main difference between ROM and efuses is that efuses are programmed after manufacturing. These are one time writable 1s and 0s that allow for cheap serialization of chips. No as for reading the efuses there in lies the trick. We might be able to read them but their may be some encryption behind them. Their not always an unlock code... I think Adam has some ideas and I can help him if he gets one.
[Verizon Samsung Galaxy S III] tprouty:
Had to do this on the Droid X2.... http://xdaforums.com/showthread.php?t=1661572

We had locked bootloader and then Dragonzkiller made is possible to have CM7 and CM9 to the X2. So it can happen.....
[Verizon Samsung Galaxy S III] NegativeOne:
It's not full CM7/CM9. It's gimped because the kernel is one of the best parts of it.
[Verizon Samsung Galaxy S III] Jazi:
I thought the kexec option had been explored and was decided to be more of a "last resort" than our first option.

Because based on my understanding, and I could be wrong here, kexec has definite performance increase as well as the risk of losing some (or maybe even quite a bit) of stability due to the face that it is overwriting the old kernel's memory while it is still executing.

So while yes it is a feasible option we should not be looking in that direction quite yet, but instead still work on unlocking the bootloader itself so as to allow our full control of the phone.
[Verizon Samsung Galaxy S III] rothnic:
Not quite as limiting as described in the kexec thread here.
[Verizon Samsung Galaxy S III] tprouty:
Right, which is why I upgraded my x2 to the SG3....... and we all see where that got me!

got my fingers crossed here! good luck Dev's!!!
[Verizon Samsung Galaxy S III] newuser134:
This may be slightly off subject, but I still think it's relevant, because it has to do with the high hopes we all have of getting a custom kernel put on this phone the "normal" way.

I haven't rooted my VZ SGS3 yet, but I've just been reading up on it and will do it here pretty soon, just want to get enough info to make sure nothing gets messed up. Anyway, I just have a few of the "bloat" apps disabled through the ICS app manager, and I eventually figured out how to switch to 3G (not that I want a fast phone on 3G, but just to see how much it helps save battery), and now it seems like this phone has AMAZING battery life. I still check mail on it a few times, have a normal load of phone calls and use the web occasionally, I'm using a battery widget to average lost battery capacity over a known time, and find an average of current draw, and on my last charge, since I switched to 3G, it has been averaging a current draw of 15 mA, even compared to my EVO 4G on Sprint before with the data turned off, drawing about 30 mA, this is phenomenal on stock ROM with a stock kernel. Just imagine what it would do with a custom kernel, and all the bloat removed! This is even more of a reason to try to break the bootloader for all of us, I think this phone is amazing when it comes to hardware. I think Samsung made an unbelievable device, now just to get the annoying VZW version bootloader unlocked. I wish for all of us that it gets done eventually.
[Verizon Samsung Galaxy S III] Imoseyon:
Don't mean to hijack the thread but I have a test custom kernel/recovery hybrid (not using kexec) and in need of a few testers. If you're interested get me on twitter or PM me? (twitter preferred). Thanks.
[Verizon Samsung Galaxy S III] newuser134:
Did Adam get his phone yet, anybody know? Has the dedicated thread for his testing been setup yet? I know it's still to early and not trying to be impatient, just want to make sure to keep an eye on it if it's there already.

Thanks
[Verizon Samsung Galaxy S III] tprouty:
I might be a little slow.... I cant PM you... I'll be happy to test...
[Verizon Samsung Galaxy S III] Karl:
So any progress?
[Verizon Samsung Galaxy S III] mkasick:
If by "kexec flag" you mean the "CONFIG_KEXEC=y" kernel config option, that's not actually default. But even with it enabled, kexec support is broken out-of-the-box for two reasons.

First, the kernel is compiled with "CONFIG_STRICT_MEMORY_RWX=y" which makes the kernel .text segment "read and execute" but doesn't allow writes, and the writeable areas aren't marked execute. The problem being that some parameters are passed to the relocate_new_kernel routine through global variables defined in the read-only section, because it must be adjacent to that code so it doesn't get blown away when the kernel is staged.

The second problem is that a "normal" kexec crashes on kernel boot, which is fairly typical, and I haven't bothered debugging it because we haven't needed to.

The hardboot approach solves both of these issues, but necessarilly requires that the recovery partition can contain an unsigned kernel. Also, as a nit, the kexec approach isn't an exploit here. The exploit is the broken bootloader signature check on the recovery partition.
[Verizon Samsung Galaxy S III] juryben:
Err.. how does the kernel interact with read only code? Some kind of syscall?
[Verizon Samsung Galaxy S III] drbveb88:
Noob question here..

Having a locked bootloader prevents us from flashing custom kernels?

We can still root and flash stock deodexed roms , correct?

Sorry if this question should've been posted somewhere else.
[Verizon Samsung Galaxy S III] mkasick:
That's why it's broken. STRICT_MEMORY isn't part of standard Linux but was added to the msm kernel tree some time ago and kexec isn't (wasn't) updated to support it. However there are kernel functions that can be used to make occasional writes to the text segment and was already being used for things like kprobes. Here's the patch.
[Verizon Samsung Galaxy S III] toosurreal01:
Correct!
[Verizon Samsung Galaxy S III] Loglud:
Not true actually because with kexec you can load a compleatly new boot.img meaning kernel and inframs.

A i see how your doing it, wonder if theres a counter like on other devices where we can make it so that it is forced to do recovery every time, if there is i think your right maybe loading it with a new bootloader like cyanoboot or any of the other ones out there so it follows the following:

bootloader (signed) -> recovery partition -> bootloader2 -> unsigned boot image (or recovery) -> system -> userdata

Interesting idea behind there. The flag i was talking about that was enabled was kernel debugging, which allows for memory allocation and flags for a kexec kernel, however booting all the way to system and then rebooting takes a while, although a "normal" kexec is ment for new kernels to be loaded on the fly. (Or atleast Kexec for x86) This decreases downtime of servers and such so there is no restarting only a force load.

All in a all i think you guys have a very good layout of how to start things, and if you can create a rom script, I can help if need be, to smash the images all together so that people can easily port roms from device to device, I think you are well on your way for a winner.

The cool thing is that, as people pointed out, the hardware is the same for all the galaxy S 3 devices. Once this recovery exploit is utilized, one can port to and from this devices with relative ease.
[Verizon Samsung Galaxy S III] ScottIsMyName:
How is this not getting more attention? Imo to the rescue!

So Imo, this is not using kexec, but instead is having recovery AND the kernel in the recovery partition?
[Verizon Samsung Galaxy S III] juryben:
The reboot method is a common to load homebrew on the Xbox 360. Basically the rebooter just loads an exploitable kernel. I'm not sure how we would store the other kkernel.
[Verizon Samsung Galaxy S III] NegativeOne:
Ok. I am just thinking of DX, where the best we could do was 2nd-init, I don't think kexec...? So no custom kernel.
[Verizon Samsung Galaxy S III] rothnic:
This post links to a post that talks about where it is executed from. Basically, the boot.img is stored on the /sdcard. Either internal or external.
[Verizon Samsung Galaxy S III] kman79:
How'd this one pan out?

I'm willing to test this out. If it doesn't work, will I be able to use ODIN to flash the stock ROM back?
[Verizon Samsung Galaxy S III] AdamLange:
The main problem is that when we pass the checks and run well done kexec kernel verizon can easly patch the "hole" in recovery sig check and we are again doomed.

We should focus on security checks in bootloader or if we cant pass it, focus on using system partition which will probably not be security checked (or verizon will be such pain they will sign it also :()

PS: im waiting now for device to arrive, i'm mapping calls in bootloader to get better view on checks it has and what we may/or not use.

Interesting thing is that it contains "Upload Mode" which may be a clue (we are using download mode, maybe upload mode is when phone is completly bricked and it allows to push firmware without checks), but its just a clue for now, i need to deep search for it.

I also asked my friend at samsung if he can help somehow providing bootloader tools, no reply yet, but i will post if he decide to help out.

Adam
[Verizon Samsung Galaxy S III] juryben:
If our phone doesn't have efuses we could flash back the original bootloader.
[Verizon Samsung Galaxy S III] AdamLange:
See, for example galaxy note got the same problem. After some update there was no "custom binary counter" reset, cause they blocked it trough bootloader. If you flashes the old one, u will got blank screen ;)

Tell me how is it to use phone with black screen? :)

Let's focus on something that they cant block or probably wont block -> system partition. At US phones we can also use the efs partition as it looks empty. Maybe there we can have files...

when i will get my device i will test all possibilities
[Verizon Samsung Galaxy S III] faehsemc:
How long til u got it??
[Verizon Samsung Galaxy S III] s197:
Just don't accept the patch. Rooting 101 is never accept OTA's once you're rooted.
[Verizon Samsung Galaxy S III] NedDasty:
s197--That would only help people who get an SGS3 between now and the patch. We don't want to doom all future SGS3 users who buy their phone after Verizon's patch.
[Verizon Samsung Galaxy S III] AdamLange:
Couple of days i think, meanwhile im still analysing files. Then will be time to test them :)

Adam
[Verizon Samsung Galaxy S III] AdamLange:
Heh, the phone is already rooted. Read full thread, its not about rooting :)

but maybe we will find a simpler method to root it (or smaller payload instead of full system.img)

Adam
[Verizon Samsung Galaxy S III] joebob296:
If you are not rooted how can you avoid taking the OTA. On my DX it gave me two options where there was an OTA they were install now or install later.
[Verizon Samsung Galaxy S III] pkd600:
You hit install later.
[Verizon Samsung Galaxy S III] mattydangerfox:
You have to access /system in order to edit the OTA updater files so it will permanently stop the notifications. So you need root.
[Verizon Samsung Galaxy S III] joebob296:
Which only delayed it for a day then installed without asking again....
[Verizon Samsung Galaxy S III] skennelly:
Lol

*Sent from my Galaxy to yours through tapatalk
[Verizon Samsung Galaxy S III] joebob296:
Thanks matty that was the answer I was looking for.
[Verizon Samsung Galaxy S III] BattsNotIncld:
To my knowledge, all phones from the factory come with the same software, regardless of when you buy them. OTA updates are exactly that - Over The Air. I'm under the impression that Samsung/Verizon does not install updated software on unpurchased phones as they become available, but rather as soon as you turn on your new phone it will prompt you for the update. I could be wrong.
[Verizon Samsung Galaxy S III] Kipland007:
I don't think this is necessarily true, at least with my old Moto Bionic. I had to get a replacement at one point at it had already received two new build updates, but they had been out for a few weeks at least at that point.

With that said I don't imagine anyone purchasing a phone from Verizon today will have some new software because Verizon is about to push it out. I would imagine it takes a few weeks to have all of them up to standard, but again it's only been my experience with my Bionic.
[Verizon Samsung Galaxy S III] d1ez3:
What will be updated in the OTA when it comes out? Also should I root in order to avoid this in case it makes my phone unrootable after?
[Verizon Samsung Galaxy S III] s197:
No one really knows what the OTA will do but the rumor is that it will stop the current method we have available for obtaining root access.

Root with an alternate recovery is your best shot at avoiding the OTA. This is my first Samsung device, but on my HTC, clockworkmod would stop any OTA from installing properly. I wouldn't even get the OTA message.

Generally OTA's give you the option to decline the install at this time. If you have root, you should be able to remove or disable the file.

Tl;dr - Yes, root and recovery are your best shot but no one will know until the OTA drops.
[Verizon Samsung Galaxy S III] ponyboy82:
It's anyone's guess. We usually don't find out until afterwards. Verizon has a long history of sneaking in updates to close exploits, etc, that are used to get root and whatnot. It's almost always safest to refuse the OTA updates until they get the OK from the devs here, or you can flash a "clean" version of the updated rom.
[Verizon Samsung Galaxy S III] tpike:
Thanks for the updates Adam and mk. Good to know y'all are still on the job.

Sent from my SCH-I535 using Xparent ICS Tapatalk 2
[Verizon Samsung Galaxy S III] papi92:
Adam why not pick the phone up in store? No wait then
[Verizon Samsung Galaxy S III] neyenlives:
is nothing happening with THIS GUYS PHONE that can be of use?
[Verizon Samsung Galaxy S III] Robster180:
Read the last post on that thread...
[Verizon Samsung Galaxy S III] mikec86:
I begining to think I rented this phone. Last to get the phone out but 1st to lock the bootloader. Really Verizon, This is not something to be proud of........
[Verizon Samsung Galaxy S III] neyenlives:
"Do you need help getting adb installed or just the instructions on how to run it?"

you're going to have to clarify, I don't understand, it looks to me like like nobody has taken him in and really tried to extract the files
[Verizon Samsung Galaxy S III] Robster180:
Invisiblek already ran through a phone with the same screen, its as locked as the rest of ours
[Verizon Samsung Galaxy S III] neyenlives:
hrm....
[Verizon Samsung Galaxy S III] stiltzkin:
Developing right now:

JackpotClavin and Invisiblek have successfully loaded a custom kernel using a modified recovery ramdisk. It's still very early but this is excellent news for us. As it stands, this method wipes ClockworkMod and requires the recovery key combination on every boot, but those issues can probably both be overcome with custom scripts.

Stay tuned guys...and mash those two guys' Thanks buttons!
[Verizon Samsung Galaxy S III] ftmaniac948:
And I'm now rebuying the device :-D
[Verizon Samsung Galaxy S III] neyenlives:
all the nay-sayers can suck it
[Verizon Samsung Galaxy S III] joebob296:
lol that is why you wait for a few days while everything plays out. no need to over react like the wife does
[Verizon Samsung Galaxy S III] tonu42:
Invisiblek succesfully booted to android using "adb reboot recovery" with his modified recovery.img.

Basically we made it look as if going to recovery, but actually continuing onto boot.img.
[Verizon Samsung Galaxy S III] neyenlives:
indeed, I can't believe how many people are over-reacting, have you no faith in our development guys? do you have to be handed CM/AOSP on a silver platter days before the device is even released? If so you chose the wrong device to begin with!
[Verizon Samsung Galaxy S III] invisiblek:
thats not 100% accurate

i flashed a modified boot.img to our recovery partition (/dev/block/mmcblk0p18)

then rebooted into recovery

it booted up into android using this modified boot.img

i don't plan for this to be of any real use to us though. proof of concept really

we need our access to /dev/block/mmcblk0p7 (where our stock boot.img actually resided)

thing is, we can flash to mmcblk0p7 just fine, but it wont boot (wont do anything actually other than let you get back into odin mode, where you can re-flash the stock boot image, or it gives you this when you try to boot android or recovery: http://i.imgur.com/Ci0gY.png )

rest assured. this is being worked on...
[Verizon Samsung Galaxy S III] SirKronan:
I am definitely hopeful and grateful for your work!! You guys are awesome. :good:
[Verizon Samsung Galaxy S III] ZServ:
I'm no phone software developer, so bear with me here:

On the "Verizon" side of the phone, you cannot put in a custom bootloader because it's checked somewhere else in the system. As well as you can't load anything because of said bootloader. So, the idea is to run a NEW bootloader and image from the "recovery" side of the phone. As a proof of concept it works, but was just to prove you could do the new bootloader. However, you cannot USE said bootloader because when you would write over the stock boot image, something says "oh hell no" on the Verizon side of things. Correct?

Under these assumptions, would either of the following be possible:

A "dualboot" of sorts? I'm assuming no because you can't boot from mmcblk0p7. Why can't you boot from it though? Is there no read/write access or what? If it was possible, could you remove the verizon side boot.img completely and put a custom rom ON the verizon side, and boot into it using the recovery side? Or is the rom itself being checked by more than the boot.img?

Alternatively, if that's not possible, I would be willing to try the next idea once I receive my SIII. Is it possible to just wipe everything on the phone? Literally everything except Odin pushing. Kernel, boot, signed code that's been hidden, whatever. Everything but the ability to push **** via Odin. If so, can you then load the contents of a variant S3 onto the phone? IE, AT&T, Tmobile, etc. I'm aware kernel issues would arise and such, but it'd be more as a proof of concept. If that was possible, could you theoretically take the drivers/kernel or whatever you want to call it that make the Verizon version work, from a rooted Verizon SIII, and futz with it until you had a functional Verizon S3 running off of competitor boot.img and all that jazz?

I know, the ideas are probably stupid, but it's what I can contribute.