• Introducing XDA Computing: Discussion zones for Hardware, Software, and more!    Check it out!
  • Fill out your device list and let everyone know which phones you have!    Edit Your Device Inventory

[R&D] Unlock Bootloaders

Status
Not open for further replies.
Search This thread

E:V:A

Inactive Recognized Developer
Dec 6, 2011
1,449
2,213
-∇ϕ
The MSM8960 Boot Architechture

The MSM8960 Boot Architecture (Ref: 80-N5009-1 B)

We still have not understood how the MSM8960 Boots up. Here is an attempt to
summarize the content in the only document available on the topic. If we do not
understand this properly there will little or no hope to unlock our bootloader.

First thing to understand is that the MSM contains several processors, each
designated to work an a particular subsystem. The table below lists the
processor types and boot addresses.

Code:
[SIZE=2]Subsystem       Processor       Boot address
---------------------------------------------------------------------
RPM             ARM7            0x0     
DSPS            ARM7            0x0 (hardware remap)
KxPSS           Krait           Configurable
Modem (FW)      Hexagon         Configurable
Modem (SW)      Hexagon         Configurable
LPASS           Hexagon         Configurable
RIVA SS         ARM9            0x0(hardware or software remap)
[/SIZE]
The boot code flow through the subsystems can be visualized like this:

attachment.php


Compared to other Snapdragons, the MSM8960 seem to employ much more strict
security measures by default. It is using the Secure Boot 3.0 (SB3) Call Stack
to accomplish this. Here is picture how this look.

attachment.php


Next we have a look at the entire boot process.

The Secure Boot 3.0 Process

The boot procedure is in the order as follows.

Code:
[SIZE=2][B]PBL[/B]

• RPM processor starts executing PBL in boot ROM
• PBL determines cold boot or warm boot
• PBL increases RPM clock speed from XO to 60 MHz
• RPM processor start address is 0x0
• [B]For cold boot, next step is to detect Flash device that chip will boot from, 
  based on the boot options[/B]
• When detected, PBL downloads SBL1 (RPMSBL) from Flash to System IMEM
• SBL1 authenticates SBL2 (Krait PBL)
• RPM uses [I][COLOR=Red]Crypto Engine 4.0[/COLOR][/I] to authenticate images
• SBL1 jumps to start of SBL2 (Krait PBL)

[B]SBL1[/B]

• SBL1 configures MIMEM and GMEM, then loads and authenticates the SBL2 there;
  MIMEM is [B]192 KB[/B], so when SBL2 grows, it will spill to GMEM
• SBL1 takes Krait out of reset
• SBL1 waits for signal from Krait SBL
• When desired signal is received, SBL1 executes RPM firmware, 
  which is downloaded by SBL2
• If RPM firmware image authentication/download fails, Krait SBL2 resets MSM and 
  enters into Boot ROM Emergency Download mode

[B]SBL2[/B]

• After being taken out of reset, Krait jumps to start of SBL2
 - Krait boot address is software-configurable via register [B][I]APCS_START_ADDR[/I][/B]
• SBL2 increases Krait clock speed
• SBL2 downloads TZ image to TZ-dedicated system IMEM
  - TZ image occupies at least [B]188 KB[/B] in system IMEM
  - TZ image sets up security environment (configures xPU, etc.)
• SBL2 authenticates TZ image
  - SBL2 uses CE-4.0 to perform authentication
• SBL2 downloads RPM firmware to Code RAM and authenticates it
• SBL2 configures DDR
• SBL2 sends RPM firmware-ready signal to RPM and lets RPM continue to 
  execute RPM firmware
• SBL2 jumps to SBL3

[B]SBL3[/B]

• SBL3 bumps the system clock
• SBL3 loads and authenticates APPSBL
• SBL3 waits for the RPM process ready interrupt
• Once the interrupt is coming, SBL3 jumps to APPSBL 

[B]SBL3/APPSBL/HLOS[/B]

• SBL3 (Krait SBL) loads and authenticates APPSBL and apps kernel
• Krait executes APPSBL and HLOS
• Krait loads and authenticates modem Hexagon firmware and 
  Hexagon software images, then takes them out of reset as needed
• Krait loads and authenticates LPA Hexagon image, then takes it out 
  of reset as needed
• Krait loads and authenticates DSPS ARM7 images, then takes them 
  out of reset as needed
