yashsingh1/xdaforums huggingface dataset:
[Verizon Samsung Galaxy S III] AdamOutler:
right, unless we can load a kernel into memory somehow..

While ralekdev was looking at aboot he mentioned this to me in G+

However, those of you who are decompiling and analyzing, please look for boolean or hexidecimal values in memory which control boot from SDCard or EMMC.. this is where we can begin hacking the hardware. It's logical to assume the special function registers (SFRs) are all located within the same block of memory. SFRs will appear to be a location in memory.

These SFRs tell the device where to boot from and they are tied directly to the resistors outside of the processor. These boolean values located in the SFRs are digital representations of highs and lows applied to pins on the processor. Though they are accessed the same way as the rest of the memory, they are actually digital inputs like GPIOs.

If we can locate these memory registers I can hook up via SSH, monitor the memory locations while probing and injecting highs and lows to look for changes. It may be possible to disable secure boot this way.
[Verizon Samsung Galaxy S III] newuser134:
Does anyone know the hardware modification required to disable secure boot? I'd be willing to try it and then try flashing a patched aboot to avoid software checks, if anyone can point out specific hardware modifications or resistors to connect/disconnect from certain pins, I'm assuming from the quoted post that secure boot can be disabled by doing some hardware modifications.
[Verizon Samsung Galaxy S III] newuser134:
Yes, but maybe I misunderstood. What I read from that post is that you can connect via SSH and set the specific memory for SFR's (by software), however, that you couldn't get software access yet since secure boot is on, but since not everyone might want to open their phone and make a hardware change, I was just wondering if it may be known which specific SFR'S might need to be set (mainly from Ralekdev's post above yours), by hardware change not by ssh or software, Ralekdev's post sounded like that might be known but it wouldn't do much good to the average owner since it couldn't be done unless by jtag or hardware modification. Kind of like you have jtag and aren't worried about flashing alternative aboot's even though the average owner wouldn't want to do that, so it wouldn't do them any good. I was just stating I wouldn't mind trying the hardware modifications to disable secure boot.

If I misunderstood, please remove the post, didn't mean to ask a pointless question, just wanted to volunteer to test if there was a known way even if not by software. Just excited to help testing to turn off secure boot.
[Verizon Samsung Galaxy S III] The Archangel:
I need to put this in my signature, btw ill clean the crap up, again before I call it a night.
[Verizon Samsung Galaxy S III] E:V:A:
Address Galore !

Sorry, I don't understand. What is the difference between these two addresses?

I need to better understand the memory map. Do you have some kind of rudimentary memory map or something that can help me understand this? I feel the ∇(Learning rate) is going well beyond my super powers! It would be very helpful see how it would relate to another known memory map. For example, this one for the MSM7x25A.

1) I don't understand, how these cannot be GPIO's. The boot configuration is certainly decided by off-chip resistors (connected to GPIOs). So what are you saying? I suppose I don't quite understand these SFR's...

2) Again, what is that (0x88eff000) memory location?

TO ALL:

Please! From now on let's try to not posting memory locations without specifying:

a) What they represent or what function you think they have.

b) How they were obtained. (Through disassembly, documentation or other forms of specified RE method.)

c) What part of memory were dealing with. (physical, virtual)

d) What tool you used to read/write this location, so that we can verify & reproduce the result by ourselves. (viewmem, lime, etc.)

This will help eliminate crosstalk and various obvious followup questions like above.
​
[Verizon Samsung Galaxy S III] Ralekdev:
0x8834 is part of the PBL code (The PBL ranges from 0x0 to 0x18000).

It's part of the function that checks if secure boot is enabled, seen below (Is it ok to post this? not sure)

