Goal: Destroy SBOOT

E:V:A · Dec 6, 2012

Did this work?

Code:

echo 0 > /sys/block/mmcblk0boot0/force_ro

If not, check your mmc sources for changes of the "force_ro" identifier...

kirch21 said:
guy posted this in the rom thread, posting it here to.. i also have no idea what it is but cant hurt right? lol

Cool! That's the reading of the Qfuse settings. Would be nice to see what binary that is linked to...

AdamOutler · Dec 6, 2012

I can get memory locations if Hash code needs them I see them on UART every time the device boots up. We need to be able to access the Boot partition.

invisiblek · Dec 6, 2012

E:V:A said:
Did this work?

Code:

echo 0 > /sys/block/mmcblkXbootY/force_ro

If not, check your mmc sources for changes of the "force_ro" identifier...

We can't see mmcblk0bootX, the kernel more or less hides them. So changing force_ro isn't even possible at this point.

AdamOutler said:
I can get memory locations if Hash code needs them I see them on UART every time the device boots up. We need to be able to access the Boot partition.

He'll probably need the output of:

Code:

cat /proc/iomem

Loglud · Dec 6, 2012

invisiblek said:
We can't see mmcblk0bootX, the kernel more or less hides them. So changing force_ro isn't even possible at this point.

He'll probably need the output of:

Code:

cat /proc/iomem

See what I'm interested in is whether or not the boot block is even in the mmc. According to the data sheet, there are quite a few places they could put it that may not be accessible to public or device knowledge. Also if it isnt, there is a way to add a pointer to the development device, however the kernel may be lacking the driver. If the kernel does not have the driver then well have to add the driver as a module to the kernel. If it is in there then a makedev might be able to make the interface.

invisiblek · Dec 6, 2012

Loglud said:
See what I'm interested in is whether or not the boot block is even in the mmc. According to the data sheet, there are quite a few places they could put it that may not be accessible to public or device knowledge. Also if it isnt, there is a way to add a pointer to the development device, however the kernel may be lacking the driver. If the kernel does not have the driver then well have to add the driver as a module to the kernel. If it is in there then a makedev might be able to make the interface.

According to the PIT it is on MMC, you can use a PIT viewer to look at this if you'd like: http://goo.im/devs/invisiblek/misc/pits/sch-i605-16gb.pit
Otherwise I can grab you a screenshot when I get home.

Loglud · Dec 6, 2012

invisiblek said:
According to the PIT it is on MMC, you can use a PIT viewer to look at this if you'd like: http://goo.im/devs/invisiblek/misc/pits/sch-i605-16gb.pit
Otherwise I can grab you a screenshot when I get home.

Hmm if that is true, two things. First of the pit I believe acts somewhat like a partition table. With the pit could you overload the pit to place something after the pit memory allocation ie.

pit = 2048 bits
boot = ~100000 bits

put pit of 102048 bits on phone and overwrite the boot sector.

Most likely this is locked up. out of curosity is the mmcblk1 in the fstab? also in the init.rc does it create the dev for the device. If not this may be as simple as creating the device based off of a lspci or lsmmc (might have to be compiled) to find the device location on the subsystem and then the makedev can make the device. I would also look at THIS which talks about the previously mentioned mmc-utils which can read and write out the blocks of a mmc.

To me it seems a little weird that they would block the boot sector in the kernel, though they vary well might have. If this is truly the case do to kernel limitations you will not be able to access the boot sector from inside the existing kernel as the modules all get loaded after the base kernel and can be tricky to make something load on top. Has the source code been relased for this device? If it has id be very interested in seeing the kernel config, as I assume that they use the basic kernel with a device limited driver making it so that when the kernel calls the driver for the /dev it cannot read or write from that subsystem.

xXJay_RXx · Dec 6, 2012

Here's the source code. I read that they did release it n I looked it up n found this. It has "ICS" in the file name but this is what came up

http://opensource.samsung.com/reception/receptionSub.do?method=search&searchValue=SCH-I605

Sent from my SCH-I605 using Tapatalk 2

nnnnr14 · Dec 6, 2012

