yashsingh1/xdaforums huggingface dataset:
[Verizon Samsung Galaxy S III] M4gicM@:
We have a little issue, AT works but not really. I will try to mess with the settings to fix this.

ATI?
Manufacturer: SAMSUNG ELECTRONICS CORPORATION
Model: SCH-I535
Revision: I535VRLG1
SVN: 01
IMEI: **************
+GCAP: +CGSM

ERROR
AT@EBI_CFG
ERROR
AT@GPIO_IN?
ERROR
AT@PMIC_LEVEL
ERROR
AT@QFUSE?
ERROR
AT+RADIOVER
ERROR
AT@CID?
ERROR
[Verizon Samsung Galaxy S III] E:V:A:
That's it!

^^ Well, what do you get? You may need to make sure you have echo setup properly. And you don't need QPST at all, apart from the drivers possibly. Once connected, enable verbose mode and echo with:

ATE1
ATV1

If that doesn't work, try some of this...
[Verizon Samsung Galaxy S III] M4gicM@:
I had verbose and echo on! What I was alluding to was that all of those other commands seem to be protected. Keep in mind that I am running this while my phone is on and fully booted (not in download mode or recovery).

Windows directions to imitate me:

go to device manager and look under modems

-Find SAMSUNG Mobile USB Modem

-right click and select properties

-click the modem tab

-take note of the COM port at the top of the tap

Open your favorite terminal emulator such as putty

Set the serial port to 9600-8-n-1 [9600buad | 8bits | no parity | 1 stop bit]
[Verizon Samsung Galaxy S III] psycho_asylum:
I've been messing with some of the commands on this post:

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

I'm gonna stop messing with it before I brick my phone...

Me right now: http://i.imgur.com/3tMYI.jpg
[Verizon Samsung Galaxy S III] newuser134:
Question for Adam/E.V.A/M4gicM@ about the qFuses

If this post is irrelevant, please feel free to remove, or let me know, and I will delete the contents.

If the boot_config_6 qFuse is blown, it is likely that Verizon did it with a command through USB after they received the phone from Samsung, I'm guessing Samsung wouldn't have irreversibly changed the phone.

If the fuse isn't blown, I was thinking if the secure_boot enable pin is internally brought to low even though it is externally brought to high through the 10k resistor at boot, would it help to use a resistor smaller than 10k to set it to high through the 1.8V source? The internal "ground" may be strong enough to override the external "high", acting as a voltage divider, so the secure_boot pin never actually sees a "high" at boot, so to avoid driving it, maybe a 1k or 2k resistor to the 1.8V source might change the bias enough to have an effect?

On the other hand, since Adam said that Samsung schematics have been proven to be wrong before, what if the pin needs to be grounded at boot to disable secure_boot? Maybe the internal low is not strong enough to fully set the pin to ground, has anyone tried completely grounding the config_6 pin to see how that turns out?

All of the above is assuming the qFuse is not blown. If it is in fact confirmed that it is blown, realistically where does this device stand as far as disabling secure_boot or being able to use an alternate (unencrypted) bootloader without actually having the signature encryption keys? Is there still a way or is all hope basically lost if the fuse is in fact permanently blown?
[Verizon Samsung Galaxy S III] E:V:A:
^^ That is a very slow speed, I forgot to say that it should usually be 115200. But its very strange you only get a few commands. Have you tried it again?

Also "Error" doesn't always mean error, but that the command is still being processed. So don't be to fast on the keyboard! Also try repeating the commands that do work, since it could be a timeout issue. It could also be that those commands are no longer supported or renamed in the MSM8690!! Also try when in recovery or download mode. I read somewhere that there is a USB test port that timeout in 90 sec, unless connected to. Look for other ports...

THIS is quite a bit diverting from topic, so let's not discuss more about this (here) unless someone actually manages to execute those relevant commands or similar.
[Verizon Samsung Galaxy S III] Ralekdev:
It looks like ours deviates slightly from this.

If the headers are to be believed,

TZ is loaded at 0x2A000000