• Krait loads and authenticates RIVA ARM9 images, then takes them 
  out of reset as needed
• Order of loading modem Hexagon, LPA Hexagon, and DSPS ARM7 
  can be decided by HLOS
[/SIZE]
The pictorial diagram:

attachment.php


Here the blue and white parts are executed in the RPM ARM7, while the grey parts are executed in the Krait.
Eventually the Krait takes over completely and we are left with the following flow .

attachment.php


PBL Boot Options


The BOOT_CONFIG[0..6] GPIOs or BOOT_CONFIG fuses can be used to
select the boot option, as shown below. Once the fuse is blown, the
GPIOs used for the boot option are free to be used as common GPIOs.

Code:
[SIZE=2]-------------------------------------------------------------------------------
BC[5:0] BOOT_CONFIG     MSM8960                                 Comments
-------------------------------------------------------------------------------
00000   0               BOOT_DEFAULT_OPTION
00001   1               BOOT_SDC_PORT3_THEN_SDC_PORT1_OPTION
00010   2               BOOT_SDC_PORT3_THEN_SDC_PORT2_OPTION
00011   3               BOOT_SDC_PORT1_OPTION
00100   4               BOOT_SDC_PORT2_OPTION
00101   5               BOOT_SPI_ON_GSBI1_OPTION
00110   6               BOOT_SPI_ON_GSBI2_OPTION                Not supported
00111   7               BOOT_SPI_ON_GSBI3_OPTION                Not supported
01000   8               BOOT_SPI_ON_GSBI4_OPTION                Not supported
01001   9               BOOT_SPI_ON_GSBI5_OPTION
01010   0x0A            BOOT_SPI_ON_GSBI6_OPTION                Not supported
01011   0x0B            BOOT_SPI_ON_GSBI8_OPTION                Not supported
01100   0x0C            BOOT_NAND_OPTION                        Not supported
01101   0x0D            BOOT_USB_OPTION
01110   0x0E            BOOT_SDC_PORT1_4BIT_OPTION
01111   0x0F            BOOT_SDC_PORT2_4BIT_OPTION
10000   0x10            BOOT_SPI_ON_GSBI9_OPTION
-------------------------------------------------------------------------------
BC[5:0] = BOOT_CONFIG[5:0]
SDC1 = eMMC
SDC2 = SD2 (not used)
SDC3 = SD1 (built in)
-------------------------------------------------------------------------------
BC6 = (0 - Secure Boot, 1 - Fast Boot)
-------------------------------------------------------------------------------
[/SIZE]

But this was all according to the Qualcomm MSM8960 specification. However, the
reference design schematic was simplified by omitting some of these
BC[x] pins, specifically the BC[2-5] pins, which are just used as regular
GPIO's, by just tying them directly to the antenna switch chips.

Thus the resulting configuration is as follows:

Code:
[SIZE=2]------------------------------------------------------------------
BC[5:0]         Mapping
------------------------------------------------------------------
0b00000         Emergency Boot from SDC3 (SD) followed by USB-HS
0b00001         SDC3 followed by SDC1 (eMMC)
0b00010         SDC3 followed by SDC2 (if used)
0b00011         SDC1 (eMMC)
------------------------------------------------------------------
[/SIZE]

However, this is not necessarily what is happening inside our SCH-I535,
because it is not confimed that the Service Manual schematics (which seem
to follow most of the reference schematic) is what is actually present on
the PCB. The reasons are that:
1) The reference schematic states that BC[0:6] are internally pulled-down.
2) Pull-ups are not needed if related Qfuses has been blown.
3) That (1) and (2) refers to Revisions C & D of reference design.

Thus we have to manually test what is going on on our device!

<< To Be Continued ... >>
 

Attachments

  • MSM8960_BA_secure_boot_1.jpg
    MSM8960_BA_secure_boot_1.jpg
    21.9 KB · Views: 88,758
  • SB3_Call_Stack.jpg
    SB3_Call_Stack.jpg
    32.8 KB · Views: 88,581
  • LoadProcess_all_4.jpg
    LoadProcess_all_4.jpg
    40.6 KB · Views: 90,615
  • SB3_3.jpg
    SB3_3.jpg
    50.7 KB · Views: 87,572
Last edited:

E:V:A

