Goal: Destroy SBOOT

[AdamOutler]

Hey guys. As the title states, we need to destroy SBOOT to leave the device in an otherwise "hard-bricked" state. This would open the door to loading an insecure bootloader. Currently our option is to perform a hardware hack to brick the device which is obviously not optimal...

So, the question is, how can I write some garbage like a Justin Beiber MP3 over the SBOOT?

If you've come up with a way to hard-brick this device, it would be very helpful if you share.

 

[AdamOutler]

Has anyone researched K-Exec on the VZW Galaxy Note2?

This change (Pointed out by XDA Recognized Developer Ralekdev) to Cyanogenmod by XDA Elite Recognized Developer Entropy512, implemented in a kernel, booted into a kexec, could expose the /dev/block/mmcblk0boot0. https://github.com/CyanogenMod/andr...4702bde8fb2a7ea082c5b385ee0911e3f86307#diff-0 We need access to this partition to be able to destroy it. I'm not a kernel developer though. I need some help with this.

 

[BeansTown106]

Has anyone researched K-Exec on the VZW Galaxy Note2?

This change (Pointed out by XDA Recognized Developer Ralekdev) to Cyanogenmod by XDA Elite Recognized Developer Entropy512, implemented in a kernel, booted into a kexec, could expose the /dev/block/mmcblk0boot0. https://github.com/CyanogenMod/andr...4702bde8fb2a7ea082c5b385ee0911e3f86307#diff-0 We need access to this partition to be able to destroy it. I'm not a kernel developer though. I need some help with this.

i can link u to a kernel but from what i know no one has looked into kexec yet.. also did u mean to put this in international forum or verizon one cause were in international now not verizon

 

[BlueHarford]

Has anyone researched K-Exec on the VZW Galaxy Note2?

This change (Pointed out by XDA Recognized Developer Ralekdev) to Cyanogenmod by XDA Elite Recognized Developer Entropy512, implemented in a kernel, booted into a kexec, could expose the /dev/block/mmcblk0boot0. https://github.com/CyanogenMod/andr...4702bde8fb2a7ea082c5b385ee0911e3f86307#diff-0 We need access to this partition to be able to destroy it. I'm not a kernel developer though. I need some help with this.

Add me on gtalk I have a guy on my team that's a kernel guru I'm sure he can get done anything you need, I'll reply with his gtalk info

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

 

[garyd9]

cause were in international now not verizon

There's currently only one dev discussion section shared among all the Note2 devices.

Adam, I haven't messed with kexec, and my schedule is a bit nightmarish until the new year... If no one has come up with something by then, I'll (try to remember to) work on it then.

take care
Gary

 

[BlueHarford]

bbedward is building a kernel right now. Adam i will PM you his gtalk

 

[bbedward]

http://goo.im/devs/bbedward/vzwnote2_image.zip

There's a stock note 2 kernel build, it includes this and is stock otherwise except for some gcc 4.7 fixes https://github.com/CyanogenMod/andr...4702bde8fb2a7ea082c5b385ee0911e3f86307#diff-0

Maybe it'll help somebody if they get kexec working :good:

 

[iamsamiam]

/dev/block/mmcblk0boot0 <---- this is the sboot block?

 

[invisiblek]

You can't flash a custom boot.img (ytod)
You can't flash a custom recovery.img (ytod)

Without either of those, I don't know that you can get kexec working.
If I remember correctly, you needed a kexec-enabled recovery in order to hardboot a different kernel (of which did NOT need to be kexec-enabled).
So you would already have to have a kexec-enabled kernel running in order to do this, and if we could do this we could just include that patch anyway.

Might be able to do some some crafty stuff with 2nd init, beyond me, I've never messed with this. Hashcode might be of some help here.

But will this allow booting a different kernel? That's your main obstacle here.

Not sure if its possible to build block as a module with that patch that adam listed and force load it on a rooted device.
(I'm pretty sure this wouldn't work since its built into the kernel already, even if you could it would probably panic, and on the off chance it did load, would mmcblk0boot0/1 even show up? doubtful...)

/dev/block/mmcblk0boot0 <---- this is the sboot block?

yes

 

[droidstyle]

You can't flash a custom boot.img (ytod)
You can't flash a custom recovery.img (ytod)

Without either of those, I don't know that you can get kexec working.
If I remember correctly, you needed a kexec-enabled recovery in order to hardboot a different kernel (of which did NOT need to be kexec-enabled).
So you would already have to have a kexec-enabled kernel running in order to do this, and if we could do this we could just include that patch anyway.

Might be able to do some some crafty stuff with 2nd init, beyond me, I've never messed with this. Hashcode might be of some help here.

But will this allow booting a different kernel? That's your main obstacle here.

Not sure if its possible to build block as a module with that patch that adam listed and force load it on a rooted device.
(I'm pretty sure this wouldn't work since its built into the kernel already, even if you could it would probably panic, and on the off chance it did load, would mmcblk0boot0/1 even show up? doubtful...)



yes

this was my thinking aswell...kexec will only work if we can flash a custom recovery.img, but since sboot checks the recovery partition, nothing custom can be flashed to it. aboot on the vzw s3 didnt check the recovery partition which left a hole to get in and use kexec.

 

