Related
Hi,
From what I've gathered (and please correct me if I'm wrong), Motorola has locked down their devices by requiring you to sign any replacement kernel with a secret key. This process is enforced by their bootloading code.
We can't replace the bootloader or the kernel without this key, but we do have root access to the Defy. Would it not be possible to write a kernel module, and load it using insmod on a rooted phone? Is insmod available on Android?
This kernel module would then run in kernel mode, and should thus have access to any and all features of the processor and the entire memory space, right? Can't this be used to load a different kernel into memory, reconfigure the MMU to put it at the appropriate memory address, and then have the phone boot the new kernel?
The limited modding that has been done on the Defy and the uncertainty about upgrades down the road are the only thing that keep me from buying it..
Never mind, apparently this is what http://freemymoto.com/tiki-index.php does, so not only is it possible, it's already been done.
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.
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.
AdamOutler said:
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.
Click to expand...
Click to collapse
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
AdamOutler said:
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.
Click to expand...
Click to collapse
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
beanstown106 said:
cause were in international now not verizon
Click to expand...
Click to collapse
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
bbedward is building a kernel right now. Adam i will PM you his gtalk
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:
/dev/block/mmcblk0boot0 <---- this is the sboot block?
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...)
iamsamiam said:
/dev/block/mmcblk0boot0 <---- this is the sboot block?
Click to expand...
Click to collapse
yes
invisiblek said:
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
Click to expand...
Click to collapse
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.
droidstyle said:
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.
Click to expand...
Click to collapse
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 said:
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...)
Click to expand...
Click to collapse
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
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.
Entropy512 said:
...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.
Click to expand...
Click to collapse
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:
Code:
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:
Code:
[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]
_Dennis_ said:
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
Click to expand...
Click to collapse
guy posted this in the rom thread, posting it here to.. i also have no idea what it is but cant hurt right? lol
invisiblek said:
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
Click to expand...
Click to collapse
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.
Click to expand...
Click to collapse
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.
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
times_infinity said:
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
Click to expand...
Click to collapse
I have recommended to Adam to talk to Hashcode as he did some creative things with the Droid 3 and kexec and custom recovery.
chayes627 said:
I have recommended to Adam to talk to Hashcode as he did some creative things with the Droid 3 and kexec and custom recovery.
Click to expand...
Click to collapse
Exactly who i was thinking of when i wrote that post.
Sent from my Galaxy Nexus using xda app-developers app
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
Hey guys I already posted this in a few kernel devs threads but I wanted to create this thread so I can share my info more easily with all the people out there.
What I found is some leftovers of knox on the ramdisk of nearly all the kernels out there - and possibilities to get rid of some more clutter.
There is this init.container.rc file which gets called from the init.rc who's job is to set up the mount points and some symlinks etc. for knox (just take a look at it). It also contains a service called "containersetup" and which's binary is located in /system/bin/containersetup.
I dont 100% know what this containersetup thingy does - but I just renamed the binary to stop it from running with no negative side-effects at all.
Disabling/removing the init.container.rc would also get rid of those reappearing data_1, data_2, data_3 etc. folders which get created by it.
---
This one is not particulary interesting for kernel devs I think, but I also found some other binaries that are or at least appear to be rather useless:
- there is "tima_dump_log" which creates some dumps related to tima on the data partition (possibly for the knox watchdog crap) - disabled that without side effects so far.
- there is "auditd" which is the audit daemon, which logs security related stuff (wether selinux allowed or disallowed stuff etc) - also disabled without side effects.
could possibly find some more.. (bootchecker, drsservice etc.. but not 100% sure on those)
P.S: Why don't you all include init.d support into the kernel? Just wondering, no attack (hard to tell in the internet hehe). Isn't that standard on linux kernel or is it a special feature which normally gets handled by the operating system / rom? (I know how to activate init.d support myself... well its not that hard.. but still wondering lol, because when switching kernels I always have to try and test if the kernel includes init.d support so scripts dont get run twice... some do some don't ...)
Just cooked my "own" custom version of faux123 v004 with the android image kitchen. (http://forum.xda-developers.com/showthread.php?t=2073775)
Removed the init.container.rc
Removed the call to init.container.rc inside init.rc
Edited the fstab.qcom to change system partitions mount flags to "ro,noatime,noauto_da_alloc,discard,journal_async_commit,errors=panic"
(you could also add init.d support to init.rc, but I already got that in my install-recovery.sh..)
--
Repacked everything together and flashed it onto my phone. This got rid of the container folders and data_1,data_2,data_3,mnt_1, etc. plus the mount "tweaks".
Unfortunately I cannot redistribute the kernel image with the modified ramdisk (its not my work, i just edited it a tiny bit...), but with the android image kitchen you can just do it yourself - until the kernel devs include this into their kernels as well. (might not be important to you guys, but I like my phone clutter free hehe)
---
ADD: By the way - this android image kitchen is awesome! I was trying to do this stuff with other versions of kernel repack tools - which are mostly made for linux. But the resulting kernels were not working. (the addresses used are not standard, and one would have had to edit the mkbootimg.c and recompile it himself to do it... but with this thing its just idiot-safe drag n drop. Just make sure you dont do any bullcrap on the ramdisk partition..
ADD2: Does anyone know how I could completely disable selinux (not just permissive, but completely turning it off)? I know it might missbehave, but I want to give it a try. The mount script already has the option to mount the firmware partition context free for the case that se-linux is disabled - so it must be possible somehow right? (what benefit does selinux give you anyway in permissive mode other than a possible nsa backdoor or smth?)
Awesome
Enviado do meu SM-N9005 através de Tapatalk
with selinux=permissive you can also deactivate the samsung drs service (this thing handles context labeling as it appears).
It consists of an app called "drsservice" and the binary /system/bin/drs. Can/could been disabled on selinux=enforcing too, but then you needed to do restorecon yourself on some occurences.
--
so on my device I disabled the following services/binaries (please lets try to find more together ...):
/system/bin/containersetup
/system/bin/auditd
/system/bin/tima_dump_log
/system/bin/kiesexe
/system/bin/drs
---
What I would like to manage (if possible) to disable the watchdog daemon and all that bullcrap that checks if the device was tempered (the watchdog daemon is related to knox right?)
zroice said:
Just cooked my "own" custom version of faux123 v004 with the android image kitchen. (http://forum.xda-developers.com/showthread.php?t=2073775)
Removed the init.container.rc
Removed the call to init.container.rc inside init.rc
Edited the fstab.qcom to change system partitions mount flags to "ro,noatime,noauto_da_alloc,discard,journal_async_commit,errors=panic"
(you could also add init.d support to init.rc, but I already got that in my install-recovery.sh..)
--
Repacked everything together and flashed it onto my phone. This got rid of the container folders and data_1,data_2,data_3,mnt_1, etc. plus the mount "tweaks".
Unfortunately I cannot redistribute the kernel image with the modified ramdisk (its not my work, i just edited it a tiny bit...), but with the android image kitchen you can just do it yourself - until the kernel devs include this into their kernels as well. (might not be important to you guys, but I like my phone clutter free hehe)
---
ADD: By the way - this android image kitchen is awesome! I was trying to do this stuff with other versions of kernel repack tools - which are mostly made for linux. But the resulting kernels were not working. (the addresses used are not standard, and one would have had to edit the mkbootimg.c and recompile it himself to do it... but with this thing its just idiot-safe drag n drop. Just make sure you dont do any bullcrap on the ramdisk partition..
ADD2: Does anyone know how I could completely disable selinux (not just permissive, but completely turning it off)? I know it might missbehave, but I want to give it a try. The mount script already has the option to mount the firmware partition context free for the case that se-linux is disabled - so it must be possible somehow right? (what benefit does selinux give you anyway in permissive mode other than a possible nsa backdoor or smth?)
Click to expand...
Click to collapse
I followed the link to the Android Image Kitchen and successfully followed your instructions from post #2 but I was wondering if you could please let me know of a good place to find some kernel tutorials for absolute beginners? Thank you for your information as well.
@zroice: Maybe you're already thinking about doing a free rom of Knox
Silverbolt said:
I followed the link to the Android Image Kitchen and successfully followed your instructions from post #2 but I was wondering if you could please let me know of a good place to find some kernel tutorials for absolute beginners? Thank you for your information as well.
Click to expand...
Click to collapse
not sure really, this was just basic scripting and editing the boot scripts, and I just found this out by playing around with the things.
I'm sure you will find a tutorial or smth on xda or google. I have yet to compile anything for android.. so I dont have a clue.
Just sharing my findings and hoping for some interesting replies what other people find out.
what about those data_x folders in a stock image?
Hi!
I've encountered these data_1 data_2 & data_3 on my stock note 3. Is there a way to remove them?
Ibe been looking for a way to remove these processes. I dont have any knox or container agents on my phone nor doea the kt747 kernel have selinux enforcing but I do see these leftovers running around. I found this thread by searching how to disable the tima log. There doeant seem to be much info about this available anywhere. I do se something else running that I suspect is a waste is called edmaudit. I suspect is enterprise device management. Not sure tho. I changed the permissions on the files you mentioned. I know its been a year but if you happen to have any new insight on thos I'd appreciate it.
I'm trying to make use of my D6603's framebuffer. As I understand it, I should be able (as root) to run "cat /dev/urandom > /dev/graphics/fb0" to pump random binary into the framebuffer, which should result in random pixel color changes occurring on my screen. Doing so appears to work just fine, but I get no output. I am not at all an expert--the best I can assume is that the stock kernel (I'm running rooted stock 23.0.1.A.5.77) somehow fails to provide framebuffer access, and that all attempts are therefore destined to fail. This seems odd though, since if it's using the framebuffer, how could there be no way to input into it given root access?
Question 1: Is this correct, or is there some way to use the framebuffer on the stock ROM?
Question 2: If not, is there a modified stock kernel that will work? As I understand it any modified kernel will prevent my DRM from working, and so maybe there's no point in asking this, and I ought to be asking whether any kernel with any rom will work?
I have a Samsung A535w which doesn't have OEM unlock enabled so I can't unlock the bootloader and thus I can't get Root.
Is it possible to use a man in the middle attack to hijack an update to enable the option?
Alternatively, can I install a rootkit to do a similar thing?
Are either of these even theoretically possible?
I read about rootkits coming from apps in the PlayStore all the time.
Does the bootloader need to be unlocked to do this?
Ignore the implicit dangers of this and assume that I am going to craft the attack updates myself.
opticyclic said:
I have a Samsung A535w which doesn't have OEM unlock enabled so I can't unlock the bootloader and thus I can't get Root.
Is it possible to use a man in the middle attack to hijack an update to enable the option?
Alternatively, can I install a rootkit to do a similar thing?
Are either of these even theoretically possible?
I read about rootkits coming from apps in the PlayStore all the time.
Does the bootloader need to be unlocked to do this?
Ignore the implicit dangers of this and assume that I am going to craft the attack updates myself.
Click to expand...
Click to collapse
hello, i cannot find any info on this device, is the processor mtk, qcom, or exynos
To root a phone's Android it's never needed to unlock phone's bootloader: this is a fairy tale which is told hundreds of times here and elsewhere.
opticyclic said:
I have a Samsung A535w which doesn't have OEM unlock enabled so I can't unlock the bootloader and thus I can't get Root.
Is it possible to use a man in the middle attack to hijack an update to enable the option?
Alternatively, can I install a rootkit to do a similar thing?
Are either of these even theoretically possible?
I read about rootkits coming from apps in the PlayStore all the time.
Does the bootloader need to be unlocked to do this?
Ignore the implicit dangers of this and assume that I am going to craft the attack updates myself.
Click to expand...
Click to collapse
Assuming the OEM uses the AOSP model (which Samsung doesn't), no.
Hardware backed Keystore
SELinux
Trusty
Android Verified Boot
All of these work together.
When the bootloader is locked, the boot image is verified (using a cryptographic hash signed by the hardware keystore, which is itself verified) to determine its integrity. This prevents persistent rootkits.
During run time, SELinux enforces access control over all processes, even those with root privileges.
Trusty is a completely separate and isolated secure environment that runs alongside the Android kernel and is used as a "trusted verifier"
And this isn't even getting into the security features implemented in the update process.
For this attack vector you're describing to work, you would have to have the OEM's private and proprietary key used to sign everything in the update package, otherwise an unsigned or incorrectly signed package will be rejected. And even if you did manage to sign the update package, you'd have to essentially reprogram the hardware keys to match, because even if the update flashed to the device, all the images would fail verification because of the hardware keystore authentication.
xXx yYy said:
To root a phone's Android it's never needed to unlock phone's bootloader: this is a fairy tale which is told hundreds of times here and elsewhere.
Click to expand...
Click to collapse
Source?
How do you get elevated permissions in a protected environment without compromising the boot image, which would make the device fail to boot?
V0latyle said:
Source?
How do you get elevated permissions in a protected environment without compromising the boot image, which would make the device fail to boot?
Click to expand...
Click to collapse
You probably don't know how rooting Android is accomplished: no elevated permissions are needed to run SU binary.
xXx yYy said:
You probably don't know how rooting Android is accomplished: no elevated permissions are needed to run SU binary.
Click to expand...
Click to collapse
Explain?
$cronos_ said:
hello, i cannot find any info on this device, is the processor mtk, qcom, or exynos
Click to expand...
Click to collapse
Samsung Galaxy A53 5G - Full phone specifications
www.gsmarena.com
Although it says exynos on that page, I believe this is a Snapdragon as it has the W suffix on the model and as I am in Canada it looks to be the US version.
PSA: There is No OEM Unlock on US Galaxy A53's
Whether you get a carrier version or the factory unlocked U1 model, OEM unlock does not exist on this phone. So those in the US that were thinking of doing custom roms with this cheap new Android device, look elsewhere.
forum.xda-developers.com
V0latyle said:
Assuming the OEM uses the AOSP model (which Samsung doesn't), no.
Hardware backed Keystore
SELinux
Trusty
Android Verified Boot
All of these work together.
When the bootloader is locked, the boot image is verified (using a cryptographic hash signed by the hardware keystore, which is itself verified) to determine its integrity. This prevents persistent rootkits.
During run time, SELinux enforces access control over all processes, even those with root privileges.
Trusty is a completely separate and isolated secure environment that runs alongside the Android kernel and is used as a "trusted verifier"
And this isn't even getting into the security features implemented in the update process.
For this attack vector you're describing to work, you would have to have the OEM's private and proprietary key used to sign everything in the update package, otherwise an unsigned or incorrectly signed package will be rejected. And even if you did manage to sign the update package, you'd have to essentially reprogram the hardware keys to match, because even if the update flashed to the device, all the images would fail verification because of the hardware keystore authentication.
Click to expand...
Click to collapse
Thanks for the info.
@pndwal since you're much more knowledgeable on this topic than I, care to jump in here?
V0latyle said:
@pndwal since you're much more knowledgeable on this topic than I, care to jump in here?
Click to expand...
Click to collapse
Topic of temp root etc using vulns / exploits?; All I know is from reading...
This 'Deployment' developer doc was removed in January but mentioned Magisk deployment via exploits:
https://github.com/topjohnwu/Magisk...62964e41201b9f157923b/docs/deploy.md#exploits
I believe this temp MagiskSU from such a root shell can then often be used to flash/obtain full-fleged Magisk root...
Exploit / vulnerability based root certainly has benefits, one of which is ease of properly (and fully) bypassing device integrity attestations since kernel can be modified while bootloader remains locked... John commented here (and on future potential):
www.twitter.com/topjohnwu/status/1299903496028790785
... Doubt he'll be elaborating on this any more somehow...
There may not be many useful exploits for root due to security research, pen testing, patching, anti rollback etc... Here's a recent one that can be leveraged for Pixel 6; POC here:
https://github.com/polygraphene/DirtyPipe-Android
... This is already patched from 2022-04-05...
Could be used for Realme GT2 Pro, some Galaxy S22 models, others(?)... The process notes may be enlightening: https://github.com/polygraphene/DirtyPipe-Android/blob/master/TECHNICAL-DETAILS.md#exploit-process
XDA article re. 'infamous "Dirty Pipe" vulnerability can be exploited on the Samsung Galaxy S22 and the Google Pixel 6 Pro to gain root shell access':
https://www.xda-developers.com/tag/root-exploit/
This vuln caused a minor furore over Google anti-rollback w/ A13 update etc... Ex XDA editor Mishael commented:
www.twitter.com/MishaalRahman/status/1511036735433715719
Johns here:
www.twitter.com/topjohnwu/status/1511107456566390785
... I want "MagiPipe" One-Click Root app w/ the rainbow Magikarp icon!
Further:
www.twitter.com/topjohnwu/status/1559786740050644992
And Shawn Willden on patching, anti-rollback counters etc here:
www.twitter.com/shawnwillden/status/1559893884120928256
Older 'Linux Kernel bug dubbed 'Dirty Cow' can Root every version of Android' article by Mishael:
https://www.xda-developers.com/9-ye...-dirty-cow-can-root-every-version-of-android/
PW
V0latyle said:
Assuming the OEM uses the AOSP model (which Samsung doesn't), no.
Click to expand...
Click to collapse
...
Please can you explain what you mean here?... I understood '(AOSP) is the bedrock of modern Android skins like One UI and MIUI'...
https://www.androidauthority.com/aosp-explained-1093505/
Is this wrong?...
Can't see how even heavy OEM Android OS skins would make a difference to OEM unlock (or even using a root kit hypothetically)... Aren't unlock options etc determined by OEMs and re-sellers?...
And user does have Samsung device anyway... PW
pndwal said:
...
Please can you explain what you mean here?... I understood '(AOSP) is the bedrock of modern Android skins like One UI and MIUI'...
https://www.androidauthority.com/aosp-explained-1093505/
Is this wrong?...
Can't see how even heavy OEM Android OS skins would make a difference to OEM unlock (or even using a root kit hypothetically)... Aren't unlock options etc determined by OEMs and re-sellers?...
And user does have Samsung device anyway... PW
Click to expand...
Click to collapse
What I mean is whether Samsung follows the same Android security model, with verified boot, dm-verity, and so on. They do have security features implemented to prevent unsigned binaries (even if the bootloader is unlocked) but they also add a lot of their own stuff like Knox and Vaultkeeper. Either way, it would be difficult for a rootkit to persist after reboot because of these security features.
My understanding of OneUI is that it's not just a reskin/overlay but it also changes a lot of the core components as well. I could be wrong.
V0latyle said:
What I mean is whether Samsung follows the same Android security model, with verified boot, dm-verity, and so on.
Click to expand...
Click to collapse
Of course they do... AVB (ie Verified Boot 2.0) is mandated for any Android 8+ certified implementation...
An AOSP-compatible device must conform to the list of requirements in the Compatibility Definition Document (CDD). An Android-compatible device must conform to the list of requirements in the CDD and Vendor Software Requirements (VSR) and tests such as those in the Vendor Test Suite (VTS) and Compatability Test Suite (CTS).
Click to expand...
Click to collapse
https://source.android.com/docs/core/architecture#hidl
Eg. CCD:
https://source.android.com/docs/compatibility/cdd
see 9.9.2. File Based Encryption:
[C-1-4] MUST support Verified Boot and ensure that DE keys are cryptographically bound to the device's hardware root of trust. etc...
https://source.android.com/docs/compatibility/8.0/android-8.0-cdd
device-mapper-verity (dm-verity) is simply a kernel feature used since A 4.4 to implement Verified Boot...
V0latyle said:
They do have security features implemented to prevent unsigned binaries (even if the bootloader is unlocked) but they also add a lot of their own stuff like Knox and Vaultkeeper.
Click to expand...
Click to collapse
Sure; and MIUI adds Xiaomi Security Centre...
OEMs can add what they like as long as they comply with the CDD and VSR incl VTS and CTS...
V0latyle said:
Either way, it would be difficult for a rootkit to persist after reboot because of these security features.
Click to expand...
Click to collapse
Well maybe...
I'm unaware of any special safeguards against root whether userspace based or exploit based personally...
V0latyle said:
My understanding of OneUI is that it's not just a reskin/overlay but it also changes a lot of the core components as well. I could be wrong.
Click to expand...
Click to collapse
Well Android skins are necessarily software tweaks that live on top of stock Android; "They often look very different and offer features that other skins don't. In other words, underneath all the additional design and functionality tweaks, the core version of Android is on all Android devices." More on this here:
https://www.androidauthority.com/android-skins-945375/
Also these can't change security requirements for API/SDK level compliance... There is lattitude for OEMs to use their own components, but this is of course costly; Eg OEMs are free to implement their own TEE OS instead of Google's Trusty TEE, but most use Trusty as it's free and works fine!... PW
All very interesting. Thanks.
I remember using Dirty Cow to root a previous device.
My first phone was the Samsung Galaxy Nexus and after that I used several Chinese brands and got root on everything.
Because of the popularity of Samsung I assumed that root would be available.