xXJay_RXx said:
Here's the source code. I read that they did release it n I looked it up n found this. It has "ICS" in the file name but this is what came up

http://opensource.samsung.com/reception/receptionSub.do?method=search&searchValue=SCH-I605

Sent from my SCH-I605 using Tapatalk 2

It just got real! Hopefully they put ics to make sure Verizon doesn't find out.

Sent from my rooted galaxy note 2... U mad?

kejar31 · Dec 6, 2012

nnnnr14 said:
It just got real! Hopefully they put ics to make sure Verizon doesn't find out.

Sent from my rooted galaxy note 2... U mad?

Huh... Exactly why would Samsung hide source code they are required to release from Verizon???

Sent from my SCH-I605 using Tapatalk 2

simone201 · Dec 6, 2012

invisiblek said:
We can't see mmcblk0bootX, the kernel more or less hides them. So changing force_ro isn't even possible at this point.

That's pretty easy to do...

A 2 lines patch for the emmc driver into the kernel source enables seeing and writing both boot0 and boot1 partitions

Every kernel that has TriangleAway support, has those partitions showing properly (check mine or any other with that patch)

Inviato dal mio GT-I9300 con Tapatalk 2

Loglud · Dec 7, 2012

simone201 said:
That's pretty easy to do...

A 2 lines patch for the emmc driver into the kernel source enables seeing and writing both boot0 and boot1 partitions

Every kernel that has TriangleAway support, has those partitions showing properly (check mine or any other with that patch)

Inviato dal mio GT-I9300 con Tapatalk 2

Wait what?

That requires the kernel to be modified, in the source, not patched as the existing kernel. As of now the kernel in the boot.img of the system partition can not be modified as it is locked. Now this could be useful to compile an existing source kernel with the patch and then kexec into that kernel. Might worth being tried, though since there is no mmcblk0 partition being loaded into the first kernel i'm not sure if the patched kernel can pick it up.

invisiblek · Dec 7, 2012

Loglud said:
Hmm if that is true, two things. First of the pit I believe acts somewhat like a partition table. With the pit could you overload the pit to place something after the pit memory allocation ie.

pit = 2048 bits
boot = ~100000 bits

put pit of 102048 bits on phone and overwrite the boot sector.

Most likely this is locked up. out of curosity is the mmcblk1 in the fstab? also in the init.rc does it create the dev for the device. If not this may be as simple as creating the device based off of a lspci or lsmmc (might have to be compiled) to find the device location on the subsystem and then the makedev can make the device. I would also look at THIS which talks about the previously mentioned mmc-utils which can read and write out the blocks of a mmc.

To me it seems a little weird that they would block the boot sector in the kernel, though they vary well might have. If this is truly the case do to kernel limitations you will not be able to access the boot sector from inside the existing kernel as the modules all get loaded after the base kernel and can be tricky to make something load on top. Has the source code been relased for this device? If it has id be very interested in seeing the kernel config, as I assume that they use the basic kernel with a device limited driver making it so that when the kernel calls the driver for the /dev it cannot read or write from that subsystem.

they are most definitely blocking the boot sector, here's some info from the PIT
BOOTLOADER: http://i.imgur.com/LzrKQ.jpg
BOOT: http://i.imgur.com/Lj3Xd.jpg
As you can see, both appear to be on the same block, just at different spots

mmcblk1 is the external sd card

kernel config here: http://paste.ubuntu.com/1415961

Loglud said:
Wait what?

That requires the kernel to be modified, in the source, not patched as the existing kernel. As of now the kernel in the boot.img of the system partition can not be modified as it is locked. Now this could be useful to compile an existing source kernel with the patch and then kexec into that kernel. Might worth being tried, though since there is no mmcblk0 partition being loaded into the first kernel i'm not sure if the patched kernel can pick it up.

exactly
i've compiled said kernel, we just have no way of booting it

AdamOutler · Dec 7, 2012

Here's a UART log. it's got lots of errors like adv-env.img.. My device is pretty messed up right now

it has no valid kernels on it.

Code:

PMIC rev = PASS2(4)
mmc_initialize: mmc->capacity = 30777344

