Database Info

Goal: Destroy SBOOT

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

[ROM][Development] NEC Terrain custom ROM

Hello!
This is a development thread for those who is ready to contribute to the creation of a custom ROM for NEC Terrain.
The prior steps, which are bootloader unlock, rooting and even repartitioning have found their solutions and can be found in:
http://forum.xda-developers.com/showthread.php?t=2515602 for the discussion
https://github.com/x29a/nec_terrain_root for an apk which opens for you an ability to have the system area of the phone writeable
https://github.com/alex-kas/nec_terrain for the last ideas on how recovery and boot images should look like and the repartitioning
So, all questions regarding all the above should be asked in that thread as they are off-topic here.
For more general questions regarding the present rom, programs to disable, features and current bugs/oddities, please, see
http://forum.xda-developers.com/general/help/q-nec-terrain-discussion-t3162070
Thanks for understanding the thread aim and welcome to development!

Found this CWM recovery creator online. Apparently you can just upload the recovery img that comes with a phone and it will generate/build a recovery based on that. Worth a try?
EDIT: Here's the link. Apparently it is necessary for some phones to upload additional files to get the recovery to work properly. I'll look into it when I start to build this thing
https://builder.clockworkmod.com/
Sent from my LG-D415 using XDA Forums

alright......so ADW launcher is very very unstable with this ROM. Basically spontaneous reboot every 30min or so.
I need 5 panels, and the stock launcher can add them, but it always make the second panel default, which is very annoying.
So which launcher do you guys prefer?

Have I found?
Unfortunately this builder does not spit output ...
I got a strong impression the Terrain is reduced CasioCommando with qwerty. @MrMEEE, I suggest to investigate this direction. The later phone is reported to have both: custom roms and custom kernel. xda has developments on this.
This guess is NOT because NEC is Casio, this is because I found that both phones use for some unknown device the so called ktrc_driver.ko kernel module and the only device apart from Terrain which I could spot by google is CasioCommando. Then, of course, accounting that NEC is Casio I make this conclusion.
Also the boot of Terrain contains commands and even kernel modules references that do not exist. I have a gut feeling that devs were in rush and just were porting some system from another phone.
EDIT: I found a binary custom recovery for commando and so far it is the ONLY recovery which comes to some graphical image! I learned that graphics is device-dependent and presence of some colored points suggests that the graphics driver is correct. One just need to adjust the resolution ... This supports my theory that commando may be the prototype for the kernel.
Will try also to look into all of that.

alex-kas said:
Unfortunately this builder does not spit output ...
I got a strong impression the Terrain is reduced CasioCommando with qwerty. @MrMEEE, I suggest to investigate this direction. The later phone is reported to have both: custom roms and custom kernel. xda has developments on this.
This guess is NOT because NEC is Casio, this is because I found that both phones use for some unknown device the so called ktrc_driver.ko kernel module and the only device apart from Terrain which I could spot by google is CasioCommando. Then, of course, accounting that NEC is Casio I make this conclusion.
Also the boot of Terrain contains commands and even kernel modules references that do not exist. I have a gut feeling that devs were in rush and just were porting some system from another phone.
EDIT: I found a binary custom recovery for commando and so far it is the ONLY recovery which comes to some graphical image! I learned that graphics is device-dependent and presence of some colored points suggests that the graphics driver is correct. One just need to adjust the resolution ... This supports my theory that commando may be the prototype for the kernel.
Will try also to look into all of that.
Click to expand...
Click to collapse
Probably explains why we have an HDMI selector in the build.prop, huh...
But wow, that's an astounding discovery! Never would have guessed NEC = Casio. I believe there are 2 Casio Commandos, I assume you are referencing the newer one?
Sent from my LG-D415 using XDA

alex-kas said:
Unfortunately this builder does not spit output ...
I got a strong impression the Terrain is reduced CasioCommando with qwerty. @MrMEEE, I suggest to investigate this direction. The later phone is reported to have both: custom roms and custom kernel. xda has developments on this.
This guess is NOT because NEC is Casio, this is because I found that both phones use for some unknown device the so called ktrc_driver.ko kernel module and the only device apart from Terrain which I could spot by google is CasioCommando. Then, of course, accounting that NEC is Casio I make this conclusion.
Also the boot of Terrain contains commands and even kernel modules references that do not exist. I have a gut feeling that devs were in rush and just were porting some system from another phone.
EDIT: I found a binary custom recovery for commando and so far it is the ONLY recovery which comes to some graphical image! I learned that graphics is device-dependent and presence of some colored points suggests that the graphics driver is correct. One just need to adjust the resolution ... This supports my theory that commando may be the prototype for the kernel.
Will try also to look into all of that.
Click to expand...
Click to collapse
If you are correct, then the kernel source is available here:
http://www.casiogzone.com/us/download/index.html
I'll look into it..