SBL3 is loaded at 0x8FF00000

APPSBL/aboot is loaded at 0x88E00000
[Verizon Samsung Galaxy S III] pyrostic:
I just really don't know how you do it. The L300 has the same Chipset as us. Furthermore, AdamOutler and E:V:A please PM me I need to get you in contact with Sextape. He has more but He'd rather discuss this elsewhere.
[Verizon Samsung Galaxy S III] :
just to confirm yes the L300 has the same chipset as the GS3
[Verizon Samsung Galaxy S III] E:V:A:
I need a JTAG expert!

Somehow I cannot just ignore and stop thinking about this post:

"How to enable/disable the secure boot authentication feature on MSM8660 by using the JTAG"

The reason is that the MSM8660 is essentially the same as our MSM8960 apart some little quirks...(to be determined.)

Here is an edited summary:

NOTE:

a) This solution does not apply to all MSM8660 versions

b) This solution does not apply to the RPM JTAG disable cases

c) This solution only uses for debug purpose.

For some reasons, if you need to to run unsigned software on a secure boot

enabled (the AUTH_EN bit in SECURE_BOOT1 register is blown) MSM8660 chip, the

following instruction is able to disable the secure boot authentication by using

RPM-JTAG.

1. Launch the Daisy Chain RPM-JTAG shortcut (i.e modem_proc\tools\t32\DC7_ARM7_RPM).

2. Execute the cmm script which contain the following command:

[SIZE=2]system.option resbreak on[/SIZE]
[SIZE=2]system.up[/SIZE]
[SIZE=2]g [B]0x7ce8 [/B]/o /cmd "r.s r0 [B][COLOR=Red]0x0[/COLOR][/B]" ; [B]0x0 for disabling[/B] the secure boot authentication[/SIZE]
[SIZE=2]wait 1ms[/SIZE]
[SIZE=2]g[/SIZE]

Of course, you can simply modify the cmm script (listed below) to enable the

secure boot authentication without blowing SECURE_BOOT1 register on MSM8660 chip

by using RPM-JTAG or short the GPIO_76 pin.

[SIZE=2]system.option resbreak on[/SIZE]
[SIZE=2]system.up[/SIZE]
[SIZE=2]g [B]0x7ce8 [/B]/o /cmd "r.s r0 [COLOR=Red][B]0x1[/B][/COLOR]" ; [B]0x1 for enabling[/B] the secure boot authentication[/SIZE]
[SIZE=2]wait 1ms[/SIZE]
[SIZE=2]g [/SIZE]

What is this command doing exactly?

My guess is that 0x7ce8 is an address, but for what?
[Verizon Samsung Galaxy S III] AdamOutler:
Well, I have some supposedly unsecure scandalous sextape files.. I attempted to pack and flash via Odin Tar file. They failed secure checks via Odin, but I believe that means nothing to the actual device itself. I'm going to manually flash these files.

This may end up with me bricking my device, but I feel like it is worth it to prove or disprove the fact that these files work. So, I wanted to post this and then begin preparations. If anyone has any reason I should not flash these files, let me know. I will be out of commission if this fails.
[Verizon Samsung Galaxy S III] pyrostic:
well the aboot will probably brick you. it is a secure file. and different size than the ours.
[Verizon Samsung Galaxy S III] prdog1:
Contact Josh at http://www.google.com/url?sa=t&rct=...S_uPnmiTnsxkUOPcA&sig2=FGVhnpXczn8hBViW_D6Bnw
[Verizon Samsung Galaxy S III] LLStarks:
Adam, might I recommend making an Odin-friendly file?

http://xdaforums.com/showthread.php?t=1777579
[Verizon Samsung Galaxy S III] E:V:A:
Not a good idea! Why would you wanna risk bricking it? (Which I say is about 90% chance of doing with the little knowledge we have.) Then rather send the thing to me... No, actually we need you to work on this, since you are the driving force and knowledge hub for many of these projects!

