yashsingh1/xdaforums huggingface dataset:
[Verizon Samsung Galaxy S III] enderblue:
If you don't flash your custom kernel to mmcblk0p7, then it will boot up just fine.

If you do flash the custom kernel, then it goes to the VZW stuff.

When going into download mode, it says "QUALCOMM SECUREBOOT: ENABLED".

So, had to use Odin to put the stock kernel back on. Booted up just fine. The bit we changed to 0 was still 0.
[Verizon Samsung Galaxy S III] segv11:
If anything in param was going to work, that would have been it. Thanks to several of you for helping to eliminate that line quickly. (Adam, it was worth a try, but Samsung wouldn't have made it that easy. Now we return to our regularly-scheduled hardware hacking.)

Sent from my BANNED Unified-Search-enabled Galaxy Nexus.
[Verizon Samsung Galaxy S III] alexmason:
Pastebin
[Verizon Samsung Galaxy S III] invisiblek:
i was looking at fsg (mmcblk0p21)

the att one that i have is blank

the one i just pulled from my phone is identical to the one i pulled from it a couple weeks ago

i pulled one from my co-worker's vzw sgs3 just now was different than mine

not sure what this partition is for. and i doubt this is going to do anything for us, but just adding to the info

EDIT: also, whats that at 009FFC00 in param?
[Verizon Samsung Galaxy S III] E:V:A:
So I'm confused... What Baseband Processor (BP/CP/modem) is this device using?

Here and here they say that some Korean LTE devices are using the Samsung CMC221 chip. Others mention it being integrated on the Processor... Somebody knows what's going on here?

@Adam, does your phone have this chip?

Here is an interesting Google translation of this Korean web page about this.
[Verizon Samsung Galaxy S III] kingnerd:
https://www.dropbox.com/s/gw26kijm775dxb1/recovery_log.txt
[Verizon Samsung Galaxy S III] neubauej:
I don't know if you still need this. But if so here it is from an AT&T S3.

https://www.box.com/shared/883af2f3195db4f6da10
[Verizon Samsung Galaxy S III] kingnerd:
I asked around on IRC and have one person saying there are no such logs on the T-Mo version despite having used Odin. I'd be interested in diffing pretty much the entire /data/log folder of an unlocked variant using the MSM8960 if anyone can produce that, especially recovery_log.txt.

Edit:

That block is the param block, changing the only value consistently different between locked and unlocked variants produced no results :/.

If you have an AT&T S3 and would be willing to dump your /data/log though, I would be very interested... just make sure you remove references to your serial number.
[Verizon Samsung Galaxy S III] AdamOutler:
I'm going to play with the PARAMS later tonight. I have more ideas, but simply not enough time..

Here is my next idea... Signing our own binaries with a fake signature.. It appears that whatever signature checks are occuring, they are very quick. I would almost say that they are checking the file size and comparing that to the signature. It is entirely possible that we could remove the signature from one file, then append it to another. However, I would say that the filesizes should be the same with signature.

So, in order to test:

1. separate signature from kernel

2. make another kernel, slightly smaller

3. add 0's until kernel sizes match.

4. apply Samsung signature.

Another Samsung trick is to apply signature to only the first 1000 bytes. If this is how it's done in this case, we can change out the kernel or ramdisk (whichever is second) and reapply the binary.

It is a 75/25 chance that this will not work, but it is definately worth a shot.
[Verizon Samsung Galaxy S III] dexter35803:
Have you compared these partitions to the Sprint version to see if you can replace them on the VZW ones since the devices are practically the same i would assume that the partitions would be just a different signature on the device if i had both i would test but im a Broke dev lol and i think it would have to be done VIA dd using shell or terminal but what do i know lol u guys are a lot smarter then me you may have to do edits like on the toro and toroplus for it to work but i think it has the most potential just need sprint dump
[Verizon Samsung Galaxy S III] neubauej:
https://www.box.com/shared/4ecb26fba45fe76463fe

If you need anything else just let me know.
[Verizon Samsung Galaxy S III] tpike:
Adam, sockmonkey has the Sprint version and can give you a dump. He asked if you could g talk him with details.

Sent from my SCH-I535 using Xparent ICS Tapatalk 2
[Verizon Samsung Galaxy S III] kingnerd:
OK, going through the logs... after this I'll compile Samsung's kernel from source and see if I can't have a go at what AdamOutler is suggesting (I don't expect too much useful to result, but I'm still in the early stages of learning)

Verizon has and AT&T doesn't have:
ro.config.vc_call_vol_steps=7
telephony.lteOnCdmaDevice=1
ro.ril.ecclist=112,911,#911,*911
ro.config.combined_signal=true
ro.sso.intent=com.motricity.verizon.ssoengine.Establish_Token
persist.radio.no_wait_for_card=1

AT&T has and Verizon doesn't have:
ro.monkey=0

Looks like nothing useful here.

recovery_kernel_log differences (on boot). I'll leave a lot of these out since there are clearly so many, and most of them are unpromising and uninteresting.

Verizon has and AT&T doesn't have:
max17040_work : CONFIG:0x1c85, RATE:0x5500

AT&T and Verizon differ in:
set_dload_mode <1> ( c0017714 ) (AT&T)
set_dload_mode <1> ( c00176d4 ) (Verizon)
no pmic restart interrupt specified (Verizon Line 2)
WDOG handled by TZ:dump @0xdd7c1000 PA:a3ec1000 (AT&T)
WDOG handled by TZ:dump @0xdd7ca000 PA:a3eca000 (Verizon)
sec_getlog_supply_kloginfo: 0xc0c43004 (AT&T)
sec_getlog_supply_kloginfo: 0xc0c43144 (Verizon)
[Verizon Samsung Galaxy S III] tpike:
Are you compiling all the diffs or just the stuff regarding the TZ?

Sent from my SCH-I535 using Xparent ICS Tapatalk 2
[Verizon Samsung Galaxy S III] kingnerd:
Not all the diffs, but the ones I excluded are mostly specific to the battery, USB port, MTP, manufacture, or model number. If you'd like me to post all the diffs online, I can do so but they're too long to post here.

Another difference, this time in the virtual kernel memory layout:

Verizon

Virtual kernel memory layout:
vector : 0xffff0000 - 0xffff1000 ( 4 kB)
fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB)
DMA : 0xff000000 - 0xffe00000 ( 14 MB)
vmalloc : 0xdf000000 - 0xfe000000 ( 496 MB)
lowmem : 0xc0000000 - 0xdeb00000 ( 491 MB)
pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB)
modules : 0xbf000000 - 0xbfe00000 ( 14 MB)
.init : 0xc0008000 - 0xc004d000 ( 276 kB)
.text : 0xc0100000 - 0xc0a75874 (9687 kB)
.data : 0xc0b00000 - 0xc0bd3d60 ( 848 kB)
.bss : 0xc0bd3d84 - 0xc100153c (4278 kB)