GPL or not GPL?
Citation from http://wiki.cyanogenmod.org/w/Doc:_porting_intro:
"The manufacturer or vender of any device using Android will minimally need to make the source code available for all GPL components upon request, including (and especially) the kernel. You definitely want to request a copy of the kernel source and keep it handy."
Can anyone clarify the tedious question in the subject? I mean, does running android implies gpl on kernel? Can anyone (NEC, ATT, Qualcom) hide the source and what the conditions should be then? Can they have proprietary blobs in the kernel?
Weird

alex-kas said:
Citation from http://wiki.cyanogenmod.org/w/Doc:_porting_intro:
"The manufacturer or vender of any device using Android will minimally need to make the source code available for all GPL components upon request, including (and especially) the kernel. You definitely want to request a copy of the kernel source and keep it handy."
Can anyone clarify the tedious question in the subject? I mean, does running android implies gpl on kernel? Can anyone (NEC, ATT, Qualcom) hide the source and what the conditions should be then? Can they have proprietary blobs in the kernel?
Weird
Click to expand...
Click to collapse
Android runs on a standard Linux kernel which is GPL covered. Android is really just a Java VM inside of a Linux kernel I believe. So yes, Android kernel IS Linux kernel so therefore it would be GPL covered (thanks for the explanation @Nardholio )
They understand GPL. Anything based on the Linux Kernel must have the source released, so AFAIK there is no "proprietary" in a Linux Kernel... however that is just my understanding and if I am wrong someone please correct me. If they put "proprietary" code in the kernel and try to use that as an excuse to not release it, I say "Too bad, that's not an excuse, since you understood GPL when you built the kernel but are refusing to follow it. Guess what, now you have to release the kernel AND your "proprietary" software! LOL!!!"
Sent from my LG-D415 using XDA

I posted this in the wrong thread. Long story short I found someone interested in helping enforce the GPL for the Terrain but I don't own one. I need someone who owns a Terrain (preferably directly bought from AT&T or NEC) and who has already requested kernel source and either received no response or a refusal (I used the feedback form on NEC's website and got a polite refusal a few days later but I don't own one)

Nardholio said:
I posted this in the wrong thread. Long story short I found someone interested in helping enforce the GPL for the Terrain but I don't own one. I need someone who owns a Terrain (preferably directly bought from AT&T or NEC) and who has already requested kernel source and either received no response or a refusal (I used the feedback form on NEC's website and got a polite refusal a few days later but I don't own one)
Click to expand...
Click to collapse
I own a Terrain, and have gotten a refusal from NEC support...
What do you have in mind???
---------- Post added at 12:21 PM ---------- Previous post was at 12:19 PM ----------
Dear Mr. Martin Juhl,
Thank you for contacting NEC.
This is in regards to your email about the kernel of the NEC Terrain phone. You may check the kernel version and build number of the device on the phone itself. We do not have the source code of the device nor release them.
Please feel free to email us at [email protected] or call our toll free Customer Service number (1-800-637-5917) if you have any additional questions.
Your reference number for this inquiry is: 150727-000011
Thank you again for taking the time to write.
Sincerely,
NEC Customer Support

MrMEEE said:
I own a Terrain, and have gotten a refusal from NEC support...
What do you have in mind???
---------- Post added at 12:21 PM ---------- Previous post was at 12:19 PM ----------
Dear Mr. Martin Juhl,
Thank you for contacting NEC.
This is in regards to your email about the kernel of the NEC Terrain phone. You may check the kernel version and build number of the device on the phone itself. We do not have the source code of the device nor release them.
Please feel free to email us at [email protected] or call our toll free Customer Service number (1-800-637-5917) if you have any additional questions.
Your reference number for this inquiry is: 150727-000011
Thank you again for taking the time to write.
Sincerely,
NEC Customer Support
Click to expand...
Click to collapse
Sweet. PM me your email address and I will hand off my communication with the SF Conservancy to you. Just saying you can go to kernel.org and download the Linux kernel is NOT a sufficient response. They need to provide full source to boot the device (including board files, device drivers, any in kernel firmware, and build scripts)