ROM:00008824 is_secure_boot_enabled ; CODE XREF: pbl_dload_auth_flash_prog+48p
ROM:00008824 ; pbl_auth__initialize_auth+24p
ROM:00008824 LDR R0, =0x706000 ; Load from Memory
ROM:00008828 LDR R0, [R0,#0x38] ; Load from Memory
ROM:0000882C ANDS R0, R0, #0x20 ; Rd = Op1 & Op2
ROM:00008830 MOVNE R0, #1 ; Rd = Op2
ROM:00008834 BX LR ; Branch to/from Thumb mode
ROM:00008834 ; End of function is_secure_boot_enabled

or in C

int __fastcall is_secure_boot_enabled()
{
int result; // r0@1

result = QFPROM_ofs_6000.SECURE_BOOT1 & 0x20;
if ( QFPROM_ofs_6000.SECURE_BOOT1 & 0x20 )
result = 1;
return result;
}

So the JTAG commands earlier would reboot the device, let it run until it got to the "BX LR" (return from function) instruction. ARM uses R0 to hold the return value from functions, so we set R0 to 0 to force the function to return false.

The other address, 0x706038 is what's checked inside the function. First 0x70600 is loaded to R0, then R0 is offset by 0x38 to give us 0x706038, then it grabs the value at that address. It then does a bitwise & between that value and 0x20. If the result is non-zero, R0 is 1 (return true), otherwise it's 0 (return false)

So we can see that 0x706038 & 0x20 controls the secure boot

Another address of note is 0x706034, which holds the BOOT_CONFIG fuse values

The value is stored in the upper 6 bits of that byte, so (value_at_706034 & 0xFC) >> 2 would give you the boot configuration used.

You can use viewmem to dump the values for yourself ("viewmem 0x70600 0x100" would be enough)

I'm not much of a hardware guy, so I don't know exactly what these addresses correspond to on the board.

A comprehensive memory map would be useful. I'll start compiling what I have.
[Verizon Samsung Galaxy S III] Rebellos:
The problem is that, unlikely on Samsung CPUs I and Adam know abit already, e-fuses are used not only to store secureboot hash keys, but these does also hold most of the boot config.

0x706034 and 0x706038 (and few more) are e-fuses SFRs (special function registers), and these most likely doesn't map any external I/Os of CPU, but these are internal one-time programmed e-fuse ROM.

SFRs are used to map physical functionallity of ARM SoC to memory location. There are milions of logical gates connected to CPU address bus, configured to connect certain peripherial gate set to CPU data bus only when address does match perfectly to desired peripherial address.

For eg this is how e-fuse read-only gates might work for 0x706034

There is set of gates that expect address bus state to match 0111 0000 0110 0000 0011 0100 (address bus state is set by LDR/STR instructions)

if STR (store register) bit is set it does probably fire data-abort error (efuses are R-O)

if LDR (load register) bit is set it does cause connecting physical 32bit e-fuse register to the data-bus of CPU, and LDR mechanism of ARM core does fetch data bus content into desired register.

This is ofc abstract. This is "kinda" idea how this all works.
[Verizon Samsung Galaxy S III] mybook4:
The JTAG setup would be used to inject an artificial return value in order to temporarily disable secureboot. It would be temporary and have to be done on every boot. However, learning more about the device (with JTAG equipment, hardware hacking, reverse engineering boot chain code, etc) will allow us to eventually find a way to permanently disable secureboot or hijack the boot chain (in a way that would allow custom kernel flashing and booting from the boot.img parition).
[Verizon Samsung Galaxy S III] :
Well if it helps sbl1-3 on s4 devices control security and write protection. There are some places that are signed some not and messing with a signed one that's in boot order will need Odin. Now the s4 is kinda new and HTC really dropped the ball with its security. It was all flawed. But sbl is not a boot loader so to say. QCom has always allowed there oems to do as they wish with security because there is an option you can try to find the secu flag on one of your partition and change from 3 (or maybe 1) to 0 and dd it back. Do that at your own risk however. You may need Odin to recover if its signed but my money is that it won't even write and you will need to find a way to disable WP.... maybe try bricking the 2nd bootloader (that's not an sbl) by sending something else there. Or changing the header to a new version if it bricks go to Linux and see if when you boot the phone it goes to emmc recovery for a while. After that you can use fuses emmc recovery program to flash other partitions on to the phone that contain the secu flag. Then repair the partition you broke and try to reboot. You should be secu off if that works. That's about all I got for now
[Verizon Samsung Galaxy S III] E:V:A:
I have a very vague memory of reading something that you need to name the boot image in a certain way...Perhaps with an "e" (for emergency) in front of normal name, but I could be wrong. If we could get a PBL dump, we could look for such a string. So if you decide to JTAG, please dump!

=================================================

Other event updates:

1) I just updated post #241 with the PBL Boot Options that I forgot to add at the time.

2) I have some problems registering with this site to download these documents,

perhaps someone else could help, that is better in Chinese than I am?

http://www.rd211.com/docu/78137.html

http://www.rd211.com/docu/79590.html

http://www.rd211.com/docu/76489.html

3) I just updated post #295 with info on the Lauterbach Trace32 JTAG script "/o" switch.

4) This could have been an interesting place for related MSM sources...

5) But this is a very useful tool:

cat /proc/kallsyms

[SIZE=2]Command: cat /proc/kallsyms
Output: <physical address> <type> <prefixed symbol name>

