[R&D] Unlock Bootloaders

Status
Not open for further replies.
Search This thread

E:V:A

Inactive Recognized Developer
Dec 6, 2011
1,447
2,222
-∇ϕ
Address Galore !

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.

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.

attachment.php



... 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. ... Though they are accessed the same way as the rest of the memory, they are actually digital inputs like GPIOs.

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.
 

Attachments

  • MSM7x27A_memory_map_1.jpg
    MSM7x27A_memory_map_1.jpg
    48.1 KB · Views: 13,027
Last edited:

Ralekdev

Retired Senior Recognized Developer
Sep 4, 2010
32
384
Sorry, I don't understand. What is the difference between these two addresses?


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)
Code:
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
Code:
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.
 
Last edited:

Rebellos

Senior Recognized Developer
May 13, 2009
1,353
3,428
Gdańsk
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.
 

mybook4

Senior Member
Apr 3, 2011
445
267
I just have to ask this: Would unlocking it by jtag be a permanent unlock (disable secure boot), or is it only until the next reboot, then it'll be locked again?

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).
 
S

simonsimons34

Guest
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

Sent from my One V using Tapatalk 2
 

E:V:A

Inactive Recognized Developer
Dec 6, 2011
1,447
2,222
-∇ϕ
... 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.

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

Code:
[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).

Code:
[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...
 
Last edited:

alquimista

Senior Member
Mar 20, 2008
218
118
Los Angeles
Here's what I got from cat /proc/iomem
Code:
00500000-00500fff : msm_ssbi.0
00700000-007060ff : hdmi_msm_qfprom_addr
0080207c-0080207f : slimbus_slew_reg
01a01000-01a01fff : msm_etb
01a03000-01a03fff : msm_tpiu
01a04000-01a04fff : msm_funnel
01a1c000-01a1dfff : msm_etm
03000000-0327ffff : wcnss_mmio
03204000-032040ff : pil_riva
04100000-04100fff : kgsl_2d0_reg_memory
04100000-04100fff : kgsl-2d0
04200000-04200fff : kgsl_2d1_reg_memory
04200000-04200fff : kgsl-2d1
04300000-0431ffff : kgsl_3d0_reg_memory
04300000-0431ffff : kgsl-3d0
04400000-044fffff : msm_vidc.0
04500000-045fffff : vfe32
04500000-045fffff : msm_vfe
04600000-046fffff : msm_gemini.0
04700000-047effff : mipi_dsi
04800000-048003ff : csid
04800000-048003ff : msm_csid
04800400-048007ff : csid
04800400-048007ff : msm_csid
04800800-04800bff : ispif
04800800-04800bff : msm_ispif
04800c00-04800fff : csiphy
04800c00-04800fff : msm_csiphy
04801000-048013ff : csiphy
04801000-048013ff : msm_csiphy
04a00000-04a00fff : hdmi_msm_hdmi_addr
04e00000-04efffff : msm_rotator.0
05100000-051effff : mdp
05300000-053fffff : vpe
05300000-053fffff : msm_vpe
08800000-088000ff : pil_qdsp6v4.1
08900000-089000ff : pil_qdsp6v4.2
08b00000-08b00003 : pil_qdsp6v4.2
08b00000-08b00003 : pil_qdsp6v4.1
12180000-121807ff : core_mem
12180800-12181fff : sdcc_dml_addr
12182000-12183fff : sdcc_bam_addr
121c0000-121c07ff : core_mem
121c0800-121c1fff : sdcc_dml_addr
121c2000-121c3fff : sdcc_bam_addr
12240000-12240fff : bamdma_dma
12244000-12247fff : bamdma_bam
12400000-124007ff : core_mem
12400800-12401fff : sdcc_dml_addr
12402000-12403fff : sdcc_bam_addr
12440000-12440003 : gsbi_base
12440000-12440003 : spi_qsd
12460000-12460fff : spi_base
12460000-12460fff : spi_qsd
12480000-12480003 : gsbi_qup_i2c_addr
12480000-12480003 : qup_i2c
124a0000-124a0fff : qup_phys_addr
124a0000-124a0fff : qup_i2c
12500000-12501000 : msm_hsusb
12500000-12501000 : msm_otg
12500000-12500fff : msm_hsusb_host
12800000-12803fff : pipe_mem
16000000-16000003 : gsbi_qup_i2c_addr
16000000-16000003 : qup_i2c
16080000-16080fff : qup_phys_addr
16080000-16080fff : qup_i2c
16200000-16200003 : gsbi_qup_i2c_addr
16200000-16200003 : qup_i2c
16280000-16280fff : qup_phys_addr
16280000-16280fff : qup_i2c
16300000-16300003 : gsbi_qup_i2c_addr
16300000-16300003 : qup_i2c
16380000-16380fff : qup_phys_addr
16380000-16380fff : qup_i2c
16400000-16400fff : gsbi_resource
16440000-16440fff : uartdm_resource
16440000-16440fff : msm_serial_hsl
16500000-16500003 : gsbi_resource
16500000-16500003 : msm_serial_hs
16540000-16540fff : uartdm_resource
16600000-16600fff : gsbi_qup_i2c_addr
16600000-16600fff : qup_i2c
16680000-16680003 : qup_phys_addr
16680000-16680003 : qup_i2c
18320000-1841ffff : msm_dmov
18500000-1850ffff : qce.0
18500000-1850ffff : qcrypto.0
1a000000-1a000003 : gsbi_qup_i2c_addr
1a000000-1a000003 : qup_i2c
1a080000-1a080fff : qup_phys_addr
1a080000-1a080fff : qup_i2c
1a200000-1a200003 : gsbi_qup_i2c_addr
1a200000-1a200003 : qup_i2c
1a280000-1a280fff : qup_phys_addr
1a280000-1a280fff : qup_i2c
1a500000-1a5001ff : msm_rng.0
28080000-28081fff : slimbus_physical
28084000-28085fff : slimbus_bam_physical
28800000-288000ff : pil_qdsp6v4.0
2a03f720-2a04071f : tz_log.0
80200000-88cfffff : System RAM
80300000-80c75873 : Kernel text
80d00000-8120153b : Kernel data
8f200000-8f6fffff : System RAM
90000000-afd7ffff : System RAM
b8602000-ba5fffff : System RAM
c0000000-e9ffffff : System RAM
ea100000-ffffefff : System RAM

I'm a bit overwhelmed with work and moving right now, but I'll try and pitch in where I can.

Ta,
ALQI

Sent from my SCH-I535 using xda app-developers app
 

AdamOutler

Retired Senior Recognized Developer
Feb 18, 2011
5,224
9,826
Miami, Fl̨̞̲̟̦̀̈̃͛҃҅͟orida
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.

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.
 
S

simonsimons34

Guest
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

Sent from my One V using Tapatalk 2
 

dexter35803

Senior Member
Apr 11, 2008
158
98
Confusion
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
 

Attachments

  • emmcdownload.jpg
    emmcdownload.jpg
    47 KB · Views: 8,461
  • softDL.png
    softDL.png
    42.8 KB · Views: 8,399
  • secBoot.jpg
    secBoot.jpg
    48.4 KB · Views: 8,207
Last edited:

E:V:A

Inactive Recognized Developer
Dec 6, 2011
1,447
2,222
-∇ϕ
Has anyone messed with the Emmc Downloader on QPST
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!)
 