YOU WILL NOT BELIEVE!
http://nec-mobilecom.co.jp/gpl/w/list/NEC_TERRAIN.html
I pressed NEC to deliver it. Have no time to check right away the integrity. Also, I have some problem downloading from CAF (I'm in a place where git is blocked). Maybe will ask someone to help (re-download to an http store).

alex-kas said:
YOU WILL NOT BELIEVE!
http://nec-mobilecom.co.jp/gpl/w/list/NEC_TERRAIN.html
I pressed NEC to deliver it. Have no time to check right away the integrity. Also, I have some problem downloading from CAF (I'm in a place where git is blocked). Maybe will ask someone to help (re-download to an http store).
Click to expand...
Click to collapse
Well sh*t... Never thought this would happen in a bazillion years.
Yet if you read their terms and conditions, it states you aren't allowed to reversed engineer their software to a "human readable form". Is this nullified by GPL, or can we be in trouble for using their kernel source for a ROM?
EDIT: Just downloaded myself a copy of the kernel.
Sent from my SAMSUNG-SGH-I747 using XDA Free mobile app

I do not care. I asked, nec gave the source publicly. no reverse engineering. Now we all gpl. My point.
Sent on the go

I don't think they would care as long as you are not reselling it...... you aren't, right?
Sent from my SGH-I547C using XDA Free mobile app

Darn, I was gonna set up a booth in front of my house and be one of those loud, obnoxious salesmen

hey mister.... I'mer gonna take two them kernel if ye can cut me a deal....
jasonmerc said:
Darn, I was gonna set up a booth in front of my house and be one of those loud, obnoxious salesmen
"GEEEETTT'CHA KERNEL SOURCE HEEEEEEAAA! TERRAIN KERNEL SOURCE, ONLY FIIIIIVE DOLLAHS! MAKE YOURSELF A ROM! CUSTOM RECOVERY! FIIIIIIVE DOLLAHS!"
Click to expand...
Click to collapse

First experiments
Results for the moment are like this:
1. The kernel does compile with the modified files with no compilation issues at all.
2. The kernel is smaller then the stock one.
3. The recovery.img produced by full caf build does boot but halts at the android image with the red triangle. Or perhaps does not halt but I did not come with a key combination to proceed.
PROS: graphics works
4. The kernel being stuffed into original boot image does boot, shows boot animation WITHOUT boot sound and then not surprisingly goes to a bootloop flashing the home screen
CONS: seems that sound is not here yet
5. The bootloop was broken using
adb reboot recovery
which means that adb does function
6. I did not try to flash the whole image to check whether bootloops are due to somewhat above the kernel (aka this kernel doesn't work with the stock soft).
Overall, we have a messy kernel source which however at least boots to init, communicates with adb and has graphics.
I'm free for a team project: who is in?
Technically, to make this particular caf manifest I had to install a virtual ubuntu 10.04 x64. My native machine failed to compile. I have gcc 4.9. Even the downgrade to 4.4.7 did not do the job. And for some reason I failed to compile gcc 4.4.3 for my machine. ubuntu 10.04 has gcc 4.4.3. But there you need to install some stuff and update the present there python (it is just 6.5 there but still some update exists still inside 6.5 and it fixes somewhat causing a peculiar error during the build). Also, be aware: you cannot compile on a virtualbox share: mmap does not work for security reasons. You must arrange ALL inside the virtual machine. After the build it is about 53GiB. So, the vm-drive should be at least 60 giga.

alex-kas said:
Results for the moment are like this:
1. The kernel does compile with the modified files with no compilation issues at all.
2. The kernel is smaller then the stock one.
3. The recovery.img produced by full caf build does boot but halts at the android image with the red triangle. Or perhaps does not halt but I did not come with a key combination to proceed.
PROS: graphics works
4. The kernel being stuffed into original boot image does boot, shows boot animation WITHOUT boot sound and then not surprisingly goes to a bootloop flashing the home screen
CONS: seems that sound is not here yet
5. The bootloop was broken using
adb reboot recovery
which means that adb does function
6. I did not try to flash the whole image to check whether bootloops are due to somewhat above the kernel (aka this kernel doesn't work with the stock soft).
Overall, we have a messy kernel source which however at least boots to init, communicates with adb and has graphics.
I'm free for a team project: who is in?
Technically, to make this particular caf manifest I had to install a virtual ubuntu 10.04 x64. My native machine failed to compile. I have gcc 4.9. Even the downgrade to 4.4.7 did not do the job. And for some reason I failed to compile gcc 4.4.3 for my machine. ubuntu 10.04 has gcc 4.4.3. But there you need to install some stuff and update the present there python (it is just 6.5 there but still some update exists still inside 6.5 and it fixes somewhat causing a peculiar error during the build). Also, be aware: you cannot compile on a virtualbox share: mmap does not work for security reasons. You must arrange ALL inside the virtual machine. After the build it is about 53GiB. So, the vm-drive should be at least 60 giga.
Click to expand...
Click to collapse
I haven't code in years, but I want to help out. I am ok with scripting and also able to load stuff to my terrain for testing. Let me know.

Progress Inquiry
Happy New Year!
Just wondering if any progress has been made for this particular device. I understand we all have lives and things get in the way, or interests wither away, its just an inquiry. I'd love to see an update to this device, even up to kitkat if that was possible. Any suggestions on how to recruit developers whom may be interested in the challenge of custom rom development for this device?

Compiled and executed new zero day exploit(CVE-2019-2215) on my G965U1

Exploit is here: https://bugs.chromium.org/p/project-zero/issues/detail?id=1942#c7
On my S9 Plus the exploit never completes(see attached screenshot). I'm running the Sept 2019 patch that is supposed to be exploitable.
Also attached is the exploit compiled for arm64 using the Linux version of Google's Android NDK: https://developer.android.com/ndk/downloads/index.html
Made the arm64 toolchain with: ./android-ndk-r20/build/tools/make_standalone_toolchain.py --arch arm64 --install-dir ./arm64
It compiled properly then I copied it to /data/data/jackpal.androidterm, "chmod -x poc" to make it executable from Terminal Emulator: https://play.google.com/store/apps/details?id=jackpal.androidterm&hl=en_US
My guess is that the S9 Plus is not vulnerable or I did something wrong in the above steps.

I tried your build on my Pixel XL on Android P, and it locks the phone up a while, system UI crashes, and then the phone dies...I may need to build myself with a different NDK version?
If it were to work I could root and/or write a bit to a certain partition to allow OEM unlock.

Can you post a screenshot of the output before it dies. If not, can you post what output you get before it crashes?

bads3ctor said:
Exploit is here: https://bugs.chromium.org/p/project-zero/issues/detail?id=1942#c7
On my S9 Plus the exploit never completes(see attached screenshot). I'm running the Sept 2019 patch that is supposed to be exploitable.
Also attached is the exploit compiled for arm64 using the Linux version of Google's Android NDK: https://developer.android.com/ndk/downloads/index.html
Made the arm64 toolchain with: ./android-ndk-r20/build/tools/make_standalone_toolchain.py --arch arm64 --install-dir ./arm64
It compiled properly then I copied it to /data/data/jackpal.androidterm, "chmod -x poc" to make it executable from Terminal Emulator: https://play.google.com/store/apps/details?id=jackpal.androidterm&hl=en_US
My guess is that the S9 Plus is not vulnerable or I did something wrong in the above steps.
Click to expand...
Click to collapse
i get same output on my g975u and n976v on stock firmware. I believe it means wont work for us lol

elliwigy said:
i get same output on my g975u and n976v on stock firmware. I believe it means wont work for us lol
Click to expand...
Click to collapse
The exploit writers said that these phones are vulnerable:
1) Pixel 2 with Android 9 and Android 10 preview
2) Huawei P20
3) Xiaomi Redmi 5A
4) Xiaomi Redmi Note 5
5) Xiaomi A1
6) Oppo A3
7) Moto Z3
8) Oreo LG phones (run same kernel according to website)
9) Samsung S7, S8, S9
I was hoping my S9 Plus was vulnerable but I guess with your output being the same as mine.....we both will not get root
For ****s and giggles I tried for a few hours to hack the code to get it to continue the exploit without success.