I know there's a bounty thread about this out there, but I'm not very happy about that. It simply means that people get greedy about their knowledge and start keeping relevant work for themselves. Let's not go there!
[Verizon Samsung Galaxy S III] papi92:
Files should work if made for Verizon SIII. May soft brick but shouldn't hard brick.
[Verizon Samsung Galaxy S III] incubus26jc:
If you brick, we will probably have a new device paid for you in a matter of mins.
[Verizon Samsung Galaxy S III] :
That's what I like to hear
[Verizon Samsung Galaxy S III] ScottIsMyName:
Please delete this post....

But with what seems like a very high chance for a hard brick, it seems somewhat foolish to flash this with the recent progress that has been made.....but then again, if it works, it will be AMAZING.
[Verizon Samsung Galaxy S III] AdamOutler:
From what I understand, Josh has already tried this. I havn't been able to contact him recently though.

I tried. It didn't work because aboot.img was not accepted by Odin/Loke.

I have JTAG capabilities. Not that I want to use them, but I have them. It may be a while before I'm back up.

This is what I'm thinking.

So here's what I'm doing..

adb shell mkdir /sdcard/STUnsec
adb push aboot.mbn /sdcard/STUnsec/
adb push boot.img /sdcard/STUnsec/
adb push persist.img.ext4 /sdcard/STUnsec/
adb push rpm.mbn /sdcard/STUnsec/
adb push sbl1.mbn /sdcard/STUnsec/
adb push sbl2.mbn /sdcard/STUnsec/
adb push SBL3.mbn /sdcard/STUnsec/
adb push tz.mbn /sdcard/STUnsec/

adb shell su -c "dd bs=4096 if=/sdcard/STUnsec/sbl1.mbn of=/dev/block/mmcblk0p2"
adb shell su -c "dd bs=4096 if=/sdcard/STUnsec/sbl2.mbn of=/dev/block/mmcblk0p3"
adb shell su -c "dd bs=4096 if=/sdcard/STUnsec/sbl3.mbn of=/dev/block/mmcblk0p4"
//adb shell su -c "dd bs=4096 if=/sdcard/STUnsec/aboot.mbn of=/dev/block/mmcblk0p5"
adb shell su -c "dd bs=4096 if=/sdcard/STUnsec/rpm.mbn of=/dev/block/mmcblk0p6"
adb shell su -c "dd bs=4096 if=/sdcard/STUnsec/boot.img of=/dev/block/mmcblk0p7"
adb shell su -c "dd bs=4096 if=/sdcard/STUnsec/tz.mbn of=/dev/block/mmcblk0p8"
adb shell su -c "dd bs=4096 if=/sdcard/STUnsec/persist.img.ext4 of=/dev/block/mmcblk0p16"
[Verizon Samsung Galaxy S III] invisiblek:
not to be a downer, but this wont work

at best you might be able to get some info from where it hangs on boot

but it will brick

jtag will be your only option

just because the L300 has the same chipset, doesnt mean its bootchain will work

if that was the case, the sprint sgs3's bootchain would have worked, especially since it has more in common

save yourself the time of jtag'ing

(my two cents)
[Verizon Samsung Galaxy S III] :
Adam just remember the aboot is different but if you know how to flash a boot headers you can get your device into download mode and reflash the stock tar

---------- Post added at 06:18 PM ---------- Previous post was at 06:16 PM ----------

Big difference is this file is unsecured im still working on a dev or unsecured i535 file
[Verizon Samsung Galaxy S III] LLStarks:
I don't see how flashing an L300 bootchain will work when the L710 chain didn't.
[Verizon Samsung Galaxy S III] AdamOutler:
I ended up with a brick. I didn't flash aboot.img. I flashed everything but. When I rebooted, it never turned back on.

I see this USB device when connected to the computer.

Bus 001 Device 037: ID 05c6:9008 Qualcomm, Inc. Gobi Wireless Modem (QDL mode)
[Verizon Samsung Galaxy S III] :
Does it detect it as a modem?

Qualcomm Download Mode
[Verizon Samsung Galaxy S III] invisiblek:
at the very least you could have jumped on irc and bounced some ideas of people before bricking it