Samsung S-Boot 4.0-414933 for SCH-I605 (Oct 28 2012 - 13:33:33)

EXYNOS4412(EVT 2.0) / 2047MB / 15028MB / Rev 10 / I605VRALJB

initialize_ddi_data: usable! (0:0x0)
read_param_file: find fail!(adv-env.img)
init_param_part: There is no env file.
<start_checksum:331>CHECKSUM_HEADER_SECTOR :4096
<start_checksum:333>offset:50, size:6296
<start_checksum:336>CHECKSUM_HEADER_INFO : NeedChecksum:0 PartNo:20
Not Need Movinand Checksum
Movinand Checksum Confirmation Pass
init_fuelgauge: fuelgauge power ok
s5p_read_adc: ch#0: 419
s5p_read_adc: ch#0: 419
s5p_read_adc: ch#0: 418
init_fuelgauge: POR status
fuelgauge_por: POR start: vcell(4123), vfocv(4125), soc(92)
fuelgauge_por: update SDI T0 parameter
fuelgauge_por: RCOMP(0x0042), TEMPCO(0x0a1b)
fuelgauge_por: POR finish: vcell(4124), vfocv(4206), soc(83)
init_fuelgauge: disable charging for soc-cal
set_charger_current: chg curr(14), in curr(23)
set_charger_state: buck(1), chg(0), reg(0x04)
init_fuelgauge: vcell comp. = 4073
get_table_soc: vcell(4073) is caculated to t-soc(82.26)
init_fuelgauge: start: vcell(4073), vfocv(4196), soc(83), table soc(82)
init_fuelgauge: finish: vcell(4073), vfocv(4196), soc(83), table soc(82)
init_microusb_ic: MUIC: CONTROL1:0x00
init_microusb_ic: MUIC: CONTROL1:0x00
init_microusb_ic: MUIC: CONTROL2:0x3b
init_microusb_ic: MUIC: CONTROL2:0x3b
PMIC_ID      = 0x02 
PMIC_IRQSRC  = 0x00 
PMIC_STATUS1 = 0x16 
PMIC_STATUS2 = 0x10 
PMIC_PWRON   = 0x40 
PMIC_IRQ1    = 0x43 
PMIC_IRQ2    = 0x00 
s5p_check_keypad: 0x0
s5p_check_reboot_mode: INFORM3 = 0 ... skip
board_check_cp_mdm9x_type : 0
s5p_check_upload: MAGIC(0x66262564), RST_STAT(0x10000)
s5p_check_upload: debug level is 0!
s5p_check_upload: level low or unknown: skip 0
microusb_get_attached_device: STATUS1:0x3f, 2:0x41
s5p_check_download: 0
s5p_check_modem_secure_fail: 0
microusb_get_attached_device: STATUS1:0x3f, 2:0x41
s5p_read_adc: ch#0: 416
s5p_read_adc: ch#0: 418
s5p_read_adc: ch#0: 418
check_pm_status: charger boot, waiting 500ms and check again
microusb_get_attached_device: STATUS1:0x3f, 2:0x41
check_pm_status: charger is ok, LPM boot
AST_CHARGING..
ddi type = 1, S.LSI
cmu_div:6, div:2, src_clk:880000000, pixel_clk:62614944
41, 16, a2, 
battery_check_terminal_open: CHG = 0x08, BAT = 0x03
battery_check_terminal_open: vcell = 4123mV
set_charger_current: chg curr(14), in curr(23)
set_charger_state: buck(1), chg(1), reg(0x05)
microusb_get_attached_device: STATUS1:0x3f, 2:0x41
set_auto_current: ta_state(0), curr(1800)
load_kernel: loading boot image from 106496..
- read_bl1
pit_check_signature (BOOT) valid.
if_ddi_data: succeeded. (0:0x0)
ATAG_CORE: 5 54410001 0 0 0
ATAG_MEM: 4 54410002 20000000 40000000
ATAG_MEM: 4 54410002 20000000 60000000
ATAG_MEM: 4 54410002 20000000 80000000
ATAG_MEM: 4 54410002 1ff00000 a0000000
ATAG_SERIAL: 4 54410006 42f70a04 8479f21
ATAG_INITRD2: 4 54420005 42000000 8eed9
ATAG_REVISION: 3 54410007 a
ATAG_CMDLINE: 67 54410009 ' sec_debug.level=0 sec_watchdog.sec_pet=5 androidboot.debug_level=0x0 softlockup_panic=0 sec_log=0x200000@0x46000000 s3cfb.bootloaderfb=0x5ec00000 lcdtype=1 consoleblank=0 lpcha'
ATAG_NONE: 0 0