[iamsamiam]

this was my thinking aswell...kexec will only work if we can flash a custom recovery.img, but since sboot checks the recovery partition, nothing custom can be flashed to it. aboot on the vzw s3 didnt check the recovery partition which left a hole to get in and use kexec.

probably out of my scope but..... sboot checks the recovery partition at STARTUP (i would guess its the first thing checked, since when i soft bricked mine it wouldnt do ANYTHING but tell me the software is not genuine, any way we could inject(probably not the right word) it after the check?

 

[invisiblek]

Not sure if its possible to build block as a module with that patch that adam listed and force load it on a rooted device.
(I'm pretty sure this wouldn't work since its built into the kernel already, even if you could it would probably panic, and on the off chance it did load, would mmcblk0boot0/1 even show up? doubtful...)

FYI guys this didn't work
Error was something about "exports duplicate symbol....(owned by kernel)"
Found it funny I got "owned by the kernel", but w/e...

Here's the module in case anyone wants to mess around with it, dmesg is where the error appears
http://invisiblek.chickenkiller.com/mmc_block.ko

Pretty sure there is no way to get this loaded, but the steps to do so would be:
- throw it in /lib/modules (this is non-persistent)
- chmod it to at least 644
- busybox modprobe -f mmc_block

 

[Entropy512]

While this is mostly specific to the Verizon variant, being able to kill SBOOT to force SD-card boot is a technique that would be usable on multiple devices in the future.

Pretty much it's that the VZW Note2 NEEDS the ability to kill SBOOT starting from a stock kernel without anything beyond root, but it may be useful on other devices too.

And if people are wondering why we're TRYING to hardbrick a device - if you hardbrick by killing SBOOT, the device falls back to booting from the SD. Samsung's "official" hardbrick recovery technique does this by shorting a resistor to disable the eMMC.

The key is whether there is some way to access mmcblk0boot0 from a stock kernel... So far, no one has ever done it without hacking the kernel itself to my knowledge.

 

[E:V:A]

...The key is whether there is some way to access mmcblk0boot0 from a stock kernel... So far, no one has ever done it without hacking the kernel itself to my knowledge.

I don't understand what prevents access to mmcblk0boot0 (and like) partitions, in the first place. (?) Any insight you care to share? Only thing I could suggest is to have a look at these mmc tools, in various repositories, although very similar, if not identical.

http://patches.linaro.org/project/linux-mmc/
http://git.kernel.org/?p=linux/kernel/git/cjb/mmc.git;a=summary
https://kernel.googlesource.com/pub/scm/linux/kernel/git/cjb/mmc-utils/

In fact, the problem of being able to fully access eMMC devices, is understated. It would have great benefits for the developer community to things ranging from removing partition write protections to unbricking TV sets...

Found in:
[linux/kernel/git/cjb/mmc.git] / Documentation / mmc / mmc-dev-parts.txt
from first link:

SD and MMC Device Partitions
============================

Device partitions are additional logical block devices present on the
SD/MMC device.

As of this writing, MMC boot partitions as supported and exposed as
/dev/mmcblkXboot0 and /dev/mmcblkXboot1, where X is the index of the
parent /dev/mmcblkX.

MMC Boot Partitions
===================

Read and write access is provided to the two MMC boot partitions. Due to
the sensitive nature of the boot partition contents, which often store
a bootloader or bootloader configuration tables crucial to booting the
platform, write access is disabled by default to reduce the chance of
accidental bricking.

To enable write access to /dev/mmcblkXbootY, disable the forced read-only
access with:

[B]echo 0 > /sys/block/mmcblkXbootY/force_ro[/B]

To re-enable read-only access:

[B]echo 1 > /sys/block/mmcblkXbootY/force_ro[/B]

The boot partitions can also be locked read only until the next power on,
with:

[B]echo 1 > /sys/block/mmcblkXbootY/ro_lock_until_next_power_on
[/B]
This is a feature of the card and not of the kernel. If the card does
not support boot partition locking, the file will not exist. If the
feature has been disabled on the card, the file will be read-only.

The boot partitions can also be locked permanently, but this feature is
not accessible through sysfs in order to avoid accidental or malicious
bricking.

The code we need to modify is probably that of the 3rd link (above), in mmc_cmds.c (and related). But I'm not sure it's possible to use this to disable write protect, although it seem like here:

[SIZE=2]...
/*
 * EXT_CSD field definitions
 */
#define EXT_CSD_HPI_SUPP                (1<<0)
#define EXT_CSD_HPI_IMPL                (1<<1)
#define EXT_CSD_CMD_SET_NORMAL          (1<<0)
[COLOR=Red][B]#define EXT_CSD_BOOT_WP_B_PWR_WP_DIS    (0x40)
#define EXT_CSD_BOOT_WP_B_PERM_WP_DIS   (0x10)[/B][/COLOR]
#define EXT_CSD_BOOT_WP_B_PERM_WP_EN    (0x04)
#define EXT_CSD_BOOT_WP_B_PWR_WP_EN     (0x01)
#define EXT_CSD_BOOT_INFO_HS_MODE       (1<<2)
#define EXT_CSD_BOOT_INFO_DDR_DDR       (1<<1)
#define EXT_CSD_BOOT_INFO_ALT           (1<<0)
#define EXT_CSD_BOOT_CFG_ACK            (1<<6)
#define EXT_CSD_BOOT_CFG_EN             (0x38)
#define EXT_CSD_BOOT_CFG_ACC            (0x03)
#define EXT_CSD_RST_N_EN_MASK           (0x03)
#define EXT_CSD_HW_RESET_EN             (0x01)
#define EXT_CSD_HW_RESET_DIS            (0x02)
#define EXT_CSD_PART_CONFIG_ACC_MASK      (0x7)
#define EXT_CSD_PART_CONFIG_ACC_BOOT0     (0x1)
#define EXT_CSD_PART_CONFIG_ACC_BOOT1     (0x2)
#define EXT_CSD_PART_CONFIG_ACC_USER_AREA (0x7)
#define EXT_CSD_PART_CONFIG_ACC_ACK       (0x40)
[SIZE=2]...[/SIZE]
[/SIZE]

[mmc.h]

 

[kirch21]

I have a t-mobile Note 2 and I was messing around with the *#197328649# menu and found these in UMTS, Version Information, secure boot status.

Secure VAL: 4369
SEC_BOOT:1
OEM_PK_HASH:1
SEC_HW_KEY:1
OEM_CONFIG:1


Like I said may or may not help but seeing secure boot made me think of you guys.


Sent from my handheld Android 'PC', NOTE II

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

 

[Loglud]

You can't flash a custom boot.img (ytod)
You can't flash a custom recovery.img (ytod)

Without either of those, I don't know that you can get kexec working.
If I remember correctly, you needed a kexec-enabled recovery in order to hardboot a different kernel (of which did NOT need to be kexec-enabled).
So you would already have to have a kexec-enabled kernel running in order to do this, and if we could do this we could just include that patch anyway.

Might be able to do some some crafty stuff with 2nd init, beyond me, I've never messed with this. Hashcode might be of some help here.

But will this allow booting a different kernel? That's your main obstacle here.

Not sure if its possible to build block as a module with that patch that adam listed and force load it on a rooted device.
(I'm pretty sure this wouldn't work since its built into the kernel already, even if you could it would probably panic, and on the off chance it did load, would mmcblk0boot0/1 even show up? doubtful...)



yes

So I think people have a misconception of what kexec is.

kexec is a system call that enables you to load and boot into another kernel from the currently running kernel.

Here

Yes there was orignally a kexec for the SGSIII that was issued in the recovery partition but this is not what kexec does. IT LOAD A KERNEL DIRECTLY ONTOP OF THE CURRENT. It does not access memory. It does not change any of the partitions, and it does not make it so that phone will not be "secure" for booting. It does not require any access to the recovery partition and does not need kexec-enabled in the kernel necessarily. When you enable kexec in the kernel, all you do is provide a handle for the actual binary so it knows where in the stack to replace the kernel. Without this you must write in your own kexec injection vectors, and this can be difficult, but has been done for devices before (see nook tablet). There's no doubt in my mind that this would be an incredibly daunting task, however if someone did it, it might prove usefull for every device in existence that has a locked bootloader.

As for the topic at hand. To what I have scene and read here it sounds like the default kernel does not allow you to access the mmcblk0, which is kinda a pain. Though it might only not allow you to do this by name. I wonder if you overloaded partition table if it would start to bleed into the first block. Or if we can write a program that references the memory by location instead of by pointer, aka 0x81000000 instead of mmcblk0. Also you might want to dump the system kernel in the recovery or any other bootable mode. It is possible that its only on the system image kernel that it blocks this. IE boot into recover mode and or download mode and see if that subspace can be accessed. As a last resort adam you might be able to boot it into panic mode with the boot pins. I havent been able to find a diagram, but it is always possable to brick the device with pins, which ones are beyond me though i found this. Unfortunately no mention of boot conditions anywhere there.

 

[times_infinity]

I wonder if something like bootstrap or safe strap could be implemented to try and boot a kexec kernel with a custom recovery so that mmcblk0boot0 gets exposed.

Sent from my Amazon Kindle Fire using xda app-developers app

 

[chayes627]

I wonder if something like bootstrap or safe strap could be implemented to try and boot a kexec kernel with a custom recovery so that mmcblk0boot0 gets exposed.

Sent from my Amazon Kindle Fire using xda app-developers app

I have recommended to Adam to talk to Hashcode as he did some creative things with the Droid 3 and kexec and custom recovery.

 

[times_infinity]

I have recommended to Adam to talk to Hashcode as he did some creative things with the Droid 3 and kexec and custom recovery.

Exactly who i was thinking of when i wrote that post.

Sent from my Galaxy Nexus using xda app-developers app

 

[kejar31]

I hit up hash on gtalk today and pointed him to this thread.. Seems at least we should be able to get a hacked recovery working like safe-strap. Then again I am no recovery nor kernel dev