Inactive Recognized Developer
Dec 6, 2011
1,449
2,213
-∇ϕ
The Secure Boot Loaders

The table below list the various boot loaders and their code execution address,
code location and the type of memory it is executed in. WARNING!
Do not take these values as a fact, until we can verify them. The documentation
this is based on is already quite old and OEMs (like Samsung) are always changing and
tweaking things, including publishing poorly quality controlled documentation.



Code:
[SIZE=2]Component       Processor       Loc     ExecAddr        ExecMemType
-------------------------------------------------------------------------------
PBL             ARM7            *ROM    0x0             RPM ROM and RAM (stack) 
SBL1            ARM7            eMMC    0x2A000000      System IMEM     
SBL2            Krait           eMMC    0x2E000000      GMEM
RPM FW          ARM7            eMMC    x20000          RPM code RAM
TZ image        Krait           eMMC    [strike]0x2a020000[/strike]      System IMEM
SBL3            Krait           eMMC    [strike]0x47f00000[/strike]      LPDDR2
APPSBL          Krait           eMMC    [strike]TBD[/strike]             LPDDR2
HLOS            Krait           eMMC    TBD             LPDDR2
-------------------------------------------------------------------------------
*RPM Boot ROM
[/SIZE]
But Ralekdev, noticed that these deviates for our device. He'd like to see:

Code:
[SIZE=2]TZ              0x2A000000
SBL3            0x8FF00000
APPSBL/aboot    0x88E00000
[/SIZE]
Obviously the PBL is the mother of all boot loaders, and is the most important to everyone.
So we need to show and understand the memory map of that.

The PBL Memory Map

attachment.php


The PBL Error Handler

But what use is a memory map without an error handler? In fact the error handler explain how to reach
the HS-USB Emergency Download mode. Which is what we are discussing here, since it could
be disabled by blowing a Qfuse. The error log goes directly into memory (RPM RAM) as was also the case for the boot
log shown in a previous post.

Debugging can be done by inspecting the 1KB Error Log in the RAM at location 0x3FF18.

Log content is defined in the following format:
Code:
[SIZE=2]typedefstructboot_pbl_error_log_location_type {
        uint32 line_num;
        char *filename;
        pbl_err_code_enum_typeerr_code;
} boot_pbl_error_log_location_type;

-------------------------------------------------------------------------------
PBL Error Code Definitions
-------------------------------------------------------------------------------
typedefenum { 
        PBL_NO_ERR= 0,
        PBL_FLASH_DET_OR_RW_ERR,
        PBL_FLASH_TIMEOUT_ERR,
        PBL_ASSERT_ERR,
        PBL_LOAD_RPM_SBL_ERR,
        PBL_RPM_SBL_FORMAT_ERR,
        PBL_FLASH_SPEC_VER_ERR,
        PBL_CERT_CHAIN_VERIFY_ERR,
        PBL_SIGNATURE_VERIFY_ERR,
        PBL_MISC_OR_EXCEPTION_ABORT_ERR,
        PBL_LOAD_DLOAD_ERR,
        PBL_BOOT_SELECT_OPTION_ERR,
        PBL_SDCC_SPEED_SELECT_ERR,
        PBL_OUT_OF_BOUND_ERR,
        PBL_NULL_PTR_ERR,               /* null pointer error */
        PBL_ROLLBACK_ERR,               /* Denotes older secure image is being used */
        PBL_OEM_NUM_ROOT_CERTS_ERR,     /* Denotes the number of OEM root certswere invalid */
        PBL_OEM_ROOT_CERT_SEL_ERR,      /* Denotes the OEM root cert selected is invalid */
        PBL_INVALID_IMAGE_TYPE_ERR,     /* invalid image being authenticated */
        PBL_INVALID_PMIC_ERR,           /* no PMIC, or not an expected Qualcomm PMIC connected */
        PBL_PMIC_FLCB_ERR,              /* Error during fast low current boot sequence ==> PMIC power down MSM. */
        PBL_USB_ENUM_ERR,               /* USB enumeration failed */
        MAX_ERR_CODE = 0x7FFFFFFF       /* To ensure it's 32 bits wide */
} pbl_err_code_enum_type;


[/SIZE]
attachment.php


<< To Be Continued... >>
 