AT&T

Virtual kernel memory layout:
vector : 0xffff0000 - 0xffff1000 ( 4 kB)
fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB)
DMA : 0xff000000 - 0xffe00000 ( 14 MB)
vmalloc : 0xdf000000 - 0xfe000000 ( 496 MB)
lowmem : 0xc0000000 - 0xdeb00000 ( 491 MB)
pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB)
modules : 0xbf000000 - 0xbfe00000 ( 14 MB)
.init : 0xc0008000 - 0xc004d000 ( 276 kB)
.text : 0xc0100000 - 0xc0a7583c (9687 kB)
.data : 0xc0b00000 - 0xc0bd3c20 ( 848 kB)
.bss : 0xc0bd3c44 - 0xc10013fc (4278 kB)

And with that, I've extracted all the seemingly useful differences from both recovery_kernel_log and recovery_log.
[Verizon Samsung Galaxy S III] ScottIsMyName:
Interesting....the Verizon versions are bigger in all of the different areas

.text differs by 40 bytes

.data and .bss differ by 320 bytes.
[Verizon Samsung Galaxy S III] tpike:
Does that mean the lock code is stored in those areas?

Sent from my SCH-I535 using Xparent ICS Tapatalk 2
[Verizon Samsung Galaxy S III] AdamOutler:
Updated Goal 2. We have a 90% recovery option. we now have bootloader partitions.
[Verizon Samsung Galaxy S III] msnglink:
nice work, i can flash it and see if it works when you are ready, just pm me on what to do
[Verizon Samsung Galaxy S III] E:V:A:
I don't believe even Samsung would be that stupid, when they could just do a simple hash. Not sure what measure you use to label it as "very quick". But SHA1 is very quick. In addition in the following post, SHA1 is mentioned, but I just don't understand the lingo for that post...