Starting kernel at 0x40008000...

SWITCH_SEL(0)
Uncompressing Linux... done, booting the kernel.

AdamOutler · Dec 7, 2012

and here's one from download mode while flashing with Heimdall

Code:

: Entering usb mode for SCH-I605 (1)..
ddi type = 1, S.LSI
cmu_div:6, div:2, src_clk:880000000, pixel_clk:62614944
41, 16, a2, 
ODIN MODE
PRODUCT NAME: SCH-I605
CUSTOM BINARY DOWNLOAD: No
CURRENT BINARY: Samsung Official
SYSTEM STATUS: Official
Verify_Binary_Config_bin_sw:
Verify_Binary_Config_bin_sw: failed.
Download mode turn to AP_USB(4)board_set_dev_pm: hello! I'm USB.(1)
exynos4 usbd2 phy init
usb old tune = 0x2819b3
usb new tune = 0x2831b3
EP2: 0, 2, 0; len=7
EP2: 0, 2, 0; len=7
sug: IN EP asserted
Error:Invalid connection string!
Error:Invalid connection string!
: Entering usb mode for SCH-I605 (1)..
ddi type = 1, S.LSI
cmu_div:6, div:2, src_clk:880000000, pixel_clk:62614944
41, 16, a2, 
ODIN MODE
PRODUCT NAME: SCH-I605
CUSTOM BINARY DOWNLOAD: No
CURRENT BINARY: Samsung Official
SYSTEM STATUS: Official
Verify_Binary_Config_bin_sw:
Verify_Binary_Config_bin_sw: failed.
Download mode turn to AP_USB(4)board_set_dev_pm: hello! I'm USB.(1)
exynos4 usbd2 phy init
usb old tune = 0x2819b3
usb new tune = 0x2831b3
EP2: 0, 2, 0; len=7
EP2: 0, 2, 0; len=7
sug: IN EP asserted
Error:Invalid connection string!
Error:Invalid connection string!
: Entering usb mode for SCH-I605 (1)..
ddi type = 1, S.LSI
cmu_div:6, div:2, src_clk:880000000, pixel_clk:62614944
41, 16, a2, 
ODIN MODE
PRODUCT NAME: SCH-I605
CUSTOM BINARY DOWNLOAD: No
CURRENT BINARY: Samsung Official
SYSTEM STATUS: Official
Verify_Binary_Config_bin_sw:
Verify_Binary_Config_bin_sw: failed.
Download mode turn to AP_USB(4)board_set_dev_pm: hello! I'm USB.(1)
exynos4 usbd2 phy init
usb old tune = 0x2819b3
usb new tune = 0x2831b3
EP2: 0, 2, 0; len=7
EP2: 0, 2, 0; len=7
sug: IN EP asserted
Error:Invalid connection string!
Error:Invalid connection string!
- Odin is connected!
process_packet: id=100, data=0
process_packet: id=100, data=1
process_packet: id=100, data=2
microusb_get_attached_device: STATUS1:0x3f, 2:0x41
process_packet: id=102, data=3
pit_flash_binary: set dn fail flag..
START: 3989504 BLOCK: 4718592
high_capacity: 1
Capacity: 30777344
wait for erase done.
it can take serveral second.
.
pit_flash_binary: written. next sector=204800
process_packet: id=102, data=2
microusb_get_attached_device: STATUS1:0x3f, 2:0x41
process_packet: id=102, data=3

pit_flash_binary: written. next sector=409600
process_packet: id=102, data=2
microusb_get_attached_device: STATUS1:0x3f, 2:0x41
process_packet: id=102, data=3