Attachments

  • SB3_PBL_memory_map.jpg
    SB3_PBL_memory_map.jpg
    37 KB · Views: 83,941
  • SB3_PBL_error_handler2.jpg
    SB3_PBL_error_handler2.jpg
    32.5 KB · Views: 83,730
Last edited:

Ralekdev

Retired Senior Recognized Developer
Sep 4, 2010
32
384
The Secure Boot Loaders

The table below list the various boot loaders and their code execution address,
code location and the type of memory it is executed in.

Code:
[SIZE=2]Component       Processor       Loc     ExecAddr        ExecMemType
-------------------------------------------------------------------------------
PBL             ARM7            *ROM    0x0             RPM ROM and RAM (stack) 
SBL1            ARM7            eMMC    0x2A000000      System IMEM     
SBL2            Krait           eMMC    0x2E000000      GMEM
RPM FW          ARM7            eMMC    x20000          RPM code RAM
TZ image        Krait           eMMC    0x2a020000      System IMEM
SBL3            Krait           eMMC    0x47f00000      LPDDR2
APPSBL          Krait           eMMC    TBD             LPDDR2
HLOS            Krait           eMMC    TBD             LPDDR2
-------------------------------------------------------------------------------
*RPM Boot ROM
[/SIZE]

It looks like ours deviates slightly from this.

If the headers are to be believed,
TZ is loaded at 0x2A000000
SBL3 is loaded at 0x8FF00000
APPSBL/aboot is loaded at 0x88E00000
 
S

sextape

Guest
Samsung L300 PIT FILE

http://d-h.st/rmS


Bootloader will be locked!


Digital_Envy.png



So question will providing the bootloader from an unlocked flash file help of course this is a different device but locked in the same matter as VZWs
 
Last edited:

pyrostic

Senior Member
Jun 23, 2010
542
212
Chicago - Northwest Suburbs
Samsung L300 PIT FILE

http://d-h.st/rmS


Bootloader will be locked!


Digital_Envy.png



So question will providing the bootloader from an unlocked flash file help of course this is a different device but locked in the same matter as VZWs

I just really don't know how you do it. The L300 has the same Chipset as us. Furthermore, AdamOutler and E:V:A please PM me I need to get you in contact with Sextape. He has more but He'd rather discuss this elsewhere.
 
Last edited:

E:V:A

Inactive Recognized Developer
Dec 6, 2011
1,449
2,213
-∇ϕ
I need a JTAG expert!

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

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

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

NOTE:
a) This solution does not apply to all MSM8660 versions
b) This solution does not apply to the RPM JTAG disable cases
c) This solution only uses for debug purpose.

For some reasons, if you need to to run unsigned software on a secure boot
enabled (the AUTH_EN bit in SECURE_BOOT1 register is blown) MSM8660 chip, the
following instruction is able to disable the secure boot authentication by using
RPM-JTAG.

1. Launch the Daisy Chain RPM-JTAG shortcut (i.e modem_proc\tools\t32\DC7_ARM7_RPM).
2. Execute the cmm script which contain the following command:

Code:
[SIZE=2]system.option resbreak on[/SIZE]
[SIZE=2]system.up[/SIZE]
[SIZE=2]g [B]0x7ce8 [/B]/o /cmd "r.s r0 [B][COLOR=Red]0x0[/COLOR][/B]" ; [B]0x0 for disabling[/B] the secure boot authentication[/SIZE]
[SIZE=2]wait 1ms[/SIZE]
[SIZE=2]g[/SIZE]
Of course, you can simply modify the cmm script (listed below) to enable the
secure boot authentication without blowing SECURE_BOOT1 register on MSM8660 chip
by using RPM-JTAG or short the GPIO_76 pin.
Code:
[SIZE=2]system.option resbreak on[/SIZE]
[SIZE=2]system.up[/SIZE]
[SIZE=2]g [B]0x7ce8 [/B]/o /cmd "r.s r0 [COLOR=Red][B]0x1[/B][/COLOR]" ;    [B]0x1 for enabling[/B] the secure boot authentication[/SIZE]
[SIZE=2]wait 1ms[/SIZE]
[SIZE=2]g [/SIZE]
What is this command doing exactly?
My guess is that 0x7ce8 is an address, but for what?
 
  • Like
Reactions: neh4pres

AdamOutler