...
c08e0fb4 r __param_bootloaderfb
c099b170 d reboot_mode
c09a1108 d s5pv310_cpufreq_reboot_notifier
...
[/SIZE]

The output can be understood from the linux "nm" command that is used to list

symbols from object files. From the man pages we have:

Summary:

1) All exported entries have their symbols prefixed with "__ksymtab_".

2) If lowercase, the symbol is local.

3) If uppercase, the symbol is global (external).

[SIZE=2]-------------------------------------------------------------------------------
a The symbol's value is absolute, and will not be changed by further linking.
b The symbol is in the uninitialized data section (known as BSS).
c The symbol is common. Common symbols are uninitialized data.
d The symbol is in the initialized data section.
g The symbol is in an initialized data section for small objects.
i The symbol is an indirect reference to another symbol. (rarely used. )
n The symbol is a debugging symbol.
r The symbol is in a read only data section.
s The symbol is in an uninitialized data section for small objects.
t The symbol is in the text (code) section.
u The symbol is undefined.
v The symbol is a weak object.
w The symbol is a weak symbol that has not been specifically tagged as such.
- The symbol is a stabs symbol in an a.out object file.
? The symbol type is unknown, or object file format specific.
-------------------------------------------------------------------------------
[/SIZE]

6) This is another: cat /proc/iomem

Conclusion: Nothing fun yet...
[Verizon Samsung Galaxy S III] tehh4ck3r:
Here you go:

http://dl.dropbox.com/u/12194390/80-VU872-41_MSM8260-MSM8660_BASEBAND_REFERENCE_SCHEMATIC.pdf

http://dl.dropbox.com/u/12194390/AP...OBILE_STATION_MODEM_DEVICE_REVISION_GUIDE.pdf

http://dl.dropbox.com/u/12194390/MS...NING_-__INTRODUCTION_%26_CHIPSET_OVERVIEW.pdf
[Verizon Samsung Galaxy S III] xd.bx:
Alright, I know this is confidential information from Qualcomm, but does anyone have the SOFTWARE INTERFACE manual? It has all the juicy hardware registers and stuff.
[Verizon Samsung Galaxy S III] AdamOutler:
I also need this. I'm done trying to figure out what Samsung did to make QDL apparently inoperative... I think it has to do with the SamsungPST + Samsung Dongle setup with some kind of crazy long hash key before QDL will even respond.... so tonight I'm JTAGing my GS3 back to life.

If we can get this manual, it will save a metric s**t ton (as opposed to the imperial s**t ton) of time on Ralekdev's part reverse engineering bootloaders to obtain SFR registers to be reverse engineered by me at the hardware level then remapped in Ralekdevs bootloaders disassembly to determine hardware modification rework required for testing.

Basically, while we can work without it, it would save us a weeks worth of work to get the software interface manual.
[Verizon Samsung Galaxy S III] :
Qdl is never gonna work without Samsung leaking the encryption key they use to unlock it themselves. Its the same for HTC s4 devices .... I know this from a few ppl I talked to who also work with these things. Now if someone can humor me. Download emmc_recovery made by fuses. Then flash an unsigned boot loader. Just change a useless byte like version. Then did it back. Just remember this can hard brick. Now run the brick detector. This has to be done fast. If it detects your device this is good and i may be able to talk to some people very good at this stuff. If you get brick detected be sure to just flash the original partition back with the tool. And yes it must be done in Linux
[Verizon Samsung Galaxy S III] KennyG123:
Thread cleaned

Please remember to only post comments that will directly help move forward of this goal

Thanks

FNM
[Verizon Samsung Galaxy S III] dexter35803:
QC EMMC Downloader

Has anyone messed with the Emmc Downloader on QPST it seems to allow writeing of the bootloaders but this bootloader has come packaged with it can anyone shed any light on this the app is pictured below

*edit*

Also looking at the Software Download for QPST it has a setting for Sec Boot 2.0 and probably more again its pictured below
[Verizon Samsung Galaxy S III] E:V:A:
We use Secure Boot 3.0, but this look very interesting. We should figure out what protocols they use to do this "conversations"... I know some people around here already know a lot about this, in particular Chainfire...