gee, i hope the community buys you another one

lets all join together everyone!!

</sarcasm>
[Verizon Samsung Galaxy S III] Rob_Storm:
Do we need to get you another one? Or, can jtag help?

Please post so we can act accordingly. PM me if you are hard bricked.
[Verizon Samsung Galaxy S III] AdamOutler:
Enough with the off topic guys. I have it covered. Basically this only means I'm out of commission for the night thanks to Josh at MobileTechVideos.com :)
[Verizon Samsung Galaxy S III] incubus26jc:
I'm not sure that comment was necessary. I always have respected your work especially with this phone. But to basically say that you hope the community doesn't get him a new phone because you feel it was a preventable brick is ridiculous. I feel like the community would do the same for you if you had bricked. Please if I have misunderstood you, ignore this post and I apologize.

Sorry for off topic.

Great News
[Verizon Samsung Galaxy S III] LLStarks:
I just don't think it's right how we let random files distract us from safer research.

If we didn't have JTAG at the ready, everything we were planning to do with the schematics would've been compromised.
[Verizon Samsung Galaxy S III] :
Sorry adam ill see what else I can dig up
[Verizon Samsung Galaxy S III] invisiblek:
can you watch the boot process with the bad flash and see how far it gets before you jtag it back to life? might come in handy...
[Verizon Samsung Galaxy S III] AdamOutler:
So, I decided to work with the new device which is enumerating...

Here's the lsusb

Bus 001 Device 040: ID 05c6:9008 Qualcomm, Inc. Gobi Wireless Modem (QDL mode)

here's the dmesg

[181577.769482] usb 1-1.3: new high-speed USB device number 39 using ehci_hcd
[181577.862963] qcserial 1-1.3:1.0: Qualcomm USB modem converter detected
[181577.863127] usb 1-1.3: Qualcomm USB modem converter now attached to ttyUSB0

I connected up with minicom and I was not able to talk to it at all. I received no response. So I decided to poke around a bit more on other things... It appears that QDL mode is like Qualcomm's version of Odin Download Mode.

I found a tool called "gobi_loader" which is supposed to communicate with this QDL mode. I'm running into a problem where it does not recognize the format of the firmware folder I am feeding it. I am trying to find out more about this.

This is some great news though. It could satisfy goal #1 as stated in the OP once we figure it out.
[Verizon Samsung Galaxy S III] :
So the brick was kinda a good thing
[Verizon Samsung Galaxy S III] Deliquified:
This thread may aid you Adam. If not, kindly diregard. http://xdaforums.com/archive/index.php/t-1188510.html
[Verizon Samsung Galaxy S III] alquimista:
How did you get a new device so fast?

More importantly, please explain how you are setup right now to talk to the device? Is it the same modem setup that you explained before?

Lastly, my ignorance is really gleaming here, what do you mean by "enumerating"?

Sorry, I'm just trying to mimic what you are doing right now to see if I can be of any help.

Ta,

ALQI
[Verizon Samsung Galaxy S III] AdamOutler:
This isn't a filesystem being used. The bootloaders are loaded into memory and then executed at startup. Once the kernel is loaded, everything prior is irrelevant.

Take note of the fact that I commented out the aboot. It was not flashed because it was advised that I do not flash that partition.

I shared all my initial thoughts. It was risky and I was willing to take the risk to verify this firmware would or would not work. I have the tools to recover so i'm not worried about the risks.

I'd do it again if another reputable source came up with an experimental firmware to flash. Ask yourself this, who else is in a position to test that sort of thing?