"ELF image load and autentication in TZ in the msm8660"

This is indeed mentioned as: "6. Call into TZ to authenticate and Reset Modem FW (Heading F. below)"

in this post: "MSM8960 Modem restart Procedure".
[Verizon Samsung Galaxy S III] AdamOutler:
Samsung only the first 1000 bytes of their bootloader binaries for Hummingbird/Exynos. Not sure what the signature applies to here but its likely they use some in-house software.
[Verizon Samsung Galaxy S III] kingnerd:
Can't you test this by just changing a random byte in the kernel? Sure it might crash, but if it doesn't trigger the "Verizon Illegal Software" warning we should be good to go.
[Verizon Samsung Galaxy S III] alexmason:
Monkey is a random event class in android. http://www.java2s.com/Open-Source/A...t/com/android/commands/monkey/Monkey.java.htm
[Verizon Samsung Galaxy S III] segv11:
Adam, there are more params on this thread, too: http://xdaforums.com/showthread.php?t=1777978
[Verizon Samsung Galaxy S III] E:V:A:
On second thought, I think that the bootloader is made by Qualcomm, in those devices featuring the Qualcomm chipsets...

In fact it should be easy to track down a string like that in the firmware, unless it's encrypted/compressed. (Given that it is a string and not an image.) We whould then be able to backtrack to the routine using that string...
[Verizon Samsung Galaxy S III] cordell12:
Assuming that is correct couldn't we "spawn children and or send in Carloline" revolutionary style, aka AlphaRevX? Not saying that exploit would work out the box, but some modding of it may do the trick.
[Verizon Samsung Galaxy S III] cmg5461:
Just an idea, but if the bootloader uses a simple hash like SHA1, couldn't we just manipulate a custom kernel until we get a matching hash? Sure it may take awhile, but it's worth a shot.

http://en.wikipedia.org/wiki/Hash_collision

Now if it's SHA256, we have a huge problem, LOL
[Verizon Samsung Galaxy S III] efrant:
:) I do not that that it would be worth even attempting to do that... I would say that it would be nearly impossible even with SHA1.
[Verizon Samsung Galaxy S III] mikejr83:
I don't remember if we were able in IRC to determine if modifying a portion of aboot would cause the device to not boot. We tried changing some EXIF data in an image, but I don't recall anyone flashing it and reporting back what happened. However, if we are able to modify portions of aboot without killing the boot process I'm wondering if modifying this key (or somehow modifying the check process) to decode to "Official" all the time might help us.

Again, not remembering if we can modify portions of aboot, but could we modify the process of setting custom_flash_count (when future custom ROMs are able to be flashed) so that we can reset our counter? I don't know how the "Triangle Reset" app did this for other Samsung phones, but it seems like it would have to do with this.