Retired Senior Recognized Developer
Feb 18, 2011
5,224
9,810
Miami, Fl̨̞̲̟̦̀̈̃͛҃҅͟orida
Well, I have some supposedly unsecure scandalous sextape files.. I attempted to pack and flash via Odin Tar file. They failed secure checks via Odin, but I believe that means nothing to the actual device itself. I'm going to manually flash these files.

This may end up with me bricking my device, but I feel like it is worth it to prove or disprove the fact that these files work. So, I wanted to post this and then begin preparations. If anyone has any reason I should not flash these files, let me know. I will be out of commission if this fails.
 

pyrostic

Senior Member
Jun 23, 2010
542
212
Chicago - Northwest Suburbs
Well, I have some supposedly unsecure scandalous sextape files.. I attempted to pack and flash via Odin Tar file. They failed secure checks via Odin, but I believe that means nothing to the actual device itself. I'm going to manually flash these files.

This may end up with me bricking my device, but I feel like it is worth it to prove or disprove the fact that these files work. So, I wanted to post this and then begin preparations. If anyone has any reason I should not flash these files, let me know. I will be out of commission if this fails.

well the aboot will probably brick you. it is a secure file. and different size than the ours.
 

prdog1

Senior Member
Mar 10, 2012
9,098
5,460
Houston, Texas
Somehow I cannot just ignore and stop thinking about this post:

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

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

NOTE:
a) This solution does not apply to all MSM8660 versions
b) This solution does not apply to the RPM JTAG disable cases
c) This solution only uses for debug purpose.

For some reasons, if you need to to run unsigned software on a secure boot
enabled (the AUTH_EN bit in SECURE_BOOT1 register is blown) MSM8660 chip, the
following instruction is able to disable the secure boot authentication by using
RPM-JTAG.

1. Launch the Daisy Chain RPM-JTAG shortcut (i.e modem_proc\tools\t32\DC7_ARM7_RPM).
2. Execute the cmm script which contain the following command:

Code:
[SIZE=2]system.option resbreak on[/SIZE]
[SIZE=2]system.up[/SIZE]
[SIZE=2]g [B]0x7ce8 [/B]/o /cmd "r.s r0 [B][COLOR=Red]0x0[/COLOR][/B]" ; [B]0x0 for disabling[/B] the secure boot authentication[/SIZE]
[SIZE=2]wait 1ms[/SIZE]
[SIZE=2]g[/SIZE]
Of course, you can simply modify the cmm script (listed below) to enable the
secure boot authentication without blowing SECURE_BOOT1 register on MSM8660 chip
by using RPM-JTAG or short the GPIO_76 pin.
Code:
[SIZE=2]system.option resbreak on[/SIZE]
[SIZE=2]system.up[/SIZE]
[SIZE=2]g [B]0x7ce8 [/B]/o /cmd "r.s r0 [COLOR=Red][B]0x1[/B][/COLOR]" ;    [B]0x1 for enabling[/B] the secure boot authentication[/SIZE]
[SIZE=2]wait 1ms[/SIZE]
[SIZE=2]g [/SIZE]
What is this command doing exactly?
My guess is that 0x7ce8 is an address, but for what?

Contact Josh at http://www.google.com/url?sa=t&rct=...S_uPnmiTnsxkUOPcA&sig2=FGVhnpXczn8hBViW_D6Bnw
 

E:V:A

Inactive Recognized Developer
Dec 6, 2011
1,449
2,213
-∇ϕ
This may end up with me bricking my device, but I feel like it is worth it to prove or disprove the fact that these files work.
Not a good idea! Why would you wanna risk bricking it? (Which I say is about 90% chance of doing with the little knowledge we have.) Then rather send the thing to me... No, actually we need you to work on this, since you are the driving force and knowledge hub for many of these projects!

I know there's a bounty thread about this out there, but I'm not very happy about that. It simply means that people get greedy about their knowledge and start keeping relevant work for themselves. Let's not go there!
 

papi92

Senior Member
Nov 15, 2009
2,436
1,565
Files should work if made for Verizon SIII. May soft brick but shouldn't hard brick.

Sent from my SCH-I535 using Tapatalk 2
 

incubus26jc

Inactive Recognized Developer
Feb 12, 2009
4,094
3,569
Illinois
Well, I have some supposedly unsecure scandalous sextape files.. I attempted to pack and flash via Odin Tar file. They failed secure checks via Odin, but I believe that means nothing to the actual device itself. I'm going to manually flash these files.