I got the same 0x1000 (instead of correct 0x2000) output on my LG V20. I played around and changed WAITQUEUE_OFFSET to 0x90 (which isn't correct, but I was just experimenting), ran it, and then it forced a reboot of the system. That's some progress, since an unprivileged app shouldn't be able to force a reboot, so there may still be a vulnerability there to be exploited.

arpruss said:
I got the same 0x1000 (instead of correct 0x2000) output on my LG V20. I played around and changed WAITQUEUE_OFFSET to 0x90 (which isn't correct, but I was just experimenting), ran it, and then it forced a reboot of the system. That's some progress, since an unprivileged app shouldn't be able to force a reboot, so there may still be a vulnerability there to be exploited.
Click to expand...
Click to collapse
i think you're on the right track. you're probably causing a kernel panic which is causing the shut down. offsets have to be updated to be kernel specific so that's why you're crashing. can you post the output you saw before the crash? crash dump if you have one?

bads3ctor said:
My guess is that the S9 Plus is not vulnerable or I did something wrong in the above steps.
Click to expand...
Click to collapse
What does
Code:
uname -a
show on your device? The poc depends on the size of struct binder_thread, and as far as I can tell digging through kernel source, at some point that size was changed. So if the S9 uses a different version of the kernel, the exploit may need modifications.

arpruss said:
So if the S9 uses a different version of the kernel, the exploit may need modifications.
Click to expand...
Click to collapse
Any suggestions will be helpful. Attached is a screenshot of the current kernel version as of the Sept 2019 update. I can easily compile the exploit with any changes to the buffer.

Got same 0x1000 on Samsung Oreo 8.0, arm64, kernel 3.18.14-13712092-*, august security patch 2019.

error Lge q710al

Has anyone tried this on the SM-G965U yet?
Update:
I tried and same results as the OP.

Phantisy said:
Has anyone tried this on the SM-G965U yet?
Update:
I tried and same results as the OP.
Click to expand...
Click to collapse
From: https://github.com/marcinguy/CVE-2019-2215/
If writev is returning 0x1000 it means the timing is off, the wait queue offset is off, the kmalloc allocation in the writev function isn't the same as the freed binder_thread, or your kernel isn't vulnerable.

bads3ctor said:
From: https://github.com/marcinguy/CVE-2019-2215/
If writev is returning 0x1000 it means the timing is off, the wait queue offset is off, the kmalloc allocation in the writev function isn't the same as the freed binder_thread, or your kernel isn't vulnerable.
Click to expand...
Click to collapse
How would we go about finding these offsets? I think it may be possible to use this exploit for our device, except that the poc may need to be tuned to samsung kernel and its offsets.

bads3ctor said:
From: https://github.com/marcinguy/CVE-2019-2215/
If writev is returning 0x1000 it means the timing is off, the wait queue offset is off, the kmalloc allocation in the writev function isn't the same as the freed binder_thread, or your kernel isn't vulnerable.
Click to expand...
Click to collapse
According to Samsung, it is vulnerable. Guess we just need to figure out what is causing it not to work.

Phantisy said:
According to Samsung, it is vulnerable. Guess we just need to figure out what is causing it not to work.
Click to expand...
Click to collapse
link to the site where it is said to be confirmed? i want to double check before i waste any time

elliwigy said:
link to the site where it is said to be confirmed? i want to double check before i waste any time
Click to expand...
Click to collapse
According to the project zero post of the cve, s7, 8 and 9 are listed under the vulnerable devices.
https://bugs.chromium.org/p/project-zero/issues/detail?id=1942

f41lbl0g said:
According to the project zero post of the cve, s7, 8 and 9 are listed under the vulnerable devices.
https://bugs.chromium.org/p/project-zero/issues/detail?id=1942
Click to expand...
Click to collapse
yea, i saw s9 but not n9 tho lol who knows
Sent from my SM-N976V using Tapatalk

Something different!
From: https://github.com/arpruss/cve2019-2215-3.18
I compiled poc98-overwrite-pipe.c which gave me the 0x1000 failure but poc98.c succeeded in overflowing the kernel buffer on my S9+(see attached screenshot).
I'm not a kernel hacker so that's as far as I can get. Seems really close to being able to su to root. I attached poc98 compiled for arm64 so others can test it.
Edit: After reading the code, the actual exploit function is commented out so I'm going to take a crack at editing it but maybe someone with some kernel experience can take a look. I doubt I can make it work...I'm just a lowly PERL hacker!
Edit2: https://github.com/arpruss/cve2019-2215-3.18 seems to be a work in progress. New code was just uploaded. I think we have to make the exploit work on our kernel version.
Edit3: I re-added clobber_addr_limit(); to poc98.c and recompiled. Running it doesn't get an exploited kernel probably because it's written for a different kernel. That's about the extent of my kernel knowledge so we need a kernel hacker to get root.

bads3ctor said:
From: https://github.com/arpruss/cve2019-2215-3.18
I compiled poc98-overwrite-pipe.c which gave me the 0x1000 failure but poc98.c succeeded in overflowing the kernel buffer on my S9+(see attached screenshot).
I'm not a kernel hacker so that's as far as I can get. Seems really close to being able to su to root. I attached poc98 compiled for arm64 so others can test it.
Edit: After reading the code, the actual exploit function is commented out so I'm going to take a crack at editing it but maybe someone with some kernel experience can take a look. I doubt I can make it work...I'm just a lowly PERL hacker!
Edit2: https://github.com/arpruss/cve2019-2215-3.18 seems to be a work in progress. New code was just uploaded. I think we have to make the exploit work on our kernel version.
Edit3: I re-added clobber_addr_limit(); to poc98.c and recompiled. Running it doesn't get an exploited kernel probably because it's written for a different kernel. That's about the extent of my kernel knowledge so we need a kernel hacker to get root.
Click to expand...
Click to collapse
could you attach the latest version of your poc? (edit 3)

General (OPEN DEV) BruteRoot - A collection of Root Tactics (Possibly Force Bootloader unlock on NA Samsung S22?)

Devices & Linux Versions I or other Testers have Successfully Gained Root on:
(Likely All) MTK CPU Based Android devices UP TO 11 (Maybe 12? I haven't tested) (I.e LG, Sony, Select Samsung devices)
Android Devices with LINUX KERNEL VERSIONS - 5.8 - 4.14 - Maybe More? (Needs Testing)
-THIS GUIDE IS NOT BEGINNER FRIENDLY - BASIC UNDERSTANDING OF PYTHON, UNIX/LINUX ETC WILL BE REQUIRED!-​
If you have been holding off updating your device, well here's some good news, your device may still be vulnerable to a method to gain root access (and subsequently, possibly the ability to edit Build.prop and therefore allow the ability for OEM unlocking on USA based devices.) <- correct me if I'm wrong, but this should be possible, and once done, should persist across updates, correct?
As of the time of writing this, there is not currently a simplified APK method, but, still this process is relatively straight forward.
Alot of the methods used HAVE been patched from what I understand, but there have got to be plenty of devices out there still which are not updated. This project aims to compile all current, former and future Root methods into an APK that will do all the leg-work. If its able to find a working method, the GUI will pop a root shell for the end user. This SHOULD work, regardless of the setting of the "OEM UNLOCK" option in the dev options. A bypass, essentially.
Regardless, The project linked below uses a myriad of known exploits & vulnerabilities and looks to find one that will work.
Methods used are:
Nearly all of GTFOBins
Writeable docker.sock
CVE-2022-0847 (Dirty pipe)
CVE-2021-4034 (pwnkit)
CVE-2021-3560
It'll exploit most sudo privileges listed in GTFOBins to pop a root shell, as well as exploiting issues like a writable docker.sock, or the recent dirty pipe (CVE-2022-0847). More methods to root will be added over time too.
There is also an alternative (Dirty Pipe) injection method the uses @topjohnwu 's Magisk , this should be implemented into the apk. See this Github repo, Here.
I would imagine this could be implented in a way to target devices that have stopped being supported for updates, aswell, that do not have TWRP, such as the SM-T307U.
One big note - I am betting there are still ALOT of devices that are in inventory at retailers that remain on the vulnerable OS. So keeping that in mind, I'd say this is worth building.
What needs to be done:
TESTING!
Build APK - HELP NEEDED WITH THIS!
Deploy
Main Goals:
Get bootloader unlock ability for devices normally not unlockable (I.e North American Samsung Galaxy S22, Etc)
Above can be achieved by getting temp root via methods detailed here or otherwise, then editing build.prop, altering the below settings (The settings may be worded differently or simply not present at all, depending on device and Firmware version):
sys.oem_unlocking_allowed to 1
ro.oem_unlock_supported to 1 (most devices are set to 1 by default.)
ro.boot.flash.locked to 0
ro.secure to 0
ro.debuggable to 1
I think there may be one or two more that pretaint to Flash.locked. I.e flash.locked.other--or something very close.
Locally, gain temp root (System preferred, but any root will do.) on as many device types as possible.
Give device control back to end user.
Stay up-to-date on new exploits for root access & update apk accordingly.
STAY ETHICAL!!!! This is, in the end, a research project. Meaning all work preformed in the context of this project could result in a damaged or bricked device. By participating in this project you acknoledge these risks and accept them, and agree to not hold me, XDA, or anyone else responsible if you do some dumb ****. - k0mraid3
Github Project link: HERE for my fork & HERE for the original project.
My fork will incorporate the original project, as well as other found root access methods, such as the magisk injection method mentioned above - my repo is mainly used as a hub for the APK's dev - i don't have enough time to work on it at the moment but all are welcome to help.
July 15th 2022 (UPDATE) (SAMSUNG DEVICES ONLY): A new Escalation method has been found via the Galaxy app store (Versions BEFORE Galaxy Store 4.5.41.8). No details known yet, but it is said to be very easy. See CVE-2022-33708 (July132022). Unknown if downgrading the app to 4.5.0.0 will enable the method again or not.
Cred: liamg
One method to run Traitor on device - Thanks @DevinDking for sharing this.
Steps to get script on phone.
//
#!/bin/sh
set -e
dir=/data/local/tmp
adb=${adb:-"adb"}
$adb push traitor ${dir} //This puts file on phone make sure to run the terminal where its located
$adb shell chmod 755 ${dir}/traitor"
//
Now to run script start a new terminal
//
adb shell
#!/bin/sh
set -e
dir=/data/local/tmp
adb=${adb:-"adb"}
${dir}/traitor //script opens
//
But I assume this wouldn't work right, and isn't right.
Idk trying my best here xD
Click to expand...
Click to collapse
Tools & References:
Linux (and Android, FTMP) Privilege Escalation Techniques
Dirty Pipe - Magisk Injection
Traitor - Main Repo
GTFOBins
CVE Database (Public Database for exploits, vulnerabilities, etc.)
Windows Subsystem For Linux (Great for Dev)
ADB App Control - Cred @Cyber.Cat
Leaked Samsung Source Code ***Mod Edit: Link Removed***
Crontab Root Template script (File Attached - you still must edit crontab with "crontab -e" and point it to this file, see comments for guide, I will add one to post later)
Android Image Kitchen Used to create custom image's etc.
MTK Client
MTK Meta Utility (Source-???)
Will add more as time goes on and more found.
Interesting Attack vectors -
GFX Componets of a system.
Issues with Linux itself (i.e Dirty Pipe)
Privilage escalation via any means (I.e GTFOBins)
unprotected system process - Hijack them if possible (i.e RILService Mode, and a wide range of other OEM apps left on devices after ship)
7/24/22 - Samsung, LG & Other OEM's obfuscating (Intentionally Hiding) Fastboot and ADB Bootloader interfaces on PC
So over the last week or so i dived head first into USB Dev - ill save you the time and sum it up.
Vendors and OEM's are actively obfuscating the USB connection between your smartphone and the PC to keep you from Rooting. As far as im aware, there is no Universal way to fix this as each OEM screws with the USB drivers differently. THIS needs to be a point of focus for the rooting community. However, i have found a few tools for Dev if you wish to screw with this. (I'll upload them tonight)
7/24/22 - MTK (MediaTek) based Exploits
I Will try to compile a few methods for FORCING Bootloader Unlock on MTK based Devices as well as a way for manipulating said devices. I will attach two tools to this thread, these tools are EXTREMELY POWERFUL and can completely **** up your device. When i say REALLY F*CK UP your device, I mean to the point you cant even access recovery, Download OR bootloader mode. I'm Talking a blank DEAD device. So use with caution.
With that said, lets talk about the tools. You will need a basic understanding of Python to make use of MTK Client
First up, we have MTK Meta Utility (Currently Version 44) (Download Below)
Next we have MTK Client (Github Link)
So what can you do? Well, you can crash the Preloader to Brom with MTK Meta Utility while at the same time using MTK Client to send any payload you like to the device via Fastboot.
I know, vague right now, but ill add detail over the coming days.
I will continue to update the below list as new methods are discovered.
If you find Guides, tutorials or new exploits, please link them in the comments so I can include them in future development!
Telegram Channel: Here.
Information on Vulnerabilities, exploits & methods - CVE-2022-0847 (Jfrog) - The Story Of "Dirty Pipe" - XDA - Dirty Pipe - PWNKIT (CVE--2021-4034) - CVE-2021-3560 - Docker Breakout / Privilege Escalation - CVE-2022-33708 (July132022) - CVE-2022-33701 (July122022) - CVE-2022-22268 (Unlock Knox Guard with DEX) (JAN2022) - MTK Client -
Dev Team & credit to -
@topjohnwu - LiamG - @wr3cckl3ss1 - bkerler -
UPDATED - 7/29/22

There is also a new vulnerability exploit by Zhenpeng Lin that allows for privilege escalation on Pixel 6 and and Galaxy S22 devices running 5.10 kernel.

Don't update... destroyer of worlds

I feel like I'm missing something because wouldn't their normally be a million responses of hype, hope and nay-saying going on here? Has this been shot down already?

olivehue512 said:
I feel like I'm missing something because wouldn't their normally be a million responses of hype, hope and nay-saying going on here? Has this been shot down already?
Click to expand...
Click to collapse
Lol, everybody already updated the patch

blackhawk said:
Lol, everybody already updated the patch
Click to expand...
Click to collapse
This is just sad panda. I'm gonna skip next update anyways unless it comes with an actual other phone that is BL unlocked. I feel like everyone wants this so bad it can't be that far out before it happens.
Does the Magisk injection method work after July patch? I was reading through the work they did to get it done. Props to those guys.

sierratango88 said:
There is also a new vulnerability exploit by Zhenpeng Lin that allows for privilege escalation on Pixel 6 and and Galaxy S22 devices running 5.10 kernel.
Click to expand...
Click to collapse
Has it got a fancy number yet?! Eager to try this!!!! Maybe it can be put in with the others.

olivehue512 said:
I feel like I'm missing something because wouldn't their normally be a million responses of hype, hope and nay-saying going on here? Has this been shot down already?
Click to expand...
Click to collapse
Well, because they are known and accepted vulnerabilities and exploits. A very few have even been marked as "WONTFIX" such as the TTY method.

olivehue512 said:
This is just sad panda. I'm gonna skip next update anyways unless it comes with an actual other phone that is BL unlocked. I feel like everyone wants this so bad it can't be that far out before it happens.
Does the Magisk injection method work after July patch? I was reading through the work they did to get it done. Props to those guys.
Click to expand...
Click to collapse
Honestly, it's worth a shot but I doubt it.
One of the goals behind building the APK compilation of all these different tactics is to enable the end user to "give it a shot" easily on different devices, without having to know how to run all of this manually. Basically imagine an apk that just tries all the above methods and if ones successful the gui will pop a root shell open. From there, the possibilities are endless. Edit Build.prop, SELinux, Verity, Etc.

FYI even you applied the July update, seems like the Kernel version is still from June 21st, is still 5.10xxxx so we could still benefit from this exploit. Very interested in how we can get root here in the US.

K0mraid3 said:
Has it got a fancy number yet?! Eager to try this!!!! Maybe it can be put in with the others.
Click to expand...
Click to collapse
There hasn't been a CVE assigned to it yet that I am aware of.

xgerryx said:
FYI even you applied the July update, seems like the Kernel version is still from June 21st, is still 5.10xxxx so we could still benefit from this exploit. Very interested in how we can get root here in the US.
Click to expand...
Click to collapse
Go to the Github linked and try the different methods, see if you can pop a root and nano build.prop to allow OEM unlocking?

sierratango88 said:
There hasn't been a CVE assigned to it yet that I am aware of.
Click to expand...
Click to collapse
GREAT news for us! LEts get this temp root! lol

Looks like another new one! CVE-2022-33708

Another Samsung Exclusive - CVE-2022-33701

So, ive just spent my entire friday and friday night MANUALLY testing all the GTFOBins & reproducing some of the newer CVE's on Samsung Galaxy S7 Edge (Android 9) -Galaxy tab A 8.4, (Android 11), Galaxy S21 & S22 (Android 12) --- A little bit of progress made. Again, ill need someone with better working knowledge on APKs & Java to really move forward. All i can say so far, is this all must be awk for sammie, because cronie is looking promising
"crontab -e"

interesting find. not "New" but still new-ish enough some may be able to use. CVE-2022-22268 (Unlock Knox Guard with DEX)

New to this all but not rooting. Anyone recommend a way tutorial on how to try these methods on Win 11?

I don't have a deep understanding of Linux, I have tried, debian and unbuntu. I get traitor to run but it's detecting the Linux kernel and not my phones. How can I get the program to search for vulnerability on my phone not my Linux. I would love a more in depth guide and I'd love to give feedback on methods.

DevinDking said:
I don't have a deep understanding of Linux, I have tried, debian and unbuntu. I get traitor to run but it's detecting the Linux kernel and not my phones. How can I get the program to search for vulnerability on my phone not my Linux. I would love a more in depth guide and I'd love to give feedback on methods.
Click to expand...
Click to collapse
i had the same issue but cant remember how i worked that out. let me see if i can find out what i did on win11

Can You Get Root With A MITM Attack?

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.