Adam, this guy needs to get voice in this thread. That's some awesome work he has done!
[Verizon Samsung Galaxy S III] NotATreoFan:
@Adam and/or Lee: PM me with the username unable to post in here. I can grant you access to contribute directly.
[Verizon Samsung Galaxy S III] kingnerd:
I tried looking for a string like that in the boot image and was unsuccessful... This email from Lee seems extremely promising though, and I'm going to let it develop before trying anything else. Here's more info about that triangle away app, including technical details: http://xdaforums.com/showthread.php?t=1494114

It allegedly works on the international S3 but not the Qualcomm S3. Despite that, I'm sure the logic is similar.
[Verizon Samsung Galaxy S III] ExodusC:
If I recall correctly, the aboot with the modified EXIF data caused the boot process to fail.

I didn't directly test it myself, but it's what I'd heard in the IRC channel.
[Verizon Samsung Galaxy S III] E:V:A:
I'd like to know more about this communication. It has also been suggested to have a look at the Qualcomm EFS Explorer tool in this post.

In addition TO ALL, it would be great if someone could regularly (every few pages or so) summarize what we have learned and what we need to do.
[Verizon Samsung Galaxy S III] AdamOutler:
ralekdev, are these on the PARAMS partition, or are these the memory locations?

If they are on the partition, we should be able to simply echo a hex value into the dd app with the count set properly..

Currently we have no debugging information and can see the debugging information in the code. I want to see the bootloader debugging information on my UART console and possibly jump into the Samsung SBL prompt where I can make changes to the device in it's native bootloader environment.

basically we would place a hex value of 0x47494844 at PARAMS partition location 0x900000?
[Verizon Samsung Galaxy S III] segv11:
It's interesting that the param partition may turn out to be key, just not that flag (whatever it was) at 0x00000014...

Sent from my BANNED Unified-Search-enabled Galaxy Nexus.
[Verizon Samsung Galaxy S III] Ralekdev:
Those are offsets into the param partition.

(I'm the Lee from the email earlier)
[Verizon Samsung Galaxy S III] rothnic:
This is supposed to be the entire bootchain for the C-Spire S3, which is supposed to be identical to the Verizon version. Might be useful for comparisons at least.

http://goo.im/devs/invisiblek/i535/sextape.bootchain.tar.md5

NOTE: No one has flashed this yet, and it could very well brick your phone if you do.
[Verizon Samsung Galaxy S III] segv11:
US-Cellular param image, from efrant's thread:

http://xdaforums.com/showpost.php?p=28982144&postcount=16
[Verizon Samsung Galaxy S III] E:V:A:
Well, did you change the debug parameter: ro.debug_level=0x4f4c ("OL" == DLOW) ??

Or are you taking about something even more early?

Or we don't know how to do that either?
[Verizon Samsung Galaxy S III] AdamOutler:
I won't have time tonight. I'm unboxing a Nexus7 for XDATV. I just took a break because my son started screaming. Keep an eye on the Google+ for a hangout as soon as he's quiet again.... I just took the back cover off..
[Verizon Samsung Galaxy S III] enderblue:
Ok, So, using Lee's algorithm's above, I can confirm that it generates a key that will correctly decrypt the 16 bytes at offset 0x9FFC00. My theory was that we could at least use our key and psn to create data that would make it seem like the phone was loading an official ROM. That would at least get rid of the padlock and 5 second delay. The bad news is that the 16 bytes change with every reboot of the phone.

We need to figure the portion that is setting these bytes.

Thanks,

EnderBlue

---------- Post added at 09:41 AM ---------- Previous post was at 09:25 AM ----------

Also, you can set the byte at offset 0x3ffe23 to either 0xEE or 0xFF and it has no bearing on bootup behavior. In fact, I have seen several instances where there was no significant data after the model name bytes (i.e. that byte was set to 0x00).

Thanks,

Ian
[Verizon Samsung Galaxy S III] Ralekdev:
Right, one thing I forgot to write earlier was that the rom_type field of the ddi_data is calculated at runtime only. All that's stored on the mmc is the first field through the end of the model name.

As for the 16 bytes in param being different every boot, it's probably because there's a timestamp embedded into part of it that's recorded how many milliseconds (I think it's ms) have passed since booting. You could try xor'ing the second int with 0xE6436679 to get that time back.