Anyways, as I stated above, I've now got a QDL device to work with.
[Verizon Samsung Galaxy S III] AdamOutler:
Ralekdev, did you try the 'viewmem' utility?
[Verizon Samsung Galaxy S III] Ralekdev:
Hadn't seen that before, but yeah it appears to have gotten at least part of it. I can't say whether it's the full thing because there are some references in the 0x20000 range but the rpm firmware is loaded there after the pbl is through which could mean the original data was overwritten. I'll take a closer look later on today
[Verizon Samsung Galaxy S III] AdamOutler:
There is an article I posted on the front page of xda today which outlines a data forensics tool called 'LImE'. It is a loadable kernel module which will make a complete dump of all memory on a device. You may be interested in it.
[Verizon Samsung Galaxy S III] Ralekdev:
I'll take a look but I think I did manage to get everything. It copies a lot of itself in the 0x12000 range up to 0x20000. It ends up looking like slide 21 in the 8960 boot architecture pdf
[Verizon Samsung Galaxy S III] mastamoon:
If we can't put another phones boot loader on our phone because of a device Id mismatch, is it possible to spoof/change our device Id along with using their boot loader? I I would guess with the level of depth you guys are able to probe you might be able to do that sort of thing, maybe? ^_^
[Verizon Samsung Galaxy S III] E:V:A:
Do you know where we can find a pre-compiled copy?
[Verizon Samsung Galaxy S III] LLStarks:
Here's Lime module built from the I535 kernel sources. This is for stock kernel.

https://www.dropbox.com/s/zdesybzfawlra0c/lime.ko

I now a have an 1.8 GB memory dump sitting on my laptop. It compresses nicely to 600 MB.

If you want the file, let me know.
[Verizon Samsung Galaxy S III] xd.bx:
Hey,

Sorry to hear about the brick. Two pointers that could interest you:

- scotty2 bricked his Desire Z some time ago. He did not have the PBL at the time, nonetheless started implementing Qualcomm's download protocol. You can look at his sources here: https://github.com/tmzt/g2root-kmod/blob/master/scotty2/pbl/pbl.pl

- there is a closed source windows implementation of QDL in the RIFF Box. Il allows writing the flash for a number of HTC phones (they call it QHUSB). If you find an S-OFF HTC phone with the same chip as the Verizon S3, then you can dump the PBL through HTC secondary bootloader "mb" command.
[Verizon Samsung Galaxy S III] Durthquake:
If this thought is not useful please remove - but isn't the One X us variant using the same S4 processor, and I believe it is unlocked (not sure if S-Off yet though?)
[Verizon Samsung Galaxy S III] LLStarks:
The Droid Incredible 4G and AT&T HTC One X have the MSM8960.

Not sure if either have achieved S-OFF.
[Verizon Samsung Galaxy S III] alquimista:
Can we load lime.ko with the app posted here:

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

It was built on an xperia s, but the dev asks for feedback on all devices.

Last, if that 1.8G dump contains no personal info, can you post it? I'd like to run it through IDA following ralekdev's instructions.

Offtopic:

How do you always have everything as soon as someone mentions it? It uncanny and amazing!

Ta,

ALQI
[Verizon Samsung Galaxy S III] LLStarks:
The module needs to be loaded with certain parameters, so I'm not sure if the app will help.

I don't want to post the dump since it has personal info.

PM me or ask on IRC.

(Alquimista, the Android build chain is awesome to have lying around.)
[Verizon Samsung Galaxy S III] Durthquake:
This thread has a couple people that got S-Off One X's with the S4 processor. maybe they can get you what you need file wise, if you reach out to them:confused: http://xdaforums.com/showthread.php?t=1645002
[Verizon Samsung Galaxy S III] xd.bx:
Hi EVA,

So after reading again the boot process, it would appear that the PBL is in the RPM-ARM7 ROM, whereas SBL2/3 are loaded into Krait which is (afaik?) the main apps ARM processor. So unless the memory view from Krait is the same as RPM, the "mb" command probably won't work.(also, note the PBL resides at 0 according to manual, not the usual 0xFFFF0000). A better alternative, I think, would be to halt with JTAG the RPM-ARM7, then simply dump the PBL. Someone with a RIFF Box & a soldered JTAG could try it, it might work wonders. Then the PBL could be studied to better understand the boot process and possibly find vulns (think bootrom vulns as in the iDevices).
[Verizon Samsung Galaxy S III] Rebellos:
I'm sorry if this has been already answered.