BTW: Did you try hit the "Qfuse..." button?? What happens? (But be very careful!! Dots usually imply another menu, but if it does not in this case...don't blame me for bricking your device!)
[Verizon Samsung Galaxy S III] AdamOutler:
Verizon GS3 is now Bootloader UNLOCKED.

We now have access to an unsecure bootloader. This was leaked by an African-Canadian Sock Monkey.

Let me make this clear. If Samsung updates your device's bootloaders, using this tool could potentially brick your device. Once you apply this,

never accept a factory update

without first flashing the Odin Packages in the Original Post of this thread. As a general rule, you want to be the last guy to apply any Samsung update. Run custom.

As of the date of this posting, this works great on Linux and it should work wonderfully on Mac too. NOTE: this may work on windows, but please, windows users.. learn to use your computer before you ask questions on XDA-Developers. This is one-click on Linux and Mac every darn time. If you're using Windows, I recommend downloading Windows Ubuntu Installer(WUBI) to install Ubuntu from within Windows.

Download

http://d-h.st/ypJ

Instructions:

1. Open this file

2. Select Root with DebugFSRoot and Do It

3. Select Flash Unsecure Aboot and Do It

4. Use Odin or CWM to flash kernels to your device

To flash from device without the above tool:

root your device

Download this link to your /sdcard/Downloads/ folder: http://d-h.st/Piq

Type this in the terminal emulator

su -c dd if=/sdcard/Downloads/aboot.img of=/dev/block/mmcblk0p5

This was tested with a Sprint kernel flashed via Odin. Although the Sprint kernel caused the device to have a blank screen due to hardware incompatibility, it's more than enough for a proof-of-concept. Stock bootloaders will not let you flash improper kernels with Odin and will cause the device not to boot. This corrects the problem. I'll leave implementation to other developers. If you feel uncomfortable flashing this on your own, wait for your favorite kernel developer to release something.

Note to developers: This CASUAL package contains everything you need. A jar can be opened as a zip file. CASUAL format sticks all scripts in the /SCRIPTS/ folder. You can obtain all files needed from within this package, then repackage them into CWM format. In order to avoid a mass brick fest, please apply an assert to your CWM scripts to verify ro.build.version.incremental and do not allow updates past what has been tested. As of the time of this writing I535VRALG7B is safe.

With the unlock of the GS3, this thread is locked. There will be no victory dancing in here. Move along to General or something. This thread will lie dormant until it is needed again in the future. Ralekdev will be releasing another exploit in the future as soon as this one stops working. Feel free to review what was learned until then.

P.S. Sorry to those who I have offended by having posts removed. I'm also sorry to those who had their intelligence insulted before I had both of our posts removed. I hope you understand that in 6 months from now when everyone forgets about this thread but needs to catch back up, the information will still be right here in condensed format.
[Verizon Samsung Galaxy S III] E:V:A:
Thanks, but please don't be too trigger happy. I actually needed to refer to this post... (Or perhaps it wasn't you who removed it?)
[Verizon Samsung Galaxy S III] AdamOutler:
I've reopened this thread upon a report that the CASUAL Jar provided above, which was working two months ago, is now causing bricks. Do not flash on recently updated devices.

Can anyone confirm or deny that the new update kills the CASUAL method above?

I do not have a Verizon Galaxy S3 anymore... However, I have a feeling that because of work in the past by a guy who will surely post below me, a new exploit will not take much time.

False alarm. User was operating a Sprint phone. Game is still on :) Thread locked.
[Verizon Samsung Galaxy S III] AdamOutler:
I took about 80 shots of the VZWGS3 mainboard. These are the best. Download the attached zip for high resolution images. I will be using these for annotation purposes.

Note the area between the processor and EMMC has scratches where I removed the conformal coating. The chips look wet because in order to attain a good shot, I had to wet them down.

Please blame my cat for hair on the processsor! I blame my cat for everything.

In the above picture you can see some sort of communications points to the left and the processor resistors above and below
[Verizon Samsung Galaxy S III] :
Delete
[Verizon Samsung Galaxy S III] E:V:A:
^^ Hi! Great detail in those photos, but the reflection is way too high. I can barely make out the chip markings on any of those chips. I suggest you use a very bright and slightly grey background mat, instead of the black. That will help your camera compensate for reflection. Then try to use daylight coming in from the sides. Any type of fluorescent light is terrible for this kind of thing. Perhaps you tought about all this already. Then please disregard. In any case, it is very nice someone posted some internal shots for another model.
[Verizon Samsung Galaxy S III] tpike:
I can't believe how smart you guys are. I'm in awe! Take this suggestion with a grain on salt, but do y'all think anyone would answer an email to that address in your dump Adam? Sorry for no quote, I'm mobile. I think the address was android.os@Samsung

Flame away cause i know the idea is kinda ridiculous. :D