Also, for anyone playing with the debug levels in param.img, note that rebooting into recovery resets the param_debug structure back to DLOW
[Verizon Samsung Galaxy S III] enderblue:
But the value isn't changing after the phone is running. Or, is it not how much time since it was booted, but how much time since the epoch (or something like that)?
[Verizon Samsung Galaxy S III] AlexDeGruven:
It's probably stamping the epoch time at boot, and then just making a comparison when something is calling for the time.

It wouldn't make sense for it to be continually updating that field while the phone is running. Leave that up to the RTC which is made for it and just query it when necessary.
[Verizon Samsung Galaxy S III] Ralekdev:
The time theory was more a guess based on how they calculate another parameter, called the "cordon", which also uses the same encryption. This cordon is passed to the kernel on the cmdline for an unknown purpose. Calculations can be seen http://pastie.org/4285958. get_time_since_boot returns an int that gets incremented by 10 every time the timer irq fires.

I haven't located where they write the 16 bytes to param.img yet, so I'm not sure exactly what the other 12 bytes are. I'm still tracking that down and trying to finish documenting the signature check on boot.img
[Verizon Samsung Galaxy S III] enderblue:
Well, I used the algorithm and decrypted the bytes. The result was the following: 0x000000EEED0808500000000000000000. I then changed the beginning to: 0x000000FF, encrypted it and wrote it to the param block.

On the next reboot, the pad lock icon was gone (there was no delay) and it booted to the OS. I shut it down and went into download mode. Nothing new and exciting. I then restarted and the pad lock icon was back (and the 5 second delay).

I may have tripped the custom flag by going into download mode, but I kind of doubt it. So, those bytes must be written after the initial boot check.

Could we possibly add some logic to the OS startup or shutdown that could reset the encrypted data? At least that way, there wouldn't be any delay on reboots and there wouldn't be a pad lock icon.

Thanks,

EnderBlue
[Verizon Samsung Galaxy S III] mybook4:
What if we were to write the FF, boot normally, then pull the 16 byte encrypted key again (by adb dd'ing), and decrypt that. I wonder if it would still show FF or return to EE?
[Verizon Samsung Galaxy S III] enderblue:
It gets reset back to 0x000000EE through a normal reboot. The first reboot has no pad lock. Subsequent reboots do. I did re-run the test and did not go into Download mode this time.

Thanks,

EnderBlue
[Verizon Samsung Galaxy S III] N00BY0815:
Just a quick and probably noobish attempt, but what about CheatEngine? Isnt it possible to modify the relevant bits during a flash, while the ROM/kernel,... is in the RAM. Couldnt you just search for the pattern you need and modify it, while Odin flashes it? Dont know, if there also is a Linux version of CheatEngine, but it works on Windows. I dont own the phone, but I read about this thread on xda and thought, I could throw in the idea ;)
[Verizon Samsung Galaxy S III] Entropy512:
When you say "quick" - how quick is "quick"?

By human standards, hardware-accelerated SHA or AES is very fast. For example, one implementation I'm aware of which is a "slow" AES engine is still capable of 1.6 gigabytes/second with somewhere around 10-13 clock latency.

SHA is also, similarly, fairly fast if implemented in hardware. It would not be surprising at all if they're using HMAC.

From a manufacturer's perspective, HMAC's pros are:

1) Simple - it's just SHA with some extra input data

2) Fast - Same reason as 1

Cons are:

It is a symmetric algorithm. A determined and well-equipped attacker could pull the HMAC secret value from the CPU

