I'm going on vacation Thursday until Sunday so I'll dive in Sunday night. I'm surprised I missed the manual as I had a one x for a month, lol.
Sent from my Galaxy Nexus using Tapatalk 2
Sent from my Galaxy Nexus using Tapatalk 2
[R&D] Unlock Bootloaders
- Thread starter AdamOutler
- Start date
- Status
S
sextape
Guest
No the manual won't be released here due to the "leaker" required sting us not to. If you need it you'll figure out how to find it.
I am, however, curious as to what this sextape leak might have in it.
Sent from my SCH-I535 using Tapatalk 2
Last edited:
This post has a whole bunch of pdfs that could be helpful including the 8960 schematic that LLStarks was referencing.
hmmm
I understand that Adam still wants a qualcomm msm8960 data sheet or at least a qfuse AN, but it could be a while until that appears. Looking through the documents, both the manual and baseband, I have come the the conclusion that the qfuse for trusted boot is blown. In the service manual I see that BOOT_CONFIG_6 is pulled high on bootup and then changes to a regular GPIO pin. Consulting the baseband documentation BOOT_CONFIG_6 is tied to an internal pulldown (must be very weak as sammy is pulling up with a 10k so there is static current). BOOT_CONFIG_6 from the baseband states that 0 = Secure Boot (default due to pulldown) | 1 = Fast Boot. So the pin is telling the MSM8960 to not use secure boot however it does it anyway. This would be typical behavior of the the MSM7xxx with a trusted boot qfuse blown. I have no reason to think that physical security on these chips varies significantly through revisions.
So I guess back to the drawing board. I am beginning to understand a lot of this boot process, I am a EE so the android booting process is a little bit of a mystery. I would love to have a google hangout with Adam, and Lee and all others who know something about how this black box works.
Adam perhaps you or someone else can spell out what part of the bootloader(or which one SBL, aboot, etc) we really need to modify to load custom kernals(I think it is probably the first two but I don't know), I am sort of a low level linux noob so explaining things could be quite helpful to me and others.
Lets start sharing every little shed of data and start a "greatest hits" repository of all things we learn that are important.
{UPDATE}
I found the other two documents LLStarks is talking about ( Secure Boot 3.0/PBL and boot_config diagram). The Boot_config datasheet gives us the same info that is on the MSM8960 baseband docs. I will reproduce it here:
Also the PBL documentation confirms that the qfuses override the physical pin connections. Oh and by the way there are fuses that also block the boot config0/1 mode (in addition to the mentioned boot config 6) so changing these physically may have no effect if they are blown.
I believe the code earlier in this thread shows that when boot fails it goes in Emergency boot, there are some nice explanations as to what is happening in the boot arch document. So anyone decompiling aboot may want to find that and look through it. Keep in mind again that emergency boot can still be blocked by a fuse. I guess we really need to read those bad boys to see what we are dealing with instead of experimenting.
By the way in case anyone didn't notice the default boot mode is Secure Boot(due to the pulldown), however as I mentioned the qualcomm baseband docs say to pull up that pin(boot_config_6) on boot on therefore negating secure boot on non fuse blown systems. So it seems qualcomm was trying to be nice and leave the door open but verizon noticed, closed, and locked it
I understand that Adam still wants a qualcomm msm8960 data sheet or at least a qfuse AN, but it could be a while until that appears. Looking through the documents, both the manual and baseband, I have come the the conclusion that the qfuse for trusted boot is blown. In the service manual I see that BOOT_CONFIG_6 is pulled high on bootup and then changes to a regular GPIO pin. Consulting the baseband documentation BOOT_CONFIG_6 is tied to an internal pulldown (must be very weak as sammy is pulling up with a 10k so there is static current). BOOT_CONFIG_6 from the baseband states that 0 = Secure Boot (default due to pulldown) | 1 = Fast Boot. So the pin is telling the MSM8960 to not use secure boot however it does it anyway. This would be typical behavior of the the MSM7xxx with a trusted boot qfuse blown. I have no reason to think that physical security on these chips varies significantly through revisions.
So I guess back to the drawing board. I am beginning to understand a lot of this boot process, I am a EE so the android booting process is a little bit of a mystery. I would love to have a google hangout with Adam, and Lee and all others who know something about how this black box works.
Adam perhaps you or someone else can spell out what part of the bootloader(or which one SBL, aboot, etc) we really need to modify to load custom kernals(I think it is probably the first two but I don't know), I am sort of a low level linux noob so explaining things could be quite helpful to me and others.
Lets start sharing every little shed of data and start a "greatest hits" repository of all things we learn that are important.
{UPDATE}
I found the other two documents LLStarks is talking about ( Secure Boot 3.0/PBL and boot_config diagram). The Boot_config datasheet gives us the same info that is on the MSM8960 baseband docs. I will reproduce it here:
Code:
BOOT_CONFIG_1 | BOOT_CONFIG_0 |
0 | 0 | EMER. BOOT(SDC3 FOLLOWED BY USB HS)
0 | 1 | SDC3 FOLLOWED BY SDC1
1 | 0 | SDC3 FOLLOWED BY SDC2
1 | 1 | SDC1 (eMMC, DEFAULT)
BOOT_CONFIG_6
0 | Secure Boot
1 | Fast BootAlso the PBL documentation confirms that the qfuses override the physical pin connections. Oh and by the way there are fuses that also block the boot config0/1 mode (in addition to the mentioned boot config 6) so changing these physically may have no effect if they are blown.
I believe the code earlier in this thread shows that when boot fails it goes in Emergency boot, there are some nice explanations as to what is happening in the boot arch document. So anyone decompiling aboot may want to find that and look through it. Keep in mind again that emergency boot can still be blocked by a fuse. I guess we really need to read those bad boys to see what we are dealing with instead of experimenting.
By the way in case anyone didn't notice the default boot mode is Secure Boot(due to the pulldown), however as I mentioned the qualcomm baseband docs say to pull up that pin(boot_config_6) on boot on therefore negating secure boot on non fuse blown systems. So it seems qualcomm was trying to be nice and leave the door open but verizon noticed, closed, and locked it
Last edited:
There are 2 more documents floating around.
I think they have what we need in the boot department.
I think they have what we need in the boot department.
Last edited:
I posit that they are in the right hands
Last edited:
important stuff.. download now.
Boot guide http://www.rd211.com/docu/78897.html.
Service manual http://stadium.weblogsinc.com/engadget/files/EN_LG-VS930_SVC_ENG_120704.pdf
Service manual http://www.mediafire.com/view/?81e7t2y1ttysc8f
Hope I don't get anyone in trouble.
Boot guide http://www.rd211.com/docu/78897.html.
Service manual http://stadium.weblogsinc.com/engadget/files/EN_LG-VS930_SVC_ENG_120704.pdf
Service manual http://www.mediafire.com/view/?81e7t2y1ttysc8f
Hope I don't get anyone in trouble.
Fixed link for the SCH-I535 service manual: http://d-h.st/LA5
Also, I managed to flash the LG1 kernel to my phone using the entire 1.2 GB LG1 flash.
COMBINATION_I535VRALG1_I535VZWALG1_743127_REV09_user_low_ship.tar.md5
Edit: Rehosts of the other files
http://d-h.st/cIv
http://d-h.st/xJ9
Also, I managed to flash the LG1 kernel to my phone using the entire 1.2 GB LG1 flash.
COMBINATION_I535VRALG1_I535VZWALG1_743127_REV09_user_low_ship.tar.md5
Edit: Rehosts of the other files
http://d-h.st/cIv
http://d-h.st/xJ9
Last edited:
Damn! This place is really exploding with new fun and juicy info.
This will be the first of a few posts collecting what we (you?) need.
First thing of, let me help you locate the boot pins on your
Qualcomm Snapdragon S4 Plus (aka. MSM8960) that is running
the show in your SCH-I535.
In the schematic diagram below we see how these are connected on the MSM8960
that is labelled "UCP700-1". The reason there is a "-1" added to the label,
is that this is a PoP (Package-on-a-Package) located directly under the 16GB
LPDDR2 DRAM memory labelled as "UCP700UP" and is a Samsung part known as:
"K3PE0E000A-XG(2)" in this document.
So for the SCH-I535 we have:
The General Boot Function Table is:
So here we can see that when the Dragon is reset by a high on MSM_RESOUT_N,
BOOT_CONFIG_0,1,6 are also pulled high, so that we have: c0:c1:c6 = 111,
which means Fast Boot from the eMMC (SDC1).
(Contrary to what was mentioned before? Correct me if I'm wrong.)
EDIT (2012-08-12): ---
Apparently this behavior have not been resolved, since there are arguments
saying that MSM_RESOUT_N is using inverted logic ("_N"). This also seem
supported by the emergency download USB device appearing after soft-bricking.
(See post #271.)
If this is true, then c0:c1:c6 = 000.
------
Here is the location of these components on the PCB.
...
So the next step is; how can we determine the Qfuse settings?
This will be the first of a few posts collecting what we (you?) need.
First thing of, let me help you locate the boot pins on your
Qualcomm Snapdragon S4 Plus (aka. MSM8960) that is running
the show in your SCH-I535.
In the schematic diagram below we see how these are connected on the MSM8960
that is labelled "UCP700-1". The reason there is a "-1" added to the label,
is that this is a PoP (Package-on-a-Package) located directly under the 16GB
LPDDR2 DRAM memory labelled as "UCP700UP" and is a Samsung part known as:
"K3PE0E000A-XG(2)" in this document.
So for the SCH-I535 we have:
Code:
[SIZE=2]-------------------------------------------------------------------------------
pad gpio name connection boot Rxxx
-------------------------------------------------------------------------------
AH32 119 BOOT_FROM_ROM ANT_SW_SEL0
AH33 118 BOOT_CONFIG_0 ANT_SW_SEL1 * R745
AM31 117 BOOT_CONFIG_1 ANT_SW_SEL2 * R746
AM30 116 BOOT_CONFIG_2 ANT_SW_SEL3
AN30 115 BOOT_CONFIG_3 BC0_SW_SEL0
AM29 114 BOOT_CONFIG_4 BC0_SW_SEL1
AN29 113 BOOT_CONFIG_5 BC1_SW_SEL0
[COLOR=Red]AK28 112 BOOT_CONFIG_6 ANT_SW_SEL4 * R747[/COLOR]
C30 - RESOUT_N MSM_RESOUT_N
-------------------------------------------------------------------------------
* ANT_SW_SEL[1,2,4] == BOOT_CONFIG_[0,1,6] are kept high through
R = [R745, R746, R747] via Q700 when MSM_RESOUT_N in high (???).
-------------------------------------------------------------------------------
R 2007-008516 R-CHIP;10Kohm,5%,1/20W,TP,0603 ERJ1GEJ103C
Q700 0505-002341 FET-SILICON;Si1013X-T1-GE3,P,-20V,-400mA SI1013X-T1-GE3
UCP700 1205-004465 <Snapdragon S4 Plus> MSM8960
UCP700UP 1105-002388 <16 GB DRAM> K3PE0E000A-XGC2
-------------------------------------------------------------------------------
[/SIZE]
Code:
[SIZE=2]------------------------------------------------------------------
[B]c1[/B][/SIZE] [SIZE=2] [B]c0[/B] function
------------------------------------------------------------------
0 0 Emergency Boot from SDC3 (SD) followed by USB-HS
0 1 SDC3 followed by SDC1 (eMMC)
1 0 SDC3 followed by SDC2 (not used?)
1 1 SDC1 (eMMC)
------------------------------------------------------------------
[B]c6[/B][/SIZE] [SIZE=2] 0 - Secure Boot
1 - Fast Boot
------------------------------------------------------------------[/SIZE]BOOT_CONFIG_0,1,6 are also pulled high, so that we have: c0:c1:c6 = 111,
which means Fast Boot from the eMMC (SDC1).
(Contrary to what was mentioned before? Correct me if I'm wrong.)
EDIT (2012-08-12): ---
Apparently this behavior have not been resolved, since there are arguments
saying that MSM_RESOUT_N is using inverted logic ("_N"). This also seem
supported by the emergency download USB device appearing after soft-bricking.
(See post #271.)
If this is true, then c0:c1:c6 = 000.
------
Here is the location of these components on the PCB.
...
So the next step is; how can we determine the Qfuse settings?
Attachments
Last edited:
Great work E:V:A. Has anyone found a processor pin-out diagram? I need to sit down and go through those schematics when I get a chance.
Ah ha.. Found it at the end of the service manual.. http://d-h.st/LA5
If someone can, rehost those files I posted earlier on dev-host.. I can't access any of them from work and I can't send an email that large to my work.. So that leaves me with the option of viewing them on my phone.
Ah ha.. Found it at the end of the service manual.. http://d-h.st/LA5
If someone can, rehost those files I posted earlier on dev-host.. I can't access any of them from work and I can't send an email that large to my work.. So that leaves me with the option of viewing them on my phone.
Last edited:
Here is the MSM8960 BGA pin map showing the BOOT_CONFIG_x pads.
Great work as usual EVA. Can you get a higher Res version?
As hackers, we can't work with the pins themselves, so that map needs to be flipped either horizontally or vertically before it can be laid on top of a processor for overlay pin mapping
(Adam, I mirrored the files in my previous post)
I'm a little confused on how the Qfuses work and the overall terminology used to described them. Are they one-way deal? How does our situation now compare to Motorola and their use of Efuses?
I'm a little confused on how the Qfuses work and the overall terminology used to described them. Are they one-way deal? How does our situation now compare to Motorola and their use of Efuses?
Last edited:
If the gate and source are connected as somewhat appears, it is called a diode connected mosfet and is excellent at modifying current however that would not be very useful because it would just be off all the time. I think the gate and source are separate but a simple multiplier test can confirm. The _N means active low so when MSM_RESOUT_N is pulled low the three lines are pulled high through a 10k. As I stated earlier though qualcomm has BOOT_CONFIG_6 internally pulled low so it is odd they pull it high through a resistor instead on directly to VDD. This tell me it is a very weak pull-down internally.
I will reiterate that the internal fuse for secure boot is blown since the schematic indicates we should boot in fast boot but we do not. However if the schematic is to be believed perhaps the gate is tied to the source meaning that all three pins are floating (except for BOOT_CONFIG_6 which is pulled down internally). This would produce secure boot even though the qfuse may not be blown! this also produces 00 for the boot mode which is emergency which is not what is happening so maybe those fuses are blown internally as well.
By the way I had some of this info a few posts back but i guess you didn't catch it
Last edited:
There's two things to keep in mind here...If the gate and source are connected as somewhat appears, it is called a diode connected mosfet and is excellent at modifying current however that would not be very useful because it would just be off all the time. I think the gate and source are separate but a simple multiplier test can confirm. The _N means active low so when MSM_RESOUT_N is pulled low the three lines are pulled high through a 10k. As I stated earlier though qualcomm has BOOT_CONFIG_6 internally pulled low so it is odd they pull it high through a resistor instead on directly to VDD. This tell me it is a very weak pull-down internally.
I will reiterate that the internal fuse for secure boot is blown since the schematic indicates we should boot in fast boot but we do not. However if the schematic is to be believed perhaps the gate is tied to the source meaning that all three pins are floating (except for BOOT_CONFIG_6 which is pulled down internally). This would produce secure boot even though the qfuse may not be blown! this also produces 00 for the boot mode which is emergency which is not what is happening so maybe those fuses are blown internally as well.
By the way I had some of this info a few posts back but i guess you didn't catch it
1. Samsung has always used resistors between any voltage or ground source and the processor.
2. The new generation of devices which Samsung is putting out encorperate a sort of UnBrickable Mod(ish) design. You insert an SDCard, then short a resistor from one side to the other which causes the device to boot from SDCard. The device is not a dual-boot development board as in UnBrickable Mod, but it is a temporary hardware method of altering the boot mode.
You are basing your information on the fuse being blown based on shematics. I've proven Samsung schematics wrong several times in the past. We will verify that. Also, these boot modes are important because we want to come up with a bootloader recovery.
Has anyone found the memory location of the BOOT_CONFIG register set? Testing should be real easy if someone can find that memory address.
Last edited:
Unfortunately not, since I don't have that document. (As you can barely see from the watermark, it's from the MSM8960 TRM, which I don't have.) I don't see how this flipping is gonna help you in this case?
Has this been confirmed?
I saw your post, and that's why I wrote what I did. But how can I edit my post #212 so not to mislead anyone? (I admit to be a bit rusty on the EE details.)
Last edited:
All very true! I was just pointing out what appears to be fact based on information thus far. As soon as we read the fuse registers it will put to rest any of my theories. How would we even go about finding these fuse settings. We know they are mapped to a shadow register do you think they would then be accessed via an mcr arm command?
Did the Samsung models that used the unbrickablemodish design also have qualcomms and have their boot mode select fuses blown? Where were the fuses located on msm7xxx or other qualcomms?
I mean no disrespect to you Adam I am just trying to question all things and come up with an answer then question it again. Keep up the amazing work! I am trying to learn what I can from everyone and I hope I am not frustrating you.
Sent from my SCH-I535 using xda app-developers app
- Status
Similar threads
Top Liked Posts
-
There are no posts matching your filters.
-
561Verizon GS3 is now Bootloader UNLOCKED.
We now have access to an unsecure bootloader. This was leaked by an African-Canadian Sock Monkey.
Let me make this clear. If Samsung updates your device's bootloaders, using this tool could potentially brick your device. Once you apply this, never accept a factory update without first flashing the Odin Packages in the Original Post of this thread. As a general rule, you want to be the last guy to apply any Samsung update. Run custom.
As of the date of this posting, this works great on Linux and it should work wonderfully on Mac too. NOTE: this may work on windows, but please, windows users.. learn to use your computer before you ask questions on XDA-Developers. This is one-click on Linux and Mac every darn time. If you're using Windows, I recommend downloading Windows Ubuntu Installer(WUBI) to install Ubuntu from within Windows.
Download
http://d-h.st/ypJ
Instructions:
1. Open this file
2. Select Root with DebugFSRoot and Do It
3. Select Flash Unsecure Aboot and Do It
4. Use Odin or CWM to flash kernels to your device
To flash from device without the above tool:- root your device
- Download this link to your /sdcard/Downloads/ folder: http://d-h.st/Piq
- Type this in the terminal emulator
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.173Rules:
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 required96
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.85It'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 official70A 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