Sent from my SCH-I535 using Xparent ICS Tapatalk 2
[Verizon Samsung Galaxy S III] AdamOutler:
Im about to go to bed. However, I would like it if someone could pull the /dev/block/mmcblk0p10 from another GS3, like AT&T or any other unlocked carrier device.

adb shell
su
dd if=/dev/block/mmcblk0p10 of=/sdcard/emmcblk0p10 bs=4096

then grab the mmcblk0p10 file from the sdcard and post it up here.

I'm fairly confident we can flash that block without triggering a problem on the Chain-of-Trust
[Verizon Samsung Galaxy S III] segv11:
At least on the Verizon Galaxy Nexus, efs mounts as /factory. The MEID is at position 0x00202d8 in /factory/nv_data.bin. It would be easy to check if the GS3 does something similar.

---------- Post added at 10:52 PM ---------- Previous post was at 10:43 PM ----------

It would be funny if Samsung left that door wide open! The param is also where the Galaxy Nexus stores bootloader lock status, at offset 0x000007C. A 1 there means locked, and a 0 means unlocked. I have a root app out which sets/clears that bit to allow bootloader unlock/relock.

It would be absolutely hilarious if tweaking some bits in param on the SGS3 would unlock the bootloader... but Samsung can't have made it that easy, can they?
[Verizon Samsung Galaxy S III] alquimista:
I doubt it. The other problem besides the GNex being a different beast, is that the SGS3's bootloader was compiled with stuff like fastboot disabled and I have no idea what other mods were made to the source code before compilation.

On the other hand, it's worth a shot.
[Verizon Samsung Galaxy S III] E:V:A:
You can always post your logs to Pastebin or Pastie ...
[Verizon Samsung Galaxy S III] segv11:
You're right, it's a long shot. We collected several SGS3 param images, one T-Mobile, one AT&T, a VZW and another VZW.

They are large files, mostly NULLs. There are only two differences between the files:

At 0x0000014, both VZW dumps have a 1, T-Mo dump has a 0, AT&T has a 0.

From 0x09ffc00 to 0x09ffc0f all of the dumps have very different strings of 16 bytes (nothing in common between any of them). This leads me to believe that this is some kind of device-specific key, hash, or serial number.

If we could get a Sprint dump, we could confirm if 0x0000014 has to do with lock state, or GSM vs CDMA.

Alternately, would anyone care to test what happens to a VZW device if that 1 at 0x0000014 is changed to a 0? Be careful though it might brick the device if this partition is being checked by crypto.

EDIT: Now we have 3 param images. Edited description above.

EDIT 2: Now we have 4...
[Verizon Samsung Galaxy S III] AtoZ0to9:
att param.img....

so why is 7zip making its filesize from 10mb to 2kb... i even unpacked it it was back at 10mb... im not so sure i trust that, ill get yall a dropbox link too...

http://dl.dropbox.com/u/85033560/param.img
[Verizon Samsung Galaxy S III] segv11:
Thanks. Updating my post above.

It compresses that much because it is almost all NULLs, like all the other param dumps. It was correct; thanks for the dropbox link cause I'm not on Windows and don't have 7zip.

TL;DR: Location 0x0000014 is looking better and better. Anybody have a Sprint image?
[Verizon Samsung Galaxy S III] AtoZ0to9:
np, lemme know if i need to pull anything else...
[Verizon Samsung Galaxy S III] segv11:
Hopefully we can get a Sprint image to double check before trying this... but is anybody game for possibly bricking their SGS3?

It needs root and busybox. It might unlock it, it might brick it, or it might do nothing...

echo -n '\x00' | dd obs=1 count=1 seek=20 of=/dev/block/platform/msm_sdcc.1/by-name/param
[Verizon Samsung Galaxy S III] mybook4:
PS, another Verizon param

http://db.tt/k2Yklgk9

My initial Samsung boot screen shows the "custom" unlocked padlock (note, this does NOT mean I have an unlocked bootloader. It means that I have flashed a custom recovery)
[Verizon Samsung Galaxy S III] E:V:A:
Just for reference. This site (anyclub.org) is awesome for Qualcomm devs...!

And this can be very useful as well...

"Android Board Bring-up"

"MSM8960 Modem restart Procedure"
[Verizon Samsung Galaxy S III] enderblue:
Two of us took the plunge.

Phone still boots. The bit is set to 0, but flashing a custom kernel still results in the lockup on boot. Had to Odin the stock kernel back to the phone.
[Verizon Samsung Galaxy S III] invisiblek:
Ender, do we get the vzw message on boot still or it just locks up?

This could be interesting if we don't get the logo...