pit_flash_binary: written. next sector=614400
process_packet: id=102, data=2
microusb_get_attached_device: STATUS1:0x3f, 2:0x41

................ a whole bunch more sectors..........

pit_flash_binary: written. next sector=2867200
process_packet: id=102, data=2
microusb_get_attached_device: STATUS1:0x3f, 2:0x41
process_packet: id=102, data=3

EXT4 binary write success.
pit_flash_binary: 'SYSTEM' is flashed fully.
process_packet: id=102, data=0
process_packet: id=102, data=2
microusb_get_attached_device: STATUS1:0x3f, 2:0x41
process_packet: id=102, data=3
Verify_Binary_Config_bin_sw:
Verify_Binary_Config_bin_sw: failed.
if_ddi_data: succeeded. (0:0x0)
- read_bl1
pit_check_signature (BOOT) valid.
if_ddi_data: succeeded. (0:0x0)
START: 106496 BLOCK: 16384
high_capacity: 1
Capacity: 30777344
wait for erase done.
it can take serveral second.
.
pit_flash_binary: 'BOOT' is flashed fully.
process_packet: id=102, data=0
process_packet: id=102, data=2
microusb_get_attached_device: STATUS1:0x3f, 2:0x41
process_packet: id=102, data=3
pit_flash_binary: new ustar param.
START: 90112 BLOCK: 16384
high_capacity: 1
Capacity: 30777344
wait for erase done.
it can take serveral second.
.read 'adv-env.img'(3624) completed.
PARAM ENV VERSION: v1.0..

pit_flash_binary: 'PARAM' is flashed fully.
process_packet: id=103, data=0
process_packet: id=103, data=1
s5p_restart_handler ('N':null)

AdamOutler · Dec 7, 2012

I don't really know what to make of this....

I was in stock firmware.. USB was plugged in. I held the key combination to reboot recovery and held it. it rebooted to "Unknown upload mode" . I continued to hold it and got into recovery with this USBID rapidly flashing but not really usable.

Code:

Bus 001 Device 100: ID 04e8:6860 Samsung Electronics Co., Ltd GT-I9100 Phone [Galaxy S II], GT-P7500 [Galaxy Tab 10.1]

But... here's the wierd part.. it was using the acellerometer instead of volume + and -.... So, i rebooted again and it kernel failed.... Ok, so then I removed the battery and replaced it, it booted fine.. Odd thing.. Maybe a security exploit in there somewhere...

Hashcode · Dec 7, 2012

Hi Guys,

There's a big difference between a "true" kexec and what the SG3 is doing using HARD_BOOT (which is kind of a patched device reset) to have the bootloader jump to a new unsigned kernel loaded into memory. The HARD_BOOT patch requires a modified recovery.img. But the end result is a perfectly booted unsigned kernel. Because the bootloader gets to run normally and set everything up as it should.

A true kexec requires nothing. You can literally execute it while fully booted into Android (not recommended.. should probably put all of the storage devices in read-only mode).

Most production kernels on our devices don't have the arm_kexec.ko module built (which contains the machine_kexec function and relocate_kernel code used by the kexec binary), but that's easy enough to write as an external module and insmod during boot. Also, it seems like ARM is a terrible platform for kexec. Compared to x86 which just works out of the box. On the Droid 3 we encounter all sorts of oddness post-kexec:
- CPU1 usually requires extra attention to bring back up and this can cause local timer issues later
- The modem requires a reset added into the driver.
- SAR memory mismatch between kernels needs to be accounted for (like from a 2.6 to a 3.0 kernel) -- this won't be as much of an issue with a new device like the Note 2.
- And even when it seems like you've done everything right, you still can have prcm issues which cause drivers to behave badly. We spent a lot of time "fixing" things which shouldn't have broken during kexec. And we still have issues which we're working through.

It's a grueling process which requires kernel devs with lower level hardware knowledge. I was VERY lucky to have the help of jonpry on the Droid 3. He basically worked through most of the major issues during the kexec bringup.

As to getting a locked bootloader recovery like Safestrap going:
I need to see the init.*.rc files for the device to determine a hijack during the boot which would allow for 2nd-init / recovery entry.