One thing to note, based on earlier comments in the thread: It looks like Qualcomm hasn't changed their architecture much compared to what I understand of MUCH older chips. In most other ARM chips, the CPU itself boots, and eventually bootloads the radio firmware in an offboard chip. In many MSMs - as I understand it, the radio boots first, and it bootloads the applications processor.

You may want to talk to some people from the HTC unlocking community - it is likely that Samsung's locking solution is (due to use of the same chip) similar to HTC's.

One of the key items of interest - did Samsung use different root keys in the CPUs for each carrier, or are they using a common key? Normally, a common key would be a massive mistake, but if they really didn't want to lock the device, they might have used the same common root of trust for all North American QCOM-based devices. However the problem here is that unlike OMAP, Exynos, and Tegra devices, it seems that the first link in the chain of trust is the damned radio firmware - which IS known to be different between each North American device. :(
[Verizon Samsung Galaxy S III] AdamOutler:
Partition numbers mean nothing on this device, this was discovered by riff box team. Modem is not first. I thought that too. What we know as a primitive boot loader is handled inside the S4 chip.. they even have a replacement for Odin called qpst. Samsung stuff starts at SBL1. The disorganization is further exemplified by the PARAMS partition location at p10 being used by SBL. I think modem is supplied by Qualcomm and therefore Samsung gets 0p2 on to work with. Qualcomm calls the customers boot loader the SBL.

I'm really thinking that they just designed the system as they went. I know there was a lot of difficulty in making this device from my chats with those who work with engineers. They probly got to debugging the kernel and decided they needed extra stuff before they added the system partition... this is my theory.
[Verizon Samsung Galaxy S III] bird333:
Have you guys been able to do this? http://xdaforums.com/showthread.php?p=29053884#post29053884 It may not help but I thought I would pass it along.
[Verizon Samsung Galaxy S III] NegativeOne:
Insecure kernel. Not vzw...
[Verizon Samsung Galaxy S III] mybook4:
I read Adam's previous post (about inserting a smaller kernel) and I wanted to see what we can "get away with" when changing things in boot.img. Hopefully this gives us more info about what is enforced with the signature (which I believe is at the end of the boot.img at 0x573000).

I made different boot.img and flashed them to see what would happen (by running dd -if= of=/dev/block/mmcblk0p7 in android in the terminal). InvisibleK was nice enough to compile a kernel zImage for me based on the stock kenrel which is smaller than the stock kernel (stock is 5513240 bytes, InvisibleK's smaller kernel is 5492040 bytes). For each boot.img below, I started with the stock boot.img and made modifications (in a hex editor).

1) Modified the "product name" of the 2k header to "TDB" (didn't touch the sha id in the 2k header)

Same yellow triangle “System software not authorized by Verizon Wireless has been found on your phone...” message. Odin'ed the boot.img back to stock and booted back into android.

2) Overwrote the stock kernel with the smaller kernel and padded with 0s until 0x543000 (where the ramdisk starts). Didn't touch the sha id in the 2k header.

Same yellow triangle “System software not authorized by Verizon Wireless has been found on your phone...” message.

Just a thought, but we may want to try to modify a file in the stock ramdisk (maybe initlogo.rle?), gzip it up, then overwrite the stock ramdisk on the stock boot.img. Most likely will be just as fruitless as above, but it's just a thought.
[Verizon Samsung Galaxy S III] Jiggity Janx:
I got the "System software not authorized by Verizon" message on my Droid Bionic recently when updating to one of the latest ICS leaks. I fxz to .902, stock recovery updated to stock .905, rooted and CWM backup and then stock recovery updated directly to the ics leak .232. Rom Manager was still installed and showed that CWM recovery was still installed even after installing the ICS .232 leak. I did not choose to install CWM recovery again. When I chose to reboot recovery from Rom Manager I received the Verizon error. After that I had a tough time and spent a lot of time un-bricking (which was tough because it took forever to get my phone to recognize usb to connect to the bootloader for rsd).

If this is not relevant and/or more common than I think than please do remove as to avoid clutter.