E:V:A

Inactive Recognized Developer
Dec 6, 2011
1,447
2,222
-∇ϕ
Some Questions and Issues, still to be resolved

There are some burning issues that still have not been addressed/resolved
that I think may be essential for further unlock development. And unless there are some recent tantalizing developments, that I'm not yet aware of, I'd like to see a plan of action. Perhaps something like this.

My Strategy / Way Points:
1. Find out if any Qfuses are blown, and which ones.
(What is the meaning/behavior of the various Qfuses on MSM8960?)
2. If we are not using Qfuses, how are the GPIO boot pins set?
3. If we are using Qfuses, what alternatives do we have to circumvent to reach code execution?
4. What is the meaning of the BOOT_CONFIG pins in (2).
5. How can we change GPIO to do what we want?
a) What do we want?
b) Is this a SW/FW hack or a HW hack?
6. How can we get our code to run?
a) Does it still need to be signed?
b) Where and when should it run?
The Issues
A) What are the:
a) cold-start BOOT_CONFIG settings?
b) warm-start BOOT_CONFIG settings?
We raised this issue in post #212, but we had a different opinion (#206, #217)
of how the MSM_RESOUT_N signal behaves during cold/warm boot. The point
being that the pins internal pull-up/down strength and behavior is decided
programatically, while the reference design was updated/changed at some point,
and thus the true behavior it was never resolved and verified.

What to do: We need someone to measure what happens on the following
UCP700 pins (see #212) during cold/warm boots, respectively.

Code:
C30     MSM_RESOUT_N, 
AK28    BOOT_CONFIG_6
AH32    BOOT_FROM_ROM

also BC[0:1] to verify...
B) How can we read all the GPIO settings as shown in #228 ?
On the SGS2 running stock GB (and many others), we can simply issue the command:
Code:
cat /sys/kernel/debug/gpio
and the result is in the form:
Code:
[SIZE=2]...
GPIOs 168-175, GPL0:
 gpio-171 (TSP_LDO_ON          ) out lo
 gpio-172 (GPB                 ) in  lo
 gpio-173 (_3_GPIO_TOUCH_INT   ) in  lo irq-537 edge-falling
 gpio-174 (USB_SEL             ) out lo
...[/SIZE]
But this doesn't work on our I535. This is probably because it doesn't have the debugfs
mounted by default. This can be fairly easily done, but does not guarantee a positive result anyway.
So how do we do it on this device? We're not sure yet, so try we try the following commands to find GPIO info.
Code:
[SIZE=2]# To find all directories called "gpio":
find / -type d -iname "gpio"

#To find all regular files called "gpio":
find / -type f -iname "gpio"
[/SIZE]
If you find a regular file called "gpio", try to print it with:
cat /path/to/gpio

What to do: Post the results of the previous commands.

If this still doesn't work, we can try to use the modem to send an AT
commands that may show the GPIO settings etc. See below.
C) How to connect to your modem from a PC terminal when connected with USB cable?

This was first discussed in #231 and #235, but without any conclusion, since the user
managed to connect, but only one of his AT commands worked. No follow up.

The modem AT command interface is firmware (radio) dependent, so the available
commands can vary widely, but generally there is a standard (3GPP TS 27.007)
that the device need to comply to, regarding the minimally supported AT command
set. However, when connected under normal circumstances (with phone in normal
operation) the AT commands to the modem may be filtered by either the internal
Adnroid device driver RIL daemon "drexe" or something like it. Therefore you may
need to put your phone in some kind of service mode, or change the Qualcomm
connection settings to bypass this filter, to have full access to all avialble
AT commands. It has been suggested that one way to do this on the I535, is using
the "hidden meny", reached by dialing "*#22745927" (???), and then selecting the
"appropriate" settings...

http://xdaforums.com/showpost.php?p=30250590&postcount=317

Or you can try this, which was used for the HTC EVO3D.