I'm not 100% sure about it but looks like it's:

restart->run until reaching 0x7CE8->set R0=0(or 1)->sleep 1ms (irrevelant)->resume

I'm nearly sure that 0x7CE8 is last OPcode of ROM bootloader's (PBL) function like

bool is_secure_boot();

And JTAG script does override its return value.

//edit3:

Or it's function loading code from solid memory to RAM and JTAG script is overriding it's parameter, telling if its secure or nonsecure boot

Thanks to RalekDev

Doing it like this will simply let PBL load and execute ANY code in place of SBL1, It'll even try jump into Nyan Cat if, of course, it passes non-secure integrity check (like md5/crc sum). It's still tethered boot, with JTAG and stuff.

//edit:

Modern multicore SoCs does usually interconnect all cores busses, so any core can access any part of RAM memory (if TMZ or MMU doesn't disallow it, also some peripherials can be useable by just one specific core), however for eg. some memory bank can be addressed under 0x10000000 from MODEM-CPU and can be seen under 0x90000000 from APPS-CPU.
[Verizon Samsung Galaxy S III] AdamOutler:
What memory locations do we need to map to physical resistors? Give me some memory locations and functions, I'll map them.

[youtube]dw8ha5caex0[/youtube]

Let me know if this is needed, if not, I'll leave my device bricked and hook up JTAG some other time.
[Verizon Samsung Galaxy S III] E:V:A:
Roger that! I was working on that, and you Mr. Spock just beat me to it.

This is (Lauterbach or ARM DS-5) TRACE32 JTAG scripting code (CMM style) with

slight variations, depending on your debugging system. (There are many!)

That's why it took me so long to figure what that line was doing.

[SIZE=2]g [B]0x7ce8 [/B]/o /cmd "r.s r0 [/SIZE][SIZE=2][COLOR=Red]0x0[/COLOR][/SIZE][SIZE=2]" ;[/SIZE]

To make a very long story short. The important commands can be summarized as this.

[SIZE=2]-------------------------------------------------------------------------------
Command Short Description
-------------------------------------------------------------------------------
data.set d.s writes data to memory.
data.dump d displays 0x20 (default) bytes of data from a specific address (range).
register.set r.s sets the value of a register.
go g starts running the device.
system.up sys.u connects to the specified target.
system.down sys.d disconnects the debugger from the target.
break b stops running the target.
-------------------------------------------------------------------------------
[/SIZE]

Then I had trouble finding the "/cmd" flag, but it simply does what you said:

"CMD <string> Execute 1 or more TRACE32 commands when the breakpoint is hit."

As for the "/o" flag, I have no idea, and could not find any info, but we got the message without it!

So this raises two questions:

a) Does this map to the same location in the MSM8960 ?

b) What is the function of GPIO_76 in the MSM8660 ? (Same as in 8960?)

EDIT: BTW. What do you mean with "nearly sure"? Can you check and confirm?

What do you need to do so? (Or better yet, if someone can provide a binary or assembly dump...)

EDIT2 (2012-08-14):

The "/o" flag is probably short for "/Onchip" which sets an on-chip hardware break-point.

(There are usually only two available, unlike SW BP's which can be oo.)
[Verizon Samsung Galaxy S III] Ralekdev:
For our phone it would need to be 0x8834.

That's the end of the function that checks if the secure boot bit is enabled, so by setting r0 to 0 you just force it to return false.

The specific value that determines whether secboot is on is at 0x706038 in memory, 5th bit (0x20). If set, secboot is on.

If this is not set, the PBL does not check the certificate chain and signature of SBL1, SBL1 doesn't check SBL2, etc.

This alone doesn't let you flash unsigned boot.img directly because our aboot does the signature check regardless of secboot, but since SBL3 would no longer check aboot's signature you can upload a patched aboot that skips the check

Unfortunately this is only really useful to people with JTAG or the knowledge to make the needed hardware modification.

As it stands, I don't see a way to disable secure boot through any software method, which is most certainly by design.