invisiblek · Dec 7, 2012

Hashcode said:
Hi Guys,

There's a big difference between a "true" kexec and what the SG3 is doing using HARD_BOOT (which is kind of a patched device reset) to have the bootloader jump to a new unsigned kernel loaded into memory. The HARD_BOOT patch requires a modified recovery.img. But the end result is a perfectly booted unsigned kernel. Because the bootloader gets to run normally and set everything up as it should.

A true kexec requires nothing. You can literally execute it while fully booted into Android (not recommended.. should probably put all of the storage devices in read-only mode).

Most production kernels on our devices don't have the arm_kexec.ko module built (which contains the machine_kexec function and relocate_kernel code used by the kexec binary), but that's easy enough to write as an external module and insmod during boot. Also, it seems like ARM is a terrible platform for kexec. Compared to x86 which just works out of the box. On the Droid 3 we encounter all sorts of oddness post-kexec:
- CPU1 usually requires extra attention to bring back up and this can cause local timer issues later
- The modem requires a reset added into the driver.
- SAR memory mismatch between kernels needs to be accounted for (like from a 2.6 to a 3.0 kernel) -- this won't be as much of an issue with a new device like the Note 2.
- And even when it seems like you've done everything right, you still can have prcm issues which cause drivers to behave badly. We spent a lot of time "fixing" things which shouldn't have broken during kexec. And we still have issues which we're working through.

It's a grueling process which requires kernel devs with lower level hardware knowledge. I was VERY lucky to have the help of jonpry on the Droid 3. He basically worked through most of the major issues during the kexec bringup.

As to getting a locked bootloader recovery like Safestrap going:
I need to see the init.*.rc files for the device to determine a hijack during the boot which would allow for 2nd-init / recovery entry.

Here is the entire ramdisk tar'd up for you
http://invisiblek.chickenkiller.com/ramdisk.tar

Also the boot.img if you need:
http://invisiblek.chickenkiller.com/boot.img

We shouldn't need to do anything with getting drivers or perfecting a kexec'd kernel, this would be a temporary thing in order to boot up and patch the bootloader. At that point (in theory) we should be able to properly flash anything we want.

EDIT: Also, I did attempt to compile kexec as a module, but failed miserably and didn't spend much time debugging the compiler errors. Samsung does have source posted for this too which you can get by searching for: i605
Here: http://opensource.samsung.com/

EDIT2: Also, vermagic:

Code:

$ modinfo btlock.ko
...
vermagic:       3.0.31-414933 SMP preempt mod_unload modversions ARMv7 p2v8
...

Believe we just need -414933 for EXTRAVERSION

droidstyle · Dec 7, 2012

Looks like Adam cracked it!

https://plus.google.com/10471104011...8q86k#104711040110222472212/posts/SjpMEC8q86k

WishRyder · Dec 7, 2012

droidstyle said:
Looks like Adam cracked it.

https://plus.google.com/10471104011...8q86k#104711040110222472212/posts/SjpMEC8q86k

Not that it's not a significant accomplishment, but is that the hardware mod he was talking about? There's only a small minority of users willing to take it to the hardware level to flash. Heck, a large number of people are worried about a simple ODIN flash.

Edit: Sorry, I'm not a developer. I got linked around and didn't realize where I ended up.

suzook · Dec 7, 2012

WishRyder said:
Not that it's not a significant accomplishment, but is that the hardware mod he was talking about? There's only a small minority of users willing to take it to the hardware level to flash. Heck, a large number of people are worried about a simple ODIN flash.

That's true. Good question.

Goal: Destroy SBOOT

Inactive Recognized Developer

Retired Senior Recognized Developer

Recognized Developer

Senior Member

Recognized Developer

Senior Member

Senior Member

Senior Member

Inactive Recognized Developer

Inactive Recognized Developer

Senior Member

Recognized Developer

Retired Senior Recognized Developer

Retired Senior Recognized Developer

Retired Senior Recognized Developer

Senior Recognized Developer

Recognized Developer

Inactive Recognized Contributor

Senior Member

Senior Member

Similar threads

Top Liked Posts