For the Sprint SGS3 you have to enter the "IOTHiddenMenu" menu by
dialing "##DIAG#" (##3424#) and then long press "Qualcomm USB Settings".
Then select "DM + MODEM + ADB", as shown here and here, or watch
the movie!

According to that post, for the AOSP SGS3 you can also use:
Code:
[SIZE=2]echo 0 > /sys/class/android_usb/android0/enable
echo 04E8 > /sys/class/android_usb/android0/idVendor
echo 6860 > /sys/class/android_usb/android0/idProduct
echo diag > /sys/class/android_usb/android0/f_diag/clients
echo 1 > /sys/class/android_usb/android0/f_acm/instances
echo diag,acm,adb > /sys/class/android_usb/android0/functions
echo 1 > /sys/class/android_usb/android0/enable
start adbd
setprop sys.usb.state sys.usb.config
[/SIZE]
To make your settings stick: Use Chainfire's "adbd-Insecure-v1.0.apk" App as posted here.
Then when you finally have modem connection. A few basic commands to test are:

Code:
[SIZE=2][code]
AT              // OK?
ATI             // device info
ATZ             // "reset" modem to default configuration (safe)
ATE1            // turn on echo
ATV1            // turn on verbose results
AT+CLAC         // lists all officially available AT commands
AT+CGMI         // Manufacturing Identification
AT+CGMM         // Model Identification
AT+CGMR         // Firmware Revision

AT$QCDMG        // Should cause phone/modem enter to diagnostic mode. (May be hard to exit...)
[/SIZE][/CODE]These are all standard ("+") AT commands. If all of these works, you are on
the right track. Next we'll lok at some specialized ("@", "$", "#", "%")
proprietary AT commands. Qualcomm proprietary AT commands usually have
the format: "AT$<command>". However, its becoming more popular for OEMs to
implement entire new sets of ATs. For example Intel/infineon have a whole
new programmable world (to be discovered). [E.g. Try on your XG626 with at@help.]

For Gobi:

Code:
[SIZE=2]AT$QCDMG                // Transitions to Diagnostics Monitor (DM) operation
AT$QCDMR=?              // Sets DM baud rate (default 115200)
AT&V                    // Dumps configuration paramters
AT$CNTI*                // Displays the access technology; 
                        // (Proprietary AT commands, AT&T Connection Manager)
[/SIZE]
According to this source, and for the HTC [(US T-mobile) G2] == [Desire Z] ==
[Vision], we can use the proprietary AT commands:
Code:
AT@EBI_CFG
AT@GPIO_IN?
AT@PMIC_LEVEL
...to get EBI, GPIO, and PMIC info.

<< To Be Continued... >>
 
Last edited:

LLStarks

Senior Member
Jun 1, 2012
2,258
1,676
Code:
shell@android:/ # cat /sys/kernel/debug/gpio
GPIOs 0-151, msmgpio:
 gpio-1   (mhl_rst             ) in  lo
 gpio-4   (lcd_22v_en          ) out hi
 gpio-8   (i2c_sda             ) in  hi
 gpio-9   (i2c_clk             ) in  hi
 gpio-10  (bt_host_wake        ) in  lo
 gpio-12  (sda                 ) in  hi
 gpio-13  (scl                 ) in  hi
 gpio-16  (tsp_sda             ) in  hi
 gpio-18  (LDO_BIAS            ) out lo
 gpio-19  (mhl_en              ) in  lo
 gpio-24  (sda                 ) in  hi
 gpio-25  (scl                 ) in  hi
 gpio-32  (sda                 ) in  hi
 gpio-33  (scl                 ) in  hi
 gpio-35  (a2220_wakeup        ) out hi
 gpio-38  (spi_mosi            ) in  lo
 gpio-39  (spi_miso            ) in  lo
 gpio-41  (spi_clk             ) in  lo
 gpio-43  (WL_REG_ON           ) out lo
 gpio-47  (scl                 ) in  hi
 gpio-48  (sda                 ) in  hi
 gpio-49  (Home                ) in  hi
 gpio-50  (Vol Up              ) in  hi
 gpio-52  (wpc-detect          ) in  lo
 gpio-54  (WL_HOST_WAKE        ) in  lo
 gpio-69  (MPUIRQ              ) in  lo
 gpio-71  (sda                 ) in  hi
 gpio-72  (scl                 ) in  hi
 gpio-73  (sda                 ) in  hi
 gpio-74  (scl                 ) in  hi
 gpio-75  (a2220_reset         ) out hi
 gpio-79  (bt_ext_wake         ) out lo
 gpio-81  (Vol Down            ) in  hi
 gpio-82  (bcm4334_bten_gpio   ) out hi
 gpio-92  (nfc_firm            ) out lo
 gpio-95  (sda                 ) in  lo
 gpio-96  (scl                 ) in  lo
 gpio-106 (nfc_int             ) in  lo

GPIOs 152-195, platform/pm8xxx-gpio, pm-gpio, can sleep:
gpio-152 (--          ) in         hi 0x05 0x10 0x24 0x30 0x40 0x58
gpio-153 (--          ) in         hi 0x05 0x10 0x24 0x30 0x40 0x58
gpio-154 (EAR_MICBIAS ) out        lo 0x05 0x18 0x2a 0x34 0x40 0x58
gpio-155 (vib enable  ) out        lo 0x05 0x18 0x2a 0x34 0x44 0x58
gpio-156 (--          ) out        lo 0x05 0x18 0x2a 0x38 0x40 0x58
gpio-157 (gpio_proximi) in         hi 0x05 0x10 0x2a 0x30 0x40 0x58
gpio-158 (--          ) in         hi 0x09 0x10 0x2a 0x38 0x42 0x58
gpio-159 (--          ) out        lo 0x03 0x18 0x2a 0x38 0x42 0x58
gpio-160 (MAG_RST     ) out        hi 0x05 0x19 0x2a 0x38 0x40 0x58
gpio-161 (--          ) off        lo 0x01 0x1c 0x20 0x30 0x40 0x58
gpio-162 (--          ) off        lo 0x01 0x1c 0x20 0x30 0x40 0x58
gpio-163 (--          ) off        lo 0x01 0x1c 0x20 0x30 0x40 0x58
gpio-164 (--          ) off        lo 0x01 0x1c 0x20 0x30 0x40 0x58
gpio-165 (--          ) off        lo 0x01 0x1c 0x20 0x30 0x40 0x58
gpio-166 (IMA_ESD_DET ) in         lo 0x0d 0x10 0x28 0x30 0x40 0x58
gpio-167 (--          ) in         hi 0x05 0x10 0x20 0x30 0x40 0x58
gpio-168 (--          ) in         lo 0x05 0x10 0x20 0x30 0x40 0x58
gpio-169 (TOP_SPK_AMP ) out        lo 0x05 0x18 0x2a 0x38 0x40 0x58
gpio-170 (BOTTOM_SPK_A) out        lo 0x05 0x18 0x2a 0x38 0x40 0x58
gpio-171 (--          ) out        lo 0x01 0x18 0x2a 0x35 0x46 0x58
gpio-172 (nfc_ven     ) out        hi 0x01 0x19 0x2a 0x34 0x40 0x58
gpio-173 (Haptic pwr e) out        hi 0x05 0x19 0x2a 0x34 0x44 0x58
gpio-174 (AV_SWITCH   ) out        lo 0x05 0x18 0x2a 0x38 0x40 0x58
gpio-175 (--          ) out        lo 0x05 0x18 0x2a 0x34 0x46 0x58
gpio-176 (--          ) in         lo 0x01 0x10 0x2a 0x35 0x46 0x58
gpio-177 (--          ) in         lo 0x05 0x10 0x2a 0x30 0x40 0x58
gpio-178 (--          ) out        lo 0x07 0x19 0x2a 0x38 0x40 0x58
gpio-179 (--          ) out        lo 0x01 0x18 0x2a 0x34 0x44 0x58
gpio-180 (--          ) out        lo 0x05 0x10 0x2a 0x38 0x42 0x58
gpio-181 (--          ) out        lo 0x07 0x18 0x2a 0x38 0x42 0x58
gpio-182 (--          ) out        lo 0x01 0x18 0x2a 0x35 0x46 0x58
gpio-183 (--          ) in         lo 0x05 0x10 0x2a 0x30 0x40 0x58
gpio-184 (--          ) in         lo 0x03 0x10 0x2a 0x38 0x42 0x58
gpio-185 (--          ) out        lo 0x09 0x18 0x2a 0x38 0x42 0x58
gpio-186 (US_EURO_SWIT) out        lo 0x05 0x18 0x2a 0x38 0x40 0x58
gpio-187 (--          ) in         hi 0x05 0x10 0x2a 0x30 0x40 0x58
gpio-188 (batt_int    ) in         lo 0x05 0x10 0x2a 0x30 0x40 0x58
gpio-189 (CDC_RESET   ) out        hi 0x05 0x19 0x2a 0x38 0x40 0x58
gpio-190 (--          ) in         hi 0x05 0x10 0x2a 0x30 0x40 0x58
gpio-191 (--          ) out        lo 0x01 0x18 0x2a 0x34 0x44 0x58
gpio-192 (--          ) out        lo 0x05 0x18 0x2a 0x34 0x44 0x58
gpio-193 (ext_otg_sw_e) in         hi 0x05 0x11 0x2a 0x30 0x40 0x58
gpio-194 (disp_rst_n  ) out        hi 0x05 0x19 0x2a 0x34 0x40 0x58
gpio-195 (IMA_ESD_DET ) in         hi 0x0d 0x10 0x2a 0x30 0x40 0x58

GPIOs 196-207, platform/pm8xxx-mpp.0, pm8xxx-mpp, can sleep:
gpio-196 (--          ) sink       lo 0xa0
gpio-197 (--          ) d_out      lo 0x3c
gpio-198 (--          ) sink       lo 0xa0
gpio-199 (--          ) d_out      lo 0x3c
gpio-200 (--          ) a_out      lo 0x85
gpio-201 (--          ) sink       lo 0xa0
gpio-202 (ext_5v_en   ) sink       lo 0xa0
gpio-203 (--          ) a_in       lo 0x6c
gpio-204 (--          ) sink       lo 0xa0
gpio-205 (--          ) sink       lo 0xa0
gpio-206 (--          ) sink       lo 0xa0
gpio-207 (--          ) sink       lo 0xa0
 

AdamOutler

Retired Senior Recognized Developer
Feb 18, 2011
5,224
9,826
Miami, Fl̨̞̲̟̦̀̈̃͛҃҅͟orida
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

1zqwmlc.png

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
    Code:
    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.
 
Last edited:

AdamOutler

Retired Senior Recognized Developer
Feb 18, 2011
5,224
9,826
Miami, Fl̨̞̲̟̦̀̈̃͛҃҅͟orida
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.
 
Last edited:
Status
Not open for further replies.

Top Liked Posts

  • There are no posts matching your filters.
  • 561
    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

    1zqwmlc.png

    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
      Code:
      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.
    173
    Rules:
    Do not post in here unless you have something constructive to say. "Thanks", "Hey this is wonderful", and any other comments like that are not wanted. They take up space and make it more difficult to find information. I'm requesting that this thread be heavily moderated. In order to work efficiently, information density must be kept high. We are all guilty of adding in a few off-topic sentances from time-to-time, but this thread is strictly business and I expect the moderators to moderate me as well.

    What is this?
    This is the place where we can research and develop a method to unlock the bootloader of the Verizon Galaxy SIII. Hopefully, this will be development at its finest.


    Why not just buy a developer edition
    GTFO! Not a single person got started developing by buying a developer phone. They started developing because they were unhappy with the features of their device and wanted something better. They wanted something more. This developer phone is a tax on developer innovation. We do not stand for that. We will break the security and we will enable XDA-Developers to do what they do best.

    Until security is broken and available for everyone, this device will get updates last, users will be unhappy because there are no additional features and Samsung violates the spirit of Open Source and copyright laws. Take a look at the bottom line of GPL-Violations.org FAQ located here: http://gpl-violations.org/faq/sourcecode-faq.html


    What are the goals?
    • Attain a bootloader recovery - 75% JTAG (the extra 25% will be for a user-friendly method)
      The Galaxy S3 is bootable from SDCard. In case of emergency this is needed. We need to verify that this works on the Verizon GS3 to bring up Odin. This will set up infrastructure for research.
    • Attain a full stock restoration via Odin or Heimdall - 90%
      For use with Odin3.
      Bootloader - BOOTLOADER_I535VRALF2_618049_REV09_user_low_ship.tar.md5 - 1.97 MB - Thanks nbsdx
      PDA - SCH-I535_VZW_1_20120705143513_fti2qg2lmf.zip
      NEED CSC PACKAGE (MODEM, PARAMS and Other Miscellaneous partitions). This is enough to recover a device though.
      To include bootloaders and recovery to a working and stock condition with the EMMC wiped entirely. Heimdall is a work in progress for this device. This will complete the infrastructure needed for research.
    • Collect information
      This will be the longest and most difficult part of this development. The information provided by Qualcomm is not readily available. Samsung is notoriously secretive about their bootloaders. Mainly we, as a community, will generate information. Please post any relevant datasheets, theory-of-operation, or manuals which you can find.
    • Provide a way to remove security checks from Odin3.] 100% - insecure aboot.img which may break in the future
      By removing security checks from Odin3 on the computer or the Loki daemon on the device we can flash anything through Odin or Heimdall.
    • Provide a way to bypass security checks within bootloaders. 200% we have two exploits, only one has been released.
      This is the ultimate goal. Once we can bypass the security checks, kernels can be flashed giving us the control required to develop


    Initial information
    [BOOTLOADER] Locked bootloader research and news: http://xdaforums.com/showthread.php?t=1756919


    My own research

    SBL1 is the first booting partition. Qualcomm provides the Modem partition so it comes first on the EMMC. SBL1 is the first bootloader and that is specified by Qualcomm standards. Qualcom mmake sthe primitive bootloader and allows their customers (Samsung) to make a Secondary bootloader. Samsung chose to use three secondary bootloaders.

    The following 0p* are located in /dev/block/mmcblk*

    0p1 = modem
    Built by se.infra
    HUDSON_GA_D2_USA-VZW-HARDKEY-PROD-USER
    I take this to mean this Qualcomm modem was built in Hudson Georgia.
    I was not able to find signatures on this block :). This does NOT mean that there are no signatures on this block. The file is 33 megs. The file is unencrypted.
    The modem uses the BLAST Kernerl ver : 02.04.02.02.00 Unfortunately we need someone who speaks French(???) to understand how this works http://blast.darkphpbb.com/faq.php
    Judging by the contents of this file, it is an operating system of it's own including keyboard, mouse and a lot of debugging information. We need to find out more about the BLAST Kernel and this partition.


    Samsung Proprietary partitions SBL1,2,3
    Overall I'm not entirely familiar with this new 3 SBL setup. If someone could help me out, that would be great. This 3 SBL setup looks like they tried to adapt (slopily) their IBL+PBL+SBL setup to the Qualcomm and added overhead.

    op2=sbl1
    This block is signed by Samsung, we will not be able to modify it.
    Some Strings we expect to see on UART are:

    0p3=sbl2
    This block is signed by Samsung, we will not be able to modify it.

    Some of the strings we may see over UART are:
    Code:
    RPM loading is successful.
    cancel RPM loading!
    SBL2, End
    SBL2, Delta
    .sbl2_hw.c
    sbl2_hw_init, Start
    sbl2_hw_init, Delta
    sbl2_hw_init_secondary, Start
    h/w version : %d
    sbl2_hw_init_secondary, Delta
    .SBL2, Start
    scatterload_region & ram_init, Start
    .scatterload_region & ram_init, Delta
    .sbl2_mc.c
    sbl2_retrieve_shared_info_from_sbl1, Start
    .sbl2_retrieve_shared_info_from_sbl1, Delta

    0p4=sbl3
    This block is signed by Samsung, we will not be able to modify it.

    Possibly useful information:
    SVC: R1-R14
    FIQ:R13-R14
    IRQ:R13-R14
    UND:R13-R14
    ABT:R13-R14
    SYS:R13-R14

    This block appears to be a full OS of its own. I'm not sure of its purpose.

    op5= aboot
    This block is signed by Samsung, we will not be able to modify it

    This block contains HTML information. It would appear that it is possible to put the device into a mode where it will provide a webserver which displays state information.

    This block appears to be a complete operating system

    This block contains the Loke Daemon which communicates with Odin3.


    0p6= rpm
    This block is signed by Samsung we will not be able to modify it

    0p7= boot
    This is the kernel. There are several things we can do here... I belive this package itself is not signed, but the zImage itself is... here is the bootimg.cfg file

    Code:
    adam@adam-Desktop:~/Desktop/VZWGS3$ cat ./bootimg.cfg 
    bootsize = 0xa00000
    pagesize = 0x800
    kerneladdr = 0x80208000
    ramdiskaddr = 0x81500000
    secondaddr = 0x81100000
    tagsaddr = 0x80200100
    name = 
    cmdline = console=null androidboot.hardware=qcom user_debug=31

    It may be possible to use that cmdline variable as an exploit.




    0p8= tzTrust Zone
    0p9= pad
    0p10= param -boot mode parameters - this could be a potential exploitation point.
    0p11= efs -serial numbers
    I've honestly got no clue about most of the following partitions.
    0p12= modemst1
    0p13= modemst2
    0p14= system - Android stuff
    0p15= userdata - App Stuff
    0p16= persist
    0p17= cache - Storage for updates
    0p18= recovery - recovery partition
    0p19= fota
    0p20= backup
    0p21= fsg
    0p22= ssd
    0p23= grow

    External UART log from initial power up:
    Code:
    [1630] AST_POWERON
    [    0.000000] heap->name mm, mb->start c0000000
    [    0.000000] Reserving memory at address ea000000 size: 100000
    [    0.000000] sec_dbg_setup: str=@0x88d90004
    [    0.000000] sec_dbg_setup: secdbg_paddr = 0x88d90004
    [    0.000000] sec_dbg_setup: secdbg_size = 0x40000
    [    0.000000] etb_buf_setup: str=@0x8fffb9c0
    [    0.000000] etb_buf_setup: secdbg_paddr = 0x8fffb9c0
    [    0.000000] etb_buf_setup: secdbg_size = 0x4000
    [    0.174515] rdev_init_debugfs: Error-Bad Function Input
    [    0.174881] AXI: msm_bus_fabric_init_driver(): msm_bus_fabric_init_driver
    [    0.176957] sec_debug_init: enable=0
    [    0.177475] ec_debug_nit: restrt_reason: 0xdf0085c
    [    .216358] msm8960_iit_cam:292]settingdone!!
    [    0.25006] i2c 2c-14: Inalid 7-bi I2C addrss 0x00
        0.25237] i2c ic-14: Can' create evice at x00
    [   0.252220]i2c i2c-1: Failed o registeri2c clien cmc624 t 0x38 (-6)
    [    .252250] 2c i2c-19:Can't crete deviceat 0x38
        0.25433] rdevinit_debufs: Error-ad Functin Input
        0.25222] max892 19-006: DVS mode disabledbecause VD0 and VI1 do not ave prope control.
    [    0.79536] ms_etm msm_tm: ETM tacing is ot enable beacaussec_debug s not enaled!
    [   0.284449 smd_chanel_probe_orker: alocation tble not iitialized
                                                                      [    0.38766] pm_untime: fil to wak up
    [   0.362032]hdmi_msm dmi_msm.1 externalcommon_stte_create sysfs grup de39e68                                                                   
    [    0362673] Iside writback_drivr_init                                                                                                         
    [   0.36275] Insidewritebackprobe                                                                                                               
    [    1.244803] TZCOM: unable to get bus clk                                                                                                     
    [    1.431680] cm36651_setup_reg: initial proximity value = 3                                                                                   
    [    1.549671] msm_otg msm_otg: request irq succeed for otg_power                                                                               
    [    1.566702] mms_ts 3-0048: [TSP] ISC Ver [0xbb] [0x20] [0x20]                                                                                
    [    1.571341] mms_ts 3-0048: [TSP] fw is latest. Do not update.                                                                                
    [    1.583488] [__s5c73m3_probe:3818] S5C73M3 probe                                                                                             
    [    1.587089] [s5c73m3_sensor_probe_cb:3793] Entered                                                                                           
    [    1.591942] [s5c73m3_i2c_probe:3675] Entered                                                                                                 
    [    1.596123] [s5c73m3_init_client:3381] Entered                                                                                               
    [    1.600579] [s5c73m3_i2c_probe:3695] Exit                                                                                                    
    [    1.604608] [s5c73m3_sensor_probe:3726] Entered                                                                                              
    [    1.609095] [s5c73m3_spi_init:226] Entered                                                                                                   
    [    1.613154] [s5c73m3_spi_probe:191] Entered                                                                                                  
    [    1.617335] [s5c73m3_spi_probe:201] s5c73m3_spi successfully probed                                                                          
    [    1.623561] [s5c73m3_sensor_probe :  3749] Probe_done!!                                                                                      
    [    1.672638] mmc0: No card detect facilities available                                                                                        
    [    1.682984] aat1290a_led_probe : Probe                                                                                                       
    [    1.693850] msm_soc_platform_init                                                                                                            
    [    1.697298] msm_afe_afe_probe                                                                                                                
    [    1.843064] msm_asoc_pcm_new                                                                                                                 
    [    1.849748] msm_asoc_pcm_new                                                                                                                 
    [    2.023134] set_dload_mode <1> ( c00176d4 )                                                                                                  
    [    2.052220] cypress_touchkey 16-0020: Touchkey FW Version: 0x06                                                                              
    [    2.123851] init: /init.qcom.rc: 466: invalid command '/system/bin/log'                                                                      
    [    2.129620] init: /init.qcom.rc: 573: ignored duplicate definition of service 'sdcard'                                                       
    [    2.137402] init: /init.qcom.rc: 586: ignored duplicate definition of service 'ftm_ptt'                                                      
    [    2.145490] init: /init.target.rc: 73: ignored duplicate definition of service 'thermald'                                                    
    [    2.154677] init: could not open /dev/keychord                                                                                               
    [    2.239951] init: Device Encryption status is (0)!!                                                                                          
    [    2.243705] init: [disk_config] :::: fsck -> /dev/block/mmcblk0p15 (ext4):::::                                                               
    [    2.251823] init: [disk_config] ext_check -> /system/bin/e2fsck -v -y /dev/block/mmcblk0p15                                                  
    [    2.588921] init: [disk_config] ext_check ->ok                                                                                               
    [    2.611597] init: [disk_config] :::: fsck -> /dev/block/mmcblk0p17 (ext4):::::                                                               
    [    2.617762] init: [disk_config] ext_check -> /system/bin/e2fsck -v -y /dev/block/mmcblk0p17                                                  
    [    2.655333] init: [disk_config] ext_check -> ok                                                                                              
    [    2.664947] init: [disk_config] :::: fsck -> /dev/block/mmcblk0p11 (ext4):::::                                                               
    [    2.671081] init: [disk_config] ext_check -> /system/bin/e2fsck -v -y /dev/block/mmcblk0p11                                                  
    [    2.704532] init: [disk_config] ext_check -> ok                                                                                              
    [    3.259056] init: cannot find '/system/etc/install-recovery.sh', disabling 'flash_recovery'                                                  
    [    3.270471] init: cannot find '/system/bin/dmbserver', disabling 'dmb'

    External UART log from battery-pull and reinsert
    Code:
    [1630] AST_POWERON
    [    0.000000] heap->name mm, mb->start c0000000
    [    0.000000] Reserving memory at address ea000000 size: 100000
    [    0.000000] sec_dbg_setup: str=@0x88d90004
    [    0.000000] sec_dbg_setup: secdbg_paddr = 0x88d90004
    [    0.000000] sec_dbg_setup: secdbg_size = 0x40000
    [    0.000000] etb_buf_setup: str=@0x8fffb9c0
    [    0.000000] etb_buf_setup: secdbg_paddr = 0x8fffb9c0
    [    0.000000] etb_buf_setup: secdbg_size = 0x4000
    [    0.174484] rdev_init_debugfs: Error-Bad Function Input
    [    0.174851] AXI: msm_bus_fabric_init_driver(): msm_bus_fabric_init_driver
    [    0.176926] sec_debug_init: enable=0
    [    0.177445] sc_debug_iit: restat_reason  0xdf0086c
    [    0216206] [sm8960_int_cam:299]setting one!!
    [   0.217915 select_req_plan:ACPU PVS:Nominal
        0.25206] i2c ic-14: Invaid 7-bit 2C addres 0x00
    [   0.25207] i2c i2-14: Can'tcreate deice at 0x0
    [    0252250] 2c i2c-19 Failed t register 2c clientcmc624 at0x38 (-16
    [    0252250] ic i2c-19: an't creae device t 0x38
    [   0.25243] rdev_iit_debugs: Error-Bd Functio Input
    [   0.25292] max895 19-0060:DVS modesdisabled ecause VI0 and VID do not hve propercontrols.
                                                                                               [    0.29536] msmetm msm_em: ETM trcing is nt enable!
    [    0.35797] pm_rntime: fal to wakeupllcation tale not intialized
    [    .362093] dmi_msm hmi_msm.1:external_ommon_stae_create:sysfs grop de39e60                                                                   
    [    0.62734] Inide writeack_driverinit                                                                                                         
    [   0.36285] Inside riteback_robe                                                                                                               
    [    1.244803] TZCOM: unable to get bus clk




    possible exploitations
    Possible entry point MODEM - Someone with a JTAG setup test viability of modifying a single byte on /dev/block/mmcblk0p1
    Possible entry point PARAMS - Samsung stores their boot parameters in PARAMS partition. It may be possible to modify PARAMS for insecure boot
    Possible entry point BOOT - Modify CMDLINE parameter to load information from another location.
    Possible entry point BOOT - We may be able to shove an insecure bootloader into memory, boot into that, and then use the recovery partition as our kernel partition. Bauwks 2nd U-Boot. U-Boot is available for the Exynos 4412, we need to find one for Qualcomm.
    Possible entry point SYSTEM - It may be possible to use a 2nd init hack from this partition to load custom kernels into memory and reboot the kernel.


    Current tasks
    What do all of these partitions do?
    Do we have a SDCard based recovery?
    Where can we find an Odin3 CSC Flash?
    Testing methods above is required
    96
    I have heard, but do not know, that there may be plans to get one of the developer phones into Adam's hands to extract from. That may provide insight into how to disable Qualcomm Secure Boot no? Anyone care to shed some light on if this is still planned or not? Thanks

    I don't need another device. I want all of the partitions from a developer device and I'd like to work with someone who has one. Remote access via "WirelessADB" and the device set to be in the "DMZ" of a router would be sufficient for all tests I would need to do.

    Just as an update, I'm slowly getting back to work. For those who were wondering, I packed up everything and moved. I have my stuff 90% set up. I'm just getting back on it. I'm working on compiling all of the Verizon GS3 exploits into a single CASUAL one-click package. Root, recovery, Busybox, Basic Hacking Tools.

    Once I've got a CASUAL package put together I'll go through and read this thread again from start to finish and figure out what needs work... my mind is totally off-topic right now after a move. Time to get back to work. I hope to have some big news at the end of next week.
    85
    It's been a few days so I wanted to give an update on the signature check on boot.img

    As has been previously guessed, everything important in boot.img is included in the signature check

    page_size is always 0x800 since we're using emmc boot

    hash_size = 0x800 (read the first page with the boot_img_header)
    hash_size += page_size * ((page_size + ramdisk_size - 1) / page_size)
    hash_size += page_size * ((page_size + kernel_size - 1) / page_size)
    hash_size += page_size * ((page_size + second_size - 1) / page_size)

    For the stock boot.img, this should come out to be 0x573000, so the first 0x573000 bytes in boot.img are checked.

    These bytes are then SHA1 hashed and passed to the verification function

    After hash_size bytes is a series of 0x100 byte blocks that will be passed to the verification function (img_sig_data parameter below)

    The verification function uses the following structure

    Code:
    struct sig_ctx_t {
    	int count;
    	int seed[65];
    	int subcheck_seed[64]; // possibly a modulus
    }

    This sig_ctx is located in aboot.img at file offset 0x12642C in VRALF2 and VRALG1 (It'll start with bytes 0x40, 0x00, 0x00, 0x00)

    I've cleaned up the first function a bit from what IDA/Hex-Rays spit out, but the second function I haven't simplified as much

    Code:
    int signature_check_data(sig_ctx_t *sig_ctx, char *img_sig_data, signed int signature_len, char *sha1_of_contents) {
    
    	int* img_ofs_0x100 = (int*)(img_sig_data + 0x100);
    	int* img_ofs_0x200 = (int*)(img_sig_data + 0x200);
    	int* img_ofs_0x300 = (int*)(img_sig_data + 0x300);
    	int* img_ofs_0x400 = (int*)(img_sig_data + 0x400); // Temporary storage
    
    	// Copy 0x0 block to 0x100
    	memcpy(img_ofs_0x100, &img_sig_data[0], signature_len);
    
    	// ofs_0x200 is filled with byte-swapped ints from img_ofs_0x100
    	for (int i = 0; i < sig_ctx->count; i++) {
    		img_ofs_0x200[i] =  htonl(img_ofs_0x100[sig_ctx->count - 1 - i]);
    	}
    
    	// subcheck(sig_block *block, int *output, int *input1, int *input2)
    	// multiplication maybe?
    	signature_subcheck(sig_ctx, img_ofs_0x300, img_ofs_0x200, sig_ctx->subcheck_seed);
    	signature_subcheck(sig_ctx, img_ofs_0x400, img_ofs_0x300, img_ofs_0x300);
    	signature_subcheck(sig_ctx, img_ofs_0x300, img_ofs_0x400, img_ofs_0x200);
    
    	if ( sig_ctx->count )
    	{
    		count_minus_1 = sig_ctx->count - 1;
    		v18 = img_ofs_0x300[sig_ctx->count - 1];
    		v19 = sig_ctx->seed[sig_ctx->count]; // seed[64]
    		// v19 = *(&sig_ctx->count + sig_ctx->count + 1);
    		if ( v18 >= v19 )
    		{
    			if ( v18 == v19 )
    			{
    				for (int i = 0; i < sig_ctx->count; i++) {
    					int v22 = img_ofs_0x300[sig_ctx->count - 1 - i];
    					int v23 = sig_ctx->seed[sig_ctx->count - 1 - i];
    					if (v22 < v23) {
    						goto LABEL_18
    					}
    				}
    			}
    			if ( sig_ctx->count > 0 )
    			{
    				int carry = 0;
    				for (int i = 0; i < sig_ctx->count; i++) {
    					uint64 temp = img_ofs_0x300[i] - (uint64)sig_ctx->seed[i + 1];
    					img_ofs_0x300[i] = img_ofs_0x300[i] - sig_ctx->seed[i + 1] + carry;
    					carry = (int)(temp >> 32); // get high 32 bits
    				}
    			}
    		}
    
    		LABEL_18:
    		// Store the calculation back into img_ofs_0x100
    		for (int i = 0; i < sig_ctx->count; i++) {
    			int val = img_ofs_0x300[sig_ctx->count - 1 - i];
    			char* dest = &img_ofs_0x100[i];
    
    			dest[0] = (val & 0xFF000000) >> 24;
    			dest[1] = ((val & 0x00FF0000) >> 16) & 0xFF;
    			dest[2] = ((val & 0x0000FF00) >> 8) & 0xFF;
    			dest[3] = (val & 0xFF);
    		}
    
    		if (memcmp(img_ofs_0x100, sig_check_compare_result, 236)) // sig_check_compare_result is a char[236] with the first 2 bytes 0x00, 0x01, and the rest 0xFF
    			return 0;
    
    		if (signature_len > 236) {
    			if (memcmp(&img_ofs_0x100[236], sha1_of_contents, signature_len - 236)) // 256-236 = 20
    				return 0;
    
    			// Signature passed
    			return 1;
    		}
    	}
    	return 0;
    }


    Here's the subcheck function, it looks like arbitrary-precision math, possibly mulmod

    Code:
    void __fastcall signature_subcheck(sig_ctx_t *sig_data, int *output, int *input1, int *input2)
    {
      int v5; // r3@2
      int count; // r4@3
      unsigned __int64 v7; // r2@6
      unsigned __int64 v8; // r8@6
      int inner_index; // r5@7
      int block1_pos; // r4@7
      int v11; // r5@14
      __int64 v12; // r8@14
      int v13; // r6@14
      unsigned __int64 v14; // r2@15
      int v15; // kr04_4@15
      int v16; // [sp+18h] [bp-48h]@6
      unsigned int v17; // [sp+1Ch] [bp-44h]@6
      int outer_index; // [sp+2Ch] [bp-34h]@5
    
      if ( sig_data->count > 0 )
      {
        v5 = 0;
        do
        {
          output[v5++] = 0;                         // this do while is just memset(output, 0, 4 * sig_data->count)
          count = sig_data->count;
        }
        while ( sig_data->count > v5 );
        if ( count > 0 )
        {
          outer_index = 0;
          do
          {
            v16 = input1[outer_index];
            v7 = (unsigned int)v16 * (unsigned __int64)(unsigned int)*input2 + (unsigned int)*output;// v7 = input1[outer_index] * (uint64)input2[0] + output[0]
            v17 = sig_data->seed[0] * v7;
            v8 = sig_data->seed[1] * (unsigned __int64)v17 + (unsigned int)v7;
            if ( count <= 1 )
            {
              block1_pos = 1;
            }
            else
            {
              inner_index = 0;
              block1_pos = 1;
              do
              {
                v7 = (unsigned int)v16 * (unsigned __int64)(unsigned int)input2[block1_pos]
                   + (unsigned int)output[block1_pos]
                   + HIDWORD(v7);
                v8 = sig_data->seed[inner_index + 2] * (unsigned __int64)v17 + HIDWORD(v8) + (unsigned int)v7;
                ++block1_pos;
                output[inner_index] = v8;
                ++inner_index;
              }
              while ( block1_pos < sig_data->count );
            }
            output[block1_pos - 1] = HIDWORD(v8) + HIDWORD(v7);
            if ( (HIDWORD(v8) + (unsigned __int64)HIDWORD(v7)) >> 32 )
            {
              if ( sig_data->count <= 0 )
                return;
              v11 = 0;
              v12 = 0LL;
              v13 = 0;
              do
              {
                v14 = (unsigned int)output[v11] - (unsigned __int64)sig_data->seed[v11 + 1];
                v15 = output[v11] - sig_data->seed[v11 + 1];
                output[v11] = output[v11] - sig_data->seed[v11 + 1] + v12;
                count = sig_data->count;
                ++v13;
                ++v11;
                v12 = (signed int)((__PAIR__(HIDWORD(v14), v15) + v12) >> 32);
              }
              while ( v13 < sig_data->count );
            }
            else
            {
              count = sig_data->count;
            }
            ++outer_index;
          }
          while ( outer_index < count );
        }
      }
    }


    The goal is to make it so that after all the calculations the 256 byte block located at img_sig_data+0x100 has the contents 0x00, 0x01, 0xFF * 236, and then the sha1 of our boot.img

    I'm in the middle of moving at the moment, so I don't have as much time as I would like to look at this right now, but that should clear up in a few days.

    Also, if there's any interest I can post a guide on how to get the bootloader files loaded into IDA for analysis. Some knowledge of ARM assembly would be required though.

    EDIT:

    In other news, I found what keeps resetting the 16 byte encrypted romtype in param.img. It's libcordon.so, which is from /system/app/SysScope.apk (it'll also be copied to /system/lib/libcordon.so). It's using quite a few checks to see if you've modified your system.

    There's an adb scanner, checking to see if you've changed the ro.secure or ro.debuggable props.

    The root process scanner checks running processes and returns true if any are found running as root that are not one of:
    "debuggerd", "init", "installd", "servicemanager", "vold", "zygote", "netd", "ueventd", "dock_kbd_attach", "pppd", "pppd_runner", "mpdecision", "thermald", "hdmid", "sec_keyboard", "seccmmond", "mfsc", "mfdp"

    There's also a partition check, kernel checker, su scanner, and a file scanning mechanism using data from a sqlite db

    So to completely remove the Samsung custom screen on bootup and 5 second delay you'd need to disable the SysScope.apk, then encrypt and write the 16 bytes yourself using 0xFF000000 as the first int to mark yourself as official
    70
    A gentleman named Lee contacted me via email. He said he has 0 posts so he could not post in here. This post contains his email to me. I am not wrapping it in quotes because quotes are destroyed in future posts. This is literally the best development we've had in this thread.



    ------email from Lee------
    I've been looking at the bootloader in aboot.img the past day or so and wanted to contribute what I know about the param.img partition and how it's used. I've been following the thread at xda, but since my account has 0 posts I can't actually post this in that thread.

    Please note these are a little rough around the edges, just things I jotted down while reverse engineering.

    param.img Structure

    At offset 0 there's an 88 byte structure I've called the header

    struct param_header {
    int status; // need to investigate more. some relationships between this and boot modes. 4 == firmware error int unk_04; // haven't seen this used anywhere int unk_08; // haven't seen this used anywhere int emmc_checksum_attempted; int emmc_checksum_ok; int nvdata_backup; // says whether we have a backup of modemst1 in "fsg" partition and a backup of modemst2 in "backup" partition?
    int unk_18[16]; // haven't seen this used anywhere };

    status (NEEDS WORK):
    1 = ?
    2 = boot_mode 3?
    3 = recovery?
    4 = boot_mode 1 - fastboot. displays "firmware update issue" image
    5 = boot_mode 4?


    at offset 0x900000 there's a structure controlling some debug variables

    struct param_debug {
    int debug_level;
    int unk_04; // 4 in dumps. haven't seen this used anywhere int unk_08; // 0 in dumps. haven't seen this used anywhere int emmc_checksum_attempted; // mirror of param_header.emmc_checksum_attempted
    int emmc_checksum_ok; // mirror of param_header.emmc_checksum_ok };

    About param_debug.debug_level:
    It has 3 possible values, and it changes some flags are passed to the kernel.
    DLOW is the default, but some features like ramdump mode only work on DMID or DHIG

    1. 0x574F4C44 (DLOW) - Low debug setting strcat(boot_img_hdr->cmdline, " androidboot.debug_level=0x4f4c");// OL strcat(boot_img_hdr->cmdline, " sec_debug.enable=0"); strcat(boot_img_hdr->cmdline, " sec_debug.enable_user=0");

    2. 0x44494D44 (DMID) - Mid-level debugging strcat(boot_img_hdr->cmdline, " androidboot.debug_level=0x494d");// IM strcat(boot_img_hdr->cmdline, " sec_debug.enable=1"); strcat(boot_img_hdr->cmdline, " sec_debug.enable_user=0");

    3. 0x47494844 (DHIG) - Full debugging
    strcat(boot_img_hdr->cmdline, " androidboot.debug_level=0x4948");// IH strcat(boot_img_hdr->cmdline, " sec_debug.enable=1"); strcat(boot_img_hdr->cmdline, " sec_debug.enable_user=1"); strcat(boot_img_hdr->cmdline, " slub_debug=FPUZ");

    Check drivers/misc/sec_misc.c for what these values do for the kernel


    At offset 0x9FFC00 (sizeof(param.img) - 0x400 is how the offset is calculated by the BL):
    Here are 16 bytes unique to each device, and they are part of what determines whether or not you have a custom rom.

    It's AES128 encrypted using a key made from the emmc's psn and some static data

    Key generation:
    First, the 4byte psn is expanded to 8 bytes

    char first_half[14];
    snprintf(first_half, 13, "%08x", mmc_get_psn()); memcpy(aes_initial_key, first_half, 8);

    The second half is calculated based on all static data

    char custom_check_index_shuf_table[] = { 1, 3, 2, 4, 5, 1, 0, 4, 4, 5, 4, 0 }; char custom_check_table[] = { 0x40, 0x74, 0x25, 0x61, 0x21, 0x74, 0x70, 0x62, 0x62, 0x24, 0x33, 0x5E }; char romtype_enc_key_buf[32];

    char* custom_check_shuffle_calc(signed int always_199, int count) { int out_index; // r3@2 int last_index; // r2@2 int odd_index; // r4@3 int table_index; // r2@3 char table_value;

    if ( count <= 0 )
    {
    out_index = 0;
    }
    else
    {
    out_index = 0;
    last_index = 0;
    do
    {
    odd_index = always_199 & 1;
    always_199 >>= 1;
    table_index = odd_index + 2 * last_index; table_value = custom_check_table[table_index]; last_index = custom_check_index_shuf_table[table_index];
    romtype_enc_key_buf[out_index++] = table_value; } while ( out_index != count ); } romtype_enc_key_buf[out_index] = 0; return romtype_enc_key_buf; }

    This function is used like this (the parameters are always 199 and 8 in the vzw aboot):
    char* second_half = custom_check_shuffle_calc(199, 8); memcpy(&aes_initial_key[8], second_half, 8);

    Now we have 16 bytes in aes_initial_key, but it's shuffled again with the following function

    char custom_check_final_index_table[] = { 0, 4, 5, 0xD, 3, 8, 0xE, 9, 0xA, 2, 1, 7, 0xB, 6, 0xC, 0xF }; void custom_check_shuffle_final_key(char *iv, char *final) { int v2; // r3@1 int v5; // r3@3

    v2 = 0;
    do
    {
    final[custom_check_final_index_table[v2]] = iv[v2];
    v2++;
    }
    while ( v2 != 16 );
    v5 = 0;
    do
    {
    final[custom_check_final_index_table[v5]] = iv[v5] ^ final[v5];
    v5++;
    }
    while ( v5 != 16 );
    }

    char aes_final_key[16];
    custom_check_shuffle_final_key(aes_initial_key, aes_final_key);

    This final key should be able to decrypt the 16 bytes

    The first 4 decrypted bytes cast to an int will be 0xFF000000 if you're running an official rom, or 0xEE000000 if you've flashed something custom If it's 0xEE000000 then you will be shown the "Custom" boot screen with the padlock on it, and it also causes a call to mdelay(5000) before actually booting the kernel.
    I've also seen 0xCC000000 mentioned in debug prints, causing it to print the device status as "Scanning" instead of "Official" or "Custom"


    Unfortunately this doesn't seem to help much with the boot.img check, but I've found where that is and am reversing it now.


    ----------------------------------------------------------------------------------------------------------------------------------------------------------------

    DDI Data
    Here's where the values like the flash count are stored (sometimes this might be called triangle state?) It's stored at 0x3FFE00 on the mmc

    struct ddi_data {
    int magic; // must be 0x12340012
    int custom_flash_count;
    int odin_count;
    int binary_type; // 0 = samsung official, 1 = custom, 2 = "Unknown"
    char model_name[16];
    int rom_type; // this is the first 4 bytes of the decrypted 16 bytes in the param partition. 0xFF000000 = samsung, 0xEE000000 = custom }


    ----------------------------------------------------------------------------------------------------------------------------------------------------------------

    Reboot Reason

    Values and effects for the reboot reason stored at 0x2A03F65C

    0x12345671 - ?
    0x12345678 - Normal mode


    0x77665500 - FASTBOOT_MODE. displays "downloading" boot image
    0x77665501 - ? seen checked but haven't found it used anywhere
    0x77665502 - RECOVERY_MODE. sets param_header.state to 3
    0x77665503 - sets param_header.state to 4. haven't seen it actually used

    0x77665507 - display the "not authorized" picture

    if ((reason & ~0xF) == 0x77665510) then they're commands for manipulating the nvdata I wouldn't play around with these unless you really know what you're doing All of them reboot the device into the normal mode except 0x77665515

    0x77665511 - copy modemst1 to fsg partition and copy modemst2 to backup partition. sets param_header.nvdata_backup to 1
    0x77665512 - copy fsg to modemst1 and copy backup to modemst2. checks to ensure param_header.nvdata_backup=1 first
    0x77665514 - erase fsg and backup partitions. clears param_header.nvdata_backup
    0x77665515 - same as 0x77665511 but then reboots the device into RECOVERY_MODE


    0x776655EE - RAMDUMP_MODE (only valid if param_debug.debug_level is DMID/DHIG)


    0xABCD4F4C - set param_debug.debug_level to DLOW 0xABCD494D - set param_debug.debug_level to DMID
    0xABCD4948 - set param_debug.debug_level to DHIG

    ----------------------------------------------------------------------------------------------------------------------------------------------------------------

    boot_type INCOMPLETE
    1 = fastboot
    2 = ramdump mode
    3 = recovery. resets param_debug
    4 = ?


    ----------------------------------------------------------------------------------------------------------------------------------------------------------------

    USB Flags INCOMPLETE

    0xF00 - jig mask
    0x100 - put the device into factory mode
    0x400 - change "console" boot parameter to "console=ttyHSL0,115200,n8%s" where %s is replaced by whatever was originally after "console="

    ----------------------------------------------------------------------------------------------------------------------------------------------------------------

    ODIN

    In addition to the ODIN/LOKE handshake sequence I saw in heimdall, there are 2 more in the S3.
    Send "FPGM" and you should get a response of "OK". It functions exactly as the ODIN/LOKE sequence.
    Send "ROOTING" and it responds with the current DDI data and terminates.

    -Lee