This may end up with me bricking my device, but I feel like it is worth it to prove or disprove the fact that these files work. So, I wanted to post this and then begin preparations. If anyone has any reason I should not flash these files, let me know. I will be out of commission if this fails.

If you brick, we will probably have a new device paid for you in a matter of mins.
 
Last edited:

AdamOutler

Retired Senior Recognized Developer
Feb 18, 2011
5,224
9,810
Miami, Fl̨̞̲̟̦̀̈̃͛҃҅͟orida
Somehow I cannot just ignore and stop thinking about this post:

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

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

NOTE:
a) This solution does not apply to all MSM8660 versions
b) This solution does not apply to the RPM JTAG disable cases
c) This solution only uses for debug purpose.

For some reasons, if you need to to run unsigned software on a secure boot
enabled (the AUTH_EN bit in SECURE_BOOT1 register is blown) MSM8660 chip, the
following instruction is able to disable the secure boot authentication by using
RPM-JTAG.

1. Launch the Daisy Chain RPM-JTAG shortcut (i.e modem_proc\tools\t32\DC7_ARM7_RPM).
2. Execute the cmm script which contain the following command:

Code:
[SIZE=2]system.option resbreak on[/SIZE]
[SIZE=2]system.up[/SIZE]
[SIZE=2]g [B]0x7ce8 [/B]/o /cmd "r.s r0 [B][COLOR=Red]0x0[/COLOR][/B]" ; [B]0x0 for disabling[/B] the secure boot authentication[/SIZE]
[SIZE=2]wait 1ms[/SIZE]
[SIZE=2]g[/SIZE]
Of course, you can simply modify the cmm script (listed below) to enable the
secure boot authentication without blowing SECURE_BOOT1 register on MSM8660 chip
by using RPM-JTAG or short the GPIO_76 pin.
Code:
[SIZE=2]system.option resbreak on[/SIZE]
[SIZE=2]system.up[/SIZE]
[SIZE=2]g [B]0x7ce8 [/B]/o /cmd "r.s r0 [COLOR=Red][B]0x1[/B][/COLOR]" ;    [B]0x1 for enabling[/B] the secure boot authentication[/SIZE]
[SIZE=2]wait 1ms[/SIZE]
[SIZE=2]g [/SIZE]
What is this command doing exactly?
My guess is that 0x7ce8 is an address, but for what?

From what I understand, Josh has already tried this. I havn't been able to contact him recently though.

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


Not a good idea! Why would you wanna risk bricking it? (Which I say is about 90% chance of doing with the little knowledge we have.) Then rather send the thing to me... No, actually we need you to work on this, since you are the driving force and knowledge hub for many of these projects!

I know there's a bounty thread about this out there, but I'm not very happy about that. It simply means that people get greedy about their knowledge and start keeping relevant work for themselves. Let's not go there!

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



Files should work if made for Verizon SIII. May soft brick but shouldn't hard brick.

Sent from my SCH-I535 using Tapatalk 2
This is what I'm thinking.




So here's what I'm doing..

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

adb shell su -c "dd bs=4096 if=/sdcard/STUnsec/sbl1.mbn of=/dev/block/mmcblk0p2"
adb shell su -c "dd bs=4096 if=/sdcard/STUnsec/sbl2.mbn of=/dev/block/mmcblk0p3"
adb shell su -c "dd bs=4096 if=/sdcard/STUnsec/sbl3.mbn of=/dev/block/mmcblk0p4"
//adb shell su -c "dd bs=4096 if=/sdcard/STUnsec/aboot.mbn of=/dev/block/mmcblk0p5"
adb shell su -c "dd bs=4096 if=/sdcard/STUnsec/rpm.mbn of=/dev/block/mmcblk0p6"
adb shell su -c "dd bs=4096 if=/sdcard/STUnsec/boot.img of=/dev/block/mmcblk0p7"
adb shell su -c "dd bs=4096 if=/sdcard/STUnsec/tz.mbn of=/dev/block/mmcblk0p8"
adb shell su -c "dd bs=4096 if=/sdcard/STUnsec/persist.img.ext4 of=/dev/block/mmcblk0p16"
 
Last edited:

invisiblek

Recognized Developer
Feb 24, 2010
1,584
5,896
Minnesota
www.invisiblek.org
So here's what I'm doing..

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

adb shell su -c "dd bs=4096 if=/sdcard/STUNSEC/sbl1.mbn of=/dev/block/mmcblk0p2"
adb shell su -c "dd bs=4096 if=/sdcard/STUNSEC/sbl2.mbn of=/dev/block/mmcblk0p3"
adb shell su -c "dd bs=4096 if=/sdcard/STUNSEC/sbl3.mbn of=/dev/block/mmcblk0p4"
//adb shell su -c "dd bs=4096 if=/sdcard/STUNSEC/aboot.mbn of=/dev/block/mmcblk0p5"
adb shell su -c "dd bs=4096 if=/sdcard/STUNSEC/rpm.mbn of=/dev/block/mmcblk0p6"
adb shell su -c "dd bs=4096 if=/sdcard/STUNSEC/boot.img of=/dev/block/mmcblk0p7"
adb shell su -c "dd bs=4096 if=/sdcard/STUNSEC/tz.mbn of=/dev/block/mmcblk0p8"
adb shell su -c "dd bs=4096 if=/sdcard/STUNSEC/persist.img.ext4 of=/dev/block/mmcblk0p16"


not to be a downer, but this wont work
at best you might be able to get some info from where it hangs on boot
but it will brick
jtag will be your only option

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

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

save yourself the time of jtag'ing

(my two cents)
 
S

sextape

Guest
From what I understand, Josh has already tried this. I havn't been able to contact him recently though.


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




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




This is what I'm thinking.




So here's what I'm doing..

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

adb shell su -c "dd bs=4096 if=/sdcard/STUNSEC/sbl1.mbn of=/dev/block/mmcblk0p2"
adb shell su -c "dd bs=4096 if=/sdcard/STUNSEC/sbl2.mbn of=/dev/block/mmcblk0p3"
adb shell su -c "dd bs=4096 if=/sdcard/STUNSEC/sbl3.mbn of=/dev/block/mmcblk0p4"
//adb shell su -c "dd bs=4096 if=/sdcard/STUNSEC/aboot.mbn of=/dev/block/mmcblk0p5"
adb shell su -c "dd bs=4096 if=/sdcard/STUNSEC/rpm.mbn of=/dev/block/mmcblk0p6"
adb shell su -c "dd bs=4096 if=/sdcard/STUNSEC/boot.img of=/dev/block/mmcblk0p7"
adb shell su -c "dd bs=4096 if=/sdcard/STUNSEC/tz.mbn of=/dev/block/mmcblk0p8"
adb shell su -c "dd bs=4096 if=/sdcard/STUNSEC/persist.img.ext4 of=/dev/block/mmcblk0p16"

Adam just remember the aboot is different but if you know how to flash a boot headers you can get your device into download mode and reflash the stock tar

Sent from my SPH-D700 using Tapatalk 2

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

not to be a downer, but this wont work
at best you might be able to get some info from where it hangs on boot
but it will brick
jtag will be your only option

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

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

save yourself the time of jtag'ing

(my two cents)

Big difference is this file is unsecured im still working on a dev or unsecured i535 file

Sent from my SPH-D700 using Tapatalk 2
 
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://forum.xda-developers.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:
    [email protected]:~/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: [email protected]
    [    0.000000] sec_dbg_setup: secdbg_paddr = 0x88d90004
    [    0.000000] sec_dbg_setup: secdbg_size = 0x40000
    [    0.000000] etb_buf_setup: [email protected]
    [    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: [email protected]
    [    0.000000] sec_dbg_setup: secdbg_paddr = 0x88d90004
    [    0.000000] sec_dbg_setup: secdbg_size = 0x40000
    [    0.000000] etb_buf_setup: [email protected]
    [    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; // [email protected]
      int count; // [email protected]
      unsigned __int64 v7; // [email protected]
      unsigned __int64 v8; // [email protected]
      int inner_index; // [email protected]
      int block1_pos; // [email protected]
      int v11; // [email protected]
      __int64 v12; // [email protected]
      int v13; // [email protected]
      unsigned __int64 v14; // [email protected]
      int v15; // [email protected]
      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; // [email protected] int last_index; // [email protected] int odd_index; // [email protected] int table_index; // [email protected] 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; // [email protected] int v5; // [email protected]

    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